WO2003040941A1

WO2003040941A1 - Method and apparatus for automating internet interactions

Info

Publication number: WO2003040941A1
Application number: PCT/US2002/030692
Authority: WO
Inventors: Jai Rawat; Silvia Doundakova; Vladimir Fridman; Rajalakshmi Subramanian; Geoffrey G. Chemmannoor; Kesapragada Shankar; Subbu Gandrala; Simon Waddington; Benedict T. S. Gladstone; Oswald D'sa; Julian Gordon; Renuka Kulkarni; Vijayasankar Dhanapal; Srinivas Gubbala; Santhosh Raman; Rajiv Anand
Original assignee: America Online Incorporated
Priority date: 2001-10-09
Filing date: 2002-09-26
Publication date: 2003-05-15

Abstract

A method and apparatus for implementing recorded data for automating interactions which occur across the Internet includes storing data at a central Web server adapted for maintaining a database. Responsive to a program script requesting data, computer program code at the central Web server selectively extracts stored data from the database, manipulates the data in accordance with the request, and supplies the manipulated data in a desired format. A method and apparatus for automating capture of electronic data provide a user with an effective universal Internet identity and e-mail address, comprehensive e-mail filtering and forwarding services, and e-receipt identification and data extraction. Detailed user e-mail preferences data stored at a central server may be selectively altered such that incoming correspondence is redirected in accordance with the user's preferences. Computer program code at the central server parses incoming e-mail header information and data content, selectively extracts data from identified types of correspondence, and forwards extracted data in accordance with user preferences data. Additional computer program code may manipulate the extracted data in accordance with format requirements and display the manipulated data to a user in a desired format.

Description

METHOD AND APPARATUS FOR AUTOMATING INTERNET INTERACTIONS

BACKGROUND OF THE INVENTION Field of the Invention

The invention relates generally to the transmission of data during Internet browsing, parsing electronic correspondence. More particularly, the invention relates to a method and apparatus for implementing recorded data for automating interactions and transactions which occur on the Internet; for recognizing certain selected forms of electronic correspondence; and for automating extraction, organization, and display of parsed data.

Description of the Related Art

Presently, many computer users primarily employ Internet browser and mail editor applications for accessing the World Wide Web (WWW, or the Web) and for corresponding via electronic mail (e-mail). The typical browser serves as the means by which a user is enabled to navigate from site to site on the Web, and further serves as the interface through which the user is enabled to interact with those sites by accessing the information content and various services provided. The typical mail editor enables the user to engage in digital correspondence, i.e. sending and receiving e-mail.

The capabilities of browser and mail editor applications can vary greatly depending upon the type of terminal and the operating system used. For example, while versions of these types of applications installed at home computers or office , workstations, which typically employ graphical user interfaces (GUIs) and large display monitors, may be capable of exploiting rich text formats and high resolution graphics, the versions of the same applications which are typically installed on portable wireless devices may be much more restricted in terms of graphic resolution and display area.

When a user is employing a device having a small keypad and using a browser of limited capabilities, navigation and data input can be tedious. In the case where the user is connected to the Internet or other network through an Internet-capable wireless telephone or Personal Digital Assistant (PDA), for example, entering a long Uniform Resource Locator (URL) for a desired Web site, typing a case-dependent e- mail address, or providing any other detailed information in alpha-numerical characters with a limited keypad is often difficult.

During any given session of Internet exploration, sometimes known as "Web surfing," a user may encounter one or more sites which require data input, in the form of registration and login data, before the full capabilities of the site can be accessed. In fact, sites requiring registration and login are becoming more prevalent on a daily basis. Web sites engaged in electronic commerce (e-commerce), for example, typically require registration before purchases can be made or items can be placed up for auction by a particular user. As another example, Web sites which host e-mail services necessarily require registration and login to deliver incoming correspondence to the correct recipient.

The registration process may vary in complexity from the very simple matter of entering data into one or two fields, to the very complicated matter of providing a social security number, credit card expiration dates, and the like. In any event, a user must navigate to a site's registration page and complete a form by providing information required for registration.

As a practical matter, irrespective of the relative complexity of the registration procedure, the user is burdened with the task of recording or remembering the information provided. At a minimum, registration at any given Web site involves providing the site with a user name, or "login" name, and a password. This data is subsequently used by the site to identify the user each time the user logs in. Conversely, access to a particular account is denied or restricted if the proper account information is not entered at login.

In addition, the user must also keep a record of the sites with which the registration process has been completed or run the risk of having multiple accounts open at the same site inadvertently, which can lead to confusion. In the case where a user intends or prefers to have multiple accounts open at the same site simultaneously, it is still incumbent upon that user to maintain accurate records of user names and passwords in order to access the various accounts.

Even in the case where a user maintains meticulous records of all the requisite information, the correct user name and password information must be provided each time the site is accessed. Typically, a registered user of a particular Web site must navigate to that site's "login page" and complete a form by providing the necessary data in order to access the site's full functionality. In this regard, even accurate records are not useful if they are not accessible. When a user stores registration information conveniently near a home computer, for example, those records are not of value when that user is attempting to access an account from a mobile or wireless apparatus or from a computer at another location, such as an office, a library, or a Web cafe. Presently, because even portable and wireless devices are Internet- capable, a user may access the Web or e-mail accounts from virtually any building having telephone service or from any location where cellular or satellite communications are possible. Unless such a user commits numerous user names and passwords to memory, or endeavors always to keep written notes within reach, careful record-keeping practices can ultimately prove of limited utility.

Further, many Web sites request users to supply data through the process of filling out forms independently of any registration or login processes. A browsing user is often required to submit information such as mailing address, billing address, credit card information, or e-mail address. With Internet activity increasing and e- commerce growing at a fantastic rate, there is a continuing and escalating need for a convenient and efficient system for organizing a user's personal account information and, more importantly, implementing that information during Web browsing.

Such a system should take into account the fact that many users are presently accessing the Internet from multiple locations and multiple computer terminals or workstations, some of which may have small or limited-function keypads and lack sophisticated input devices and displays. Moreover, to provide maximum convenience and utility, a system organizing and implementing a user's account information should automate much of the interaction which is currently completed manually. Also in this general context, some systems have sought to make Internet transactions and interactions more convenient for users. Efforts are being directed toward automating registration and login procedures, establishing global (or Internet- wide) user identities, and creating universal e-mail addresses for users. Though successful with respect to simplifying various types of Internet transactions and thereby facilitating e-commerce, these systems have thus far failed to address a natural consequence of the increasing ease with which e-commerce may be conducted: an increase in e-commerce related e-mail correspondence, much of which may be in the form of electronic receipts (e-receipts).

For example, when a user places an order for the purchase of goods or services through electronic channels, the seller ("e-tailer") or service provider generally supplies an e-receipt subsequent to receiving the order and payment authorization. These e-receipts, electronic correspondence delivered to an e-mail account or address designated by the user, typically include relevant information concerning the transaction: the purchaser's name, shipping and billing addresses, and credit card information; the appropriate product identification, quantity, and unit price; an identifying order reference number; the order date; the shipping status; and so forth.

Information concerning a particular order is usually available for a limited time at the e-commerce site which hosted the transaction. Ordinarily, a user must provide the correct user name, password, and order reference number information each time that user desires to access order information at the host site. In this regard, even accurate records are not useful if they are not readily accessible; when a user stores information conveniently near a home computer, for example, or retrieves electronic correspondence using a particular computer terminal, those records will not be of value when that user is attempting to access an account from a mobile or wireless apparatus or from a computer at another location, such as an office, a library, or a Web cafe. Presently, since even portable and wireless devices are Internet-capable, a user may access the Web or e-mail accounts from virtually any building having telephone service or from any location where cellular or satellite communications are possible. Unless such a user commits an unwieldy amount of user name, password, and other account-specific information to memory, or endeavors always to keep written notes within reach, careful record-keeping practices can ultimately prove of limited utility.

Users may want access to e-commerce order information for a number of reasons. For example, whereas one user may simply be interested in checking the status of an order to determine if and when purchased goods have been shipped, another user may wish to cross-reference e-commerce order data with bank account data available on-line to determine if and when a particular payment, in the correct amount, has cleared the user's bank account.

As a user's e-commerce activity increases, that user becomes increasingly burdened with having to remember or to record more information, related not simply to user names and passwords for registered accounts, but also to specific order numbers and payment authorizations. Since, as noted above, accessing individual registered accounts can be tedious, some users attempting to organize e-commerce data prefer to rely upon e-receipts and shipping updates forwarded to a specified e-mail address from e-commerce vendors and service providers. While such reliance upon e-receipts and other correspondence can sometimes prove more convenient, to some degree, than repeatedly accessing the site which hosted the transaction, confusion may still prevail when various transactions are at different stages of completion, when a user wishes to access information from more than one computer terminal or wireless device, or when different correspondence is directed to different e-mail accounts. Logistically, keeping track of e-commerce activity through careful monitoring and organizing of incoming e-receipts can be just as difficult as tracking the status of on-line orders through independent login with the various host sites.

Though some systems currently in use, as noted above, are directed to simplifying some of the more tedious mechanisms associated with commercial activity on the Internet, such systems generally do not facilitate the collection and organization of the data generated by e-commerce activity and other electronic correspondence.

With Internet activity increasing and e-commerce growing at a fantastic rate, there is a continuing and escalating need for a convenient and efficient system of organizing a user's e-receipt information. Such a system should take into account the fact that many users are presently accessing the Internet from multiple locations and multiple computer terminals or workstations, some of which may have small or limited- function key pads and lack sophisticated input devices and displays.

