JP2002535754A - Client-side electronic form completion method and apparatus - Google Patents

Abstract

SUMMARY A method, system, and computer program product for automatically filling an electronic form on a user computer having a program that can be implemented as a browser are disclosed. The present invention provides the user with the ability to manually enter data into electronic forms without having the user store any programs or data on the user computer, and without compromising the user's security by having window cross communication. Alleviate the burden. This is done by using a remote personal information server that registers and stores user data and delivers the user data as an executable code module to any browser where the user will be.

Description

DETAILED DESCRIPTION OF THE INVENTION

BACKGROUND OF THE INVENTION The present invention relates generally to computer software for filling out form documents over a computer network. In particular, the present invention provides a method and system for automatically filling out fields in an electronic form document on a browser program using a remote server.

[0002] 2. Description of the Related Art Rapid growth and technological advances are changing the way many people now use computers. In the early days of computers, there was a paradigm that there were more computer users than computers, so most computers had many designated or dedicated users. As technology has advanced, personal computers ("PCs") have emerged, and it has become commonplace that many computers have only one user. The next period of growth, particularly in the 1990s, has seen the emergence of a culture or paradigm in which computer users access one or more computers. As mentioned above, many individuals currently have substantial access to multiple computers, for example, at work, school, libraries and homes, and while traveling. The percentage of available computers per computer user will increase over time. Thus, it is increasingly desirable to have computer-based programs and services accessible to a particular user from any computer, rather than a computer programmed or applied for that particular user.

[0003] One consequence of the recent explosive computer growth is the amount of communication that occurs between remote computers or remote computer systems. Many methods and systems exist for communication between computers or computer systems. This has many implications, such as the growth of the Internet. For the discussion that follows, some methods and systems are described with respect to the Internet as a matter of convenience. However, this does not limit the scope of the present discussion,
And many other devices and protocols applicable to computer communications, such as "intranets", closed proxy networks, enterprises-
You must understand that there are wide networks, direct modem connections, etc.

A browser program capable of operating one or more windows can utilize a simple method of communicating information between multiple computers over the Internet, as illustrated in FIG. Typically, of the pool of random independent Internet users 101-106, independent Internet user 106 opens a browser window 131 in the Internet browser program, depicted by arrow 161. Thereafter, the user 106 sends the Internet web page 14 to be downloaded to a browser window 131 belonging to the user 106.
4 (for example, an HTML page). The request of the user 106 is processed by the browser program and a connection is made with an appropriate remote Internet resource 112, typically an Internet web server, selected from a pool of random remote Internet resources 110-112, as depicted by arrow 161. You. Remote Internet resource 112 returns an HTML document 143, depicted by arrow 163. The HTML document 143 substantially contains the complete content needed to display a complete web page 144. Thereafter, the web page 144 returns to the user 106 and is displayed in the browser window 131, depicted by arrow 164.

[0005] A model known in the art as the "ad server" model advances this simple browser programming method of communicating information over the Internet. Many Internet browser pages are composite pages and obtain information in the form of images, text, and / or codes to be derived from several different remote Internet resources. Ad servers are commonly used to integrate electronic materials such as banner advertisements directed to such composite Internet web pages. In this way, the ad server
FIG. 3 is one example of a remote Internet resource that provides the composite web page with the material separately. FIG. A computer network communication method using an ad server is also shown in FIG.

The independent Internet user 102 opens a browser window 130 in the user's Internet browser program, depicted by arrow 151. Thereafter, the user 102 places a request on the Internet web page 142 to be downloaded to the browser window 130. This request is processed by the browser program and a connection is made with the appropriate remote Internet resource 110, typically an Internet web server, as depicted by arrow 152. Remote Internet resource 110 returns a core HTML document 140, depicted by arrow 153. The core HTML document 140 includes additional remote content resources 120, in this case, some displayable content and additional links to other images 141, in this case an ad server, stored in an ad server. The browser program parses the core document 140
Then, find and use this link to search for image 141. Thereafter, the browser program connects to the remote Internet resource 120, depicted by arrow 154, and retrieves image 141. The remote Internet resource 120 returns the image 141, depicted by arrow 155, to the browser program. Thereafter, an image 141 appears along with the displayable content of the core document 140 to have a complete web page 142. Thereafter, the web page 142 is returned to the user 102 in the browser window 130, as depicted by arrow 156, and is displayed. It should be appreciated that this method will be repeated many times for many different parts of a particular web page. In fact, many web pages
Includes links to a number of other remote Internet resources required for this method to be repeated for each other link.

[0007] Many remote Internet resources include a special user identifier containing state information, called a session identifier or "cookie", whenever a user connects to the resource and retrieves an Internet web page, for example. , Assigned to each particular user. This cookie is placed in the user's browser program. The program instructs the resource to look at the cookie on the next visit, so that the resource can recognize the user. The cookie conveys to the resource who is the user and which documents or components the user wants. The use of these cookies means that when components are assembled from various remote Internet resources into one integrated web page, the page core HTM is used while the page is assembled.
L-document resources are important because various visits or communications can be obtained from a web browser. Without such a cookie, using a composite web page would be substantially prevented. Many resources allocate a temporary cookie for this purpose, which expires at the end of the session or when closing the browser program. However, other cookies are
Beyond one Internet session, allocated for a long time for recognition. For one such purpose, long-term cookies or persistent cookies identify the user to special user histories and preferences, and thus provide information, such as content-specific banner ads associated with such user histories and preferences. Such information will be directed to recognized users in the future.

[0008] Proxy systems generally group many individual computers and computer users into a single network. This network typically works with a single proxy server. The proxy server acts as a conduit for all communications between personal network users and between certain personal network users and certain external remote electronic resources or users. Proxy servers provide some useful functions, such as high-speed communication between network users,
It is possible to provide firewall protection for all network computers and a large-capacity and high-efficiency storage device. One example of efficient storage by a proxy server occurs when one network user requests a web page from a remote resource that has recently been retrieved by other network users. Rather than re-searching the same web page from the same remote resource,
The proxy server simply delivers the web page stored in it from the previous request. While using a proxy server to change the path that information and communications will traverse, such use does not substantially change the basic functionality of the methods and systems described herein. Should understand.

In general, a number of methods can be used to assist a user in completing an electronic form document. One such method is called the "wallet" method, which can be found, for example, in "eWallet" at http://www.ewallet.com. This method requires the user to download the software application and install it on the user's computer. The user will then need to enter a personal information item into the application, including username, address, and credit card information. This information is stored on the user's computer for future use. The user can then use this “e-wallet” application and the personal information item entered to automatically fill out an electronic form document that is closely related to the “e-wallet” application. Whenever the user wishes to fill out the relevant electronic form document, the user opens the "e-wallet" application and clicks and drags the virtual credit card from the virtual wallet onto the form document. Thereafter, the "e-wallet" application automatically inserts the entered personal information item into the document. The click and drag process must be repeated for each page of the electronic form document. Then, before transmitting, the user
View and approve form documents.

[0010] Another method of assisting a user in completing an electronic form document is the so-called "transactor" method. This is, for example, http: in the //www.t ransactor.net "transactor Networks (Transacor Networks)"
Can be found in This method differs from the wallet method in that the user does not need to download or install any software on his computer. Instead, the personal information items are entered and stored in a database on a remote server. This server is then accessed each time an attempt is made to fill an electronic form document. This remote server containing the personal information items is accessed through a browser window separate from the browser window containing the electronic form document to be filled. Thus, this method requires communication between remote browser windows.

FIG. 2 shows a method of filling an electronic form document using the transactor method. The independent Internet user 202 of the pool of random independent Internet users 201-206 opens a browser window 230 in the user's Internet browser program, depicted by arrow 251. Thereafter, user 202 places a request on a web page containing electronic form document 240 to be downloaded to browser window 230. This request is processed by the browser program and a connection is made with the appropriate remote Internet resource 210, typically an Internet web server selected from a pool of random remote Internet resources 210-212, as depicted by arrow 252. . Remote Internet resource 210 returns an HTML web page, including electronic form document 240, depicted by arrow 253. This process may include retrieving other portions of the web page from another remote electronic resource, as described above in the ad server model. User 202 opens another remote browser window 231, typically via a bookmark,
Activate the "transactor" method. Thereafter, the browser program connects to the transactor server 220, as depicted by arrow 255, and retrieves the user personal information item 241. Transactor server 220
Returns the user personal information item 241 to the browser program in the browser window 231, depicted by arrow 256. It should be noted that the process represented by arrows 254-256 will be completed before or after the process represented by arrows 251-253. Once both processes are completed, window 231 initiates communication with window 230 and begins automated entry of electronic form document 240 in window 230. The window communicates, if necessary, until the form 240 is filled, depicted by a double-ended arrow 257. The filled-in electronic form document 242 is then returned to the user 202 in the browser window 230, depicted by arrow 258, and displayed. The user 202 can then view and approve the completed electronic form document before transmitting it as a complete form.

