WO2001090994A2

WO2001090994A2 - System and method for simplifying and/or securing transactions over a network

Info

Publication number: WO2001090994A2
Application number: PCT/US2001/014068
Authority: WO
Inventors: Joseph A. Mcdonnell; George C. Morton; Peter C. Murphy; Andrew S. Tappert; Alessandro Worth
Original assignee: Ishopsecure.Com, Inc.
Priority date: 2000-05-19
Filing date: 2001-05-02
Publication date: 2001-11-29
Also published as: WO2001090994A3; AU2001261113A1

Abstract

To provide secure transactions over a network, a communication of at least a purchase amount for a purchase that a user desires to make is received, and authorization for at least the purchase amount against a payment account of the user is obtained. Then a communication to the user providing a separate payment account with which to make the purchase over the network is sent. To simplify transactions over a network, a user issues a request to fill out at least a portion of an electronic order form of a merchant accessed over the network, and at least part of the at least a portion of the electronic order form is filled out using pre-stored information in response to the received user request.

Description

SYSTEM AND METHOD FOR SIMPLIFYING AND/OR SECURING TRANSACTIONS ONER A NETWORK

FIELD OF THE INVENTION The present invention relates to simplifying and/or securing transactions over a network, particularly, public networks such as the Internet.

BACKGROUND OF THE INVENTION

The Internet has become ubiquitous throughout the world, and consists of interconnected computers and computer networks communicating according to certain well-established signal transmission protocols. Currently, anyone with the proper hardware and software can connect to the Internet, and readily obtain access to information world wide. The pervasiveness of information on the Internet, and the ability to communicate with connected users world wide, has created a new electronic marketplace.

Merchants in the electronic marketplace offer an entire range of goods for sale, from durable goods to information or service-based products such as reports and software. Any user browsing merchant web sites on the Internet is considered a potential customer. However, it is estimated that less than half of these potential customers ever complete transactions or purchases using the Internet. It is believed that the difficulty of transacting over the Internet and the Internet's inherent lack of security are two of the biggest factors contributing to this loss of business. Shopping on the Internet can be a time consuming process. The user must visit a merchant's virtual store, and usually browse for items presented in a traditional catalog format. Once items for purchase are selected, the user must then go through a time-consuming checkout process. During this process, the user is required to enter personal information, shipping information, billing address information and/or payment account information (e.g., credit card information). Each time a user visits a merchant site and wants to make a purchase, the user must again go through the time- consuming checkout process. Because shopping on the Internet can be such a time consuming process, users tend to become frustrated, and often fail to complete transactions.

As discussed above, as part of the checkout process, the user is required to enter personal information, shipping information, billing address information and/or payment account information. Many users prefer not to give their personal information out, or at least not out over the Internet where users believe thieves and computer hackers can obtain and use this information to a user's detriment.

Consequently, these users terminate the shopping process without completing a transaction with the merchant. Other users, fearing this lack of security, decide not to provide their payment account information, and terminate the shopping process without completing a transaction with the merchant. Accordingly, a demand exists for simplifying Internet transactions and for eliminating the security concerns of users. It is expected that satisfying such demands will result in converting numerous potential and lost customers in the electronic marketplace into actual customers. SUMMARY OF THE INVENTION

The system and method according to the present invention provide for secure transactions over a network by allowing users to make purchases without divulging information about the user which the user considers sensitive (e.g., credit card numbers). When a user desires to make a purchase from a merchant doing business over the network, the user contacts a shopping system. Prior to shopping on the network, the user will have provided the shopping system with at least the user's payment account information (e.g., credit card information), preferably via a relatively secure communication channel as compared to the network. When the user contacts the shopping system, the user provides the shopping system with the amount of the purchase. The shopping system charges at least the purchase amount against the previously obtained user payment account, preferably in a conventionally secure manner, and issues the user a separate payment account, which is associated with the shopping system.

The user then uses the separate payment account to make the purchase from the merchant over the network. Consequently, the user no longer risks the financial injury that can occur when hackers and thieves obtain payment account information communicated over the network to make purchases. In a preferred embodiment, the communication between the user and the shopping system in obtaining the separate payment account occurs automatically over the network. In this embodiment, prior to shopping, the user obtains a shopping assistant program from the shopping system. The shopping assistant program runs on the user's computer connected to the network, and at the users request, the shopping assistant communicates with the shopping system over the network to obtain the separate payment account. As will be appreciated, even in this preferred embodiment, when obtaining the separate payment account, the user's payment account information is not communicated over the network.

Another aspect of the system and method of the present invention, independent from providing secure transactions, but preferably used in conjunction • therewith, is the provisiori of simplifying the transaction process, Namely, the user is provided with a mechanism by which at least a portion of the electronic order forms of merchants on the network can be automatically filled out. In a preferred embodiment, the user runs a shopping assistant program on the user's computer connected to the network. When the user want to automatically complete at least a portion of an electronic order form, the user makes such a request of the shopping assistant. The shopping assistant accesses information, and fills in the at least a portion of the electronic order form. The accessed information can be information pre-stored on the user's computer, or information obtained via the network from a shopping system. As a result, the usually frustrating burden of manually filling in electronic order forms is at least partially lifted by the present invention.

By providing for secure transactions and/or by simplifying the transaction process, significant impediments on the electronic superhighway have been eliminated. The present invention therefore paves the way for significantly increasing business transacted in the electronic marketplace. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying drawings which are given by way of illustration only, wherein like reference numerals designate corresponding parts in the various drawings, and wherein:

Fig. 1 illustrates a block diagram of the shopping system according to an embodiment of the present invention as well as networks and other elements connected to the system; " . .

Fig. 2 illustrates a block diagram of the shopping assistant according to an embodiment of the present invention;