SUMMARY OF THE INVENTION The invention addresses the foregoing and other shortcomings of conventional Internet communications and data transmission interactions by providing a method and apparatus for automating many of the tedious interactions which are required of a user during a typical Internet browsing session.

In one embodiment, the invention comprises storing a registered user's personal account information in a secure, encrypted central database which is accessible from any Internet-capable device with a single user name and password. For example, a user name and password may be stored in association with an account at a particular Web site, along with the Uniform Resource Locator, or URL, of that site's login page. For a second account at a second Web site, the user may have selected a different user name and a different password; this information, likewise, is stored in the central database, along with the URL for the login page of the second Web site. Upon login to the system of the present invention, the registered user has access to the full functional capabilities of the unique interface provided by the system, as well as any and all account information related to that user's various Web site specific accounts. Ideally, this system requires memorization of only a single user name and a single password, regardless of the number of specific accounts which are maintained at any of a plurality of different Web sites at any given time.

Specifically, the invention is related to a system provides an interface between the foregoing central database and the various Web sites visited by the user during the course of browsing the Internet. In one embodiment, a utility window or navigation bar may be appended to the user's standard browser navigation window, and may be used to interface with the system and to access its capabilities. In another embodiment, standard elements of a browser may enable a user to access the functional capabilities of the system directly. This embodiment may be particularly desirable for use in conjunction with text-based browsers, such as are employed by Personal Digital Assistants (PDAs) or Internet-enabled wireless telephones, for example. The programming scripts employed by the system, and invoked through the browser, automate many of the tasks ordinarily completed manually by the user.

According to one embodiment of the invention, a user's personal information stored in the central database is accessed by the system such that registration forms associated with opening an account may be completed automatically. As an example, the system may be adapted separately to maintain a vast database of common Web sites, including the URLs of their respective registration pages as well as the nature and format of their respective registration forms. Convenient hyperlinks may be offered to a user through the browser, for instance, upon login to the system such that if the user desires to register with a mapped Web site, the program code embodied in the system communicates with the proper site and completes the appropriate sections of the registration form without intervention on the part of the user. In addition, if a user desires to register with a Web site and independently navigates to the page containing the form, the system may be adapted to recognize that the user is attempting to create a registered account which has not previously been recorded, and may prompt the user to record the registration information if desired.

Further, the form filling feature of the invention is not limited to registration forms.

Many other types of forms exist in the Internet universe, and the invention is adapted to access recorded user data and to implement the same in filling virtually any type of form a user is likely to encounter. In particular, a common type of form which is filled on a regular basis is a login form. The system of the invention provides an automatic login procedure through which a user may be automatically logged in to a pre-existing registered account.

In accordance with this aspect of the invention, a user may login to a Web site or mail server quickly and easily without having to re-enter a user name and password at each subsequent visit. As noted above, the central database may store a specific user name and password associated with each and every account maintained by the user. When the user wishes to access a particular account at a specific Web site or mail server, the present invention allows the user to invoke program scripts at the central server which automate the login procedure. The central server navigates to the proper page or site, identifies the login form, accesses the appropriate user name and password information from the database, completes the form with the proper user data extracted from the database, and submits the form on behalf of the user automatically, thus logging the user into the account at the site. As noted above, such automation may be particularly desirable in the case where a user is operating a terminal having a limited-function keypad or cumbersome navigation tools.

Additionally, the method and apparatus may be adapted to recognize when a user is attempting to login manually to an account which has not already been recorded in the central database, and may prompt the user to record the account information if desired. The user may thereby be relieved of the obligation to remember which password is associated with which account at a given Web site.

The invention also addresses the foregoing and other shortcomings of e-commerce related systems currently in use by providing a method and apparatus for identifying, aggregating, and organizing the data associated with the user's on-line commercial transactions. Additionally, the system may be expanded to parse any kind of electronic correspondence, whether e-commerce related or not, and to organize the data extracted therefrom in accordance with user preferences.

Specifically, the invention is provides a user with a single, universal e-mail address and comprehensive e-mail filtering, data extraction, and forwarding services. This aspect of the invention may be supported by a centralized, Web-based server which may host the foregoing central database. The present invention may advantageously employ program code at the central server capable of recognizing certain characteristic qualities of e-receipts, in particular, from parsed electronic correspondence; order data related to the transaction identified in the e-receipt may be extracted and organized in accordance with the user's preferences.

According to one embodiment of the invention, a user having a registered account with the system may be provided with a universal e-mail address to which all correspondence may be directed. Incoming mail, i.e. addressed to the universal e- mail address, may be parsed by program code at the central server; e-mail header information and content may be compared with the user's e-mail preference data records stored in the central database. Header and addressing information may be modified according to preferences specified by the user. In this manner, all inbound correspondence may be forwarded to one or more different e-mail accounts at e-mail servers designated by the user. Advantageously, all e-mail may be directed to such a single, universal address, irrespective of origin or ultimate destination. A user may adjust the preferences records in the central database to redirect incoming e-mail as desired, without having to apprise family, friends, and business contacts of a change of address, and without fear of misdirected correspondence.

In addition, one embodiment of the system of the present invention may employ program code at the central server for parsing incoming e-mail specifically to identify e-receipts. In accordance with this "receipt capture" aspect of the invention, examination of parsed header and address data may establish that the incoming correspondence contains information which is characteristic of an e-receipt. In the case where the inbound e-mail is determined to be an e-receipt, program code at the central server may extract relevant data content and store information regarding the e-commerce transaction to which the e-receipt is related in the central database.

Similarly, other kinds of electronic correspondence may be parsed such that desired data may be extracted and stored and/or displayed according to user preferences. For example, the system may be configured to recognize incoming e-mail confirming registration at a particular Web site; the confirmation may be parsed, and relevant user name and password data may be extracted for storage in the addressee's user profile data record. As another example, incoming electronic correspondence may be parsed for content, filtered according to user preferences, and forwarded to appropriate destination addresses based upon the content (e.g. news, stock market alerts, special e-commerce or retail offers, personal correspondence, and so forth). As indicated above, an important aspect of the present invention is that its operation is not limited with respect to location or to a particular computer terminal or workstation. Upon registering with the system for the first time, the user is subsequently enabled to access its functionality from virtually any Internet-capable computer terminal or device.

Also, a convenient aspect of the present invention is that its operation is not limited with respect to location or to a particular computer terminal, workstation, or wireless device employed by the user. Since the functionality of the e-mail filtering, e-mail forwarding, e-mail data extraction and organization, and receipt capture features may reside entirely on the central server, the system's operation does not require special software or hardware on the client or user side. A user may take advantage of the system's features from virtually any Internet-capable computer terminal or device.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a simplified diagrammatic view of the interaction presently required between an Internet user and several sites with which that user may maintain registered accounts;

Figure 2 is a simplified diagrammatic view of the interaction required between an Internet user and several sites with which that user may maintain registered accounts, with the system of the present invention acting as an intermediary;

Figure 3 is a simplified view of the Graphical User Interface presented by an ordinary Web browser application modified to include one embodiment of the interface of the present invention;

Figure 4 is a simplified view of the user interface and navigation tools presented by an exemplary Internet-capable wireless device;

Figure 5 is a simplified diagrammatic view of the interaction between the central server of the present invention and several servers with which a user maintains registered accounts;

Figure 6 is a simplified view of a typical form, which may be encountered by a user during an Internet browsing session;

Figure 7 is a simplified diagrammatic view of one embodiment of the interaction between the central server of the invention and a form page of a typical Web site;

Figure 8 is a simplified diagrammatic view of one embodiment of the automatic login feature of the present invention;

Figure 9 is a simplified diagrammatic view of another embodiment of the automatic login feature of the invention;

Figure 10 is a simplified diagrammatic view of the data extraction and e-receipt capture feature of the invention; and

Figure 11 is a simplified flow chart showing a general progression of one embodiment of the e-receipt capture feature of the invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Figure 1 shows a simplified diagrammatic view of the interaction presently required between a typical Internet user and several sites with which that user may maintain at least one registered account. Conventionally, a user connects to the Internet by means of a computer terminal 110 such as a desktop personal computer (PC) or workstation, a laptop, notebook, subnotebook, or portable machine such as a

Personal Digital Assistant (PDA), a Personal Communications Systems (PCS), an Internet-enabled wireless telephone or other wireless hand-held device, and the like.

Once connected to the Internet, the user accesses e-mail accounts and visits Web servers, or sites, such as those represented by reference numerals 121-125, through means of one or more software applications, such as a Web browser. During the course of visiting the numerous sites which form the framework of the Internet, the user is frequently prompted to register, or to open an account, with a particular site.

Registration serves both to enable the Web server to identify the user, as well as to simplify certain aspects of interaction with the site for the user on subsequent visits.

For example, sites which specialize in auctions, sales of goods, service oriented business transactions, and the like via the Internet (e-commerce), frequently require a user to maintain a registered account at the site before the user may be permitted to use services offered at the site. The amount and type of account information for a particular user maintained at any given site varies considerably, depending upon the nature of the business conducted. Some examples of the nature of information requested from the user during registration include first and last name, date of birth, mailing address, gender, social security number, credit card numbers and expiration dates, mother's maiden name, and so forth. Billing addresses and preferred shipping addresses are common data requested by e-commerce sites specializing in the sale of goods. In theory, the sites' maintaining respective databases of such information for a registered user offers the user convenience and efficiency upon subsequent visits to the Web site.