However, both “wallets” and “transactors” have some disadvantages. Both methods require a substantial initial time investment required for the user to enter all of the user's personal information items. The wallet method also requires the user to download and install software on the user's computer. This is a problem if the user uses a computer that does not have the installed wallet program and the input personal information item of the user, as there is no way for the user to access this method.
Re-installing and re-inputting for each computer that the user has access to is not only inconvenient, but also because the computer used by the user initially has the user's personal information item. Impossible in practice. While the transactor method attempts to overcome this deficiency of the wallet method in a server-side database, it requires cross communication between windows. This is known in the art to jeopardize user security. In addition, the need to retrieve information from the server-side database during window cross communication slows down the automated electronic form document entry process.

[0013] Accordingly, what is desired is a method and system for a remote server-based application that quickly and automatically fills out electronic form documents, thereby allowing users to manually enter data into such form documents. And a system that reduces the burden on users, eliminates the need for the user to be on a particular computer, and does not compromise user security. In other words, what is desired is a method and system that allows a computer user to automatically fill out electronic form documents with a simple click of the mouse from any computer or network client location. Also, what is sought and granted in such methods and systems, is that the user does not need to download or install any type of permanent or resident software on any computer and automatically converts electronic form documents. Ability to fill in.

[0014]

Summary of the Invention

In the present invention, methods, systems, and computer program products for automatically filling out electronic forms on a user computer having a program that can be implemented as a browser are disclosed. The present invention provides the user with the ability to manually enter data into electronic forms without having the user store any programs or data on the user computer, and without compromising the user's security by having window cross communication. Alleviate the burden. This is done by using a remote personal information server that registers and stores user data and delivers the user data as an executable code module to any browser where the user will be.

In one aspect, the present invention provides a method for automatically filling an electronic form document. The method includes accessing an electronic form using a browser, executing a link to a personal information server, receiving a personal information module transmitted from the personal information server, and executing the personal information module to execute the module. Is filled in the fields in the electronic form using the data contained in. Advantageously, this allows the user to automatically fill out an electronic form without requiring the user's computer to store any programs and data, and without using inter-window communication.

In one embodiment, the electronic form is downloaded from a remote web server that has already registered the form with a personal information server. Connections between the remote web server, the user computer, and the personal information server are all made via the Internet. In another embodiment, executing the link includes transmitting a session identifier, such as a user cookie, and an electronic form identifier, such as a uniform resource locator, from the browser to the personal information server. In yet another embodiment, transmitting the personal information module includes examining the electronic form and the derived negotiation history module of the user. These negotiation history modules preferably include a form mapping corresponding to an electronic form and a raw data profile corresponding to a user. Other embodiments include submitting an electronic form after some or all of the fields have been completed. This transmission may send the completed electronic form to the personal information server, where the user data is updated if necessary, and may be sent to the remote web server from which the electronic form came.

In a second aspect, the present invention provides a system for automatically filling out electronic forms. The system includes an information server having a plurality of registered users and personal information for form mapping, a web server having an electronic form registered in the information server and having an input button, a browser capable of downloading the electronic form, and A user computer having a user registered in the information server. The information server and the user computer communicate over a network to send an electronic form, which is partially or completely filled out when the input button is activated.

In a third aspect, the present invention provides a computer program product for automatically filling out an electronic form on a user computer having a browser. The computer program product includes a computer-readable medium having computer code for performing a number of functions. These functions include accessing an electronic form, performing a link to a personal information server, transmitting a personal information module from the personal information server to a user computer, and executing the personal information module at the user computer to perform multiple fields of the electronic form. Including filling in.

[0019]

DETAILED DESCRIPTION OF THE INVENTION

The invention will be better understood with reference to the following description, taken in conjunction with the accompanying drawings. Reference will now be made in detail to the preferred embodiments of the invention. An example of a preferred embodiment is illustrated in the accompanying drawings. While the invention will be described in connection with the preferred embodiments, it will be understood that they are not intended to limit the invention to certain preferred embodiments. On the contrary, the intention is to cover variations, modifications and equivalents, which can be included within the spirit and scope of the invention as defined by the appended claims.

Various figures illustrate a method and system for automatically filling out electronic forms on a computer that does not require the user to download or install any resident software on the computer. As the presence of merchants and services on the Internet increases,
Electronic trading or e-commerce is growing. More consumers will go to the Internet, for example, to purchase goods and services. This is typically
Give the consumer / user at least some data to the merchant, typically various fields, most commonly names, addresses, credit card numbers,
It would need to be provided by filling out an electronic form with a telephone number or the like. For consumers, purchasing merchandise from many merchant sites and possibly using a variety of computers (eg, work computers, other computers at home, and other computers while traveling or traveling), these forms Repeating manual entries is tedious, tedious and inefficient. The present invention seeks to inform consumers / users of the privacy precautions given by a particular merchant site, while at the same time reducing the burden of completing electronic forms, and downloading any resident software to users. Try not to need to be done. What is inherent in the latter feature is that it allows consumers to use the process of the present invention from any computer connected to a network, especially the Internet.

The present invention uses a remote server or a new electronic resource that responds to data requests by creating and transmitting specific documents in the form of a “privacy bank”, ie, JavaScript. . The Javascript is dynamically formed by the privacy bank upon receiving a request for data. The Javascript generated by Privacy Bank is a "profile", i.e., where the user has access to a particular merchant site (eg,
ishermanstore.com ") is a mapping between the field names in a particular form that need to be filled out at the privacy bank server and the standardized field names stored on the privacy bank server. Most of the fields in the Fisherman Store form are automatically filled in. In the described embodiment, the user becomes a member of the Privacy Bank by providing personal information (also called raw data) to the Privacy Bank once. This raw data can be updated from time to time by the user, if desired.In another aspect, the user can enter privacy rules or requests when initially becoming a member. Squid There is no need to download any software from the resource.In the described embodiment, the merchant (eg, Fisherman Store) provides the affiliate or affiliate of the Privacy Bank Network by providing a sample document of the form or forms. member)
It becomes. The privacy bank can then establish a mapping between the fields in the merchant's form and the standardized fields in its own database. These methods, components, and associated data structures are described in the various figures that follow.

FIG. 3A is a block diagram of a system for automatically filling out electronic form documents according to one aspect of the present invention. Many end-user computers are shown on the right side of the figure. These computers can be client computers in a network that access the Internet or can be part of an intranet. In the described embodiment, end-user computer 302 is a stand-alone computer that accesses the Internet, and includes an Internet browser program and browser window as shown at 304. In the center of the figure,
There are many web servers. One particular web server 306 is a server such as a merchant website, for example, www.fishermanstore.com , which allows a user or consumer to purchase and visit merchandise online on the Internet. On the left side of the figure, in the described embodiment, there is a specific electronic resource called a privacy bank server computer 308, which also connects to the Internet.

The method of automatic electronic form completion begins with a user downloading a form from a website, such as a Fisherman store site. The manner in which a user becomes a member and how to log in to the privacy bank server is described in more detail in FIG. Returning to FIG. 3A, a user / consumer on computer 302 (“user 302”) is represented by an arrow 310, a Netscape Navigator or Internet Explorer.
browser window 3 in Internet browser programs such as xplorer)
Open 04. User 302 then, go to ww w.fishermanstore.com indicated by the arrow through the browser, it determines the purchase of goods. The user 302 then downloads the electronic purchase form needed to complete from the website contained on web server 306, as depicted by arrow 314. A purchase form 316, typically an HTML document, is returned and downloaded and displayed in browser 304. At this point, the user 302 will typically have to fill in the "manual" fields of the purchase form. Most of this information is typically standard. That is, the name, address, telephone number, payment method, user e-mail address, and the like. In accordance with one aspect of the present invention, user 302 can "click" on a privacy bank icon or button in form 316 to have the form automatically filled out.

As mentioned above, in this discussion, www.fishermanstore.com is registered with the privacy bank server 308, thereby allowing the privacy bank server 30
Assume that you are a relevant member of the Assessable Privacy Bank Service from Step 8. Purchase form 3 if you are a related member of Privacy Bank Service
16 includes a privacy bank icon or button 318. By clicking on the privacy bank icon 318, the user 302 automatically sends the completed form to the privacy bank service on the server 308, depicted by arrow 320, by invisibly submitting the form to the form 316. Complete the filling method essentially. Once the form 316 (HTML document), which occurs when the form 316 is downloaded, is parsed, the information needed to fill out the form is sent to the user 302. This method is described in more detail in FIG. The user 302 informs the privacy bank server 308 of the user's identity and which form on the website (s) he wants to fill out and which website. This information is transmitted to privacy bank 308, unknown to user 302, when downloading form 316. The accompanying technology will be described below. Once the privacy bank server 308 receives a request from the registered user 302 (by an external link in the form 316 executed when the form is parsed by the user 302), the user computer 30
2. Start creating the information that must be filled out in form 316 on 2. Arrow 32
2 will be described in more detail with reference to FIGS. 6 and 7. In the described embodiment, the information transmitted to the user computer 302 is a Javascript program 324 called a "profile." Briefly, this profile includes a mapping of privacy bank standardization fields and fields in the purchase form 316 to "raw" data associated with the user 302, typically personal data. The contents of this profile and the general Javascript program will be described in more detail in FIGS. 7A and 7B below. User computer 30
2 once received by the browser program on 2, the completed purchase form 31
6 is displayed to user 302 as depicted by arrow 326. This occurs when the user 302 presses or clicks on the privacy bank icon 318. The information needed to complete form 316 already resides in the browser program. At this point, the user 302 may submit a form or decline to submit a form (typically after seeing the Fisherman Store website privacy safeguard or for other reasons). After filling in several fields such as items to buy, quantity, etc.) it can be decided whether to proceed.

