US 20060047847 A1
A host-based system for sharing personal information of a network user with the resources accessed by that network user. The host-based system generally involves either or both of two data stores, referred to as passport and wallet. Passport and wallet are host-based collections of routinely requested personal information and can be maintained independently or collectively. A user with a populated passport or wallet can pass selected information to web sites, automatically or with very little effort, to enable an enhanced browsing experience or to assist in the completion of an online transaction.
1. A computer-implemented method for sharing a user's financial information, the method comprising:
maintain a user's financial information at a first server system;
receiving, at the first server system, a request for the financial information from a second server system, wherein the second server system corresponds to a business entity and the user is engaged in an e-commerce transaction with the business entity through the second server system; and
sending, from the first server system, the requested financial information to the second server system such that the second server system uses the financial information to complete the e-commerce transaction which the user is engaged in with the business entity.
2. The method of
3. The method of
4. The method of
receiving, at the first server system, a digital certificate from the second server system; and
verifying the identity of the second server using the digital certificate.
5. The method of
6. The method of
7. The method of
8. The method of
generating, at the first server system, an identifier; and
associating, at the first server system, the generated identifier with the financial information.
9. The method of
receiving, at the first server system, an identifier from the second server system;
determining that the received identifier corresponds to the identifier associated with the financial information.
10. A computer-implemented method for obtaining a user's financial information to complete an e-commerce transaction, the method comprising:
receiving, at a first server system, a request from a user to engage in an e-commerce transaction;
sending, from the first server system, a request for the financial information for the user to a second server system that maintains the user's financial information;
receiving, at the first server system, the requested financial information from the second server system; and
completing the e-commerce transaction using the received financial information.
11. The method of
receiving partial credit card information from the second server system;
requesting confirmation from the user that a credit card account associated with the credit card information should be used to complete the e-commerce transaction;
receiving confirmation from the user that the credit card account associated with the credit card information should be used to complete the e-commerce transaction;
receiving full credit card information after receiving the confirmation.
12. The method of
receiving, at the first server system, the requested financial information from the second server system comprises receiving full credit card information from the second server system; and
completing the e-commerce transaction using the received financial information comprises completing the e-commerce transaction using the full credit card information.
13. The method of
14. The method of
receiving a request from the user for a web page in the merchant website; and
sending the requested web page to the user.
15. The method of
receiving, at the first server system, an identifier;
sending the identifier to the second server system.
16. A computer-implemented method for sharing a user's personal information, the method comprising:
maintain a user's personal information at a first server system;
associating, at the first server system, an identifier with the user's personal information;
receiving, at the first server system, a request for at least a portion of the user's personal information from a second server system, the request including an identifier; and
sending the requested information to the second server system when the received identifier corresponds to the identifier associated with the user's personal information.
17. The method of
receiving, at the first server system, information that authenticates the user;
generating, at the first server system, the identifier in response to the server receiving the information that authenticates the user; and
associating, at the first server system, the generated identifier with the user's personal information.
18. The method of
19. The method of
20. The method of
This application is a continuation of U.S. patent application Ser. No. 09/693,860, filed on Oct. 23, 2000, now U.S. Pat. No. 6,944,669, titled “Sharing the Personal Information of a Network User with the Resources Accessed by that Network User,” which claims priority to U.S. Provisional Application No. 60/160,874, filed Oct. 22, 1999, titled “Sharing A User's Personal Information.” The entire contents of both applications are hereby incorporated by reference in their entirety.
The computer system 100 illustrated in
As shown in
In practice, a server system 200 typically is not a single monolithic entity, but is a network of interconnected server computers, possibly physically dispersed from each other, each dedicated to its own set of duties and/or to a particular geographic region. In such a case, the individual servers are connected by a network of communication links in known fashion.
A “browser” is an example of client software that enables users to access and view electronic content stored either locally or remotely, such as in a network environment (local area network (LAN), intranet, and wide area network (WAN) such as the Internet). A browser is typically used for displaying documents described in Hypertext Markup Language (HTML) and stored on servers connected to a network, e.g., the Internet. Technically, a web browser is a client program that uses the Hypertext Transfer Protocol (HTTP) to make requests of web servers throughout the Internet on behalf of the browser user. A web server contains, in addition to the HTML and other files it can serve, an HTTP server daemon, which is a program designed to wait for HTTP requests and handle those requests when received.
A user can instruct a browser to access a HTML document or web page by specifying a network address or Uniform Resource Locator (URL) at which a desired document resides. URLs are defined in Internet standard RFC 1738 to include an indication of the protocol to be used and the location of a resource on a web server. In response to instructions from the user, the browser contacts the corresponding server hosting the requested webpage, retrieves the one or more files that make up the webpage, and then displays the webpage in a window on the user's computer screen.
Web pages can typically be transported using HTTP as defined in Internet standard RFC 2068. HTTP is a set of rules for exchanging files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web (WWW). Relative to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols which are the basis for information exchange on the Internet, HTTP is an application layer protocol.
When a user of a web browser sends a HTTP request by typing in an URL or clicking on a hypertext link, the browser builds a HTTP request and sends it to the address indicated by the URL. The HTTP server daemon in the destination server machine receives the request and, after any necessary processing, the requested file is returned. The response is sent to the browser where it can be displayed to the user. The HTTP protocol response includes various codes detailing the result of the request. For example, return code 404 indicates that the information requested was not found. For transactions requiring security, the HTTP connection can be secured with encryption. This variant is known as Secure HTTP (HTTPS) or Secure Socket Layer (SSL).
HTTPS is a web protocol developed by Netscape Communications, Inc. (Netscape) of Mountain View, Calif. and is implemented in several browsers. The HTTPS protocol encrypts and decrypts user page requests as well as the pages that are returned by the web server. HTTPS uses Netscape's SSL as a sublayer under its regular HTTP application layer. HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP. SSL uses a key size of a predetermined number of bits (typically between 40 and 128) for the RC4 stream encryption algorithm, which is considered a minimal degree of encryption for commercial exchange.
When visiting an electronic commerce merchant, a user typically is presented with a web page order form URL that starts with “https://”, indicating the use of the HTTPS protocol. When sending the response, the browser will use the HTTPS layer for encryption. The acknowledgement received from the server also will travel in encrypted form using HTTPS, and will be decrypted by the browser's HTTPS layer.
HTTPS and SSL support the use of X.509 digital certificates form the server so that, if necessary, a user can authenticate (i.e., confirm the identity of) the sender. SSL is an open, nonproprietary protocol that Netscape has proposed as a standard to the World Wide Web Consortium (W3C). HTTPS is not to be confused with SHTTP, a security-enhanced version of HTTP developed and proposed as a standard by EIT.
A digital certificate is an electronic token that establishes the credentials of a party doing business or other transactions on the web. Certificates can be issued by a certification authority (CA). Typically, certificates can contain a party's names, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting and decrypting messages and digital signatures), and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Some digital certificates conform to a standard, X.509. Digital certificates can be kept in registries so authenticated users can look up other user's public keys.
Consumers can buy and sell products and services shown on web pages via electronic commerce (“e-commerce”) transactions. To enable these transactions, a consumer and merchant exchange personal and financial information concerning the online transaction, such as their credit card, billing address, and shipping address. Conventional payment systems associated with many Internet commerce sites therefore require customers to type their credit card and mailing information into a HTML form.
Navigating and completing such forms involves a great deal of repetition and associated inconvenience to users when providing name, shipping address, billing address, and credit card data to merchants. Completing electronic forms often is a tedious and error-prone process. Furthermore, using these payment systems, customers visiting several online stores may need to re-enter their payment/address information at each online store at which they make a purchase. For many stores, shoppers additionally may need to re-enter payment information at each subsequent visit.
To facilitate the process of completing forms, “form fillers” have been developed. These applications can automate the filling of forms encountered when visiting web sites. The form filler can recognize forms in the HTML and can record the data entered in the fields when the user fills out the form for the first time. Then, when similar fields show up in subsequent forms, the form filler can use the recorded data to automatically fill out these fields. An example of such a form filler is built into Microsoft Internet Explorer 5.0.
A similar, but more sophisticated, approach to facilitating online transactions is the digital wallet. A digital wallet is a software application that allows the user to input shipping and billing data once and reuse this information at many different web sites to complete a purchase. Digital wallets that complete merchant forms or directly transfer data to merchants have been successfully built into browsers in several ways, including as helper applications to browsers, stand-alone applications, and browser plug-ins.
Once the digital wallet is set up, the user can store, manipulate, and pay for Internet purchases with various types of payment instruments, e.g., credit cards or electronic cash.
Client-based personal electronic wallets have been developed to relieve this burden. Client-based wallets store e-commerce information for a particular user at the machine operated by that user. When that machine interfaces with a merchant website through the Internet, e-commerce information stored in the local wallet may be transferred to the merchant. However, because client-based wallets reside on the user machine, these wallets are subject to the limitations of the machine upon which they reside. For instance, security attacks on the user machine may be used to target the wallets residing thereon. In addition, limitations on portability for the machine result in limitations for the wallet.
One or more of the following advantages may be provided. The techniques and methods described here may enable the user to drastically reduce the amount of work required to fill out forms on web pages. This may be accomplished in one or more of the following ways. First, multiple pages of content may be completed without requiring the user to view each page. Presenting only those fields and forms that are not automatically completed minimizes the work for users. Users can be selectively queried for any merchant-specific missing fields, thus optimizing the form filling process. Users need not inspect each form and approve its contents. Further, merchants using the techniques and methods described here may be able to provide information that is tailored and customized for the user, thus increasing the usefulness of the merchant's content to the user.
Other advantages for the user include ease of use since no additional software is required. Further, as the user is not tied to a single computer, the user's information can be accessed from any computer capable of accessing the merchant's site, regardless of location. In addition, the security of the user improves because risks associated with data sniffing on the user's local area network and accessing storage devices attached to the user's computer can be reduced.
The merchant can access specific information about a customer's preferences and history and use that information to customize the content presented. Merchants can track completed purchases in order to better handle service and information requests. Because merchants can access the information using a protocol, merchants can easily modify forms without causing problems with many different types of software. Merchants can obtain demographic data for future targeted advertising. An intimate relationship between the merchant, the user, and the online service can be fostered.
These techniques and methods can be generalized and applied to a variety of user preference data, e.g., travel preferences, in addition to shipping, billing, and demographic data. These techniques can be implemented as a system, method, software, or some combination thereof.
Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
Like reference symbols in the various drawings may indicate like elements.
Quick checkout (QC) is a host-based system for sharing personal information of a network user with the resources accessed by that network user. QC generally involves either or both of two data stores, referred to as passport and wallet. Passport and wallet can be host-based collections of routinely requested personal billing, shipping, and demographics information (hereinafter, “personal information”). Passport and wallet can be maintained independently or collectively. A user with a populated passport or wallet can choose to pass selected information to web sites, automatically or with very little effort, to enable an enhanced browsing experience or to assist in the completion of an online transaction.
For instance, when merchants offer QC as a payment option and the user elects to invoke QC, the merchant passes the order information to a pre-determined SSL-enabled QC form that is displayed to the consumer. Payment information and shipping address can be sent from the QC database to the QC form, and the form is confirmed, rejected or modified by the user. In this manner, the user does not need to redundantly enter payment information for each transaction or each merchant. Rather, the user can rely on the wallet for this information, with the user confirming the accuracy of the information. As will be explained in greater detail below, when the wallet includes several options for payment, shipping, etc., the consumer can establish default information, and has the ability to select desired information from among that stored.
This host-based system facilitates an integration with other merchant services as well as the surrounding wallet/passport provider environment. Because the wallet and passport are host-based, the wallet and passport can be portable, updateable, secures and simple to setup and use.
QC can be used to share many different pieces of a user's personal information, before and during an e-commerce transaction. For instance, using QC, selected user information can be shared with a merchant server upon a user's access to a web site or later, when performing an e-commerce transaction. More specifically, upon access to a merchant's web site, the merchant can personalize the content and services provided to the user. QC can share a variety of personal information, such as travel preferences, demographic information, food choices, and medical information. Thereafter, upon checkout, personal information of a more specific nature, generally concerning e-commerce information, can be shared. For instance, commercial information such as user name, address, and credit card information can be shared, when appropriates to further e-commerce transactions. Each user's information can be stored in a “profile” that can be updated. This information can be stored in a proprietary or commercially available relational or object database management system (DBMS), such as provided by Oracle, Inc. or Informix, Inc.
HTTPS is generally used as a transport for requests and responses. However, other protocols could be used as transport mechanisms. Input parameters in requests and return values can be URL-encoded so that nonstandard characters can be properly transmitted over the Internet. Furthermore, return codes from the requests can be used to verify their success.
Although the framework does not require a fixed sequence of requests from network hosts, communications between the user, the merchant, and the framework typically follow a particular pattern, illustrated in
In step 720 b, preferences information about the user can be returned by the preferences server 703 to the merchant server 702. In step 720 c, the information can be formatted into a web page requesting confirmation of the information from the user at client computer 701. At this stage, only a portion of any previously entered credit card information is returned for security purposes, the returned information providing enough information for the user to confirm and/or edit the user information at this stage.
Finally, the results of this transaction are sent to preferences server 703 for customer service, record keeping, and order tracking purposes. These results can be stored in the database for use in future transactions. The merchant can check the HTTP return status code from the preferences server 703 and take appropriate action, if a failure occurs.
The flowchart of
Next, the user can be shown the authentication page from website, e.g., the AOL site (step 802). This page is shown in
Once the user has either successfully authenticated or registered, the user is shown a web page to review the order information.
If the user chooses to edit transaction information, the user is shown a set of edit screens (step 805). The first such screen is shown in
If the user chooses to edit credit cards, a screen, as shown in
If the user chooses to edit addresses, the process is similar to that for editing credit cards, as shown in
If the user chooses to change security information, the screen, as shown in
If the user chooses to delete AOL Quick Checkout settings, the screen shown in
If the user requests customer service, the screen shown in
If the user in step 804 of
If the user in step 804 of
In some implementations, a proxy server is used with the host-to-host architecture. The proxy can act as an intermediary for traffic between host service computers and the Internet. The proxy can perform load balancing by switching connections to the least utilized hardware for performance. The proxy also contains a list of hosts that can be redirected to internal AOL sites. The internal sites provide AOL users with a more consistent look and feel. The internal sites can also be more tightly integrated with the AOL system because they are under AOL control.
In another implementation, as a user selects items to purchase from a particular merchant, the merchant collects and stores information about the purchase order, designated with an order identifier that is used to unify the order information. The order information typically is presented to the consumer (user) in a shopping cart upon request or at checkout. Using this order information, the consumer can confirm the contents of the shopping cart by invocation of QC or otherwise, as the order identifier can tie a subsequent QC information to the order information stored by the merchant.
Then, when the consumer launches QC, for example, by clicking on an icon at the merchant website, the merchant authenticates the consumer as a QC user. To do so, the merchant directs users to the AQC aolqc_auth url for authentication. If the GET to this url returns successfully, the user can be “logged in” as an AQC member. For example, the GET returns with a session identifier (aolqc_session_id) which serves as a key to the consumer account. Thereafter, the session id is passed with each backend call made by the merchant e.g., to retrieve billing information for the customer or to enable editing by the customer. Once the consumer is authenticated once by a merchant, the consumer will not be redirected back to the authentication page until the consumer has logged off of the AOL service.
If authenticated, payment and shipping information is collected from QC. Preferably, the merchant makes a host-to-host call to fetch a “pretty print” user-displayable version of the user's default billing and shipping information from the QC, which does not include all of the information. The merchant then automatically produces a form that includes an order id, which is posted to https://payment.aol.com/placeorder. For instance, a standard form can include the parameters listed in Appendix A (see parameters spanning pp 5-6 of AOL QC Merchant Connectivity Specification filed with provisional application No. 60/160,874 filed Oct. 22, 1999, which is incorporated by reference in its entirety). Using the order_allow_multi_shipto field of the placeholder form, a merchant can enable designation of different shipping destinations for different aspects of the order, e.g., per unit or per item. Similarly, other fields can be duplicated to provide flexibility, as needed.
In response to the placeorder form, available QC information can be returned from the wallet and posted at the merchant. Default QC information can be automatically selected to eliminate the need for additional user interaction, unless editing is necessary. Alternatively, the consumer can select among available QC information. e.g., credit card, shipping address information. In either case, a subset of the sensitive QC information from the wallet can be provided to the merchant in response to the placeorder request. This subset can include enough for the consumer to confirm/select, but intentionally omits some information to avoid possible security problems, such as trojan horses. The selected subset of QC information can be posted by the QC host to the merchant site at the https://payment.aol.com/order_target_url page for future use in creating a confirmation page combining order and QC information. Fields from an exemplary form are listed on pgs. 6-7 of AOL QC Merchant Connectivity Specification, which was filed with provisional application No. 60/160,874 filed Oct. 22, 1999, which is incorporated by reference in its entirety). If the merchant can allow multiple shipping destinations for aspects of a single order, and the consumer can designate multiple destinations in the information provided by the merchant to the host, multiple posts can be made by the host to the https://payment.aol.com/order_target_url page. Each post can have the same order id, number but different information where appropriate to accomplish the consumer order.
After the consumer is redirected to the merchant site, the merchant can provide an order confirmation page displaying the order and payment data. Specifically, the merchant can generate a form that displays the selected QC info and that queries the consumer to confirm the purchase. The confirmation page posts to a designated location known to wallet host, e.g., https://payment.aol.com/confirmorder. Fields from an exemplary form are listed in Appendix C (see list of parameters listed on p8 of AOL QC Merchant Connectivity Specification). If the merchant allows multiple shipping destinations for aspects of a single order, the consumer can designate multiple destinations in the information provided by the merchant to the host, and multiple posts can be made by the host to the https://payment.aol.com/order_target_url page with the same order id number. The merchant can generate a confirmation page for each part of the order. Generally, information is filtered before being returned to the merchant for confirmation (to prevent the merchant from obtaining enough financial information to complete the transaction until after the complete transaction is confirmed by consumer). The merchant can then display a screen requesting confirmation of the transaction with limited information being shown about the credit card.
After the order has been confirmed, three processes are performed:
1. the customer is redirected to the http://payment.aol.com/order_return_url page, which displays a message from the merchant thanking the customer for their order,
2. the merchant receives complete credit card information from the host along with other order information that is posted to a target url specified in the order_target_url field of the initial post generated by the merchant. This information is used by the merchant to deliver the ordered goods. An exemplary format for the order information is shown by appendix D (see pp 8-10 of AOL QC Merchant Connectivity Specification), and
3. the merchant pushes order data to a URL accessible to the wallet host for customer service, record keeping and order tracking purposes.
Using this system and the ability to store and share personal information, enhanced functionality such as parental controls, AOL rewards, gift reminders, purchase history, and keyword billing can be provided.
Furthermore, integration with a service provider enabling several screen-names for a single account can allow the user to designate separate wallets/passports for different members on an account, each drawing on some common and some independent information. For instance, several family members having different screen-names can each maintain independent wallets with separate e-commerce information. while being provided access to a shared wallet having shared e-commerce information. In this manner, selected credit cards or e-commerce information can be made accessible to some or all screen-names without sharing all credit cards or other e-commerce information. Furthermore, when combined with the passport functionality, this model can allow information to be maintained and communicated for each independent screen-name.
The techniques, methods, and systems described here can find applicability in any computing or processing environment in which electronic content can be viewed, accessed, or otherwise manipulated. For instance, the concept of sharing e-commerce transaction information between hosts in a networked computing environment can be applied whenever those preferences are useful to a third party, such as an e-commerce merchant. One such environment can involve a computer system, e.g., a Microsoft Windows-based PC or Apple Macintosh, connected to the Internet.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. A system or other apparatus that uses one or more of the techniques and methods described here can be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer system to operate on input and/or generate output in a specific and predefined manner. Such a computer system can include one or more programmable processors that receive data and instructions from, and transmit data and instructions to, a data storage system, and suitable input and output devices.
Each computer program can be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors.
Generally, a processor can receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer instructions and data can include forms of non-volatile memory, including semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks.
Any of the foregoing can be supplemented by, or implemented in, specially designed ASICs (application specific integrated circuits).
A number of implementations have been described. Nevertheless, it will be understood that various modifications can be made without departing from the spirit and scope of the invention. For example, advantageous results still could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components.
Accordingly, other implementations are within the scope of the following claims.