In practice, however, registering with Web sites often places a significant burden on the user. Providing the site with required or requested information generally involves completing and submitting a form. Completing such forms is onerous, and unavoidably introduces the possibility of error, such as misspellings or transposition of numbers, with every submission. Particularly when the user is operating a PDA, an Internet-capable wireless PCS, or other hand-held device which may have limited or awkward input mechanisms, data entry can be exceptionally problematic. Additionally, once the form has been submitted and the registration process is complete, it is incumbent upon the user to remember the user name and password required to access the registered account.

As shown in Fig. 1 , the effect of a user's maintaining an account at a plurality of sites is apparent. At a minimum, registration with a Web site, such as sites 121-125 in Fig. 1 , requires creating an account which can be accessed only by supplying the correct user name and password during login. That is, to access the full range of services provided at a particular site upon subsequent visits, a user is required to submit, through computer terminal 110, the user name and password selected originally during the registration process.

As shown in Fig. 1 , a user having a separate account at each of sites 121-125 is required to maintain accurate records of at least five separate user names and passwords. While certain of these user names and passwords may be used for more than one account, users often feel that use of a different user name and password for each account is preferable for security reasons.

During a typical Web browsing session, a user may want to login to a registered account at a particular Web site, for example, site 121 in Fig. 1. To login to site 121 , the user must first navigate to the correct login page associated with site 121. Upon arriving at the login page, the user is presented with a login form, into which the user must enter the correct user name and password to access the account. When the form is completed and submitted, the user is logged into the appropriate account at site 121. If the user then wants to login to a different registered account which may be at a different Web site, such as site 122 in Fig. 1 , for example, the above process must be repeated at the appropriate login page for site 122. As noted above, navigating from site to site and entering user account data on a portable or mobile device may be particularly cumbersome and awkward.

In the case where a user is not registered with a particular site, such as site 123 in Fig. 1 for example, the user may be required to register prior to making full use of the services available. To register with site .123, the user must first navigate to the correct registration page associated with site 123. Upon arriving at the registration page, the user is typically presented with a form, into which the user must enter a wide range of registration information in order to create an account. When the form is completed and submitted, the user may subsequently login to the newly created account, for example, in the manner described above. In any event, account data must be transmitted between the user's computer terminal 110 and the various sites 121-125 each time the user wishes to login to a particular account. These data transmission interactions are represented by the arrows in Fig. 1. The interaction between the user and the Web site, required in the name of convenience, is ultimately tedious and necessarily subject to error. Further, as noted above, the data required during the registration and login procedures are typically unique for each account, requiring the user to remember such data or to record it in a convenient, yet secure, location.

Figure 2 is a simplified diagrammatic view of the interaction required between an Internet user, with the invention acting as an intermediary between the user and the various sites with which that user may maintain registered accounts. As illustrated in Fig. 2, the user's computer terminal 210 corresponds to computer terminal 110 illustrated in Fig. 1.

As discussed above, computer terminal 210 may be any type of Internet-capable machine, including PCs and workstations as well as a wide variety of portable devices such as PDAs, PCSs, Internet-enabled wireless telephones, other wireless hand-held devices, and so forth. Additionally, users may have access to the Internet through communication and navigation systems installed in vehicles such as automobiles or boats, for example, or through interactive, Internet-capable television systems (cable or satellite based), and the like. Those of skill in the art will appreciate that the invention is not limited by the type of device used to access the Internet. The method and apparatus set forth herein are equally applicable to any and all Internet-enabled devices. Importantly, the method or means by which computer terminal 210 is connected to the Internet is immaterial. The connection may be through traditional land-line telephone dial-up service, Digital Subscriber Line (DSL) service, a T-1 , T-3, or ISDN network, fiber-optic or cable modem connections, wireless or satellite communications, and the like.

It will be appreciated by those of skill in the art that the method of connection may affect the communication protocols employed by the network hardware as well as the file format required by the user's computer terminal 210. For example, whereas a PC or workstation equipped with a traditional Graphical User Interface (GUI) and Internet browser software may be adapted to display Web content provided in Hypertext Markup Language (HTML), various mobile or wireless devices such as PDAs, PCSs, and the like may be adapted to display different types of markup languages such as Extensible Markup Language (XML), Hand-Held Device Markup Language (HDML), Wireless Markup Language (WML), compact HTML (cHTML), extensible HTML (xHTML), Dynamic HTML (DHTML), and so forth. In general, connection with a mobile or cellular Internet Service Provider (ISP) automatically establishes the correct protocols and determines the proper file format for the specific type of network connection and computer terminal 210. The system of the present invention is not limited to a specific markup language or file format.

Once the connection to the Internet is made, irrespective of the method, the user may employ a software application, such as a Web browser installed on computer terminal 210, for example, to navigate to a Web site hosting a centralized server and database, such as indicated by reference numeral 299. In the case of a PDA or other portable or wireless computer terminal 210, Internet navigation and e-mail functionality may be handled by the operating system and proprietary software which is provided by the manufacturer of the device. In the several embodiments of the invention, the user may open a registered account at the central, Web-based server 299. This registration procedure, as with typical Web site registrations, requires the user to select a user name and password for identification and security purposes, respectively. Upon registration with central server 299, the user may login to the registered account on subsequent visits by completing and submitting the login form with the correct user name and password. The foregoing procedures are not substantially different from the typical registration and login procedures required by ordinary Web sites. The invention provides substantial benefits in terms of convenience and utility, however, after the user is logged in to the registered account at central server 299.

For example, as is illustrated in Fig. 2, the user need only login once to central server 299 during a particular Web browsing session. Subsequent form filling and login procedures at various other sites, such as sites 221-225, for instance, require little or no interaction on the part of the user. Data transmission interactions are represented by the arrows in Fig. 2. With respect to form filling or registration procedures, for example, central server 299 may handle all data entry, completing forms automatically. The user need only review the information for accuracy and submit the completed form. It may be desirable in certain circumstances to submit the completed form on behalf of the user directly from central server 299. This submission must be made through the user's computer terminal 210, but may be accomplished without requiring any action by the user. With respect to subsequent login procedures for registered accounts at other Web servers such as 221-225, central server 299 may handle the navigation, data entry, and login form submission tasks automatically, logging the user in to a desired account at a particular Web site with virtually no action required by the user.

Advantageously, central server 299 is adapted to maintain a detailed database for the user, including a vast amount of personal information supplied by the user. The data recorded may be both general as well as account-specific. For example, general, or global, information may include first and last name, primary billing address, and social security number, and the like. This information is typically constant, irrespective of the Web site with which an account may be maintained. Examples of account-specific information may include user name and password, URL of the login page for the account, favorite genre of literature, and the like. This information may vary according to the information most relevant to the particular site with which the account is maintained.

Importantly, the foregoing general and account-specific information recorded in the database is easily accessible to the user, through login with central server 299, and may be transmitted at appropriate times automatically through the functionality of the system as set forth in detail below. In this regard, the user name and password associated with the user's registered account with central server 299 become global. The user need only remember these two items of information to allow the system of the invention, through central server 299, to serve as an interface with the rest of the Internet universe. The user is thus relieved of the burden of remembering, for example, the URL of a site's login page along with the user name and password selected for a particular account at that site.

In one embodiment of the invention, a unique interface is provided for accessing the functionality of the system. Figure 3 is a simplified view of the GUI presented by an ordinary Web browser application modified to include the expanded interface of the invention. A conventional Web browser application provides the user with a GUI 310 through which interaction with the Internet is enabled. In a standard configuration, GUI 310 may include a menu bar 311 for interacting with the browser software, a control bar 312 for navigation, data management, and other purposes, and a text box 313 for entering text, such as the URL of a desired Web site, for example. These elements are common in the art. The primary element of the browser GUI 310 is the navigation window 314, in which the contents of the various Web sites and pages are displayed. Web site content includes, for example, text, video, hyperlinks to other Web sites, and interactive forms which must be completed and submitted.

As can be seen at the bottom of Fig. 3, the Web browser GUI 310 modified in accordance with this embodiment of the invention includes a utility window 350 appended to navigation window 314. In this embodiment, utility window 350 serves as an interface for accessing the various capabilities of the system. The requisite code for expanding the capabilities of the browser to include utility window 350 may be downloaded and installed into the user's computer terminal 210 automatically

, upon registration with the central server 299 in Fig. 2, for example. As an alternative, the browser software may be modified independently of the registration process, such as, for example, after the user already has a registered account and wants to access that account from a computer which does not already have the software for utility window 350 installed.

Further details of Fig. 3 as related to the installation and operation of utility window 350,' as well as the interaction between browser software, utility window 350, and the functionality of the system software is found in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

In another embodiment which may be particularly convenient when employed with devices having limited graphical capabilities or Web browser software adapted for text-only displays, the invention does not make use of supplemental software code at the user's computer terminal 210. It may be desirable, for example, not to rely upon enhanced user interface mechanisms, such as utility window 350 illustrated in Fig. 3, for invoking the software code provided at central server 299 of the invention. In certain instances, due to the operating system or the display capabilities of the user's computer terminal 210, network communication bandwidth, file format, or other factors, inclusion of such enhanced user interface features may be impossible. The invention may be adapted to these situations through implementation of software code at the central server, such as server 299 in Fig. 2. In this embodiment, the functionality of the software code at the central server is not necessarily dependent upon, nor responsive to, any additional code installed at the user's computer terminal.