FIG. 3B shows an electronic form on a remote user computer that can be automatically filled in.
FIG. 3 is a block diagram illustrating components of a privacy bank server. A privacy bank server, such as server 308 in FIG. 3A, includes some of the functional and storage components needed to compile the data needed to fill out a form, such as form 316. In the described embodiment, four large components of the privacy bank server are shown in FIG. 3B. These components and storage include a raw data profile storage 328, a form mapping storage 330, a negotiation history module 332, and a shippable code constructor 334. The raw data profile storage area 328 includes a set of data, a set or a profile, shown in area 336, that is associated with a registered user of the Privacy Bank service. Registered users have a unique account number, shown in area 338, that can be used as an identifier and password. 8A and 8
The standard field names set by the Privacy Bank Service, discussed in more detail in B and 8C, are the data string entered by the user (first name or home street address) followed by the use-prefer condition.
ence condition). The use-selection condition is used in the negotiation history module 332. This is discussed in more detail in FIG. 7 below. This data is included in area 340. Other profiles of other registered users are shown in area 342. Each registered user has a similar raw data profile.

The form mapping area 330 includes a plurality of form mappings, an example of which is shown in an area 344. Each electronic form that is registered with the privacy bank service by an online merchant or seller (ie, an affiliate) has a form mapping. The privacy bank standard field name is shown in FIG.
Match or map "non-standard" field names from electronic forms registered with the service, as discussed in A, 8B and 8C, and as described above in area 340. For example, the non-standard field name for an individual's last name could be "Last Name", "Surname", or simply "Last". Different forms use different variants of the name for this or other fields. This will map to the Privacy Bank "standard" field name, which in the described embodiment is "Person Name.Last". Also, the area 346 contains a practice-preference condition provided by the online merchant or seller when registering the form.
ition). This condition is used by the negotiation history module 350 and the dispatchable code constructor 334, as in the use-selection condition in field 340. This is discussed in more detail in FIG. 7 below. Another mapping 348 having the same format for other registration forms continues in region 344.

The negotiation history module 332 is used to determine which fields in the electronic form are automatically filled out by the privacy bank server. The processing associated with the negotiation history module 332 will be described in more detail with reference to FIG. Module 332 includes a plurality of negotiation objects, an example of which is shown in region 350. In the described embodiment, each negotiation object corresponds to a "non-standard" field of the form. Briefly, the negotiation object 350 is based on privacy and usage selections (as communicated to the usage-selection criteria in area 340) and the fields in the form are set by the user (practice-selection criteria in area 346). Include information about what to fill out, as compared to the intended practice (as communicated by). This comparison is made in the negotiation history module. The module includes a negotiator or comparator that compares these conditions. Specific conditions in the described embodiment are described below. If a decision is made to fill in a non-standard field in the form, area 340
Will be included in the negotiation object 350. The dispatchable code constructor 334 includes a component 332
And access storage areas 328 and 330 to derive software modules for transmission to the user computer. In the described embodiment, the software module is a Javascript program transmitted to and executed by a browser on a user computer, thereby inserting a plurality of data strings into form fields.

FIG. 4 is a flow diagram of a method for automatically filling an electronic form of a computer network according to one aspect of the present invention. The method described hereinafter is described in FIG.
Can be performed by the configuration of the server and the computer described in. At step 402, an online user / consumer wishing to purchase a product on the Internet downloads an electronic form to make a purchase to the user's browser program.
At step 404, the browser parses the contents of the electronic form, typically an HTML document, and recognizes all external links. As is common with web pages, HTML documents include links to other external websites from which to retrieve content or other types of data. In many instances, web pages are composites of different components from various sites within the core HTML document. One example is an external link to an ad server that retrieves the banner ad component of the core HTML document. In this case, the electronic form can be viewed as a core HTML document. This parsing
Is automatically performed by the browser and is a well-known feature.

At step 406, the browser identifies an external link to the privacy bank server. In the described embodiment, this link will be mandatory since the website is an affiliate site of the privacy bank service network of the registration site. A description of what "registration" means in this context is described in more detail below. At step 408, the browser executes an external link to connect the browser with the privacy bank server. The external link is, in the described embodiment, referred to as a dispatchable code link to a privacy bank server. In this context, the dispatchable code is a JavaScript program transmitted from the privacy bank server to the user computer and browser. This shippable code can be used to describe the electronic form in a manner described in more detail below.
Can be filled out automatically. At step 410, once the privacy bank server has been contacted via a routable code link in the electronic form, the privacy bank server will contact the user computer or browser with a valid state identifier ("cookie") previously assigned to it by the privacy bank server. "). A cookie is used when a user first visits a website in any given session (the time that the user logs on to the web and then leaves the web by leaving the browser), whether on a web server or a server such as a privacy bank server. The identifier assigned to the user / visitor by the website. The cookies assigned by the website belong to a particular user. In the described embodiment, the user holds this cookie (temporary cookie) during the session, from which the website can recognize the user when the user returns to the website during the session; A cookie is provided on the website that allows the user to retrieve user characteristics from the data repository. As is known in the Internet application programming art, cookies can also be made persistent after a user logs off a browser, so that they remain with the user and can be used in new sessions. The concept and execution of cookies themselves is
It is well known in the Internet, and more generally in the field of computer network programming.

If the privacy bank server determines that the user computer or browser does not have a valid cookie, it means that the user has not yet logged in to the privacy bank service. If so, control is passed to step 41
Go to 2, where the privacy bank server retrieves the login sequence code. Thus, as described in more detail below, the code can trigger a login sequence, causing the user to log in and register with the Privacy Bank Service in a later step of the method. At step 414, the privacy bank server forms a complete package of the dispatchable code including the retrieved login sequence code, so that in a later step of the method, the login sequence is triggered. At step 422, the browser retrieves this complete package of codes that can be sent from the Privacy Bank server. The dispatchable code is then stored in a browser resident on the user computer and can be executed by a user trigger, described in more detail below.

If the privacy bank server determines that the user / browser contacted by downloading the electronic form and executing an external link has a valid cookie, control passes to step 416, where the privacy bank server determines Obtain the user's cookie and read the cookie. In this context, having a valid cookie indicates that the user has recently gone through a login sequence, for example during a current Internet session, so that the user does not have to go through the login sequence again. . By reading the user's cookie, the privacy bank server can determine who the user is and thus search the user's raw data stored in the privacy bank. The content and format of this personal raw data is described in more detail in FIGS. 8A, 8B and 8C. At step 418, the privacy bank server retrieves user data for the user identified by the valid cookie. The privacy bank server sends the user data and identifier, for example, a URL (uniform
source locator) to determine how to fill out the electronic form document. At step 420, the privacy bank server forms a complete package of dispatchable code (item number 324 in FIG. 3A) that includes the user data used to fill out the form document. In the described embodiment, this dispatchable code (called a profile) is in the form of a Javascript program. This dispatchable code is formed from information in a privacy bank memory that allows a form document to be automatically filled out in a later step of the method. At step 422, the browser receives the routable code, or profile, from the Privacy Bank server and accesses it on the user computer, if desired by the user. This profile is stored in a browser resident on the user computer and can be executed by a user trigger.

If the user wants to automatically fill out an electronic form using the privacy bank, the user executes a user trigger. In the described embodiment, at step 424, the trigger is generated by the user clicking on an "autofill" button included in the form and associated with the privacy bank. By clicking on the auto-fill button, the user causes the browser to execute the dispatchable code or the profile stored therein. At step 426, determine whether the dispatchable code includes user data that will allow it to fill out a form document. If the user data is contained in a dispatchable code resident on the browser, control proceeds to step 434 where the browser utilizes the dispatchable code and the user data to fill the electronic form document. Of course, as described above, when the form document is searched first, the user data present in the dispatchable code is:
Relying on a browser with valid cookies already present.