Figs. 3A-3D illustrate flowcharts of the method of securing and simplifying transactions over a network according to an embodiment of the present invention;

Figs. 4A-4F illustrate flowcharts of the method of filling in information on an electronic order form according to an embodiment of the present invention; Fig. 5 illustrates a flowchart of the method of securing and simplifying transactions over a network according to another embodiment of the present invention; and

Figs. 6A-6C illustrate example checkout screens of a merchant's virtual store.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

SYSTEM ARCHITECTURE Fig. 1 illustrates a block diagram of the shopping system according to one embodiment of the present invention as well as networks and other elements connected to the system. As shown, the shopping system 100 is connected via a first network 15 to network users 20 and to merchants 25 having virtual stores on the network 15. The users 20 and the merchants 25 in Fig. 1 represent both the entities and the computer hardware and software used to connect these entities to the first network 15. In a preferred embodiment, the network 15 is a public network such as the Internet, but it will be appreciated that the present invention is not limited to being used with the Internet or public networks.

As further shown in Fig. 1, the shopping system 100 is also connected via a second network 30 to account servers 35. The second network 30 can be one or multiple private or public networks sufficient to obtain authorization of charges against payment accounts (e.g., credit card accounts, checking accounts, savings accounts, money market accounts, etc.) and to obtain funding of payment accounts of the shopping system 100. For example, the second network 30 can represent a direct public telephone switch network (PTSN) connection between the shopping system 100 and one of the account servers 35, even though for the purposes of simplicity, the second network 30 is shown connected to multiple account servers 35. As another example, the second network 30 could be the same as the first network 15, but preferably, the first and second networks 15 and 30 are different networks with the second network 30 having greater inherent security than the first network 15. The account servers 35 represent the servers of banks and other institutions handling payment accounts.

The shopping system 100 is connected to the first network 15 through network connection servers 110. For example, when the first network 15 is the Internet, the network connection servers 110 are web servers. The network connection servers 110 connect database servers 120 and accounting servers 130 to the first network 15 via first and second firewalls 115 and 125, respectively. The network connection servers 110 also connect call center servers 135 to the first network 15. Human operators, referred to as call center personnel 140, in communication with the users 20 can also enter, update and access information in the database and accounting servers 120 and 130 via the call center servers 135. As further shown in Fig. 1, the accounting servers 130 are connected via a'^hird firewall to the second network 30.^'

SYSTEM OPERATION

Next the operation of the shopping system will be described. Specifically, the method of becoming a shopping system member will be described first, followed by a description of the process by which a user 20 obtains the shopping assistant that interacts with the shopping system 100 to simplify and secure transactions over the first network 15. Next, a method of simply and securely shopping on the first network 15 via a portal site established by the shopping system 100 will be described. Then, a method of simply and securely shopping on the first network without going through the portal site established by the shopping system 100 will be described. And, finally, the process of updating the shopping assistant will be described.

BECOMING A MEMBER OF THE SHOPPING SYSTEM 100 A user 20 can become a member of the shopping system by a one of three routes or a combination of these routes: on-line application, mailed or faxed application, application via telephone. As alluded to previously, the network connection servers 110 maintain a portal site on the first network 15. The home page of that site offers a user 20 visiting the site the option of becoming a member. If a user 20 elects to become a member by choosing this option, the user is presented with the terms and conditions of becoming a member, and requested to accept or deny these conditions. If not accepted, the user 20 is returned to the home page. If accepted, the user 20 is presented with an electronic application form and informed that the user 20 can terminate the on-line application process at any time, and (1) print out the on-line form and fax the completed form to the call center personnel 140, or (2) call the call center personnel 140 via a toll free number to complete the on-line application process. Opt out options (1) and (2) provide a more secure method of applying to become a member which involves, as described below, providing information that users 20 typically desire to transfer in a secure fashion. Opt out options (1) and (2) also require that the user 20 accept, in writing with (1) or verbally with (2), the terms and conditions of membership.

Regardless of the application method or combination of methods chosen, the user 20 becoming a member will supply the call center servers 135 with the following information:

Personal Information Profile • Name

• Street Address

• Suite or Apartment Number (if applicable)

• City State

Country

Zip Code

Home Telephone Number

Business Telephone Number e-mail address

Login

Password

Member Shopping Code

Forgot Login or Password Question, example: "Mother First Name?"

Forgot Login or Password Answer, example: "EDNA"

Shipping Information - here the user 20 will be able to enter 20 shipping address profiles, the information for each profile is listed below.

• Name

• Reminder Name like: "Office Shipping Address" or "Aunt Fanny's Home Address"

• Business Name if any

• Street Address

• Suite or Apartment Number

• P.O. Box (if applicable)

• City • State

• Country

• Zip Code

• Telephone Number for FedEx or UPS Shipping

Anonymous Personal Profiles - the shopping system 100 has a database in the database servers 120 of over 200 million fake personal profiles. Each user 20 is given four anonymous profiles for use when shopping. If desired, the user 20 can select/change the following information for each of the four anonymous profiles.

• Name

• Telephone