Figure 4 is a simplified view of the user interface and navigation tools presented by an exemplary Internet-capable wireless device for use in accordance with this embodiment of the invention. The user's device 410, which corresponds to the computer terminal 210 shown in Fig. 2, is illustrated in Fig. 4 as an Internet-capable wireless telephone or PCS. As noted above, device 410 may alternatively be a PDA, subnotebook, or other portable computer terminal. In this embodiment, the user interface 414 may be text-based or otherwise limited in terms of graphics resolution or display area. A navigation tool 415 is generally provided for enabling a user to interact with various options provided in user interface 414, such as scrolling through items displayed in user interface 414, accessing a menu feature 411 or editing function 412, or entering text required by forms encountered during Internet activity.

As shown in Fig. 4, user interface 414 of device 410 is capable of displaying a form 480, which requires certain data to be entered into fields 481 and 482. Of particular interest in Fig. 4 is the alpha-numeric keypad 419 which enables a user to enter data into fields 481 and 482. As is typical of portable devices such as PDAs and PCSs, virtually every button or key of keypad 419 represents a combination of letters and numbers, and is associated with more than one function. Entering case-dependent user name information into the user name field 481 and a case-dependent password into the password field 482 is a complicated and tedious matter when a user must employ such limited data entry tools as keypad 419.

Given the limited capabilities of user interface 414 illustrated in Fig. 4, it may be desirable to provide the full functionality of the system at the central server. Whereas the user's browser software was altered to include additional program code for inserting utility window 350 in Fig. 3, user interface 414 in Fig. 4 remains unaltered. The user of Internet-capable device 410 shown in Fig. 4 may take advantage of the full functionality of the system merely by logging in with the central server of the invention.

As noted above, browser software, or perhaps a mobile operating system itself, at the user's computer terminal 210 or 410 generally serves as a front-end interface between the user and the system. The system, in turn, provides an interface between the central server 299 of Fig. 2 and the various sites 221-225 visited by the user, automating certain tedious tasks commonly encountered during Web browsing. In particular, the functionality provided by the system is substantially as follows: effective universal Internet identity and e-mail filtering and forwarding. Automatic form filling for virtually any form encountered during Web browsing; and automatic login to sites where a registered account is maintained. These functional aspects of the system are addressed in detail below.

As described above with reference to Fig. 2, upon registration with central server 299, the user has an effective universal user name and password. Once logged into the registered account with central server 299, the user need not remember any additional passwords or other information which may have been disseminated to the various Web sites 221-225 for the purpose of registering or maintaining an account therewith. The requisite information is stored in one or more database records at central server 299 and is readily accessible by the user once logged in to the system. In addition to being relieved of the burden of remembering and organizing an overwhelming amount of information, another benefit to the user of the system of the invention is that the universal user name and password facilitate e-mail filtering and forwarding.

Figure 5 is a simplified diagrammatic view of the interaction between the central server 599 of the invention and several servers 581-583 with which a user maintains registered accounts. In Fig. 5, central server 599 corresponds to that represented by reference numeral 299 in Fig. 2, and the user's computer terminal 510 corresponds to computer terminal 210 or Internet-capable device 410. Various Web sites 521- 525 are shown in Fig. 5 along with a plurality of servers, denoted as servers 581- 583, at which a user may maintain one or more registered e-mail accounts. The servers 581-583 may, for example, correspond to a user's home e-mail account, school e-mail account, and work e-mail account, respectively. It will be appreciated that a user may maintain more or fewer than three e-mail accounts, and furthermore that more than one e-mail account may be maintained at a single server; accordingly, the arrangement of Fig. 5 is illustrated by way of example only.

According to one embodiment of the invention, a user may be provided with a universal virtual e-mail address upon registration with central server 599. This universal e-mail address may be characterized as virtual because the system may not actually maintain a full service e-mail account for the user at central server 599, but rather only function to forward incoming mail to one or more of a plurality of registered e-mail accounts at one or more of a plurality of servers designated by the user. For example, e-mail delivered to the user's universal virtual e-mail address at central server 599 may be selectively forwarded to a single account at server 581 exclusively, or it may be selectively forwarded to one or more registered accounts at all of the servers 581-583. In any event, the user's friends, relatives, business contacts, and others representing the entire Internet universe all sending electronic correspondence to a single address at central server 599, where it may be directed according to the user's preference.

A detailed description of the universal virtual e-mail functionality of the invention is set forth with reference to Fig. 4 in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS Web sites often request that a browsing user supply information, and many of the most popular Web sites, particularly those engaged in e-commerce, actually require as much. As a consequence, a user is often faced with the onerous task of filling out forms during a given Web browsing session. Figure 6 is a simplified view of a typical form 680 which may be encountered by a user during an Internet browsing session.

In addition to the form 680 itself, Fig. 6 also shows the entire browser GUI 610, complete with the standard menu 611 , control bar 612, text box 613, and navigation window 614, in which form 680 is displayed. The GUI 610 illustrated in Fig. 6 has been modified to include the utility window 650, through which the various functions supported at the central server, such as server 299 or 599, may be accessed. In particular, utility window 650 includes at least one operative button, such as button 655, which enables access to the automatic form filling feature of the present invention. As an alternative, access to the automatic form filling feature may be provided by means other than a button, for example, through a drop-down menu such as 656.

It will be appreciated that the particular form 680 illustrated in Fig. 6 is representative only, and further that a different browser may require display of form 680 in a very different manner. As noted above, some PDAs or Internet-capable wireless telephones may be incapable of reading HTML documents, for example; as a consequence of the different file format, such as XML, WML, or HDML, which may be required by the device or the protocol of the network over which the device is communicating, the presentation of form 680 may be very different from that illustrated in Fig. 6. That is, form 680 may be presented in a manner similar to that depicted as form 480 in Fig. 4. In the embodiment illustrated in Fig. 4, access to the automatic form filling feature may be provided as an active option in menu 411 , for instance.

As noted above, even forms requesting identical data may require submission of that data in different formats. For example, the "Name" field 681 may be subdivided such that a different form may request the same data in three different fields corresponding to last name, first name, and middle name. Likewise, the "Phone" field 682 may be subdivided into three different fields corresponding to area code, exchange, and last four digits. A fourth field may be included for an extension number. Similarly, various forms additionally include drop-down menus or radio buttons wherein the user is requested to select, for example, an age range, an occupation or title, or a preferred credit card type from a limited list.

As described above, the system of the invention maintains detailed records of information provided by a user both during the registration process and subsequent to registration, at the user's discretion. That is, when a user creates a registered account at the central server, the server creates a database record for that particular user; various user data may be retained. The server may request information from the user in as granular a format as possible. That is, telephone numbers, for example, may be segmented into at least four fields corresponding to country code, area code, full telephone number, and extension. As another example, names may be stored at the server in first name, middle name, last name format rather than as a single field. In this manner, the system of the present invention may be adapted to provide data to various forms requiring data in any one of numerous formats. By way of background, typical forms encountered during Web exploration may be encoded in the HTML documents, or pages, visited by the user during browsing. In the case of wireless PDAs and Internet-capable telephones, the documents may be in another format, such as HDML, WML, cHTML, xHTML, DHTML, and the like, as noted above. It will be appreciated by those of skill in the art that the present invention is not limited to any specific document format or communication protocol; the following discussion refers to these file formats using the generic term: markup language (ML).

Any given ML page may include one or more forms, distinguished in the underlying ML code. The invention uses program code at the central server to parse the ML pages when the user invokes the form filling function. The program code is adapted to identify text strings in the ML code which represent forms embedded therein. Each form contains one or more "meta types" recognizable by the system. Each meta type represents a logical data block comprising one or more information fields which are logically related in a meaningful way. Each information field, in turn, has a particular format associated therewith. The foregoing hierarchy of form components assists the system in assigning the granular user data to the correct location in the form during the form fill process.

In this regard, it will be appreciated that classifying different types of data according to meta type enables the system to approach the task of completing forms in an efficient manner which minimizes system overhead and user inconvenience. Either before or during the form fill process, for example, each meta type in its entirety, along with the specific data used for filling its fields, may be selected independently; that is, the user may employ drop-down menus or other GUI mechanisms provided in the utility window to select from a plurality of previously stored data within a given meta type. The interface in the utility window may be adapted to accommodate such selection through inclusion of a drop-down menu for each meta type, for example. In the case of user interfaces limited to text-only displays, a separate text-based menu may be provided for user selection of meta types; as noted above, such an option may be made accessible through the menu option 411 in Fig. 4, for example.

A detailed description of meta types and the form filling functionality of the invention is set forth in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

In accordance with one embodiment of the invention, the user data stored at the central server is extracted from the database and manipulated so as to conform with the formatting requirements of the form by the program software at the server. The properly formatted user data may be used to fill a desired form such that the user need not enter the information manually. Subsequently, the filled form may be transmitted to the user's computer terminal or portable device for verification or alteration. In an alternative embodiment, it may be desirable to use program code at the server to submit the filled form automatically, without any interaction from the user. While the number, type, and format of forms a user may encounter on the Internet are as varied as the number of Web sites requesting their completion, the invention recognizes any given form as falling into one of two broad categories: those forms which have been mapped into the system's database; and those forms which have not been mapped. In addition to maintaining a database of user information at a central Web-based server, the invention is adapted to maintain a database of form data related to the numerous forms which may be encountered most often by users browsing the Web. These forms, required or requested by the most popular or most frequently visited Web sites, for example, may be mapped. Mapped forms have been parsed, for example, by a software script adapted to read the underlying ML code of the Web page containing the form.