However, if the user data is not included in the dispatchable code resident in the browser, control proceeds to step 428, where a login sequence is initiated to identify the currently unknown user. You. The dispatchable code used by the browser in this step includes the login sequence code,
This is the result of the browser not having a pre-existing valid cookie when the form document was initially retrieved, as described above. The login process of step 428 is described in more detail in the part of FIG. Once the user has completed the login sequence in step 428, the privacy bank server assigns a cookie to the user / browser, which instructs the privacy bank to
In subsequent transactions, it is possible to recognize the message from the user and the user's browser. In step 430, the privacy bank server retrieves the user data of the recognized user, concatenates the user data with an identifier such as a URL (uniform resource locator), and describes how the electronic form document is filled out. And form a complete package of routable code that includes the user data used to fill the form document. This step is substantially the same as step 418, described above.
Same as 420. In step 428, the browser has received the routable code or profile from the privacy bank server and is accessing it at the user computer. Now, the dispatchable code includes user data that allows the form document to be automatically filled out. At this stage, control proceeds to step 434, where the browser uses the dispatchable code and the user data to fill out an electronic form document.
No further input from the user is required, for example, a re-click of the "autofill" button. In other words, once the user has properly completed the login sequence, the form is automatically filled out and it is not necessary for the user to click the "auto-fill" button again.

At step 436, the user visually inspects the completed form and the privacy features provided by the website to determine if the form is acceptable. If the user finds that the form requires further adjustment, at step 438, the user adjusts the document. This can be done manually or through any auxiliary automated process such as a client-based macro. This includes filling in fields that could not be filled out by the profile sent by the privacy bank server (in other words, fields that could not be filled out from raw data).
Such fields include, for example, the item purchased and the amount of the item. It also includes updated personal information such as a new address and a new credit card number. In this case, the user simply has to retype the information already in the field. Control then returns to step 436, which will be satisfied after proceeding to step 438. In step 440, when the user clicks the Submit button in the browser window, the browser finally sends the completed electronic form to the merchant's web server. In the described embodiment, the completed form is first transmitted to a privacy bank server that is not known or at least invisible to the user. The completed form is received and inspected by the Privacy Bank, which updates its raw data repository to reflect any changes the user has made to the user's personal information. Then, the privacy bank server sends a message back to the user computer (HT
According to the TP protocol, when the server receives an HTML document from a user, it must send a message back to the user. ). In the described embodiment, the message returned or sent to the user's browser is similar to a "Click Here To Continue" type screen for the user. Hidden behind this message is the completed form sent to the privacy bank server. Possibly, the user clicks on to proceed, thereby submitting the hidden completed form to the merchant's web server. In another preferred embodiment, the completed form is sent to the privacy bank server and the merchant's web server simultaneously.
In yet another preferred embodiment, the completed form is automatically sent from the privacy bank server directly to the merchant's site without any additional input from the user. At this stage, the automatic form filling process is completed.

FIG. 5 is a flow diagram of a process for allowing a new user to join a privacy bank or log into an existing member to use services in one embodiment of the present invention. Portions of FIG. 5 are shown in more detail in step 428 of FIG. 4, where a login sequence is initiated to identify the user. Once the privacy bank server determines that the user does not have a valid cookie, the server inserts a login process for the user into the dispatchable code, and if the user does not already have one, An account is created.
This is done for the following reasons. If the user is the user's current session (c
Assuming that the cookie for the urrent session has not been assigned by the privacy bank, the user is not logged on to the privacy bank service or is probably not a registered member. The first occurrence in the login sequence is that the privacy bank server displays a login screen in the user's browser window, as shown in step 502. In step 504, the user determines whether the user is a privacy bank member and proceeds to use the appropriate section of the login screen. One section of the login screen requires the user to enter a user identification and password for an existing account, while another section allows the user to select an icon to route to the account creation screen.

As shown in step 506, for account creation, in the described embodiment, the user selects the “New Account” icon on the login screen. At step 508, a privacy bank account creation screen is displayed. At step 510, the user enters user identification, password, name, other information, and high-level privacy choices on the account creation screen. In essence, the user sets up accounts and personal information items that are stored for the user in the privacy bank repository. The information entered into the newly created account is sent back to the privacy bank server, as shown at step 512. At step 514, the privacy bank server accepts the new account information and establishes a new user location in the privacy bank repository. Then, the newly input information is recorded in the repository location. As shown in step 522, the privacy bank server sets a cookie for the current user session and the process ends.

For an existing user login, in the described embodiment, the user enters the user's existing user identification and password, as shown in step 516. In step 518, the login information is returned to the privacy bank server, which evaluates the information. At step 520, the privacy bank server determines whether the information sent is correct, ie, whether it corresponds to a valid user identification with an appropriate password. If the information sent does not correspond to a valid user identification and password, the attempted login fails and the process returns to step 502 and
A new login screen appears. If the information sent is correct, the login was successful and the process proceeds to step 522. The privacy bank server then sets the cookie for the current user session, as shown in step 522, and the process ends.

FIG. 6 is a flow diagram illustrating a process for deriving the parts needed to build a routable code segment or profile to be transmitted to a user according to one embodiment of the present invention. . It describes the process leading up to step 416 in FIG. 4 in more detail, where the browser retrieves the routable code sent from Privacy Bank. Recall that the user's browser parses the electronic form to identify any links to external resources, and then executes to obtain the external components to the core HTML document. In the case of a privacy bank server (the merchant's website from which the electronic form is downloaded is an affiliate of the privacy bank (affilia
te member)), the server receives the operation according to the link from the user and starts execution. In step 602, the user searches for two items: a user cookie and an identifier of the electronic form that the user will want to complete. A user cookie (assigned to the user by the privacy bank server from the time the user logs on to the service) informs the privacy bank server of the user's identity. The electronic form identifier includes the merchant's website identifier, and the particular form at the site that the user is downloading, and in the described embodiment, in the form of a URL. In many cases, there is only one form on a website.

At step 604, the privacy bank server retrieves the user's raw data from the privacy bank memory using the user cookie. The aspects and contents of the raw data are described in more detail in FIGS. 8A, 8B and 8C. Raw data is a set of data items that are very similar to those required to fill widely used electronic purchase forms. As described in detail below, each raw data item corresponds to a unique Privacy Bank standard label or name. In step 606, the privacy bank server uses the URL, or a special form identifier (eg, legacy name) to fill out to retrieve the mapping of each field name in the electronic form, to the privacy bank standard name. . This mapping or field name matching is performed when the merchant becomes a relevant member of the Privacy Bank Service. At this point, the merchant submits one or more forms to the Privacy Bank, which examines each field name in the form and matches it with the Privacy Bank field names. In the described embodiment, if there are legacy names that do not have a matching privacy bank field name, the privacy bank user raw data settings will be updated if the unique legacy field name appears to have started appearing in other forms. Is done. Alternatively, as shown in step 424 of FIG. 4, the user is caused to manually input.

In step 608, through a join-type operation, the server merges the retrieved name map with the user raw data. Two tuples (tu
ple) merger: Legacy name / privacy bank name tuple and privacy bank name / raw data value tuple are described in more detail below. The merger result is a series of tuples matching the legacy name with the raw data values associated with the user. In other preferred embodiments, the merger is performed using other data construction and operations. However, the result is a pairing of the legacy field name and the raw data value. At step 610, the series of merger tuples is converted into a dispatchable code. In the described embodiment, the dispatchable code is in the form of a Javascript program and is sent to a browser on the user's computer. Generally, a browser program has a JavaScript component operated by a JavaScript command. These Javascript commands in the dispatchable code are used to fill out electronic forms on the browser, and techniques are well known in the Internet and Java programming arts. Here, it is useful to know that the form is actually completed on the user's computer via a browser that uses Javascript commands for the dispatchable code. The form is not filled out on the Privacy Bank server, but the information to fill out the form is built there, but then sent to the user computer. At this stage, the process of deriving the dispatchable code on the privacy bank server is completed.

FIG. 7 is a flow diagram of a mapping process through which form names are mapped to user raw data values, according to one embodiment of the present invention. As described above, in step 702, the privacy bank server
Using the RL or other identifier, search for a mapping in the form that maps the legacy name by the Privacy Bank standardized name. The mapping includes one or more practices for each field name, which is described in more detail below. This mapping is generated when the merchant or service provider decides to become a relevant member of the Privacy Bank Service. In the registration process, the merchant informs the Privacy Bank which form it wants to register and the field names in that form, which are paired with the Privacy Bank standardized name. At step 704, the user cookie is used to obtain the user's raw data, which includes the actual data values and the selections associated with each data value. The above practices associated with the legacy name and the choices associated with the user's raw data are represented by conditions. In the described embodiment, there are a number of conditions such as marketing, system administration, personalization, research and development, activity completion (eg, order placement). Other embodiments have more or less conditions.