• E-mail (e.g., pointed to the Member's anonymous e-mail server that forwards all e-mail on to the Member).

Payment Account Information - a payment account is an account against which charges can be made. Payment accounts include, but are not limited to, credit card accounts (a form of credit account), checking accounts (a form of debit account), savings accounts, money market accounts, etc. A user 20 can provide up to four different payment accounts. For each account, the following information is requested:

• Member payment account alias or nickname (e.g., "My Credit Card) • Member payment account type (e.g., Name of Credit Card )

• Member payment account number (e.g., credit card number)

• Member payment account expiration date (e.g., credit card expiration date)

• Member billing address if different from that supplied with personal information profile

Once the above information is received by the call center servers 135, the call center servers 135 determine whether the login, password and shopping code chosen by the user 20 are acceptable. An acceptable login, password and shopping code will have to meet predetermined minimum length requirements and prohibited symbol requirements to be acceptable. These requirements are a matter of design choice, and therefore, examples have not been provided. Furthermore, the login, password and shopping code will have to be unique with respect to existing members of the shopping system 100. If the uniqueness requirement is not met, the user 20 will be requested to reselect the non-unique item.

When applying on-line or by telephone, the information entered by the user 20 can be monitored in substantially real time by the call center servers 135, checked for length and prohibited symbols, and compared against existing logins, passwords and shopping codes saved in the database servers 120. Accordingly, the user 20 can be notified immediately of the failure to meet the acceptance requirements discussed above, and requested to chose a new login, password or shopping code meeting the acceptance requirements. If the application is acceptable, the call center servers 135 store the application information in the database servers 120. The user 20 is then notified of acceptance as a member. Preferably, notification is made by the same method used for application, and at the time of application if possible. However, notification can be accomplished by regular mail, fax, or e-mail. Additionally, in one embodiment of the present invention, the method of notification is selectable by the user 20 as an information item in the membership application. The method of notification is also used to notify users 20 applying- by facsimile or mail if their application- does not meet the acceptance requirements. Once the user 20 has become a member, the user 20, as part of the notification process, is instructed on how to obtain a shopping assistant program. The shopping assistant program will reside on the user's computer, which connects the user 20 to the first network 15, and will interact with the shopping system 100 to provide simple and secure transactions over the first network 15. The process of obtaining the shopping assistant is described in detail in the next section.

As will be appreciated from the forgoing disclosure, numerous modifications and alternatives exist to solicit, obtain and record users 20 as members of the shopping system 100. For example, the number of ship to addresses can be greater or less than 20 and the number of anonymous persona can be greater than or less than 4. In the end, obtaining the above listed user information in correlation with a login, password and shopping code are the preferable results of the methodology for becoming a member of the shopping system 100. As will be further appreciated from the following disclosure, the use of a shopping code is optional, and the present invention should not be construed as limited to use with the shopping code. The methodologies of the present invention function without the use of the shopping code, which merely provides an added layer of security.

OBTAINING THE SHOPPING ASSISTANT

As with becoming a member of the shopping system 100, numerous methods exist for a user to obtain the shopping assistant program. For instance, the shopping assistant could be shipped to the user 20 ori a^'recordirig medium such as an optical ^■ disk. The shopping assistant could also be e-mailed to the user 20 as an attachment. In a preferred embodiment, the user 20 downloads the shopping assistant by choosing a download option on the home page of the portal site maintained by the network connection servers 110.

In contrast to the other two examples given, the shopping system 100 does not know which member is requesting the shopping assistant when the download option is chosen. Accordingly, in response to choosing the download selection on the portal site home page, the user 20 is required to login. The following is a description of the login process, and will be referred to hereinafter as the login process.

The network connection servers 110 generate a window that requires the user 20 to login into the shopping system 100 by entering their login and password. The network connection servers 100 then send the login information to the database servers 120 for confirmation. The database servers 120 determine if the entered login and password match that of a member. If no match exists, the database servers 120 instruct the network connection servers 100 that the user 20 is not a member, and the network connection servers 100 notify the user 20 that the login and password are not valid. If a match does exist, the database servers 120 confirm to the network connection servers 110 that the user 20 is a member.

Once logged in, the network connection servers 110 request a shopping assistant for the user 20 from the database servers 120. The shopping assistant program for the user 20 includes a generic operation part shown in Fig. 2, a specific data part, specific to the user 20, and a general data part. Fig. 2 illustrates a block diagram of the shopping assistant 40 according to an embodiment of the present invention. As shown, the shopping assistant 40 includes a user interface 42, which maintains a constant display of four functional buttons on the display of the computer used by the user 20. The four functional buttons include a user profile button 44a, a ship-to addresses button 44b, a fill out form button 44c and a fill out billing button 44d. The user interface 42 is connected to a controller 46. The controller 46 is connected to a shopping system interface 48, a locator 50 and memory 52. The memory 52 is a portion of the memory in the computer used by the user 20, and stores the specific and general data parts. The specific data part includes the personal information profile, the shipping information, the anonymous personal profiles, and the payment account aliases and/or payment account identifiers for the user 20. The general data part includes the billing address of the shopping system 100 (e.g., name, address, etc., of the shopping system 100) associated with the separate payment accounts of the shopping system 100 and the libraries used by the locator 50 (which is a search engine) in searching. The general data part will be described in greater detail below. Also, the operation of the shopping assistant 40 will be described in detail with respect to Fig. 2 in the following section entitled Shopping Via the Shopping System Portal Site.

SHOPPING VIA THE SHOPPING SYSTEM PORTAL SITE Next, shopping via the shopping system portal site will be described with reference to Figs. 1-2 and the flowcharts illustrated in Figs. 3A-4F.

Referring first to Fig. 3 A, the user 20 visits the portal site of the shopping system in step S10. Besides the becoming a member and -download options discussed ^• above, the home page includes a shopping anonymously option. In step S20, the user 20 selects this option, and goes through the login process. Once logged in, the network connection servers 110 allow the user 20 to access the anonymous portal so that when the user 20 browses other locations or sites on the first network 15, the location being visited recognizes the user 20 only as the anonymous portal.

Then, in step S30, the network connection servers 110 communicate with the computer of the user 20 to determine if the shopping assistant is running. If the shopping assistant is not running, the user 20 is instructed to activate the shopping assistant. The user 20 activates the shopping assistant by running the shopping assistant program received as discussed above in the previous section.

The user 20 then browses the first network 15 and shops in the conventional manner in step S40. When the user 20 decides to make a purchase from the virtual store of a merchant 25, the user 20 will be presented with one or more screens such as shown in Figs. 6A-6C in which the user is requested to enter personal, shipping, billing and/or payment information. Most virtual stores refer to these screens as the checkout process.

As will be appreciated, the checkout screens in Figs. 6A-6C represent one set of the many different sets of checkout screens in existence or which may be developed. However, it will be appreciated from the forgoing disclosure that the present invention is applicable regardless of the type of checkout screens. Furthermore, the information requested by merchants 25 during the checkout process ^• differs from merchant 25 to merchant 25. Again, however, the present invention is applicable regardless of the information requested and not requested. Accordingly, for the purposes of example only, the checkout screens in Figs. 6A-6C will be referred to in describing the operation of the present invention. As shown, the first checkout screen in Fig. 6 A shows the product(s)/service(s) being purchased and requests the user 20 to enter personal or customer information in the fields provided. The next checkout screen, shown in Fig. 6B, also shows the product(s)/service(s) being purchased and requests the user 20 to enter ship to address information in the fields provided. The last screen of the checkout process shown in Fig. 6C requests that the user 20 enter in the billing address information and the payment account information in the fields provided.

To have the personal, ship to address, billing address and payment account information of the electronic order form automatically entered, in step S50 the user 20 clicks on the fill out form button 44c. When the user 20 clicks on the fill out form button 44c, the shopping assistant 40 performs the process illustrated in the flow chart of Figs. 4A-4F for the currently displayed screen of the merchant's virtual store. Fill Out Form Operation As shown in step S510 of Fig. 4A, clicking on the fill out form button 44c causes the controller 46, which receives this instruction from the user interface 42, to instruct the locator 50 to search the currently displayed screen of the merchant's virtual store for personal information, ship to address information, billing address information and payment account information request types. In a preferred embodiment, the locator 50 is a text search engine. When the fill- oujt form button 44c is activated by the user 20, the locator 50 in step S510 accesses a first library stored in the memory 52. The first library was stored in the memory 52 as part of the general data part of the shopping assistant 40. The first library includes a plurality of predetermined searches for the locator 50 to execute. Each text search in the first library is associated with one of the information request types - personal information, ship to address information, billing information, and payment account information. For example, one of the searches for identifying the personal information request types is: "Customer" within two words of "Information". This would allow the locator 50 to identify that personal information request type in the checkout screen of Fig. 6A. Figs. 6A-6C inherently provide examples of other searches for identifying information request types. Because the searches are a matter of design choice and can be developed without undue experimentation, and for the sake of brevity, a complete example of the first library, and the second-fifth libraries discussed later, have not been provided. Next, in step S515, the controller 46 determines from the search results of the locator 50 if a personal information request type was found. If so, then in step S520, the controller 46 causes the user interface 42 to ask the user 20 whether the personal information profile of the user 20 or an anonymous profile should be used in satisfying the personal information requests. If the user 20 selects an anonymous profile, the controller 46 then, in step S525, causes the user interface 42 to ask the user 20 to select one of the four anonymous profiles stored in the memory 52.

Subsequently, in step S530, the controller 46 instructs the locator 50 -to .locate each personal information request. A personal information request can include any of the items of personal information obtained from the user 20 when the user 20 became a member of the shopping system 100. To locate each personal information request, the locator 50 accesses a second library stored in the memory 52. The second library was stored in the memory 52 as part of the general data part of the shopping assistant 40. The second library includes a plurality of predetermined searches for the locator 50 to execute. Each text search in the second library is associated with one of the items in the personal information profile and the anonymous profiles, these profiles being stored in the memory 52. For example, one of the searches is "NAME" with an input field adjacent thereto.

In searching for each personal information request, the locator 50 searches the text from each of personal information request types located in step S510 (e.g., the

"CUSTOMER INFORMATION" heading in Fig. 6C) until the end of the screen or the next identified information request type (e.g., ship to address, billing address, or payment account). As each personal information request is located by the locator 50, the controller 46 recognizes the information being requested based on the information item associated in the second library with the located information request and fills in the requested information using the corresponding item in the personal or anonymous information profile selected in steps S520 and S525 by the user 20.

After step S530, or if the controller 46 deteπnines in step S515 that no personal information request types were found in the current screen, processing proceeds to step S535 in Fig. 4B. In step S535, the controller 46 determines from the results of step S510 if the current screen includes ship to address request types. If so, then in step S540, the controller 46 causes the user interface 42 to ask the user 20 which of the ship to addresses in the ship to address list to use in satisfying the ship to address requests. Instead of displaying the complete ship to address information in the ship to address list, only the nicknames or aliases can be displayed along with an option to view the address in full detail. Then, in step S540, the controller 46 instructs the locator 50 to locate each ship to address information request. To locate each ship to address information request, the locator 50 accesses a third library stored in the memory 52. The third library was stored in the memory 42 as part of the general data part of the shopping assistant 40. The third library includes a plurality of predetermined searches for the locator 50 to execute. Each text search in the third library is associated with one of the items in the ship to address information, this ship to address information being stored in the memory 52.

In searching for each ship to address information request, the locator 50 searches the text from the ship to address information request types located in step S510 (e.g., the "ENTER SHIPPING ADDRESS") until the end of the screen or the next identified information request type. As each ship to information request is located by the locator 50, the controller 46 recognizes the information being requested based on the information item associated in the third library with the located information request and fills in the requested information using the corresponding item in the ship to address selected by the user 20 in step S540.

After step S545, or if the controller 46 determines in step S535 that no ship to address information requests were found in the current screen, processing proceeds to step S550 in Fig. 4C. In step S550, the controller 46 determines from the results of step S510 if the current screen includes billing address information request types. If so, then in step S555, the controller 46 instructs the locator 50 to locate each billing address information request. For each located billing address information request, the controller 46 fills in the corresponding requested information saved in the memory 52. This operation is substantially the same as the operation discussed above with respect to step S545, except that the locator 50 accesses a fourth library stored in the memory

52. The fourth library includes a plurality of predetermined searches, each associated with one of the items in the billing address information.

As mentioned previously, the billing address information is stored in the memory 52 as part of the general data part of the shopping assistant 40. The billing address information items are the same as the ship to address items, but each item of billing address information pertains to the billing address of the shopping system 100. The billing address of the shopping system 100 is the billing address associated with a plurality of separate payment accounts owned by the shopping system 100. After step S555, or if the controller 46 determines in step S550 that no billing address information requests were found in the current screen, processing proceeds to step S560. In step S560, the controller 46 determines from the results of step S510 if the current screen includes payment account information request types. If no such request type is found, then processing ends. However, if this request type was found, then in step S620 of Fig. 4D, the controller 46 causes the user interface 42 to ask the user 20 which of the four payment accounts saved in the - memory 52 to use for this transaction. Once a selection has. been made; the controller^{' - '}. 46 causes the user interface 42 to ask the user 20 to enter their login, password, shopping code, and the purchase amount of the purchase being made in step S625.

Once the user 20 has entered this information, the controller 46 via the shopping system interface 48 establishes, in step S630, a secure socket link (SSL) with the database servers 120 via the first network 15, the network connection server 110 and the firewall 115. Over the SSL, the controller 46 sends the information provided in steps S620 and S625 along with a fill out billing request. With respect to supplying the information of step S620, the controller 46 supplies insufficient information for an eavesdropper to use and make charges against the identified payment account. For example, in one embodiment the nickname assigned by the user 20 is used to identify the payment account. In a preferred embodiment, each account is given a number, not associated with the payment account, when the user 20 became a member. That number is sent as part of the specific data part of the shopping assistant 40, and sent to the shopping system 100 in step S 630 to identify the payment account of the user 20. Then, in step S635, the database servers 120 determine if the user 20 is a member. Specifically, the database servers 120 perform the login process, and if the user 20 is confirmed, then the database servers 120 verify whether the received shopping code matches the stored shopping code of the user 20. If the login process or the shopping code verification process fail to confirm the user 20 as a member, then in step S640, the controller 46, in response to instructions from the database serves 120, notifies the user 120 that confirmation failed because of improper login, password or shopping code in step S640. Processing then returns to step S625 so that the user 20 can reenter this information. If the user 20 is confirmed as a member in step S635, then processing proceeds to step S645 in Fig. 4E. In this step, the database servers 120 forward the fill out billing request and associated information (login, password, shopping code, payment account identifier, and payment amount) to the accounting servers 130. Then in step S650, the accounting servers 130 use the login, password and shopping code to identify the payment accounts of the user 20 stored therein; although, it will be readily appreciated that this could be accomplished using only one of the login, password and shopping code. Next, the accounting servers 130 identify the payment account of the user 20 to use in the transaction based on the payment account identification information received. The accounting servers 130 then seek authorization for the payment amount plus 15% from the account servers 35 handling this payment account for the user 20 via the second network 30. The additional 15% provides a margin of error to cover shipping, handling, or taxes not included as part of payment amount given by the user 20 in step S625. It will, however, be appreciated that the margin of error is not limited to 15%, but could be greater or less than 15%.

In step S655, if authorization is not received, then in step S660, the accounting servers 130 notify the database servers 120, which in turn notify the controller 46 of the shopping assistant 40 via the secure socket link. In response, the controller 46 causes the user interface 42 to notify the user 20 that the payment account was not authorized and to choose another payment account. The user 20 can also be notified to -call the Call center personnel 140 via a toll free number. The secured socket link ^■ then ends, and processing proceeds to step S620. If, in step S655, the payment account of the user is authorized, then in step

S665, the accounting servers 130 establish a separate payment account for the payment amount plus 15%. Specifically, the shopping system 100 has, in a preferred embodiment, over 1 million payment accounts associated therewith and not with any user 20. The separate payment accounts are debit and/or credit type accounts, but in a preferred embodiment, the separate payment accounts are debit accounts. The accounting servers 130 rotationally use these separate payment accounts to prevent abuse by merchants 25 and others.

After selecting the separate payment account to use, the accounting servers 130 contact the account server 35 of the entity handling the account, and request that the separate payment account be credited for the payment amount plus 15%. The request also includes instructions that, or by pre-existing instructions with the account handler, the separate payment account remain valid for a limited period of time (e.g., 10 minutes). Once the request is processed, in step S670, the accounting servers 130 send information on the separate payment account to the controller 46 of the shopping assistant 40 via the database servers 120 and the SSL. The information on the separate payment account is sufficient to allow for charges to be made against the account. Next, in step S675 of Fig. 4F, the controller 46 instructs the locator 50 to locate each payment account information request. To locate each payment account information request, the locator 50 accesses a fifth library stored in the memory 52. The fifth library was stored in the memory 52 as part of the general data part of the shopping assistant 40. The fifth library includes a plurality of predetermined searches for the locator 50 to execute. Each text search in the fifth library is associated with one of the items in the payment account information received over the SSL from the shopping system 100.

In searching for each payment account information request, the locator 50 searches the text from the payment account information request types located in step S510 (e.g., the "CREDIT CARD NUMBER") until the end of the screen or the next identified information request type. As each payment account information request is located by the locator 50, the controller 46 recognizes the information being requested based on the information item associated in the fifth library with the located information request and fills in the requested information using the corresponding item of separate payment account information. Next, in step S680, the user 20 determines if the checkout screen has been completely filled out. If so, then the next checkout screen is usually displayed automatically by the merchant's site, unless the user 20 just filled out the last checkout screen. If the checkout screen is not completely filled, perhaps because the libraries used by the locator 50 have not been updated to allow completion of the checkout screen, then the user 20 manually enters the missing information in step S685.

For each of the checkout screens, the user 20 can automatically fill in the requested information by activating the fill out form button 44c. Accordingly, the present invention greatly simplifies the checkout process, and eliminates the frustration users 20 may feel during the checkout process. As a result, users 20 will be inclined to complete the checkout process and make purchase at a merchant's virtual store.

Completing the Transaction Once steps S50 detailed in Figs. 4A-4F is complete, processing proceeds to step S70 shown in Fig. 3B. In step S70, the user 20 has completed automatically filling out the electronic order form, and submitted the form to the merchant 25. If the separate payment account includes sufficient funds for the purchase, then the merchant 25 will indicate a completed transaction (i.e. reconciled funds). If the funds are reconciled, then in step S100 of Fig. 3C, the accounting servers 130 determine the actual amount charged against the separate account. The actual amount is deducted from the amount charged against the user's payment account to determine an excess amount charged against the user's payment account. Then, in step SI 10, the accounting servers 130 contact the account server 35 handling the user's payment account via the second network 30, and request the account server 35 to credit the excess amount to the user's payment account. However, if the transaction fails to complete because of insufficient funds in the separate account, the merchant 25 will notify the user 20 of the insufficient funds. Then, the account server 35 for the separate payment account notifies the accounting servers 130 of the shopping system 100 that the transaction involving the separate payment account was not authorized because of lack of funds and the amount of the requested authorization. Next, in step S75, the accounting servers 130 subtract the amount credited to the separate payment account from the amount of the requested authorization to^" determine the additional funds -needed to complete the transaction. The accounting servers 130 then send an additional funds request to the controller 46 via the database servers 120 and the SSL. The controller 46 causes the user interface

42 to notify the user 20 that additional funds are required to complete the transaction, and to ask the user 20, in step S80, if the user 20 authorizes charging the additional funds against their payment account. If the user 20 does not authorize the additional funds, processing ends. If the additional funds are authorized, then in step S90 of Fig. 3D, the controller 46 increases the payment amount by the additional funds, and processing proceeds to step S650 in Fig. 4E.

Override Option For various reasons the user 20 may wish to override the information filled in a particular screen with the billing address information. If the user 20 decides to perform this override, then the user 20 activates the fill out billing button 44d. When activated, the controller 46 will cause the locator 50 to accesses the fourth and fifth libraries and search from the current screen till the end of the checkout screens. For each infoπnation request located by the locator 50, regardless of information request type, the controller 46 will fill in the corresponding item from the billing address information and payment account information. For instance, if the user 20 were to activate the fill out billing button 44d while viewing the checkout screen in Fig. 6B, the NAME field in both Figs. 6B and 6C would be filled out with the name from the billing address information.

' , Conclusion . • ^• •

When shopping on the first network 15 (e.g., the Internet), a user 20 does not enter his payment account (e.g., credit card) on the electronic order form of a merchant 25. Instead, the payment account of the user 20 is charged via the second network 30 (e.g., credit card authorization network commonly used by most merchants), and the payment account of the shopping system 100 is entered on the electronic order form. In this manner, the shopping system 100 assumes the risk that thieves and computer hackers may obtain this information. Accordingly, with respect to payment account information, the present invention renders shopping on the first network 15 as secure as shopping in person and using a credit card to pay for a purchase.

Furthermore, because the user 20 has the option to remain anonymous, both while browsing the network 15 and when supplying information requested on the electronic order form, the present invention also thwarts the effort of thieves and hackers to obtain non-payment account information considered sensitive by the user 20. And, as discussed previously, the present invention greatly simplifies the some time arduous task of completing the electronic order form of merchants 25.

As a result, the present invention eliminates the most significant hurdles in convincing the consuming public to complete transactions over networks such as the Internet.

SHOPPING OUTSIDE OF THE PORTAL SITE OF THE SHOPPING SYSTEM 100 The user 20 does not have to shop via the portal, site of the shopping system

100 to obtain most of the advantages offered by the present invention. Instead, the user 20 can browse the first network 15 without going through the portal site.

However, when browsing in this fashion, the merchant sites visited will recognize the user 20.

Fig. 5 illustrates the operational flow chart when shopping outside the portal site. As shown, in step S800, the user 20 browses the first network 15 and shops in the conventional manner in step S800. When the user 20 decides to make a purchase from the virtual store of a merchant 25, the user 20 will be presented with one or more screens such as shown in Figs. 6A-6C in which the user is requested to enter personal, shipping, billing and/or payment information.

To take advantage of the benefits provided by the present invention, the user 20 will activate the shopping assistant 40 in step S805 if the shopping assistant 40 has not already been activated. Then, processing proceeds to step S50 in Fig. 3 A, and is the same as discussed above with respect to shopping via the portal site. Accordingly, except for browsing anonymously, the user 20 obtains the same benefits provided by the present invention when shopping outside the portal site as when shopping via the portal site.

UPDATING THE SHOPPING ASSISTANT

As discussed previously, the shopping assistant 40 is extremely adaptable and flexible. As will be discussed in detail in this section, the user 20 can update the personal profile information, anonymous profile information, the ship to' ddress- •>:^':. _,^'«- information, the libraries stored in the memory 52, and can also update the user's payment account information stored by the shopping system 100.

To update the personal and/or anonymous profile information, the user 20 activates the user profile button 42a. This causes the controller 46 to display, via the user interface 42, the personal and anonymous profile information stored in the memory 52. The user 20 can then change any of the personal profile information and the name, telephone number, and e-mail address of any of the anonymous profiles.

The changed information is stored in the memory 52.

Similarly, to update the ship to address information, the user 20 activates the ship to address button 44b. This causes the controller 46 to display, via the user interface 42, the ship to address information stored in the memory 52. The user 20 can then change any of the information, and the changed information is stored in the memory 52.

Whenever, the user 20 updates information using the user profile and ship to address buttons 44a and 44b, the controller 46 sets an update flag. Whenever the user 20 logs onto the shopping system 100, the controller 46 checks the update flag. If the update flag has been set, the controller 46 uploads the personal profile, anonymous profile and ship to address information to the shopping system 100. In a preferred embodiment, the controller 46 uses flags associated with each piece of information that the user 20 can alter using the user profile and ship to address buttons 44a and

44b so that only the altered information is uploaded.

Also, whenever the user 20 logs onto the shopping system 100, the controller 46 pro vi es'the- shopping system lOO-with the current version of the libraries stored in the memory 52. If the stored version is not the current version, the shopping system 100 downloads the updates to the libraries and provides the new version number.

The user 20 can also update the payment account information used by the shopping system 100 using any of the methods discussed in the becoming a member section to provide payment account information to the shopping system 100. The shopping system 100 will then set a flag indicating that the payment account information has been changed. The next time the user 20 logs on, this will triggers a download of the changes in the information stored in the memory 52 corresponding to the user's payment accounts (e.g., the payment account identifiers and/or nick names). As the discussion above demonstrates, the present invention is adaptable to the changing needs of the users 20, and also adaptable to the ever changing electronic marketplace.

CONCLUSION The invention being thus described, it will be obvious that the same may be varied in many ways. For example, the present invention is not limited to the automatic forms of communication discussed above with respect to the preferred embodiment. For instance, the user 20 could request the use of a separate payment account via the telephone and the call center personnel 140, via e-mail and the call center personnel 140, etc. The separate payment account is then be provided using the telephone, e-mail, a user 20 only accessible portion of the portal, site, etc. And, the user 20 manually fills out an electronic order form using the obtained separate payment account. As another example, the user 20 could obtain version of the shopping assistant that does not include the specific data part and does not support obtaining a separate payment account from the shopping system 100. In this embodiment, the user 20 uses the user profile and ship to addresses buttons 44a and 44b to enter in information. The user 20 can then automatically fill in at least the personal and ship to address information requests of an electronic order form automatically.

Such variations are not to be regarded as a departure from the spirit and scope of the invention, and it will be appreciated that many more alternatives too numerous to list all are intended to be included within the scope of the following claims.

Claims

We claim:

1. A method of providing secure transactions over a network, comprising: first receiving a communication of at least a purchase amount for a purchase that a user desires to make over a first network; obtaining authorization for at least the purchase amount against a payment account of the user; and sending a communication to the user providing a separate payment account with which to make the purchase over the first network.

2. The method of claim 1, wherein the first receiving step further receives user identification information.

3. The method of claim 2, further comprising: confirming whether the user is a member based on the received user identification information and previously stored user identification information.

4. The method of claim 3, wherein the obtaining and sending steps are not performed unless the confirming step confirms the user is a member.

5. The method of claim 1, wherein the obtaining step obtains authorization of at least the purchase amount against one of a credit type and a debit type payment account of the user.

6. The method of claim 1, wherein the obtaining step obtains authorization of at least the purchase amount against a payment account of the user previously identified in a separate communication from the user.

7. The method of claim 1, wherein the obtaining step obtains authorization of more than the purchase amount against the payment account of the user.

8,-The-method of clainr-1, further comprising: second receiving, prior to the first receiving step, a communication from the user providing information on at least one payment account of the user, the information being sufficient to allow charges to be made against the at least one payment account.

9. The method of claim 8, wherein the second receiving step receives an off- line communication from the user, off-line communications being communications not over a network.

10. The method of claim 8, wherein the second receiving step receives a communication from the user over said first network.

11. The method of claim 8, wherein the second receiving step receives a communication from the user providing information on at least a first and second payment account of the user; the first receiving step further receives account identification information identifying one of the first and second payment accounts; and the obtaining step obtains authorization of at least the purchase amount against the identified payment account.

12. The method of claim 11, wherein the account identification information is insufficient infomiation by itself to allow charges to be made against the identified payment account. ^'

13. The method of claim 1, further comprising: establishing the separate payment account.

14. The method of claim 12, wherein the establishing step establishes the separate payment account when the obtaining step obtains authorization.

15. The method of claim 12, wherein the establishing step credits a preexisting payment account for at least the purchase amount to establish the separate payment account.

16. The method of claim 12, wherein the establishing step establishes one of a credit type and a debit type account as the separate payment account.

17. The method of claim 1, wherein the sending step sends the communication to the user if the obtaining step obtains authorization.

18. The method of claim 1, further comprising: second receiving user identification information from the user; and providing a means for the user to visit network locations in anonymity.

19. The method of claim 18, further comprising: confirming whether the user is a member based on the received user identification information and previously stored user identification information; and wherein the providing step provides the user a means to electronically browse network locations in anonymity when the confirming step confirms the user is a member.

20. The method of claim 1, wherein one of the communications of the receiving and the sending steps is an electronic mail communication.

21. The method of claim 1, wherein the receiving, obtaining and sending steps are performed without human intervention.

22. The method of claim 1, wherein the first network is the Internet.

23. The method of claim 2, wherein the obtaining step obtains authorization over a second network, different from the first network.

24. A method of providing secure transactions over a network, comprising: first receiving a communication over the network of at least a purchase amount for a purchase that a user desires to make on-line from a merchant; obtaining authorization for at least the purchase amount against a payment account of the user; and. filling in payment account information of an on-line payment form of the merchant using information on a separate payment account, wherein the separate payment account is not a payment account of the user.

25. A method of providing secure transactions over a network, comprising: receiving a request to download a software agent that assists in providing secure transactions over the network from a user; and sending the software agent to the user, the software agent performing, when requested by the user, the steps of, first sending a communication over the network requesting a separate payment account with which to make a purchase from a merchant, the separate payment account being a payment account not associated with the user making the purchase; receiving a communication providing information on the separate payment account over the network; and filling in payment account information of an on-line electronic order form of the merchant using the received information on the separate payment account.

26. A method of providing for simplified transactions over a network, comprising: receiving a request to download a software agent that assists in providing secure transactions over the network from-a user; and sending the software agent to the user, the software agent performing, when requested by the user, the step of, filling out at least a portion of the electronic order form of a merchant accessed via the network using pre-stored information.

27. A method of providing secure transactions over a network, comprising: first sending a communication over the network requesting a separate payment account with which to make a purchase from a merchant, the separate payment account being a payment account not associated with a user making the purchase; receiving a communication over the network providing information on the separate payment account; and first filling in payment account information of an on-line electronic order form of the merchant using the received information on the separate payment account.

28. The method of claim 27, wherein the first sending step further sends a payment amount that the separate payment account should cover, the payment amount being at least a purchase amount to make the purchase.

29. The method of claim 28, wherein the first sending step further sends user identification information.

30. The method of claim 29, wherein the first sending step further sends account identification information identifying a payment account of the user.

31. The method of claim 30, wherein the account identification information is insufficient information by itself to allow charges to be made against the identified payment account.

32. The method of claim 27, wherein the first sending step further sends account identification information identifying a payment account of the user.

33. The method of claim 32, wherein the account identification infoπnation is insufficient information by itself to allow charges to be made against the identified payment account.

34. The method of claim 27, wherein said first filling step is performed by a software agent.

35. The method of claim 27, further comprising: performing the first sending, receiving and first filling steps in response to user input.

36. The method of claim 27, further comprising: receiving a user request to fill out at least a portion of an electronic order form of the merchant; and second filling out at least part of the at least a portion of the electronic order form using pre-stored information in response to the received user request.

37. The method of claim 36, wherein the second filling step fills in a personal information part on the electronic order form.

38. The method of claim 37, wherein the second filling step fills in the personal infoπnation using one of more than two pre-stored personal information personas.

39. The method of claim 38, wherein at least one of the more than two pre- stored personal information personas are unrelated to the personal information of the user.

40. The method of claim 39, further comprising: electronically browsing a network location of the merchant via a portal of which the user is a member, the portal providing anonymity to members browsing the network via the portal.

41. The method of claim 38, wherein the second filling step comprises: obtaining user input as to which of the more than two pre-stored personal information _.personas to use in filling out a personal information part of the electronic form; and filling out the personal information part of the electronic form based on the obtained user input.

42. The method of claim 37, wherein the second filling step fills in the shipping address information part of the electronic form.

43. The method of claim 42, wherein the second filling step fills in the shipping address information using one of more than two pre-stored shipping addresses.

44. The method of claim 43, wherein at least one of the more than two pre- stored shipping addresses is not an address of the user.

45. The method of claim 43, wherein the second filling step comprises: obtaining user input as to which of the more than two pre-stored shipping addresses to use in filling out a shipping address information part of the electronic form; and filling out the shipping addresses part of the electronic form based on the obtained user input.

46. The method of claim 36, wherein the second filling -step fills in the shipping address information part of trie' electronic form.

47. The method of claim 46, wherein the second filling step fills in the shipping address information using one of more than two pre-stored shipping addresses.

48. The method of claim 47, wherein at least one of the more than two pre- stored shipping addresses is not an address of the user.

49. The method of claim 47, wherein the second filling step comprises: obtaining user input as to which of the more than two pre-stored shipping addresses to use in filling out a shipping address information part of the electronic form; and filling out the shipping addresses part of the electronic form based on the obtained user input.

50. The method of claim 36, prior to the first sending step, further comprising: receiving the pre-stored information via an on-line communication; and storing the pre-stored information.

51. The method of claim 50, further comprising: altering the pre-stored information based on user input, the altering step including additions, deletions and changes to the pre-stored information.

52. The method of claim 51, further comprising: second sending an on-line communication indicating the change in the pre- stored information.

53. The method of claim 36, wherein the first sending, the receiving and the first filling steps are substeps of the second filling step.

54. The method of claim 27, further comprising: electronically downloading a software agent that performs the first sending, receiving and first filling steps.

55. The method of claim 27, wherein the network is the Internet.

56. A method of simplifying transactions over a network, comprising: receiving a user request to fill out at least a portion of an electronic order form of a merchant accessed over the network; and filling out at least part of the at least a portion of the electronic order form using pre-stored information in response to the received user request.

57. A processor-readable article of manufacture having embodied thereon software comprising a plurality of code segments that implement the method of claim 1 to provide for secure transactions over a network.

58. A processor-readable article of manufacture having embodied thereon software comprising a plurality of code segments that implement the method of claim 27 to provide for secure transactions over a network.

59. A processor-readable article of manufacture having embodied thereon software comprising a plurality of code segments that implement the method of claim

56 to provide for simplified transactions over a network.

60. An apparatus to implement the method of claim 1 to provide for secure transactions over a network.

61. An apparatus to implement the method of claim 27 to provide for secure transactions over a network.

60. An apparatus to implement the method of claim 56 to provide for simplified transactions over a network.