The mapping process enables the system to recognize a previously mapped form upon subsequent encounters therewith. Recognition of a particular form's fields and structure, in turn, enables the program code at the server to input the correct user data into each field, in the proper format, efficiently and systematically. Accordingly, mapping a form may involve all of the following: examining the underlying ML code for the purpose of analyzing the form's structure and arrangement; identifying the required fields, the optional fields, and the requested format of each; matching the form fields with the user data fields in the database to which they correspond; and recording all of the foregoing information under a unique identifier string through which the system may prospectively identify that particular form.

A detailed description of the ML parsing process, the mapping procedures used by the system of the invention, and the granularity of database records is set forth in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

In one embodiment, the form filling feature of the invention may employ both the program code at the central server, as well as the code underlying the enhanced interface, such as described above with reference to Figs. 3 and 6, provided at the user's computer terminal. Figure 7 is a simplified diagrammatic view of the interaction between the central server 799 of the invention and a form page of a typical Web site visited by a user at a computer terminal 710. In Fig. 7, the form 780 may correspond to forms 480 and 680 discussed above with reference to Figs. 4 and 6. The standard Internet browser's capabilities have been expanded to include the utility window 750 which may correspond to utility window 350 described above. As discussed previously, upon login with central server 799, certain of the system utilities may be imported into utility window 750 by means of program code which may affect the appearance and operation of utility window 750.

In this particular embodiment of the present invention, user interface with the form filling function is enabled, and may be presented to the user in the form of an operative button, such as illustrated in Fig. 3 as button 351 , or as an operative option in a menu such as 411 in Fig. 4, for example.

A detailed description of the interaction between central server 799 and the user's computer terminal 710 with respect to the form filling functionality of the invention is set forth with reference to Fig. 6 in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

In one embodiment, for example, the programming code at central server 799 may simply extract the appropriate user data from the database records and return that data to the user's computer terminal 710 for filling form 780. The filled or partially filled form 780 may then be displayed to the user, who may alter, delete, or add information selectively. This embodiment provides two advantages: the user has an opportunity to delete or to modify optional information which the user does not wish to supply as specifically recorded in the database; and previously unmapped forms may be mapped according to the information provided by the user. As noted above, the system may alternatively be adapted to submit the form automatically. In such a case, the user may be prompted selectively to supply any optional data at the user's discretion.

It will be appreciated from the foregoing that, once the user has logged in to the registered account at central server, the form filling feature provides a significant convenience. By selecting the form fill option, for example through a utility window or through standard browser interface mechanisms, the user can complete an entire form or portions of a form automatically with little or no manual input. In addition, the system may recognize input from the user when a particular page is unloaded indicating that a form, which has been filled manually by the user, is being submitted independent of the form filling feature. In this manner, the system can learn from the user's experiences, mapping forms for future form fill operations invoked by other users.

The invention also offers appreciable convenience when a user desires to login to a particular registered account at an e-mail server or an e-commerce Web site, for example. A typical Web browser application offers a list, which may be edited, of the Web sites most frequently visited by the user. As commonly implemented, a "bookmarks" or "favorites" list merely enables the user to navigate to a particular site without having to enter the site's URL string; that is, the typical bookmark is only a navigational tool which is capable of no more than directing the browser to a specified address in cyber-space.

The invention, on the other hand, combines the navigational utility of the typical bookmark with a customized form filling operation which substantially simplifies login procedures by eliminating the need for data input. The net result of this combination is a smart bookmark, which not only navigates a user to the login page of a specified account, but also completes and submits the login form, thereby logging the user in to a registered account without further intervention by the user.

The interface for this login feature may be installed into the utility window upon login with the central server as described above with reference to Fig. 3. In this particular instance, the interface may comprise a drop-down menu, for example, which may include an operative option for setting up an account to be displayed as an independent selection in the menu. As an alternative which may be particularly advantageous in the context of mobile or wireless computer devices, the ordinary browser interface is used to invoke the automatic login feature. For example, smart bookmarks may be provided in menu 411 shown in Fig. 4. Selection of a site may invoke the automated login feature described below. In either case, requests for login may be directed through the central server of the system.

By way of background, the types of registered accounts to which a user may be entitled access vary considerably. In the same manner in which a user may maintain multiple e-mail accounts at a single e-mail server, a user may also maintain more than one registered account at other types of servers, such as e-commerce Web sites, for example. The invention accommodates recordation of necessary data concerning multiple accounts in the same domain, corresponding to a home account and a work account, for example, at the same server.

Conversely, an account at one site may entitle a registered user to login at a different Web site in an entirely different domain, perhaps operated by the same entity or a co-brand partner. That is, creating an account at one Web site may potentially entitle the registered user to access that Web site's partner sites in different locations using the same user name and password recognized by the site with which the user is registered. The invention recognizes these types of partnership accounts, at least with respect to mapped sites. This recognition is not limited to the mapped sites.

Because a plurality of accounts may be accessed through the central server, for example, each account for which the login feature may be invoked may be given a unique identifier, or nickname, for identifying the account. The nickname of each account may be displayed to the user, for example, in menu or list form. In the case where a user is attempting to submit data concerning a second or subsequent account in the same domain, the program code at the central server may inform the user that an account already exists at the selected site, and prompt the user to confirm a new user name and password along with a different nickname for the new account.

As noted above, during a particular Web browsing session, a user need only select an account from the menu or list such as menu 411 for example, in order to invoke the program scripts at the central server which logs the user in to the selected registered account. Initially, however, the accounts for which the login feature is activated must be input so as to be recognized by the system.

A detailed description of the manner in which account data may be input is provided in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

Figure 8 is a simplified diagrammatic view of one embodiment of the automatic login feature of the invention which represents the situation in which the login form for a particular Web site 821 has already been mapped into the system. In this situation, the system already knows the URL of the login page and the structure of the login form. This information may be stored at central server 899, for example, in a form database record associated with a specific form identifier string. A list of recognized Web sites having login forms which are already mapped may be available to the user at the user's computer terminal 810 upon login with central server 899. During browsing, the user may select one of the active options presented, for example, in the menu feature 411 depicted in Fig. 4, to invoke the automatic login process.

In the exemplary automatic login procedure illustrated in Fig. 8, central server 899 may receive a request to log the user into an account maintained at Web site 821. This request is represented by the arrow labeled 1 in Fig. 8. As noted above, subsequent to login with central server 899, all requests for login from the user's computer terminal or device 810 may advantageously be directed through central server 899. Upon invocation of the automatic login procedure, central server 899 may initiate program code employing the form fill technology discussed. The mapped login form may be retrieved from the database at central server 899 and a login template may be created. The login template may generally be a page, created in the appropriate ML, which mimics the normal login page of the site, such as Web site 821 , to which the user would like to login. Additionally, the login template includes the appropriate user data associated with the particular account which is required for login. That is, the form filling feature of the present invention is employed to fill the user name and password fields in the correct portions of the login template. In this manner, a login template including all requisite data, in the appropriate format, may be constructed at central server 899. The login template with user name and password data may then be transmitted to the user's device 810, as indicated by the arrow labeled 2 in Fig. 8.

The login feature of the invention preferably includes the additional step of actually submitting the form without further intervention on the part of the user. This automatic submission is depicted by the arrow labeled 3 in Fig. 8. The program code at central server 899, for example, may execute one or more program scripts in conjunction with creating the login template which may automate form submission, through the user's device 810, to Web site 821. An ML page including a form usually includes an operative button or other form action for executing the submission script which unloads the page and delivers the ML data to the server requesting the form. The login feature of the invention may include program code which simulates selection of the operative button in the ML page or some other more complicated or sophisticated form action. Accordingly, the form may be submitted under software control, thereby logging the user into the selected account. At the completion of the login process, Web site 821 may send a confirmation page to the browser at device 810, indicating that login was successful. This transmission is illustrated by the arrow labeled 4 in Fig. 8.

A detailed description of automating form submission, for example through simulated selection of a button or other form actions in ML, is set forth in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS".

The embodiment illustrated in Fig. 8 may also be employed in conjunction with cached login pages. As an alternative to a mapped login form, for instance, the invention may advantageously maintain login pages of various frequently accessed Web sites in a memory cache. It will be appreciated that such a cache arrangement may significantly reduce system overhead and retrieval time for a given automatic login operation.

Figure 9 is a simplified diagrammatic view of another embodiment of the automatic login feature of the invention representing the situation in which the login template is generated dynamically when the user invokes the automatic login feature. Dynamic login template generation may be desirable or required, for example, when a login form has not previously been mapped or the login form has been removed from the cache. The embodiment illustrated in Fig. 9 is similar to that depicted in Fig. 8. The interaction between the user's device 910 and the central server 999, as well as the interaction between the user's device 910 and the Web site 921 , is substantially the same as that illustrated in Fig. 8.

As shown in Fig. 9, the process of dynamic login template generation additionally involves direct interaction between central server 999 and Web site 921. As indicated by the arrow labeled 2 in Fig. 9, central server 999 may request a normal login page from Web site 921. When the login page is received, central server 999 parses the ML of the login page and identifies the login form. An heuristic algorithm, such as that described in copending application, U.S. Serial No. 09/561 ,449, filed April 28, 2000, entitled "METHOD AND SYSTEM OF IMPLEMENTING RECORDED DATA FOR AUTOMATING INTERNET INTERACTIONS", for example, may be implemented at central server 999 to identify the nature and structure of the login form at the URL provided by the user.