When a merchant registers with the Privacy Bank Service, it refers to which conditions each legacy field is used. For example, for the field "Last Name", the practice states that it will use this field for personalization and completion of activities, and nothing else. "
For the "Payment Method" field, this practice states that this field is used only for "Activity Complete", "Research and Development", and "Administration". In this way, the merchant builds a list of pairs (legacy field names, practices) stored at the privacy bank server. Similarly, when a user becomes a member of the Privacy Bank Service, the user is required to provide raw data values (specific fields of the raw data are described below) and corresponding choices are stated by the conditions. . From the user's point of view, these are privacy or use thresholds.
These are called choices because they indicate threshold). For example, the user may require that the last name be used only for "personalization", "activity completion", "system administration", and preclude its use as, for example, targeted "marketing". Can be. In the described embodiment, if the user does not specify the selection criteria, data items such as social security numbers or maiden maiden names are not released.

In step 706, the privacy bank server retrieves one (legacy name, practice) pair and its corresponding standardized privacy bank name from the form mapping retrieved in step 702. In the described embodiment, this pair is the first form field in the merchant's online form. In step 708, the server responds from the user's raw data "file" (standardized privacy bank name, selection)
Search for pairs. The privacy bank name in this pair must match the privacy bank name in the pair retrieved in step 706: [(legacy name, practice), PB name 1]: [PB name 1, select]

In step 710, the privacy bank server compares the practice conditions of the left merchant with the selection conditions of the right user. For example, for the last name field, the merchant specifies that it is a practice to use this data item for the conditions "personalization" and "activity completed". The user is subject to the user's last name subject to the terms "Personalization", "Activity Complete" and "System Administration"
To be allowed to use. The conditions of the merchant and the conditions of the user are compared. At step 712, the privacy bank server determines whether the merchant's form field is to be filled, taking into account the user's privacy threshold for that field. In the described embodiment, this is done by determining whether the user's selection condition is a superset of the merchant's practice conditions. That is, whether the merchant intends to use the user's last name other than the one specified by the user. In the last name example, the user's choice is a superset of the merchant's practices: "Personalization", "Complete Activity" and "System Administration" replace at least all of "Personalization" and "Complete Activity". Contains.

If the user's selection is not a superset of the merchant's practices, control proceeds to step 714, where the fields are automatically set because the merchant may use the information in ways other than the user's consent. A message is displayed to the user indicating that no entry will be made. In the described embodiment, if one field in the form meets this condition, no field in the form is filled and the process is complete. In another preferred embodiment, the user has the option to manually enter this field, and have the Privacy Bank service fill out the remaining fields.

If the user's selection is a superset of the merchant's practices, control proceeds to step 716, where the fields are filled with raw data values. Steps 710 and 712 are shown as a two-step negotiation process. The merchant form, indicated as "information buyer", applies for a user indicated as "information seller". The subscription is in the form of virtually any data item that the information buyer wants and for what purpose. This is the first step in the negotiation process, where the privacy bank server acts as a negotiator. The user obtains the application and checks whether the merchant's conditions exceed the user's choice. In other words, the user checks whether the merchant intends to use the data item for a purpose not specifically authorized by the user. If the merchant's practice conditions are acceptable (by performing the superset test in step 712), the user sends an acceptance to the merchant, at which point the raw data values are retrieved and associated with the legacy fields. .
If the merchant conditions are not accepted, the user is "not acceptable"
Send the message to the merchant via the negotiator without any raw data values. This completes the second step in the negotiation process. Each two-stage negotiation is viewed as an object that is later used to construct a Javascript program (dispatchable code) using standard Java programming techniques.

In step 718, the server checks the merchant's form for other (legacy name, practice) pairs. If there are more legacy fields, control returns to step 706 and the process repeats. If there are no fields to fill, the process is complete. At this stage, there is a series of objects or negotiation history derived from the mapping process. These sets of objects are used to build Javascript programs. In the described embodiment, all objects have the acceptance from the user and the accompanying raw data values included in the JavaScript profile sent to the browser / user. In other preferred embodiments, some of the objects may have an "unavailable" or rejected message indicating that certain specific fields of the form are not filled and have no raw data values. As described above, in the described embodiment, if one of the fields of the form is not filled due to merchant's practices exceeding the user's choice, the entire form is not filled. The dispatchable code or profile sent to the user is a series of (legacy names, raw data values) without any reference to selections and practices, all negotiations of data values performed on the Privacy Bank server. Represents a pair.

FIG. 8 is an elevation chart showing how fields including raw data and user selections are organized on a privacy bank server, according to one embodiment of the present invention. The top level user table 802 has four columns: USER 804, CATEGORY 806, TYPE 808, and SHORT DISPLAY NAME 810. The user table 802 has four rows: HOME (work) 812, work (work) 814, and billing (BILLI).
NG) 816, and the column user (USER) represented by SHIPPING 818.
) 804, there are four data areas. In the described embodiment, the user is provided with these four data areas when registering with the Privacy Bank Service and enters information through each of these data areas. Category (C
ATEGORY) 806, for a while, column type (TYPE) 808 moves the raw data tree down one level from the top level represented by table 802. For example, the data area home (HOME) 812 is Info. This is implemented as a pointer or link to the Info table 820. The first column 822 of table 820 is labeled Info, but the other three columns shown in table 802:
That is, the same applies to the category 806, the type 808, and the short display name 810.

In the table 820, the user starts to input data, and the data is the home information and the shipping data area 8 in the table 802.
18 Since the data also has Info in its type column 808, it is used for shipping. The name row 822 has in its type column 808 a reference to yet another table person name (PERSONNAME), as shown in table 824. Like tables 802 and 820, Person Name table 824 has a first column labeled Person Name and three columns similar to the other tables. All five data areas in the person name table 824: prefix (PREFIX), first (FIRST), middle (MIDDLE), last (
LAST), suffix (SUFFIX), as type (TYPE), in the described embodiment,
It has a primitive type referred to as text (TEXT). The text represents a data string, which is the actual data item stored on the privacy bank server. By examining the TYPE column 808 of each data area, the user enters all raw personal data. The actual data item is entered in each type box containing text and represents a leaf node when viewed as a primitive type or tree structure. If the type column does not contain text, there are other tables that further refine the data area.

Along with another example, in the data area billing 816 shown in the table 802, the type 808 indicates BillInfo, not text. Table building info also has six data areas, none of which are of the text type, and therefore no actual data values can be found at this level. Taking the credit card data area as an example, the type indicates "credit card". The table credit card shown in FIG. 8C has four data areas: Type, Number, and Expiration Month (ExpMo
nth), expiration year (ExpYear), all of which are type text and contain the actual data values.

The short display name column 810 includes a string, which is displayed to a user via the registration graphical user interface of the described embodiment. The user follows the data tree through the user interface using field names or short display names as a guide for data entry. The data area having a primitive type that is text in the described embodiment is a privacy bank field name, which is mapped to a legacy field name in the electronic form registered with the service. In the described embodiment, the privacy bank name includes the following (simplified form):

[0052]

[Table 1]

The category column 806 relates to the privacy settings set by the user, which privacy settings are connected to the selections set by the user and are defined by the conditions described above, especially in FIG. Related to privacy settings. Conditions or usage thresholds in the described embodiments are marketing, system administration, personalization, research and development, and completion of activities (eg, order placement). The categories that can be used in the embodiment of the description are physical contact information (Physical Contact Information) and online contact information (Online Co
ntact Information), demographic data (Demographic Data), and financial data (Financial Data). The relationship between the category and the condition in the embodiment of the description is described in a table of 5 rows and 4 columns (20 cell table), where each condition is one row in the table and each category is one column in the table.

The present invention employs a number of computer-implemented operations involving data stored in computer systems. These operations require, but are not limited to, physical operations of physical quantities. Usually, though not necessary, these quantities have the form of electrical or magnetic signals that are stored, transferred, combined, compared, or manipulated. The operations described herein that form part of the present invention are useful machine operations. The operations performed are often referred to in forms, such as producing, identifying, performing, determining, comparing, executing, downloading, or detecting.
These electrical or magnetic signals are converted into bits, primarily for reasons of common usage.
It is convenient to refer to values, elements, variables, features, data, and the like. However, it should be remembered that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

The present invention also relates to a device, system or apparatus for performing the above operations. The system is a general purpose computer specially constructed for the required purposes, or selectively executed or configured by a computer program stored in the computer. The process proposed above is not inherently related to any particular computer or other computing device. In particular, many general-purpose computers may be employed with programs written in accordance with the teachings herein, or it may be convenient to construct more specialized computer systems to perform the required operations.

FIG. 9 is a block diagram of a general-purpose computer system 900 suitable for performing processing in accordance with one embodiment of the present invention. FIG. 9 illustrates one aspect of a general-purpose computer system, such as the user computer of FIG. 3A,
Describes many components found in the privacy bank server 308. Other computer system architectures and aspects can be used to perform the procedures of the present invention. The computer system 900 including the following subsystems includes at least one microprocessor subsystem 90.
2 (also referred to as a central processing unit, or CPU). That is, the CPU 902 is executed by a single-chip processor or a plurality of processors. The CPU 902 is a general-purpose digital processor, and controls the operation of the computer system 900. Using the instructions retrieved from the memory, the CPU 902 controls the reception and operation of input data, and the output and display of data on an output device.

The CPU 902 unidirectionally communicates with the first primary storage device 904, typically a random access memory (RAM), and unidirectionally communicates with the second primary storage area 906, typically a read only memory (ROM). It is connected via a memory bus 908. As is well known in the art, primary storage 904 is used as a general storage area and as a scratchpad memory, and is used to store input data and processed data. It can also store programming instructions and data objects, i.e., data in the form of, for example, Javascript programs, in addition to other data and instructions of the processes executed on CPU 902, and Are used for fast transfer of data and instructions in a bidirectional manner via a memory bus 908. As is well known in the art, primary storage 906 typically contains basic operating instructions, program code, data, and objects used by CPU 902 to perform its functions. Primary storage devices 904 and 906 may comprise any suitable computer-readable storage media, for example, depending on whether data access requires two-way or one-way, as described below. The CPU 902 can also search the cache memory 910 for frequently needed data directly and very quickly.

The removable mass storage device 912 provides additional data storage capacity for the computer system 900 and the CPU 902 via a peripheral bus 914.
Is connected in two directions or one direction. For example, special removable mass storage devices are widely and commonly known as CD-ROMs, which typically store data on a C-ROM.
The floppy disk sends data to the CPU 902 bi-directionally, while the data is sent uni-directionally to the PU 902. The storage device 912 can also be read by a computer, such as magnetic tape, flash memory, carrier-loaded signals, PC cards, portable mass storage devices, holographic storage devices, and other storage devices. May have a suitable medium. Fixed mass storage device 916 also provides additional data storage capacity and is bidirectionally coupled to CPU 902 via peripheral bus 914. The most common example of mass storage 916 is a hard disk drive. Generally, access to these media is slower than access to primary storage devices 904,906.

Mass storage devices 912, 916 generally store additional programming instructions, data, etc. that are not typically in active use by CPU 902. The information held in the mass storage devices 912, 916 may be incorporated in a standard format, if necessary, as virtual memory as part of the primary storage device 904 (eg, RAM).

In addition to providing the CPU 902 to the storage subsystem, the peripheral bus 914 is used to provide access to other subsystems and devices. In the described embodiment, these include a display monitor 918, an adapter 920, a printer device 922, a network interface 924, a secondary input / output device interface 926, a sound card 928, a speaker 930, and other subsystems as needed.

A network interface 924 allows the CPU 902 to connect to another computer, a computer network, or a communication network using the network connections shown. Via network interface 924, C
PU 902 receives information, such as data objects and program instructions, from other networks, or outputs information to other networks according to the method steps described above. Information often represented as a sequence of instructions executed on a CPU is received from another computer network and output to another computer network, for example, in the form of a computer data signal carried on a carrier wave. An interface card or similar device and appropriate software executed by CPU 902 is used to connect computer system 900 to an external network and transfer data according to standard protocols. That is, the method embodiments of the present invention may be performed solely on CPU 902, or may be performed over a network such as the Internet, an intranet network, or a local area network, with a remote CPU sharing a portion of the processing. Additional mass storage (not shown) is also provided by the CPU 9 via the network interface 924.
02 may be connected.

Secondary I / O device interface 926 represents a general or customized interface that causes CPU 902 to transmit data and, more typically, a microphone, touch-sensitive display, transducer card reader, Allows data to be received from other devices such as tape readers, voice or handwriting recognizers, biometric readers, cameras, portable mass storage devices, and other computers.

A keyboard controller 932 for receiving an input from the keyboard 936 or the pointer device 938 via the local bus 934 is connected to the CPU 902.
8 is transmitted to the CPU 902. Pointer devices are mice, styluses, trackballs, tablets, and are useful when interacting with a graphical user interface.

Further, embodiments of the present invention relate to a computer storage product with a computer readable medium containing program code for performing operations performed by a number of computers. Computer readable media can be any data storage device that can store data which can be subsequently read by a computer system. The media and program code may be those specially designed and constructed for the purposes of the present invention, or may be well known to those skilled in the computer software arts. Examples of computer readable media are, but are not limited to, all the media described above: magnetic media such as hard disks, floppy disks, magnetic disks; optical media such as CD-ROM disks; Magneto-optical media such as; application-specific integrated circuits (ASICs), programmable logic devices (PLDs), specially configured hardware devices such as ROM and RAM devices. The computer readable medium is also distributed as a data signal on a carrier wave through a network of linked computer systems, and the computer readable code is stored and executed in a distributed manner. Examples of program code include, for example, machine code produced by a complier, files containing higher-level code executed using an interpreter.

For those skilled in the art, the hardware and software elements described above are standard designs and constructions. Other computer systems suitably used in the present invention may have additional or fewer subsystems. Further, memory bus 908, peripheral bus 914, and local bus 934 are examples of any connection scheme that provides a link to a subsystem. For example, a local bus may be used by the CPU to couple to fixed mass storage 916 and display adapter 120. The computer system in FIG. 9 is merely an example of a computer system suitably used with the present invention. Other computer architectures having different aspects of the subsystem can also be used.

While the above invention has been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. It is further noted that there are other ways to carry out both the process and apparatus of the present invention. For example, the raw data may include more or fewer fields than described if necessary, and there may be additional privacy or threshold usage conditions for the five described. In another example, the completed electronic form may be automatically sent to the merchant's web server after the privacy bank server updates its raw data without additional input from the user. In another example, raw data and legacy fields may be bundled and encoded in software modules other than the JavaScript module. Accordingly, the present embodiments are illustrative and not limiting, and the invention is not limited to the details given herein, but may vary within the scope and equivalents of the appended claims.

[Brief description of the drawings]

FIG. 1 is an illustration of a prior art “ad server” model.

FIG. 2 is an illustration of a transactor model according to the prior art.

FIG. 3A is an illustration of a system for automatically filling out electronic form documents according to one aspect of the present invention.

FIG. 3B is a block diagram illustrating components of a server that enables automatic insertion of data into an electronic form on a remote computer, according to one aspect of the invention.

FIG. 4 is a flow diagram of a method for automatically filling an electronic form document according to one aspect of the present invention.

FIG. 5 is a flow diagram of a method for an initial user session for a service for automatic electronic form completion, according to one aspect of the present invention.

FIG. 6 is a flow diagram of a method for constructing and transmitting a code segment dispatchable from a server to a user computer according to one aspect of the present invention.

FIG. 7 is a flow diagram of a mapping method whereby a form name is mapped to a raw data value of a user, according to one aspect of the present invention.

FIG. 8A is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 8B is a chart illustrating a format of a field name and registered user data according to an aspect of the present invention.

FIG. 8C is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 9 is a block diagram of an exemplary computer system suitable for performing certain aspects of the present invention.

[Procedure amendment]

[Submission date] August 3, 2001 (2001.8.3)

[Procedure amendment 1]

[Document name to be amended] Statement

[Correction target item name] 0011

[Correction method] Change

[Contents of correction]

FIG. 2 shows a method of filling an electronic form document using the transactor method. The independent Internet user 202 of the pool of random independent Internet users 201-206 opens a browser window 230 in the user's Internet browser program, depicted by arrow 251. Thereafter, user 202 places a request on a web page containing electronic form document 240 to be downloaded to browser window 230. This request is processed by the browser program and a connection is made with the appropriate remote Internet resource 210, typically an Internet web server selected from a pool of random remote Internet resources 210-212, as depicted by arrow 252. . Remote Internet resource 210 returns an HTML web page, including electronic form document 240, depicted by arrow 253. This process may include retrieving other portions of the web page from another remote electronic resource, as described above in the ad server model. The user 202 opens another remote browser window 231 to activate the "transactor" method, typically through the bookmark depicted by arrow 254 . afterwards,
The browser program is a transactor server (transact
or server) 220 to search for the user personal information item 241. Transactor server 220 returns user personal information item 241 to the browser program in browser window 231, depicted by arrow 256. Arrow 254-2
It should be noted that the process represented by 56 will be completed before or after the process represented by arrows 251-253. Once both processes are completed, window 231 initiates communication with window 230 and begins automated entry of electronic form document 240 in window 230. The window is a double-ended arrow 25
Communicate if necessary until form 240 is completed, depicted at 7. The filled-in electronic form document 242 is then returned to the user 202 in the browser window 230, depicted by arrow 258, and displayed. The user 202 can then view and approve the completed electronic form document before transmitting it as a complete form.

[Procedure amendment 2]

[Document name to be amended] Statement

[Correction target item name] 0025

[Correction method] Change

[Contents of correction]