In operation, program code at central server 999 may examine the normal login form in sufficient detail to enable the form fill routine to fill out the form accurately; this scenario reduces down to the embodiment illustrated in Fig. 8, i.e. the login form had been previously mapped. The form fill script is invoked and the form may be submitted on behalf of the user as described above. In an alternative embodiment, the invention may be adapted not to submit the login template automatically, but rather to give the user the opportunity to confirm that the heuristic algorithm correctly mapped the form and to ensure that the user name and password data have been filled in the proper locations.

Irrespective of the manner in which the registered account is set up to function with the login feature, once the central server has been provided with all of the requisite data, subsequent login with respect to any registered account may be automatic upon selection of the desired account. This selection may either be accomplished through the utility window interface described above with reference to Fig. 3, or through unadulterated browser software options as described above with reference to Fig. 4. The program scripts at the central server may be adapted to procure the login page from the desired Web site. As noted above, a program script may simulate selection of the submission option in the login page ML such that the form is submitted to the Web site, logging the user into the selected registered account automatically.

Figure 10 is a simplified diagrammatic view of the data extraction and e-receipt capture feature of the invention, which identifies e-mail data content and e-receipts and extracts selected types of data, such as e-commerce data, for example. The central server of the invention preferably includes an e-mail server 1030 to which all incoming e-mail is directed; this inbound e-mail may be addressed to a user's universal virtual e-mail address as described above.

In operation, e-mail server 1030 accepts incoming e-mail from the various domains which make up the Internet universe. Program code resident at e-mail server 1030 may read the incoming e-mail packet header information and identify both the origin as well as the sender of the correspondence. Additional program code at e-mail server 1030 may query the database 1040 at the central server, identify the appropriate user preferences data record, update the address header data in accordance with the user's preferences, and redirect the e-mail to the designated e- mail account.

While forwarding the e-mail to the account specified in the user preferences record in database 1040, e-mail server 1030 may employ program code to copy the correspondence and to place the copy, rather than the original, in a queue 1050 for parsing. It will be appreciated that this procedure is efficient and provides timely delivery of the original e-mail to its ultimate destination, while a copy is parsed to determine if the correspondence is an e-receipt or contains data content selected for extraction by e-mail preferences. This is the arrangement illustrated in Fig. 10. In an alternative embodiment, the system may operate exclusively with the original e-mail.

In one embodiment, each e-mail may be copied to two files for parsing: one file representing the header; and one representing the text, or body, of the correspondence. Generally, such a scheme may expedite the parsing process because the header file may be parsed first; in any event, as noted above, the header information must be parsed and analyzed for forwarding purposes, making this bifurcated parsing scheme more efficient. In this manner, only some e-mail bodies, i.e. those with headers which may be indicative of data content of interest (such as, for example, e-receipts), need be parsed and analyzed. Alternatively, copying and parsing may be effectuated using a single file representing both header information as well as the body of the e-mail. This alternative may be particularly desirable in the case described above where e-mail may be forwarded according to its data content, for example.

Whether one or more files are created during copying, each copied file may be assigned a unique message identifier, sequence number, or some other convenient identification tag or marker. Such identification enables the system of the invention to direct data to the correct user database records following e-receipt identification and/or general e-mail data extraction. As illustrated in Fig. 10, an e-mail string (or stream of e-mail data) is sent by a queue manager program code module or other software script (not shown) from queue 1050 to a parser engine 1060, which represents the program application code and logic underlying the e-receipt capture and data extraction features of the invention. By way of specific example, but not by way of limitation, operation of the Fig. 10 embodiment will be described below in the context of identifying e-receipt data. Program code at parser engine 1060 attempts to identify e-receipts as set forth below.

As noted above, the first step in determining whether a given e-mail is an e-receipt may involve parsing header data to determine the origin of the correspondence. This may include the domain from which the e-mail originated. Program code at parser engine 1060 may access a template database 1065 in an attempt to match the e-mail with a known, or mapped, template.

By way of example, template database 1065 may maintain, for each known e- commerce host or e-receipt provider domain, one or more templates which may serve as models of the various kinds of e-commerce related correspondence normally originating from that specific domain. For example, while a receipt may generally provide certain information in a particular format, a shipping status or backorder report generally provides different information in a different format, and a shipping confirmation notice provides still different or additional information in yet another format. It will be appreciated that other types of correspondence may be provided by various e-commerce hosts. In one embodiment, each of the various known categories of correspondence, i.e. receipt, backorder report, projected shipping date notice, shipping confirmation, and so forth, for a variety of e-commerce vendors and service providers may have a unique template stored in a database record in template database 1065. After the header information of the incoming correspondence has been parsed, such database records may be accessed by parser engine 1060 so as to facilitate parsing and to assist in identifying relevant data from the body of the e-mail efficiently.

The parsing process may employ various filtering and/or weighting techniques, in accordance with the information included in the various templates, for determining the nature of the correspondence. A confidence level may be assigned to each incoming e-mail relative to each template. Such filtering and/or weighting techniques are well known to the ordinarily skilled artisan, and are not detailed here.

By way of example, e-mail originating from the ".edu" domain (for educational institutions or entities) may be less likely to be of a commercial nature than e-mail originating in the ".com" domain (for individuals, commercial enterprises, and businesses). Accordingly, e-mail originating in certain domains, such as ".com" for instance, may be weighted differently from e-mail originating in others. Similarly, some e-mail addressed to multiple recipients, (more than one or more than two, for example), may be weighted so as to be distinguished from e-mail addressed to a single recipient, where the latter may be assumed more likely to be a receipt. It will be appreciated that other criteria, such as the content of the "Subject:" line, may be used for filtering purposes, particularly in cases where e-receipt providers use predictable strings in the subject line; this predictability is reflected in the template. Various aspects of e-mail may be examined and weighted, depending upon the nature and content of the templates extracted from template database 1065 to which the incoming e-mail is compared. Those aspects enumerated here are listed by way of example only, and not by way of limitation.

Parser engine 1060 may include program code to filter through packet header data and e-mail content (depending upon the instructions in the template) and to apply weighting functions (again, depending upon the template) based upon various criteria such as, inter alia, the origin domain and number of recipients as discussed above. In one embodiment, the weighted results of the foregoing filtering process may be forwarded to a scoring engine or other program code which may employ the weighted results in an algorithm for providing each e-mail with a final score or confidence level relative to each template to which it has been compared. Generally, in accordance with this embodiment, a confidence level above a certain threshold with respect to one or more templates may be considered to establish the e-mail as an e-receipt. Similarly, a confidence level below a certain threshold with respect to all the analyzed templates may be considered indicative of the e-mail's status as not an e-receipt.

If the incoming e-mail can be associated with, i.e. its format matches, an existing template as evidenced, for example, by a confidence level above a certain threshold, extracting relevant e-commerce or other data is a fairly straightforward matter, because the information provided and the specific format in which it is presented is known. The information may be extracted according to extraction instructions provided in the template and subsequently stored in database 1040 according to user preferences. If, on the other hand, the e-mail has been determined not to be of interest, as evidenced by a confidence level which does not meet a particular threshold, for instance, the e-mail may be ignored by the system and deleted.

The foregoing threshold confidence levels may be the same. That is, the invention may be adapted to employ Boolean logic. In such an embodiment, incoming e-mail may either be established as e-receipt material or not. Alternatively, a questionable confidence range may be provided, wherein, for e-mails having middling scores between the threshold levels, the program code at parser engine 1060 does not make a determination unilaterally. In this embodiment, as illustrated in Fig. 10, parser engine 1060 may be adapted to forward a copy of the questionable e-mail to an administration module 1070 for further analysis.

Administration module 1070 may be a Web-based or server-side application, for example, designed for administrative viewing (preferably by an operator) of questionable e-mail. In this embodiment, such a server-side application may read the e-mail data forwarded from parser engine 1060 and display information relevant to the e-receipt inquiry to an administrator. The administrator may ultimately make the determination as to whether a given e-mail is, or is not, an e-receipt. In such an embodiment, e-receipts may be returned to queue 1050 for subsequent processing, while general correspondence may preferably be deleted.

In parser engine 1060, information concerning e-mail which has been determined to be no more than general correspondence may be deleted, as noted above. On the other hand, any given e-mail which has been established as an e-receipt or containing data of interest may be parsed such that relevant data concerning the e- commerce transaction may be extracted. As noted above, if the format of the e-mail matches an existing template, data extraction may proceed in accordance with the format of the template and the instructions provided therein. If no template is matched, however, the markup language of the e-mail must be examined in detail to locate and to extract the appropriate data.

Though an associated template may not be found for a particular e-receipt, program code at parser engine 1060 may be employed to examine the markup language of the identified e-receipt so as to identify items or elements which may be similar to elements in known or mapped templates. That is, an iterative program procedure may sort through the data content and make comparisons with one or more templates stored in template database 1065. Though the entire format of the e- receipt may not be known at the beginning of the iterative procedure, it is likely that much of the data contained in the markup language is matched to known elements or fields in existing templates. Such an iterative procedure has two advantages: first, relevant data may be extracted from the e-receipt based upon similarities with data in existing templates; and second, a template may be constructed, or reverse engineered, as the data is extracted.