FIG. 3B shows an electronic form on a remote user computer that can be automatically filled in.
FIG. 3 is a block diagram illustrating components of a privacy bank server. A privacy bank server, such as server 308 in FIG. 3A, includes some of the functional and storage components needed to compile the data needed to fill out a form, such as form 316. In the described embodiment, four large components of the privacy bank server are shown in FIG. 3B. These components and storage include a raw data profile storage 328, a form mapping storage 330, a negotiation history module 332, and a shippable code constructor 334. The raw data profile storage area 328 includes a set of data, a set or a profile, shown in area 336, that is associated with a registered user of the Privacy Bank service. Registered users have a unique account number, shown in area 338, that can be used as an identifier and password. 8A, 8B , 8C, 8D and 8E , the standard field names set by the Privacy Bank service are data strings entered by the user (first name or home street address), followed by use- Pair with a use-preference condition. The use-selection condition is used in the negotiation history module 332. This is discussed in more detail in FIG. 7 below. This data is included in area 340. Other profiles of other registered users are shown in area 342. Each registered user has a similar raw data profile.

[Procedure amendment 3]

[Document name to be amended] Statement

[Correction target item name] 0026

[Correction method] Change

[Contents of correction]

The form mapping area 330 includes a plurality of form mappings, an example of which is shown in an area 344. Each electronic form that is registered with the privacy bank service by an online merchant or seller (ie, an affiliate) has a form mapping. Privacy bank standard field names may be "non-standard" from electronic forms registered with the service, as discussed in FIGS. 8A , 8B, 8C, 8D and 8E below, and as described above in area 340. Match or map to the field name. For example, non-standard field names for a person's last name are "Last Name", "Surna
me) "or simply" Last. "Different forms use various variants of the name for this or other fields.
This is described in the embodiment described as “Person Name.Last.
The field will be mapped to the Privacy Bank "Standard" field name, which is "." And area 346 contains the practice-pre-conditions provided by the online merchant or seller when registering the form.
ference condition). This condition is used by the negotiation history module 350 and the dispatchable code constructor 334, as in the use-selection condition in field 340. This is discussed in more detail in FIG. 7 below. Another mapping 348 having the same format for other registration forms continues in region 344.

[Procedure amendment 4]

[Document name to be amended] Statement

[Correction target item name] 0028

[Correction method] Change

[Contents of correction]

FIGS. 4A and 4B show a flow diagram of a method for automatically filling an electronic form of a computer network according to one aspect of the present invention. The method described below is
This can be performed with the configuration of the server and the computer described in FIG. 3A. In step 402 shown in FIG. 4A, an online user / consumer wishing to purchase a product on the Internet downloads an electronic form to make a purchase to the user's browser program. At step 404, the browser parses the contents of the electronic form, typically an HTML document, and recognizes all external links. As is common with web pages, HTML documents include links to other external websites from which to retrieve content or other types of data.
In many instances, web pages are composites of different components from various sites within the core HTML document. One example is an external link to an ad server that retrieves the banner ad component of the core HTML document. In this case, the electronic form can be viewed as a core HTML document. This parsing is performed automatically by the browser and is a well-known feature.

[Procedure amendment 5]

[Document name to be amended] Statement

[Correction target item name] 0031

[Correction method] Change

[Contents of correction]

If the privacy bank server determines that the user / browser contacted by downloading the electronic form and executing an external link has a valid cookie, control passes to step 416, where the privacy bank server determines Obtain the user's cookie and read the cookie. In this context, having a valid cookie indicates that the user has recently gone through a login sequence, for example during a current Internet session, so that the user does not have to go through the login sequence again. . By reading the user's cookie, the privacy bank server can determine who the user is and thus search the user's raw data stored in the privacy bank. The content and format of this personal raw data is described in more detail in FIGS. 8A, 8B, 8C, 8D and 8E . At step 418, the privacy bank server retrieves user data for the user identified by the valid cookie. The privacy bank server sends this user data and identifier, eg, a URL
(Uniform resource locator) to determine how to fill out the electronic form document. At step 420, the privacy bank server forms a complete package of dispatchable code (item number 324 in FIG. 3A) that includes the user data used to fill out the form document. In the described embodiment, this dispatchable code (called a profile) is in the form of a Javascript program.
This dispatchable code is formed from information in a privacy bank memory that allows a form document to be automatically filled out in a later step of the method. Step 422
At this point, the browser receives the dispatchable code, or profile, from the privacy bank server and accesses it on the user computer, if desired by the user. This profile is stored in a browser resident on the user computer and can be executed by a user trigger.

[Procedure amendment 6]

[Document name to be amended] Statement

[Correction target item name] 0032

[Correction method] Change

[Contents of correction]

If the user wants to automatically fill out an electronic form using the privacy bank, the user executes a user trigger. In the described embodiment, at step 424, the trigger is generated by the user clicking on an "autofill" button included in the form and associated with the privacy bank. By clicking on the auto-fill button, the user causes the browser to execute the dispatchable code or the profile stored therein. In step 426 shown in FIG. 4B , it is determined whether the dispatchable code includes user data that would allow it to fill out a form document.
If the user data is contained in a dispatchable code resident on the browser, control proceeds to step 434 where the browser utilizes the dispatchable code and the user data to fill the electronic form document. Of course, as mentioned above,
When the form document is first retrieved, the user data present in the dispatchable code is dependent on the browser having a pre-existing valid cookie.

[Procedure amendment 7]

[Document name to be amended] Statement

[Correction target item name] 0033

[Correction method] Change

[Contents of correction]

However, if the user data is not included in the dispatchable code resident in the browser, control proceeds to step 428, where a login sequence is initiated to identify the currently unknown user. You. The dispatchable code used by the browser in this step includes the login sequence code,
This is the result of the browser not having a pre-existing valid cookie when the form document was initially retrieved, as described above. The login process of step 428 is described in more detail in the part of FIG. Once the user has completed the login sequence in step 428, the privacy bank server assigns a cookie to the user / browser, which instructs the privacy bank to
In subsequent transactions, it is possible to recognize the message from the user and the user's browser. In step 430, the privacy bank server retrieves the user data of the recognized user, concatenates the user data with an identifier such as a URL (uniform resource locator), and describes how the electronic form document is filled out. And form a complete package of routable code that includes the user data used to fill the form document. This step is substantially the same as step 418, described above.
Same as 420. At step 430 , the browser has received the routable code or profile from the privacy bank server and is accessing it at the user computer. Now, the dispatchable code includes user data that allows the form document to be automatically filled out. At this stage, control proceeds to step 434, where the browser uses the dispatchable code and the user data to fill out an electronic form document.
No further input from the user is required, for example, a re-click of the "autofill" button. In other words, once the user has properly completed the login sequence, the form is automatically filled out and it is not necessary for the user to click the "auto-fill" button again.

[Procedure amendment 8]

[Document name to be amended] Statement

[Correction target item name] 0039

[Correction method] Change

[Contents of correction]

At step 604, the privacy bank server retrieves the user's raw data from the privacy bank memory using the user cookie. The raw data aspects and content are described in more detail in FIGS. 8A, 8B, 8C, 8D and 8E . Raw data is a set of data items that are very similar to those required to fill widely used electronic purchase forms. As described in detail below, each raw data item corresponds to a unique Privacy Bank standard label or name. In step 606, the privacy bank server sends the URL,
Or a special form identifier to fill out to find the mapping for each field name in the electronic form (eg, legacy name)
), Is used for the Privacy Bank standard name. This mapping or field name matching is performed when the merchant becomes a relevant member of the Privacy Bank Service. At this point, the merchant submits one or more forms to the Privacy Bank, which examines each field name in the form and matches it with the Privacy Bank field names. In the described embodiment, if there are legacy names that do not have a matching privacy bank field name, the privacy bank user raw data settings will be updated if the unique legacy field name appears to have started appearing in other forms. Is done. Alternatively, as shown in step 424 of FIG. 4, the user is caused to manually input.

[Procedure amendment 9]

[Document name to be amended] Statement

[Correction target item name] 0048

[Correction method] Change

[Contents of correction]

FIGS. 8A, 8B, 8C, 8D and 8E illustrate one embodiment of the invention.
FIG. 5 is an elevation chart showing how fields containing raw data and user selections are organized on a Privacy Bank server. The top-level user table 802 shown in FIG. 8A has four columns: user (USER) 804, category (CATEG).
ORY) 806, type (TYPE) 808, and short display name (SHORT D
ISPLAY NAME) 810. The user table 802 has four rows: HOME 8
12, WORK 814, BILLING 816, and SHIP
PING) 818 has four data areas under column USER 804. In the described embodiment, the user is provided with these four data areas when registering with the Privacy Bank Service and enters information through each of these data areas. Skipping the CATEGORY 806 for a while, the TYPE 808 moves the raw data tree down one level from the top level represented by the table 802. For example, data area home (HOME) 81
2 is Info. This is implemented as a pointer or link to the Info table 820. The first column 821 of the table 820 shown in FIG. 8B is labeled Info, but the other three columns shown in the table 802 are the same: category 806, type 808, and short display name 810.

[Procedure amendment 10]

[Document name to be amended] Statement

[Correction target item name] 0049

[Correction method] Change

[Contents of correction]