In still another embodiment, general parsing techniques may be employed in lieu of a template-dependent system. While templating, and in particular matching parsed data in accordance with pre-existing or dynamically generated templates, may provide for increased accuracy in extracting and organizing desired data in certain circumstances, those of skill in the art will appreciate that general parsing algorithms may be used for examining data content for particular information. Use of such general parsing and data extracting methods may be particularly desirable in an embodiment directed to extracting data from general or personal correspondence, i.e. data which is not necessarily related to e-commerce.

Output from parser engine 1060, i.e. data extracted from e-receipts, may be written, for example, to a file in a desired markup language such as HTML, XML, and so forth. In certain instances, it may be desirable to send extracted data directly to central database 1040 in raw form. In the latter case, additional program code may be provided for querying database 1040, extracting desired data, and selectively displaying e-commerce information in a user-friendly or user-specified format; such additional program code may advantageously reside on the server-side, i.e. at the central Web-based server of the present invention, or alternatively, on the client-side, e.g. at a user's computer terminal or wireless device.

By way of example, Figure 11 is a simplified flow, chart illustrating a general progression of one embodiment of the e-receipt capture feature of the invention. In the following discussion, that embodiment is described with reference to the general process flow depicted in Fig. 11 , and several variations are noted. Again, it should be appreciated that the general progression illustrated in Fig. 11 may also be useful for extracting data from generic electronic correspondence; that is, the Fig. 11 embodiment is not limited to e-receipt identification and data extraction, but is also applicable to data extraction from other types of e-mail.

Initially, as shown at block 1101 , inbound e-mail, i.e. addressed to a user's universal virtual e-mail address as described above, may be received at an e-mail server. Program code resident at the e-mail server may read incoming e-mail packet header information so as to identify both the origin as well as the sender of the correspondence. As indicated at block 1102, program code at the e-mail server may query a database at the central server in order to identify the appropriate user preferences data record related to the origin domain and/or the sender of the incoming e-mail. In this manner, the system may determine the ultimate destination, which has previously been specified by the user, for the various e-mail items delivered to the universal address.

At block 1 103, the address header data may be updated for any given correspondence in accordance with the user's preferences; this alteration of the address header data allows the system to redirect e-mail to the designated e-mail account as shown at block 1104. In such an embodiment, i.e. where the original e- mail is forwarded to its destination address before being sent to the parser engine as described above, a copy may be made at the e-mail server. While the e-mail server is forwarding the original at block 1104, program code may be copying the correspondence and forwarding the copy, rather than the original, to a queue for subsequent parsing; this is shown at block 1105.

Each incoming e-mail, in turn, is transmitted from the queue to the parser engine, as represented at block 1106. During parsing, the parser engine may query data records maintained in a template database, as shown at block 1107. Upon retrieving template records, the parser engine may attempt to identify potential similarities between the parsed e-mail and any known, or mapped, template. Similarities may be identified, for example, through filtering and/or weighting of the parsed e-mail data, such as occurs at block 1108. As noted above, the filtering and/or weighting techniques applied by the system are well known in the art, and may include comparison of e-mail data with template data extracted from the template database. As noted above, it may be desirable to provide the e-mail with a total score or weight.

At decision block 1109, the overall score or weight for the e-mail, which may be assigned based upon the foregoing filtering and weighting, may be measured against one or more threshold values. The comparison result may generally be accepted as a determination of the presence or absence of e-commerce data, or any other type of data desired, in the e-mail. Where the overall score of an e-mail falls within a certain range relative to a particular threshold, the e-mail may be eliminated as a potential e-receipt, in which case the e-mail is deleted as shown in block 1110. On the other hand, where the score of an e-mail falls within a certain range relative to a particular threshold, the e-mail may be identified as an e-receipt, in which case the system may proceed to block 1190, where e-commerce data is extracted.

As noted above with reference to Fig. 10, it is possible that decision block 1109 may have an additional outcome, i.e. a "Maybe" result. If the filter and/or weighting techniques fail to provide a given e-mail with a definitive score relative to the thresholds defined by the system, the e-mail may be forwarded to an administration module, as shown at block 1 11 1 , for analysis by an administrator. The administrator's examination of the header and text of the e-mail will enable a positive determination as to the nature of the correspondence, as represented at decision block 1112. If the e-mail is determined not to be an e-receipt, it is preferably deleted at block 1113.

If the e-mail is identified by the administrator as an e-receipt at decision block 1112, on the other hand, the copy of the e-mail may be returned to the queue at block 1105, for example, for additional parsing by the parser engine. In such a case, the copy of the e-mail may be provided with a short data indicator field or flag which serves as positive identification of the correspondence as an e-receipt. In this manner, when an e-mail is on its second trip through the parser engine, i.e. it has already been determined to be an e-receipt by the administrator, a flag may be set (for example, by the administrator) such that the parser engine is required to return a "Yes" result at block 1109.

As noted above with reference to Fig. 10, a system which forwards original e-mail to its ultimate destination (as shown in block 1104 in Fig. 11) before examining its contents in detail may be efficient and provide timely delivery. On the other hand, it is within the scope and contemplation of the present invention to provide an alternative scheme wherein the system may operate exclusively with the original e- mail. In that regard, it will be appreciated that various individual blocks or sections of the diagram illustrated in Fig. 11 may be relocated or eliminated in several alternative embodiments.

For example, in the case where a full-service e-mail account may be maintained for each user at the central server of the invention, there may be no requirement for forwarding e-mail to an additional account or sever at another destination. In such a situation, updating header data at block 1103 and forwarding e-mail at block 1104 both may be unnecessary. Though the system may not be directing e-mail to other locations as specified in the user preferences record in the database, querying the database such as represented in block 1 102, may still be desired in this embodiment. Incoming e-mail may be prioritized, censored, deleted automatically, or returned to the sender, for example, depending upon the user's preference data as recorded in the database, as described above. Those of skill in the art will appreciate that block 1102 may be advantageously inserted at various locations in Fig. 11 , even in an embodiment which does not employ the forwarding feature.

Similarly, copying incoming e-mail and sending only a copy to the queue, as in block 1105, may be unnecessary or undesirable in certain situations. Where bandwidth and system resources are sufficient, for example, it may be advantageous for the system to parse original e-mails directly, without copying and prior to forwarding. In such a system, incoming e-mail may be sent from block 1101 directly to block 1106 in Fig. 11. Such a strategy may provide more options and more convenience for a user. As an example, a user maintaining an e-commerce specific e-mail account may want to direct e-receipts, exclusively, to that account; in this embodiment, the invention may be adapted to forward e-mail to such an exclusive account contingent upon the result of block 1109 in Fig. 11 , for instance. In accordance with this potentially desirable sequence of events, the parsing and the identification of e- commerce data may occur prior to copying or forwarding any particular e-mail.

It should be noted that various adaptations are possible following the extraction of e- commerce data, i.e. block 1190 in Fig. 11. For example, extracted e-receipt data may be written directly to the central database maintained by the central server of the system as discussed above with reference to Fig. 10. In such an embodiment, program code may allow a user access to the appropriate database records upon login with the central server. Alternatively, the data may be inserted into a markup language document formatted according to a user's preferences and forwarded directly to the user, at a specified address and in the desired format. In this manner, all the e-commerce data provided to an individual user may be presented in a consistent format selected by the user, irrespective of the original format, for example.

For each e-receipt or e-commerce related correspondence, some or all of the following information may be extracted from the incoming e-mail's markup language: item identification or description; quantity ordered; quantity shipped; total and per- unit price; total and per-unit tax; shipping cost; purchase date; credit card type, number, and expiration date; discount or coupon redemption; order status; order number; confirmation number; tracking number (for shipments); receipt date; and any reference numbers or comments provided by the e-commerce host. It will be appreciated that the foregoing list is not exhaustive, and is given by way of example only, and not by way of limitation.

As noted above, it may be desirable to maintain one or more detailed database records of the e-commerce related information extracted from the identified e- receipts for each registered user of the system. Upon login with the system of the present invention, users may access program code at the central server and thus be enabled selectively to access records of e-commerce activity. Data concerning on- line purchases as extracted from captured e-receipts may be maintained in the system for a certain period of time, for example, such as one calendar year or one fiscal year.

It should also be recognized that users may desire the option to manipulate, to alter, or to disable various features of the system. Accordingly, program code may be provided such that, upon login with the system, users may further be enabled to adjust certain aspects of the system's functionality. In such an embodiment, a user may select from one or more options related to the type of information displayed, the display format, or the duration of data retention, for example. Additionally, the user may be provided with an option for selectively enabling or disabling the e-receipt capture feature.

Additionally, it will be apparent from examination of Figs. 10 and 11 that the invention is capable of identifying types of electronic correspondence other than e-receipts. The contents of template database 10611 , for example, may affect the data identification and extraction processes. As noted above, the system may be configured to identify user name and password data from e-mail confirming a Web site registration, for example, or to extract data from an e-mail confirming a travel itinerary sent by a travel agent's reservation system. The system may distinguish news stories from stock updates. Data extracted from electronic mail may be stored in the addressee's database record maintained at the central server of the system.

As with e-receipt data, maintaining a database record of the data content of other types of e-mail provides a user with substantial benefits upon login with the system of the invention. For example, users may access program code at the central server and thus be enabled selectively to access records and make those records available to other software programs. Data concerning the date and time of an upcoming meeting or event, as extracted from an e-mail reminder, for instance, may be maintained in the system and accessed by a personal or company calendar/planner software program. As an example, PDAs typically are equipped with calendar and organizer software. The travel itinerary from the foregoing example may be exported to, or accessed by, a central or remote calendar function such as installed on a PDA, and the user's schedule, calendar, and/or digital agenda may be updated automatically. Similarly, if a colleague e-mails a change of telephone number or other contact information, the new contact data may be parsed from the markup language of the e-mail and either: stored in the central database; used to update the addressee's software automatically; or both. As with the e-receipt embodiment, users may further be able to adjust or to disable certain aspects of the system's functionality.

With the functionality of the system residing on the server-side, proprietary or additional software need not be installed at the client-side. A registered user of the system may obtain records of e-commerce activity from any Internet-enabled computer terminal, without having to login to the host site's server, and without having to provide order number or payment authorization data. The information is available to the user regardless of the e-mail address to which a particular e-receipt was directed by the system.

It will be appreciated by those of skill in the art that the disclosure contemplates numerous forms of electronic correspondence. References herein to electronic correspondence, either of a commercial or a private nature, e-receipts, e-commerce data, personal e-mail correspondence, and the like, are exemplary only, and are not intended to be construed in any limiting sense. It is within the scope and contemplation of the invention to apply the teachings herein to electronic correspondence of all forms.

From the foregoing, it can be seen that a system designed in accordance with the invention provides a versatile, efficient, and personalized Internet interface for specialized applications, particularly with respect to automating certain interactions which ordinarily must be completed manually. The preferred embodiments disclosed herein have been described and illustrated by way of example only, and not by way of limitation. While only certain embodiments of the invention have been specifically described herein, it will be apparent that numerous modifications may be made thereto without departing from the spirit and scope of the invention.

Claims

1. A system for automating data transactions between computer servers, comprising: a first server for maintaining a database having stored data recorded therein; program code residing on said first server for creating extracted data by selectively extracting said stored data responsive to a request; and additional program code residing on said first server for obtaining a blank form, and for parsing said blank form to identify which of said extracted data should be used to fill in at least a part of said blank form.

2. The system of claim 1 wherein said extracted data includes data for all fields in said blank form.

3. The system of claim 1 wherein said blank form is obtained from a second server.

4. The system of claim 1 wherein said blank form is filled in using a fuzzy fill procedure.

5. The system of claim 1 wherein said blank form is a login form.

6. The system of claim 1 wherein said additional program code includes instructions for creating a filled form using said extracted data to fill in said blank form.

7. The system of claim 6 wherein said additional program code further includes instructions for submitting said filled form to a second server.

8. The system of claim 1 further comprising: an additional database maintained at said first server; said additional database having stored form data recorded therein; said stored form data relating to forms required by at least one other server.

9. The system of claim 8 wherein said additional program code includes instructions for comparing data fields in said blank form with said stored form data recorded in said additional database.

10. The system of claim 8 wherein said stored form data includes parsed form data from said at least one other server.

11. The system of claim 9 further comprising: form filling program instructions residing on said first server, using a result of said comparing data fields in said blank form with said stored form data, for creating a filled form by filling in said blank form using a fuzzy fill procedure.

12. The system of claim 11 further comprising: form submitting program instructions residing on said first server, using a result of said form filling program instructions, for automatically submitting said filled form to a second server.

13. A method of automating data transactions between computer servers, comprising the steps of: maintaining a database having stored data recorded therein at a first server; selectively extracting said stored data responsive to a request; obtaining a blank form; and parsing said blank form to identify which of said stored data should be used to fill in at least a part of said blank form.

14. The method of claim 13 wherein said selectively extracting includes extracting data for all fields in said blank form.

15. The method of claim 13 wherein said obtaining a blank form includes receiving form data from a second server.

16. The method of claim 13 wherein said obtaining a blank form includes receiving login form data from a second server.

17. The method of claim 13 further comprising the step of: filling in said blank form using a fuzzy fill procedure.

18. The method of claim 17 further comprising the step of: automatically submitting the result of said filling to a second server.

19. The method of claim 13 further comprising the step of: maintaining an additional database at said first server; said additional database having stored form data recorded therein; said stored form data relating to forms required by at least one other server.

20. The method of claim 19 wherein said parsing includes comparing data fields in said blank form with said stored form data recorded in said additional database.

21. The method of claim 19 wherein said maintaining an additional database includes parsing form data from said at least one other server.

22. The method of claim 21 further comprising the step of: filling in said blank form using a fuzzy fill procedure as a result of said parsing.

23. The method of claim 19 further comprising the step of: automatically submitting the result of said filling to a second server.

24. A method of automating login transactions, comprising the steps of: maintaining a database having stored data recorded therein at a first server; selectively extracting said stored data responsive to a request; obtaining a blank login form; parsing said blank login form to identify which of said stored data should be used to fill in at least a part of said blank login form; filling in said blank login form using said stored data; and employing program code residing on said first server for automatically submitting the result of said filling to a second server.

25. The method of claim 24 wherein said selectively extracting includes extracting data for all fields in said blank login form.

26. The method of claim 24 wherein said obtaining a blank login form includes receiving form data from said second server.

27. The method of claim 24 wherein said filling in said blank login form includes using a fuzzy fill procedure.

28. The method of claim 24 further comprising the step of: maintaining an additional database at said first server, said additional database having stored form data recorded therein, and said stored form data relating to login forms required by at least one other server.

29. The method of claim 28 wherein said parsing includes comparing data fields in said blank login form with said stored form data recorded in said additional database.

30. The method of claim 28 wherein said maintaining an additional database includes parsing login form data from said at least one other server.

31. A system for capturing electronic receipts, comprising:

a first server receiving electronic correspondence and parsing said electronic correspondence to identify commercial data related to a commercial transaction; and

program code residing on said first server for creating receipt data by extracting said commercial data from said electronic correspondence.

32. The system of claim 31 , wherein said first server permits display of said receipt data.

33. The system of claim 31 , further comprising:

a database at said first server; and

wherein said first server permits alteration of header data of said electronic correspondence in accordance with data records stored in said database.

34. The system of claim 33, wherein said program code includes instructions for storing said receipt data in said database.

35. The system of claim 34, wherein said first server permits extraction of said receipt data from said database.

36. A method for capturing electronic receipts, comprising the steps of:

receiving electronic correspondence; and

examining said electronic correspondence to extract commercial data related to a commercial transaction.

37. The method of claim 36, further comprising the step of updating header data of said electronic correspondence.

38. The method of claim 37, wherein said updating header data comprises the steps of:

querying a database of address data; and

altering header data of said electronic correspondence in accordance with a result of said querying.

39. The method of claim 36, wherein said examining comprises the steps of:

querying a database of template data; and

comparing said electronic correspondence with said template data obtained from said querying.

40. The method of claim 36, further comprising the steps of:

providing a database for storing receipt data; and

storing identified commercial data as receipt data in said database.

41. The method of claim 39, further comprising the steps of:

parsing said electronic correspondence to create parsed data if said comparing does not identify said electronic correspondence as containing said commercial data; and

examining said parsed data to extract said commercial data, if said parsing results in an identification of said commercial data in said electronic correspondence.

42. A system for capturing data from electronic correspondence, comprising: a first server receiving electronic correspondence;

a database having data records accessible to said first server;

program code residing on said first server for parsing said electronic correspondence to identify data content; and

additional program code for extracting said data content in accordance with instructions contained in said data records.

43. The system of claim 42, wherein said first server permits display of said data content.

44. The system of claim 42, wherein said first server permits alteration of header data of said electronic correspondence and wherein said first server forwards said electronic correspondence to a second server in accordance with instructions contained in said data records.

45. The system of claim 42, wherein said program code includes instructions for storing said data content in said database.

46. The system of claim 45, wherein said first server permits extraction of said data content from said database.

47. The system of claim 42, wherein said first server permits alteration of said instructions contained in said data records.

48. The system of claim 42, wherein said electronic correspondence contains data content related to an e-receipt.

49. The system of claim 42, wherein said electronic correspondence contains data content related to contact information.

50. The system of claim 42, wherein said electronic correspondence contains data content related to news.

51. The system of claim 42, wherein said electronic correspondence contains data content related to a securities mark.

52. The system of claim 42, wherein said electronic correspondence contains data content related to a schedule.

53. A method of capturing electronic data, comprising the steps of:

maintaining a database of data records;

receiving electronic correspondence; and

examining said electronic correspondence to extract data content in accordance with instructions contained in said data records.

54. The method of claim 53, further comprising updating header data of said electronic correspondence.

55. The method of claim 54, wherein said updating header data comprises the steps of:

querying a database of address data; and

56. The method of claim 53, wherein said examining comprises the steps of:

querying a database of template data; and

comparing said electronic correspondence with said template data.

57. The method of claim 53, further comprising the steps of:

providing an additional database for storing said data content; and

storing said data content in said additional database in accordance with instructions contained in said data records.

58. The method of claim 53, wherein said first server permits alteration of said instructions contained in said data records.

59. The method of claim 53, wherein said examining includes extracting data content related to an e-receipt.

60. The method of claim 53, wherein said examining includes extracting data content related to contact information.

61. The method of claim 53, wherein said examining includes extracting data content related to news.

62. The method of claim 53, wherein said examining includes extracting data content related to a securities mark.

63. The method of claim 53, wherein said examining includes extracting data content related to a schedule.