In the table 820, the user starts to input data, and the data is the home information and the shipping data area 8 in the table 802.
18 Since the data also has Info in its type column 808, it is used for shipping. Name row 822 has a reference in its type column 808 to yet another table person name (PERSONNAME), as shown in table 824 shown in FIG. 8C . As in tables 802 and 820, the person name (PERSONN
The AME) table 824 has a first column labeled Person Name and three columns similar to the other tables. All five data areas in the person name table 824: prefix (PREFIX), first (FIRST), middle (MIDD)
LE), last (LAST), suffix (SUFFIX), and primitive type (primitive t) referred to as type (TYPE), and in the described embodiment as text (TEXT).
ype). The text represents a data string, which is the actual data item stored on the privacy bank server. By examining the TYPE column 808 of each data area, the user enters all raw personal data. The actual data item is entered in each type box containing text and represents a leaf node when viewed as a primitive type or tree structure. If the type column does not contain text,
There are other tables that further refine the data area.

[Procedure amendment 11]

[Document name to be amended] Statement

[Correction target item name] 0050

[Correction method] Change

[Contents of correction]

Along with another example, in the data area billing 816 shown in the table 802, the type 808 indicates BillInfo, not text. Table building info also has six data areas, none of which are of the text type, and therefore no actual data values can be found at this level. Taking the credit card data area as an example, the type indicates "credit card". The table credit card shown in FIG. 8E has four data areas: Type, Number, and Expiration Month (ExpMo
nth), expiration year (ExpYear), all of which are type text and contain the actual data values.

[Procedure amendment 12]

[Document name to be amended] Statement

[Correction target item name] 0053

[Correction method] Change

[Contents of correction]

The category column 806 relates to the privacy settings set by the user, which privacy settings are connected to the selections set by the user and are defined by the conditions described above, especially in FIG. Related to privacy settings. Conditions or usage thresholds in the described embodiments are marketing, system administration, personalization, research and development, and completion of activities (eg, order placement). The categories available in the described embodiment include physical contact information, online contact information, and demographic data, as shown in the tables of FIGS. 8A, 8B, 8C, 8D, and 8E. Dat
a), Financial data. The relationship between the category and the condition in the embodiment of the description is described in a table of 5 rows and 4 columns (20 cell table), where each condition is one row in the table and each category is one column in the table.

[Procedure amendment 13]

[Document name to be amended] Statement

[Correction target item name] 0065

[Correction method] Change

[Contents of correction]

For those skilled in the art, the hardware and software elements described above are standard designs and constructions. Other computer systems suitably used in the present invention may have additional or fewer subsystems. Further, memory bus 908, peripheral bus 914, and local bus 934 are examples of any connection scheme that provides a link to a subsystem. For example, a local bus may be used by the CPU to connect to fixed mass storage 916 and display adapter 920 . The computer system in FIG. 9 is merely an example of a computer system suitably used with the present invention. Other computer architectures having different aspects of the subsystem can also be used.

[Procedure amendment 14]

[Document name to be amended] Statement

[Correction target item name] Brief description of drawings

[Correction method] Change

[Contents of correction]

[Brief description of the drawings]

FIG. 1 is an illustration of a prior art “ad server” model.

FIG. 2 is an illustration of a transactor model according to the prior art.

FIG. 3A is an illustration of a system for automatically filling out electronic form documents according to one aspect of the present invention.

FIG. 3B is a block diagram illustrating components of a server that enables automatic insertion of data into an electronic form on a remote computer, according to one aspect of the invention.

FIG. 4A is a flow diagram of a method for automatically filling an electronic form document according to one aspect of the present invention.

FIG. 4B is a flow diagram of a method for automatically filling an electronic form document according to one aspect of the present invention.

FIG. 5 is a flow diagram of a method for an initial user session for a service for automatic electronic form completion, according to one aspect of the present invention.

FIG. 6 is a flow diagram of a method for constructing and transmitting a code segment dispatchable from a server to a user computer according to one aspect of the present invention.

FIG. 7 is a flow diagram of a mapping method whereby a form name is mapped to a raw data value of a user, according to one aspect of the present invention.

FIG. 8A is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 8B is a chart illustrating a format of a field name and registered user data according to an aspect of the present invention.

FIG. 8C is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 8D is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 8E is a chart showing the format of field names and registered user data, according to one aspect of the present invention.

FIG. 9 is a block diagram of an exemplary computer system suitable for performing certain aspects of the present invention.

[Procedure amendment 15]

[Document name to be amended] Drawing

[Correction target item name] All figures

[Correction method] Change

[Contents of correction]

FIG.

FIG. 2

FIG. 3A

FIG. 3B

FIG. 4A

FIG. 4B

FIG. 5

FIG. 6

FIG. 7

FIG. 8A

FIG. 8B

FIG. 8C

FIG. 8D

FIG. 8E

FIG. 9

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID , IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW

Claims (29)

[Claims] 1. A method for automatically filling out an electronic form on a computer of a user having a program running as a browser, the method comprising accessing the electronic form using the program, the program comprising: Executing a link from the user's computer to a personal information server; transmitting a personal information module from the personal information server to the user's computer; the personal information module at the user's computer And filling in at least some of the plurality of fields in the electronic form. 2. The electronic form of claim 1, wherein accessing the electronic form further comprises downloading the electronic form from a remote web server, the remote web server registering the electronic form with the personal information server. A method comprising: 3. The method of claim 1, wherein accessing the electronic form comprises displaying the electronic form in a window in the program. 4. The method of claim 1, wherein executing the link to a personal information server further comprises parsing the electronic form when downloading the electronic form to the user's computer. 5. The method according to claim 4, wherein when the electronic form is parsed and the link is recognized, the link is executed. 6. The method of claim 1, wherein executing the link to the personal information server further comprises transmitting a session identifier and an electronic form identifier to the personal information server, the session identifier associated with the user's computer. A method characterized by doing. 7. The method of claim 6, wherein the session identifier is a cookie and the electronic form identifier is a uniform resource locator that indicates the location of the electronic form. 8. The method of claim 1, wherein transmitting the personal information module further comprises examining the electronic form and a plurality of derived negotiation history modules for a particular user. 9. The method of claim 8, wherein each negotiation history module is obtained using form mapping corresponding to the electronic form and raw data corresponding to the particular user. 10. The method of claim 8, further comprising constructing a Javascript program from the plurality of negotiation history programs. 11. The method of claim 1, wherein executing the personal information module on the user's computer further comprises inserting data strings into a plurality of fields in the electronic form. 12. The method of claim 1, wherein executing the personal information module on the user's computer further comprises inputting the personal information module into a Java-related component of the program. 13. The method of claim 1, further comprising sending an electronic form in which at least some of the plurality of fields are completed to a personal information server. 14. The method of claim 13, further comprising updating data strings at the personal information server upon receiving the electronic form. 15. The method of claim 2, further comprising transmitting an electronic form in which at least some of the plurality of fields are completed to the remote web server. 16. The method according to claim 2, wherein the remote server, the user computer, and the personal information server are all connected via the Internet. 17. The method of claim 1, wherein the program is a web browser and the electronic form is a form used to purchase goods or services online. 18. The method of claim 11, further comprising using the session identifier to search for one or more data strings in a personal information server. 19. A system for automatically filling out electronic forms, the system comprising: an information server having access to personal information associated with a plurality of registered users and a plurality of form mappings; A web server having access to an electronic form including an associated input button, said electronic form being registered with said information server; a user computer including a browser and having a user, said electronic form being provided to said browser Downloaded and the user is registered with the information server; the information server and the user computer are adapted to communicate over a network, and when the electronic form is downloaded and the input button is actuated, the While the browser is on the user's computer, the electronic form A system characterized by being at least partially completed. 20. The system of claim 19, wherein the information server further includes a negotiation history module having a plurality of negotiation objects. 21. The system according to claim 20, wherein each negotiation object includes one of an acceptance component and a rejection component. 22. The constructor of claim 19, wherein the information server further comprises: a transmittable code module constructor for generating a software module containing instructions and data strings required for a browser on the user computer to fill the electronic form. A system comprising: 23. The system according to claim 22, wherein the software module is a Javascript program. 24. The system of claim 19, wherein the browser on the user computer includes a document parsing component for identifying one or more remote electronic resources and executing external links. 25. The system of claim 19, wherein the information server further has a plurality of raw data profiles and a plurality of form mappings. 26. The system of claim 25, wherein each raw data profile includes a field name and a corresponding data string. 27. The system of claim 25, wherein each form mapping includes a relationship between a first set of fields and a second set of fields. 28. The system according to claim 19, wherein said network is the Internet. 29. A computer program product for automatically filling out an electronic form on a user computer having a program that can be executed as a browser, the product comprising computer code for accessing the electronic form using the program. Computer program resident on the user computer; computer code for performing a link from the user computer to a personal information server; computer code for transmitting a personal information module from the personal information server to the user computer; Computer code for executing the personal information module on the user computer and filling in at least some of the plurality of fields of the electronic form;
A computer program product having a computer-readable medium storing the computer code.