Method and system for disclosing information during online transactions

CROSS REFERENCES TO RELATED APPLICATIONS

[0001] The present patent application claims priority from U.S. Provisional Patent Application 60/185,624, Alan Skea, Method and system for disclosing information during online transactions, filed Feb. 29, 2000.

BACKGROUND

[0002] 1. Field of Invention

[0003] This invention relates to the communication of possibly sensitive information amongst parties to a transaction carried out over a computer network such as the Internet.

[0004] b <b>2</b>. Description of Prior Art

[0005] Computer networks, and in particular the Internet, are increasingly being used for the exchange of information as part of various transactions. A common example of this is the use of the Internet to transact the purchase of goods or services. A customer uses a computer connected to the Internet to retrieve descriptions of the goods or services from a vendor's system and to transfer purchasing information to the vendor's system. The purchasing information is typically the customer's credit card details for payment, the customer's address for delivery and some indication of the item or items that are being purchased.

[0006] Present day techniques for making transactions using computer networks have problems including:

[0007] the fact that information received from the customer during the transaction remains in the vendor's hands after the transaction;

[0008] Many of the techniques used for making transactions on the internet require that the vendor agree to standard techniques for transferring and storing information; and

[0009] Many of the techniques require that the customer have special hardware and/or software. Beginning with the problem of retention of information received from the customer, a vendor will often not make direct use of all of the information themselves but will pass some of it on to other parties to effect part of the transaction. For example, merchants often pass a customer's credit card information along with purchase price and merchant account information to a credit card clearing agent or payment services provider. The merchant has no real need for the credit card information themselves except to pass it along to their clearing agent. Similarly, delivery of goods may be carried out on behalf of the merchant by a delivery agent. If so then the merchant has no need for the customer's address except to pass on to the delivery agent along with the goods to be delivered and any other information that the delivery agent might require from the merchant.

[0010] In both these examples the merchant concludes the transaction in possession of information which is not essential for their part in the transaction and which the customer might prefer not to disclose. Once disclosed the customer has little or no control over what the vendor might do with the information and despite vendor assurances and privacy policy statements, there are regular news stories reporting failures of vendor data security or dubious vendor data practices.

[0011] The problem of retained information is has been aggravated by the widespread use of certain techniques for streamlining the process of placing an order over the Internet. For example, in U.S. Pat. No. 5,960,411 to Hartman et al. (1999), a system is proposed whereby a merchant maintains a database of customer information and identifiers. On returning to a merchant using this system, a customer's system automatically provides a previously assigned identifier (known as a cookie). This identifier is then used to retrieve the customer's data from the database and the customer need not re-enter their credit card, delivery address or other details. Using this or a similar system a customer might place an order with only a few interactions with the merchant's system. While this might be a very compelling proposition to many customers, it requires that they permit the merchant to store the information for longer than the time required for a single transaction. In granting this permission the customer foregoes any control they have over the use of the information. The merchant may make certain assurances regarding their intended use of the information but these are not binding and the customer runs a further risk that the information may be unintentionally or maliciously disclosed to third parties.

[0012] In addition to the concerns regarding the loss of control over the information, a customer has the problem of maintaining the currency and validity of the information that might be kept in various merchants' databases. Unless the customer only ever buys from one merchant, there are likely to be a number of merchants to whom the customer has disclosed information for storage in a database. If the customer's details change (perhaps the customer's credit card expires and is replaced by a new one) then the customer must update this information with each of the merchants with whom they have regular dealings.

[0013] Retention of information is also a problem with “electronic wallets”. Some kinds of electronic wallets also require specialized software and other kinds are limited by the lack of standards. There are two main types of electronic wallets. The first type requires that the customer install a piece of software on their computer which manages their personal information and the communication of this information to merchants. While this software preserves control over the customer's information and provides a central location for information maintenance, it needs to understand exactly how each merchant requires the information to be presented and interact with that merchant accordingly. This is a monumental task and will always be one step behind the new features that merchants may offer. Customer's will be caught up in a cycle of perpetual upgrades and the electronic wallet software manufacturers will have the task of trying to convince merchants to use a rigid format for acquisition of customer information. In cases where an unusual piece of information is needed, the customer will have to bypass the electronic wallet software and interact with the merchant directly.

[0014] The second main type of electronic wallet allows customers to give custody of their information to an electronic wallet system which is hosted on a remote system. This system stores the customer's information in a database and gives the customer an identifier to be used when shopping. In addition to requiring the trust of the customer and the data security risks associated with building databases full of customer data, this system also has the problem that it must convince merchants to participate and it cannot be used at non-participating merchants. Since there are several providers of this sort of electronic wallet it is likely that there will not be any one dominant provider and merchants will have to choose which, if any, provider to work with. To achieve streamlined transactions with all merchants who offer electronic wallet based shopping, customers will have to submit their information to many electronic wallet providers. While the number of electronic wallet providers is likely to very much less than the number of merchants, there will still be a number of places at which a customer will need to maintain the currency and validity of their information.

[0015] Another big drawback with submitting information to an electronic wallet provider is that the provider can monitor the customer's shopping behaviour at all participating merchants and draw inferences about the customer's lifestyle and future behaviour. This information can then be used by other organisations to target promotions for their goods and services and the provision of this information to these other organisations can provide a source of revenue for the electronic wallet provider. Many customers would prefer not to have their behaviour monitored in this way.

[0016] As with the method of Hartman et al., at the conclusion of a transaction which has been mediated by an electronic wallet, the vendor is in possession of customer data that they no longer need and which the customer might prefer them not to have. Again the customer has lost control over the uses to which their data might be put.

[0017] Many systems have been proposed to protect customer data while it is in transit during a transaction. Currently the most commonly used method on the Internet is the Secure Sockets Layer (SSL) which uses strong encryption to protect the data in transit and is built into most Internet browsing software. Many writers speculate that such a system is not strong enough to prevent network eavesdroppers from acquiring the data and propose systems that attempt to provide a more secure solution. U.S. Pat. Nos. 5,903,721 to Sixtus, 5,883,810 to Franklin et al. and 6,000,832 to Franklin et al. all propose such systems. What they and other such systems all neglect is the practical reality that the data in transit that is encrypted using SSL is protected to a much greater degree than data stored on a vendor's system. There are know security problems with all the major operating systems that are used by vendors for Internet commerce and there is little point in improving the security of data in transit when the data stored on a vendor's system or an electronic wallet provider's system is more vulnerable. A serious data thief will try to compromise security at the weakest point where there are likely to be rewards which make the effort worthwhile. Each customer-vendor session using SSL has different encryption and it is likely that a separate effort would be needed to compromise each session and obtain a single customer's data. On a vendor's system they are likely to find the data records of many customers protected by the security system inherent in the vendor's operating system. This operating system is likely to have known security flaws and new security flaws are being constantly discovered. This is the point that most data-thieves will attack and where developments in data security are needed.

[0018] The requirements of special hardware or software and the lack of standards are barriers to adoption of many proposed systems for doing transactions via a network. If the customers have to download a piece of software, or give their data to a “trusted provider” then there is a barrier to customer adoption. If the vendor has to make arrangements with each and every trusted provider then there is a barrier to vendor adoption. Unless both the customers and the vendors are likely to gain significantly from the adoption of a new system and lose nothing or very little, then it is likely that the barriers will be too great and the system will not achieve the market penetration necessary for it to be a commercial success. Good examples of this are the Secure Electronic Transactions protocol (SET) and Digicash. SET required customers and vendors to obtain certificates before they could participate and provided added benefits in the form of fraud reduction to only the credit card companies. Digicash arranged for special electronic tokens to be sold to customer who stored them for later spending. The tokens could be authenticated but contained no customer data so any purchase could be anonymous. This required a big leap of faith on the part of the customers and vendors that the tokens wouldn't be lost by anyone involved in the transactions and that the value of the tokens would be stable. It is an object of the invention to overcome the above and other problems of present-day techniques of performing transactions over networks.

SUMMARY OF THE INVENTION

[0019] The invention solves the problems posed by vendor retention of information provided by customers, by the lack of standard systems, and by the need with many systems to employ special software and/or hardware by adapting the standard HTTP protocol to make a system which makes it so easy for a customer (or broadly, a user) to provide a vendor with transaction-invariant information about the user that there is no need for the vendor to retain such transaction-invariant information between transactions. Transaction-invariant information is simply information about the user that generally does not change between transactions. The system is implemented in a service program running in a server system that interacts with a user agent that is running in a system used by the customer. One example of a user agent is a browser; other examples are be similar programs executing in portable devices such as palm computers or cellular telephones or in television sets or smart telephones.

[0020] The user agent is a typical user agent such as a browser program that has been improved by including transaction-invariant user information that is stored in the user agent. The transaction-invariant user information permits the service to perform the transaction without requiring the user to input additional transaction-invariant information user information during the transaction and an operation in the browser automatically provides the transaction-invariant user information to the service. The operation that provides the transaction-invariant user information requires substantially less interaction by the user with the user agent than that required to input the transaction-invariant user information to the user agent.

[0021] The service is a typical service executing in a server which has been improved in that the service receives the user agent-stored transaction-invariant user information in the service during the transaction and uses the transaction-invariant user information to perform the transaction without either using transaction-invariant user information retained from a previous transaction between the provider and the user or requiring the user to input additional transaction-invariant user information during the transaction.

[0022] The transaction-invariant user information may include information such as personal identification information for the user, information which may be provided to another participant in the transaction who vouches for the user with regard to the transaction, contact information for the user, delivery information for an item being shipped as a result of the transaction, or payment information.

[0023] In one embodiment of the invention, the user employs the user agent to input the transaction-invariant user information to the service. The service uses the transaction-invariant user information to make the user agent-stored transaction-invariant user information and returns the transaction-invariant user information to the user agent, which stores it for later use. In the embodiment, the service and the user agent employ the HTTP protocol and the service returns the transaction-invariant user information to the user agent as a cookie.

[0024] In another aspect of the invention, more than one service may participate in the transaction and one of the services may provide another of the services with a transaction identifier that identifies the transaction via the user agent. The services can then use the transaction identifier to identify information that one service sends the other regarding the transaction.

OBJECTS AND ADVANTAGES OF THE INVENTION

[0025] Accordingly, several objects and advantages of the present invention are:

[0026] (a) that providers need never be given any more than the bare minimum of information that is necessary to effect their part of the transaction. For goods or services that can be delivered entirely electronically or which are collected from the providers by the customer or an agent of the customer, the transaction can be entirely anonymous. Similarly, a credit card agency need never know what items the customer is purchasing, only the identity of the provider making the sale and the amount to be charged to the customer;

[0027] (b) that a customer has custody of their own information and can change it, make it unavailable, limit its validity or destroy it at will;

[0028] (c) that the customer can store the information required by a particular provider once and use the stored information many times without re-entering;

[0029] (d) that if the customer's information changes or expires then the customer need only update the copy stored on their own system;

[0030] (e) that once information is stored on the customer's system transactions are streamlined and may be carried out with very few interactions with a provider. This is convenient for the customer, lowers the barriers to online purchasing and facilitates impulse buying;

[0031] (f) that the invention can be implemented using a combination of existing features of Internet protocols. Most customers who already use Internet software need not upgrade or install any new software to make use of this invention on the Internet.

[0032] Further objects and advantages of the invention will become apparent from a consideration of the drawings and ensuing description.

DRAWINGS FIGURES

[0033] In the drawings closely related figures have been given the same number but different suffixes.

[0034]FIG. 1 is a block diagram illustrating a customer's system in an embodiment of this invention.

[0035]FIG. 2 is a block diagram illustrating a provider's system in an embodiment of this invention.

[0036]FIG. 3 illustrates the use of the method of this invention in a transaction involving a customer and a single provider.

[0037]FIG. 4 illustrates the use of the method of this invention in a transaction involving a customer and two providers.

[0038]FIG. 5A illustrates the use of the method of this invention in a transaction involving a customer and three providers where all providers act equally on their own behalf.

[0039] FIGS. <b>5</b>B-<b>550</b> through <b>5</b>B-<b>585</b> show the HTTP request-line and headers for the requests and the HTTP status-line and headers for the replies that are used in a transaction using the method of this invention involving a customer and three providers such as is shown in FIG. 5A. The numeric suffix on the figure number corresponds to the request or reply of the same number shown in FIG. 5A. Lines numbers have been added and long lines have been folded at the margins to fit on the page. Line 1 in each figure is always either a request-line (for requests) or a status-line (for replies). The remaining lines are all HTTP headers.

[0040]FIG. 6A illustrates the use of the method of this invention in a transaction involving a customer and three providers where one of the providers acts as an information manager on behalf of the other providers.

[0041] FIGS. <b>6</b>B-<b>650</b> through <b>6</b>B-<b>675</b> show the HTTP request-line and headers for the requests and the HTTP status-line and headers for the replies that are used in a transaction using the method of this invention involving a customer and three providers such as is shown in FIG. 6A. The numeric suffix on the figure number corresponds to the request or reply of the same number shown in FIG. 6A. Line numbers have been added and long lines have been folded at the margins to fit on the page. Line 1 in each figure is always either a request-line (for requests) or a status-line (for replies). The remaining lines are all HTTP headers.

[0042]FIG. 7 is a flow diagram of a routine for a first provider's system that creates a Web page in which transactions using the method of this invention are enabled.

[0043]FIG. 8 is flow diagram of a routine for a first provider's system that uses the method of this invention to continue the processing of a transaction.

[0044]FIG. 9 is a flow diagram of a routine for a first provider's system that uses the method of this invention to complete the processing of a transaction.

[0045]FIG. 10 is a flow diagram for a routine for a second provider's system that uses the method of this invention to collects customer data for a possible transaction.

[0046]FIG. 11 is a flow diagram of a routine for a second provider's system that uses the method of this invention to assemble all transaction data, to process the transaction and return the result to a first provider's system.

[0047]FIG. 12 is a screenshot taken on a customer's system of a secure form produced by a second provider's system for the management of credit card data.

[0048]FIG. 13 is a screenshot taken on a customer's system of a dialogue message displayed when a second provider's system passes encrypted information to a customer's system for storage in the form of a cookie.

[0049]FIG. 14 is a screenshot taken on a customer's system of a secure confirmation screen produced by a second provider's system showing the credit card data that was received, encrypted and sent back to the customer's system as a cookie.

[0050]FIG. 15 is a screenshot taken on a customer's system of a secure form produced by a second provider's system for the management of delivery address data.

[0051]FIG. 16 is a screenshot taken on a customer's system of an insecure page produced by a second provider's system that summarises a proposed transaction and allows the customer to vary the transaction parameters and accept or reject the transaction.

[0052]FIG. 17 is a screenshot taken on a customer's system of a secure form produced by a second provider's system for the management of transaction preferences which could streamline a transaction.

[0053]FIGS. 18A and 18B show the request-line and headers from an HTTP request and the status-line and headers from an HTTP reply that use the method of this invention to store user-information at the user's machine in the form of an encrypted cookie.

[0054]FIG. 19 shows some extracts from the HTTP specification that give the format for an HTTP message.

DESCRIPTION AND OPERATION OF THE INVENTION

[0055] Background to Network Protocols

[0056] Much of the following discussion refers to example embodiments that use the HTTP protocol, the specifications of which can be found at the web site of the World Wide Web Consortium:

[0057] http://www.w3.org/Protocols/HTTP/1.1/rfc2616.txt.gz

[0058] http://www.w3.org/Protocols/rfc1945/rfc1945

[0059] Also relevant to the discussion are the extensions to this specification which provide for cookies and which were proposed by Netscape in:

[0060] http://home.netscape.com/newsref/std/cookie spec.html

[0061] and revised and formalised (though the revisions are not yet widely used) in the later proposals:

[0062] http://www.w3.org/Protocols/rfc2109/rfc2109

[0063] http://portal.research.bell-labs.com/˜dmk/cookie-3.12.txt

[0064] The HTTP cookies used as examples in this document conform to the earlier Netscape specification.

[0065] Although the discussion here uses HTTP as an example, other technologies also lend themselves to use of this invention. The Wireless Application Protocol (WAP) is one such other technology. The specification for the Wireless Session Protocol layer of the WAP protocol stack:

[0066] http://www1.wapforum.org/tech/terms.asp?doc=WAP-203-WSP-20000504-a.pdf

[0067] states that:

[0068] The core of the WSP design is a binary form of HTTP

[0069] The WSP specification includes an equivalent of the HTTP cookies and it is clear from this and on further reading of the WSP specification that it too could use the method of this invention.

[0070] Section 4.1 of the HTTP/1.1 specification (rfc2616) describes the structure of an HTTP as follows:

[0071] HTTP messages consist of requests from client to server and responses from server to client. Request and Response messages use the generic message format of RFC 822 for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as “headers”), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.

[0072]FIG. 19 shows the syntax of an HTTP message as given in the specification. There are two kinds of messages: request messages which the browser sends to the service and response messages which the service sends to the client in response to request messages. The important parts of these messages for the purposes of the example embodiments of this invention are the Request-line for HTTP requests, the Status-line for HTTP responses, and the message-headers for both requests and replies. The Request-line contains the Request-URI which is the network name for the resource that is being requested. Line 14 of FIG. 19 shows the syntax of an http-URL which is the particular type of Request-URI used in the HTTP protocol. Other information may be associated with the Request-URI and this enables the client sending the request an opportunity to pass the extra information to the service for use in handling the request. In the present invention, the extra information includes a transaction identifier.

[0073] The Status line includes a status type. Of particular interest in the present context is the redirect status type. When the client receives a response message with the redirect status type, the client redirects the message to a service at a URI specified with the keyword location in the HTTP message header. As before, the URI may have other information such as a transaction identifier associated with the URI. The present invention uses a response message with the redirect status type and a URI with an associated transaction identifier to pass the transaction identifier from a first service to a second service via the client.

[0074] The message-headers may contain two headers which are of particular interest in the example embodiments of this invention. These are the Cookie: header that is used in Request messages (illustrated in FIG. 5B-<b>560</b>) and the Set-Cookie: header used in Response messages (illustrated in FIG. 18B). When a client receives a Response message containing a Set-Cookie header, it may store the contents of the header (the cookie) for later use in Request messages. Cookies are associated with a domain (a network address) and a path (the name of a resource at that address) and are only included in Request messages where the Request-URI matches the domain and path (if specified). If the domain and path are not specified in the Set-Cookie: header then the Cookie is associated with the current path at the responding host. In the normal course of operation this means that a server can store information at a client that will only ever be returned to itself. In the preferred embodiment, Set-Cookie is used to send a cookie containing transaction-invariant user information to the client and Cookie is the mechanism by which the cookie is automatically set to the service when a Request-URI specifies the service's domain and path.

[0075] Embodiments of the Invention

[0076] A typical transaction that might make use of this invention is the online sale of goods or services. There are two types of parties to the provision of the goods or services. The first type of party is a customer who is requesting the goods or services; the second type of party is a provider of the goods or services. While the transaction is discussed in terms of the customer and the provider in the following, it should be understood that the customer performs the actions ascribed to him or her by means of a user agent and the provider performs the actions ascribed to it by means of a service executing in a server. Each customer is in possession of various pieces of information which are necessary to the provision of the goods or services by various providers. This invention allows a customer to pass to various providers the information necessary for each provider to perform their part of a transaction. If there is more than one provider for a particular transaction then this invention also provides a method whereby a provider can share other information with other providers who are also involved in the transaction.

[0077] In order to use the method of this invention for transactions a customers must first arrange to record some of the information required for those transactions (the transaction-invariant user information) in such a way that it can be made available to the providers who will need this information to effect their part of a transaction. This step can be performed once and the recorded results used many times and although the information may change and need to be updated from time to time, for the most part it is transaction-invariant. In one embodiment of the invention the method for recording this information is for the customer to visit the web site of each provider involved in the transaction. At each provider's web site a form is made available and the information that will be required by that provider is entered by the customer into the form. FIGS. 12 and 15 show examples of such forms and FIG. 18A shows the request-line and headers from an HTTP request which sends the contents of such a form to a provider's system. The provider's system then constructs a token (commonly known as a cookie) and asks the customer's system to store the cookie. FIG. 13 shows a dialogue that might be displayed by the customer's system to confirm acceptance of such a cookie and FIG. 18B shows the status-line and headers from an HTTP reply that contains such a cookie at line 6. The provider may then discard the cookie and all the information gathered in the process of constructing the cookie. The cookie will automatically be included in any request that the customer's system might later send to the provider's system and at that time the provider can extract the information from the cookie. FIG. 5B-<b>560</b> shows the request-line and headers from an HTTP request containing several such cookies at line 7.

[0078] With the cookies in place it is possible for the customer to use the method of this invention to enter into transactions involving those who also use the method of this invention.

[0079]FIG. 1 is a block diagram illustrating a customer's system in an embodiment of this invention. The customer's system <b>100</b> comprises a processing element <b>110</b>, a memory <b>120</b>, and an external interface <b>130</b>. The memory element <b>120</b> contains a client module <b>121</b> comprising a program (the user agent) which can be executed by the processing element <b>110</b> and other data which may be required for the execution of the program. The memory element <b>120</b> may also contain a cookie table <b>122</b> comprising a collection of cookies that have been collected by the system during the course of its use.

[0080] The program in the client module <b>121</b> is capable of using external interface <b>130</b> to send requests to providers on behalf of the customer and to receive replies from these providers. These replies may result in further requests being sent to the same or other providers or may be communicated to the customer. The external interface <b>130</b> may include facilities for sending requests and receiving replies via local or wide-area networks including the Internet.

[0081] In this embodiment the means by which the customer specifies the requests to be sent, and the means by which the received replies are communicated to the customer are not a part of the customer's system <b>100</b>. The external interface <b>130</b> is also used to receive requests from and send replies to external components or systems which perform these functions. One skilled in the art would see that these external components could equally well be part of the customer's system in a different embodiment of this invention.

[0082]FIG. 2 is a block diagram illustrating a provider's system in an embodiment of this invention. The provider's system <b>200</b> comprises a processing element <b>210</b>, a memory element <b>220</b> and an external interface <b>230</b>. The memory element <b>220</b> contains a server module <b>221</b> comprising a program which can be executed by the processing element <b>210</b> and other data which may be required for the execution of the program. The memory element <b>220</b> also contains a transaction module <b>222</b> and a transaction identifier table <b>223</b>. The transaction module <b>222</b> comprises a program (the service) which can be executed by the processing element <b>210</b> and other data which may be required for the execution of the program. The external interface <b>230</b> is used by the program to receive requests from and send replies to various other systems, possibly including facilities for communicating over local or wide-area networks including the Internet.

[0083] The program in the server module <b>221</b> is capable of receiving requests from and sending replies to customers or other providers, possibly making use of the transaction module <b>222</b> to provide the replies to be sent. This program might also be capable of extracting customer information from any cookies which might arrive as part of a request, allocating a transaction identifier and storing this along with the customer information in the transaction identifier table <b>223</b>. The transaction identifier may be included in the reply sent to a request containing a cookie.

[0084] The program in the server module <b>221</b> may also be capable of extracting customer information from a request from a customer and constructing a cookie to be stored on the customer's system. The cookie is then sent to the customer as part of a reply to the request and the customer information is discarded.

[0085] The program in the transaction module <b>222</b> is capable of constructing a reply to a transaction request on behalf of the server module <b>221</b>. The transaction requests may come from a customer or from another provider. On receiving a request this program attempts to locate a record in the transaction identifier table <b>223</b> which corresponds to an identifier supplied in the request. If found this program uses the information stored in this record and information from the request to execute the requested transaction. A reply is then constructed and passed back to the server module <b>221</b> to be sent.

[0086] The following examples show a variety of ways in which a customer's system can use the method of this invention to effect an online transaction with various providers' systems. Note that where the following examples refer to a credit card, other forms of charge card, debit card or other payment system might equally be used.

FIRST EXAMPLE

[0087] Two Parties—Customer &amp; Vendor

[0088]FIG. 3 shows the sequence of events when a customer transacts the purchase of goods or services from a provider over the Internet using an embodiment of this invention.

[0089] The customer's system or user-agent <b>300</b> sends a request <b>350</b> for information to a provider's system <b>301</b>. The provider's system <b>301</b> sends a reply <b>355</b> describing the goods or services for sale back to the customer's system. For each possible transaction the reply <b>355</b> contains a link to another location at the provider's system <b>301</b> containing data identifying the possible transaction, e.g. a link associated with an offer to sell stock item number <b>47</b> might look like this:

[0090] http://www.P301.com/buy?object=47

[0091] When the customer decides to purchase one of the items described in reply <b>355</b>, the customer takes an action that causes the customer's system <b>300</b> to use one of the links in reply <b>355</b> to send a request <b>360</b> to the provider's system <b>301</b>. The request <b>360</b> contains information contained in link as well as a cookie previously stored at the customer's system <b>300</b> by the provider's system <b>301</b>. In this example, the cookie contains an aggregation of the data that the customer must provide in order to allow a charge against the customer's credit card and possibly information that allows purchased goods to be delivered to the customer. The request <b>360</b> constitutes an order for goods or services and the provider's system <b>301</b> is now in possession of all the necessary information to proceed with the processing of this transaction.

[0092] The provider's system <b>301</b> attempts to charge the price of the goods or services ordered to the customer's credit card using whatever means it has at its disposal and communicates the success or failure of the transaction by sending a reply <b>365</b> to the customer's system <b>300</b>.

SECOND EXAMPLE

[0093] Three Parties—Customer, Vendor, Credit Agent

[0094]FIG. 4 shows the sequence of events using an embodiment of this invention when a customer places an order for goods or services with a first provider over the Internet and where the charge against the customer's credit card is handled by a second provider.

[0095] The customer's system or user-agent <b>400</b> sends a request <b>450</b> for information to a first provider's system <b>401</b>. The first provider's system <b>401</b> sends a reply <b>455</b> describing the goods or services for sale. For each possible transaction the reply <b>455</b> contains a link to a location at a second provider's system <b>402</b>. In this case the second provider is an agent for processing credit card transactions. Each of these links in reply <b>455</b> contains data identifying the possible transaction and identifying the first provider offering the transaction, e.g. a link associated with an offer to sell stock item number 9217 might look like this:

[0096] http://www.P402.com/buy?www.P401.com&amp;object=9217

[0097] When the customer decides to purchase one of the goods or services described in reply <b>455</b>, the customer takes an action that causes the customer's system <b>400</b> to use one of the links in reply <b>455</b> to send a request <b>460</b> to the second provider's system <b>402</b>. The request <b>460</b> contains all the information contained in the selected link as well as a cookie previously stored at the customer's system <b>400</b> by the second provider's system <b>402</b>. In this example the cookie contains an aggregation of the data that the customer must provide in order to allow a charge against the customer's credit card. The second provider's system <b>402</b> allocates an identifier for the transaction and constructs a new link to the first provider's system <b>401</b> which includes information from the selected link and this transaction identifier, e.g.

[0098] http://buy.P401.com/buy?object=9217&amp;id402=a923f928-0bb39de1

[0099] The second provider's system <b>402</b> then sends a reply <b>465</b> to the customer's system <b>400</b> comprising a document containing the newly constructed link and remembers for a period of time an association of data comprising the customer's credit card details, the transaction identifier and any other information available that might be useful for the proposed transaction.

[0100] The reply <b>465</b> may either:

[0101] (a) cause the customer's system <b>400</b> to automatically send a request <b>470</b> to the first provider's system <b>401</b> (reply <b>465</b> is a redirect), or

[0102] (b) cause the customer's system <b>400</b> to arrange for the document contained in the reply <b>465</b> to be displayed to the customer. In order to proceed with the transaction the customer must then take a further action that causes the customer's system <b>400</b> to use the provided link to send a request <b>470</b> to the first provider's system <b>401</b>.

[0103] In either case if the transaction proceeds then the first provider's system <b>401</b> receives from the customer's system <b>400</b> a request <b>470</b> which contains the transaction identifier allocated by the second provider's system <b>402</b> and other information from the selected link. Request <b>470</b> constitutes an order for the goods or services.

[0104] Before the first provider's system <b>401</b> can reply to the customer's system <b>400</b> and confirm or reject the transaction it must interact with the second provider's system <b>402</b> to attempt to effect a charge against the customer's credit card.

[0105] The first provider's system <b>401</b> establishes a communication link <b>471</b> with the second provider's system <b>402</b> using whatever means are available and provides the second provider's system <b>402</b> with the transaction identifier, the amount to be charged to the customer's credit card and any other information necessary to continue the transaction (e.g. a merchant account number and perhaps bank details for the payment of funds).

[0106] The second provider's system <b>402</b> attempts to correlate the transaction identifier with any transaction identifiers that it recently allocated and remembered. If this is successful then the second provider's system <b>402</b> now has all the necessary information and attempts to process the credit card transaction. The second provider's system <b>402</b> communicates the result of this attempt back to first provider's system <b>401</b> along with any other relevant information that the customer has authorised the second provider to disclose (possibly the customer's delivery address if physical delivery of goods is required).

[0107] The first provider's system <b>401</b> then sends a reply <b>475</b> to the customer's system <b>400</b> comprising a document reporting the status of the transaction and possibly containing another link to the second provider's system which includes the transaction identifier. The customer's system <b>400</b> may use this link to send a further request (not shown in FIG. 4) to the second provider's system <b>402</b> to get further information about the success or failure of the transaction which was not disclosed to or passed on by the first provider's system <b>401</b>.

[0108] This example embodiment shows how the invention can be used to carry out e-commerce transactions while preserving as much as possible the privacy of the customer. Parties to the transaction receive only the information that they need to complete their part of the transaction. Information from the transactions need not be saved by the providers for later transactions as this invention furnishes the customer with the ability to efficiently provide the information whenever necessary in the form of a cookie.

[0109] Instead of charging a sum to the customer's credit card, the arrangement described in this example could be used to establish some other credential of the customer—perhaps that the customer is of sufficient age to legally purchase alcoholic beverages. Again there is no need for the vendor to know the identity of the customer, only that their credentials have been validated.

THIRD EXAMPLE

[0110] Four Parties—Customer, Vendor, Credit Agency, Delivery Company

[0111]FIG. 5A shows the sequence of events using an embodiment of this invention when a customer orders goods over the Internet and several providers co-operate to transact the sale and delivery of those goods to the customer. The first provider is a vendor of various goods, the second provider is a credit card clearing agent, and the third provider is a company who will be responsible for the delivery of the item from the first provider to the customer.

[0112] As in the second example, a customer's system or user-agent <b>500</b> first sends a request <b>550</b> to a first provider's system <b>501</b>. FIG. 5B-<b>550</b> shows the request-line and headers from such a request made using the HTTP protocol to a provider with network name demoshop/dev.skea.com.

[0113] The first provider's system <b>501</b> sends a reply <b>555</b> with a page describing items for sale. For each possible transaction the reply <b>555</b> contains a link to a second provider's system <b>502</b>. Each link contains references to a third provider's system <b>503</b> and data identifying the possible transaction and the provider offering the transaction, e.g. a link associated with stock item number 819 might look like this:

[0114] http://www.P502.com/buy?www.P503.com&amp;www.P501.com&amp;object=819

[0115]FIG. 5B-<b>555</b> shows the status-line and headers from such a reply made using the HTTP protocol. The links to a second provider's system as discussed above would be conveyed in the body of the message and are not shown.

[0116] When the customer decides to purchase goods described in reply <b>555</b>, the customer takes an action that causes the customer's system <b>500</b> to use one of the links in reply <b>555</b> to send a request <b>560</b> to the second provider's system <b>502</b>. The request <b>560</b> contains all the information contained in the selected link as well as a cookie previously stored at the customer's system <b>500</b> by the second provider's system <b>502</b>. In this example, the cookie contains an aggregation of the data that the customer must provide in order to allow a charge against the customer's credit card. FIG. 5B-<b>560</b> shows the request-line and headers from such a request made using the HTTP protocol to a second provider with network name CredGuard-dev.skea.com. Line 1 (the request-line) contains the details of the selected link and the Cookie: header at line 7 contains several cookies previously stored at the customer's system by CredGuard-dev.skea.com.

[0117] The second provider's system <b>502</b> allocates an identifier for the transaction and constructs a link to the third provider's system <b>503</b> using information from first selected link and associates the transaction identifier with the first selected link, e.g.

[0118] http://www.P503.com/buy?www.P501.com&amp;object=819&amp;id502=AA287

[0119] The second provider's system <b>502</b> then sends a reply <b>565</b> to the customer's system <b>500</b> comprising a document containing the newly constructed link and remembers for a period of time an association of data comprising the customer's credit card details, the transaction identifier and any other information available that might be useful for the proposed transaction. FIG. 5B-<b>565</b> shows the status-line and headers from such a reply made using the HTTP protocol and containing at line 4 the new link to the third provider's system with the information from the selected link and the newly allocated transaction identifier.

[0120] The reply <b>565</b> may either:

[0121] (a) cause the customer's system <b>500</b> to automatically send a request <b>570</b> to the third provider's system <b>503</b> (reply <b>565</b> is a redirect), or

[0122] (b) cause the customer's system <b>500</b> to arrange for the document contained in the reply <b>565</b> to be displayed to the customer. In order to proceed with the transaction the customer must then take a further action that causes the customer's system <b>500</b> to use the provided link to send a request <b>570</b> to the third provider's system <b>503</b>.

[0123] In either case if the transaction proceeds then the third provider's system <b>503</b> receives from the customer's system <b>500</b> a request <b>570</b> which contains information from the link provided in reply <b>565</b> and possibly a cookie previously stored at the customer's system <b>500</b> by the third provider's system <b>503</b>. In this example the cookie contains the address for delivery of goods to the customer. FIG. 5B-<b>570</b> shows the request-line and headers from such a request made using the HTTP protocol to third provider with a network name PostMan-dev.skea.com. Line 1 (the request-line) contains the details of the provided link and the Cookie: header at line 7 contains two cookies previously stored at the customer's system by PostMan-dev.skea.com.

[0124] The third provider's system <b>503</b> allocates an identifier for the transaction and constructs a link to the first provider's system <b>501</b> using information contained in the request <b>570</b> and this transaction identifier, e.g.

[0125] http://www.P501.com/buy?object=819&amp;id502=AA287&amp;id503=1230af93

[0126] The third provider's system <b>503</b> then sends a reply <b>575</b> to the customer's system <b>500</b> comprising a document containing the newly constructed link and remembers for a period of time an association of data comprising the customer's delivery address, the transaction identifier just allocated and any other information available that might be useful for the proposed transaction. FIG. 5B-<b>575</b> shows the status-line and headers from such a reply made using the HTTP protocol and containing at line 4 the new link to the first provider's system with the information from the earlier request and the newly allocated transaction identifier.

[0127] The reply <b>575</b> may either:

[0128] (a) cause the customer's system <b>500</b> to automatically send a request <b>580</b> to the first provider's system <b>501</b> (reply <b>575</b> is a redirect), or

[0129] (b) cause the customer's system <b>500</b> to arrange for the document contained in the reply <b>575</b> to be displayed to the customer. In order to proceed with the transaction the customer must then take a further action that causes the customer's system <b>500</b> to use the provided link to send a request <b>580</b> to the first provider's system <b>501</b>.

[0130] In either case if the transaction proceeds then the first provider's system <b>501</b> receives from the customer's system <b>500</b> a request <b>580</b> which contains the transaction identifiers allocated by the second provider's system <b>502</b> and the third provider's system <b>503</b>. The request <b>580</b> constitutes an order for the goods. FIG. 5B-<b>580</b> shows the request-line and headers from such a request made using the HTTP protocol to a first provider with a network name DemoShop/dev.Skea.com. It is notable that there are no cookies being passed to the first provider in this request and the transaction identifiers allocated by the other providers are now present in line 1 (the request-line) of the request.

[0131] Before the first provider's system <b>501</b> can reply to the customer's system <b>500</b> and confirm or reject the purchase it must interact with the second provider's system <b>502</b> to attempt to effect a charge against the Customer's credit card and if successful with the third provider's system <b>503</b> to arrange delivery of the goods.

[0132] The first provider's system <b>501</b> establishes a communication link <b>581</b> with the second provider's system <b>502</b> using whatever means are available and provides the second provider's system <b>502</b> with the transaction identifier allocated by that system, the amount to be charged to the Customer's credit card and any other information necessary to continue the transaction (e.g. a merchant account number and perhaps bank details for the payment of funds).

[0133] The second provider's system <b>502</b> attempts to correlate the transaction identifier with any transaction identifiers that it recently allocated and remembered. If this is successful then the second provider's system <b>502</b> now has all the necessary information and attempts to process the credit card transaction. The second provider's system <b>502</b> communicates the result of this attempt back to the first provider's system <b>501</b> along with any other relevant information that the customer has authorised the second provider to disclose.

[0134] If the second provider's system <b>502</b> successfully processed the credit card transaction then the first provider's system <b>501</b> proceeds to establish a communication link <b>582</b> with the third provider's system <b>503</b> using whatever means are available and provides the third provider's system <b>503</b> with the identifier allocated by that system and any other information that the third provider's system <b>503</b> needs for effecting delivery of the purchased item.

[0135] On conclusion of its communications with the third provider's system <b>503</b>, the first provider's system <b>501</b> then sends a reply <b>585</b> to the customer's system <b>500</b> comprising a document reporting the status of the transaction and possibly containing further links to the second provider's system <b>502</b> and the third provider's system <b>503</b> which include the relevant transaction identifiers allocated by those systems. FIG. 5B-<b>585</b> shows the status-line and headers from such a reply made using the HTTP protocol. The links to the other providers' systems as discussed above would be conveyed in the body of the message and are not shown.

[0136] The customer's system <b>500</b> may use the further links in reply <b>585</b> (if present) to send further requests (not shown in FIG. 5A) to the second provider's system <b>502</b> and the third provider's system <b>503</b> containing the identifiers allocated by those systems to obtain further information about the payment or delivery aspects of the transaction that were not disclosed to or passed on by the first provider's system <b>501</b>.

FOURTH EXAMPLE

[0137] Four Parties—Customer, Vendor, Credit Agency, Delivery Company

[0138]FIG. 6A shows the sequence of events using an embodiment of this invention when a customer orders goods over the Internet and several providers co-operate to transact the sale and delivery of those goods to the customer. The first provider is a vendor of various goods, the second provider acts as a credit card clearing agent and an information management agent, and the third provider is a company who will be responsible for the delivery of the item from the first provider to the customer.

[0139] As in the second example, a customer's system or user-agent <b>600</b> first sends a request <b>650</b> to a first provider's system <b>601</b>. FIG. 6B-<b>650</b> shows the request-line and headers form such a request made using the HTTP protocol to a provider with the network name demoshop/dev.skea.com.

[0140] The first provider's system <b>601</b> sends a reply <b>655</b> with a page describing items for sale. For each possible transaction the reply <b>655</b> contains a link to a second provider's system <b>602</b>. In this example the second provider fulfils the roles of credit card clearing agent and information management agent as explained below. Each link contains:

[0141] (a) a reference to a third provider's system <b>603</b> and an indication of the information that is to be passed on to the third provider;

[0142] (b) data identifying the possible transaction; and

[0143] (c) data identifying the provider offering the transaction

[0144] e.g. a link associated with stock item number 819 might look like this:

[0145] http://www.P602.com/buy?deliver=www.P603.com&amp;www.P601.com&amp;object=819

[0146]FIG. 6B-<b>655</b> shows the status-line and headers from such a reply made using the HTTP protocol. The links to a second provider's system as discussed above would be conveyed in the body of the message and are not shown.

[0147] When the customer decides to purchase an item described in reply <b>655</b>, the customer takes an action that causes the customer's system <b>600</b> to use one of the links in reply <b>655</b> to send a request <b>660</b> to the second provider's system <b>602</b>. The request <b>660</b> contains all the information contained in the selected link as well as any cookies previously stored at the customer's system <b>600</b> by the second provider's system <b>602</b>. In this example there are two such cookies. The first cookie contains an aggregation of the data that the customer must provide in order to allow a charge against the customer's credit card. The second cookie contains an aggregation of the data that is necessary for the third provider to effect delivery of an item to the customer. FIG. 6B-<b>660</b> shows the request-line and headers from such a request made using the HTTP protocol to a second provider with the network name CredGuard-dev.skea.com. Line 1 (the request-line) contains the details of the selected link and the Cookie: header at line 7 contains several cookies previously stored at the customer's system by CredGuard-dev.skea.com. In this example details required by the third provider have been stored at the customer's system by the second provider and are being returned to the second provider in the cookies accompanying this request. These details will be made available to the third provider by the second provider later in the course of the transaction if appropriate.

[0148] The second provider's system <b>602</b> allocates an identifier for the transaction and constructs a new link to the first provider's system <b>601</b> using information from the first selected link and this transaction identifier, e.g.

[0149] http://www.P601.com/buy?object=819&amp;id602=09211-229

[0150] The second provider's system <b>602</b> then sends a reply <b>665</b> to the customer's system <b>600</b> comprising a document containing the newly constructed link and remembers for a period of time an association of data comprising the two cookies received in the request <b>660</b>, the transaction identifier and any other information available that might be useful for the proposed transaction. FIG. 6B-<b>665</b> shows the status-line and headers from such a reply made using the HTTP protocol and containing at line 4 the new link to the first provider's system with the information from the selected link and the newly allocated transaction identifier.

[0151] The reply <b>665</b> may either:

[0152] (a) cause the customer's system <b>600</b> to automatically send a request <b>670</b> to the first provider's system <b>601</b> (reply <b>665</b> is a redirect), or

[0153] (b) cause the customer's system <b>600</b> to arrange for the document contained in the reply <b>665</b> to be displayed to the customer. In order to proceed with the transaction the customer must then take a further action that causes the customer's system <b>600</b> to use the provided link to send a request <b>670</b> to the first provider's system <b>601</b>.

[0154] In either case if the transaction proceeds the first provider's system <b>601</b> receives from the customer's system <b>600</b> a request <b>670</b> which contains all the information from the link provided in reply <b>665</b>. The request <b>670</b> constitutes an order for the goods. FIG. 6B-<b>670</b> shows the request-line and headers from such a request made using the HTTP protocol to a first provider with the network name DemoShop-dev.Skea.com. The newly allocated transaction identifier is contained in line 1 (the request-line) of the request.

[0155] Before the first provider's system <b>601</b> can reply to the customer's system <b>600</b> and confirm or reject the purchase it must interact with the second provider's system <b>602</b> to attempt to effect a charge against the customer's credit card and to arrange delivery of the goods.

[0156] The first provider's system <b>601</b> establishes a communication link <b>671</b> with the second provider's system <b>602</b> using whatever means are available and provides the second provider's system <b>602</b> with the transaction identifier allocated by that system, the amount to be charged to the customer's credit card, the information necessary for a delivery agent to collect the goods from the first provider and any other information necessary to continue the transaction (e.g. a merchant account number and perhaps bank details for the payment of funds).

[0157] The second provider's system <b>602</b> attempts to correlate the transaction identifier with any transaction identifiers that it recently allocated and remembered. If this is successful then the second provider's system <b>602</b> now has all the necessary information and attempts to process the credit card transaction. If the attempt is successful then the second provider's system <b>602</b> establishes a communications link <b>672</b> with the third provider's system <b>603</b> using whatever means are available and provides the third provider's system <b>603</b> with an association of data comprising the transaction identifier, the information necessary for a delivery agent to collect the goods from the first provider, the customer's delivery information which was contained in the second cookie of request <b>660</b> and any other details necessary for the third provider to effect collection and delivery from the first provider to the customer.

[0158] The second provider's system <b>602</b> communicates the result of the payment attempt back and the delivery arrangements to the first provider's system <b>601</b> along with any other relevant information that the customer has authorised the second provider to disclose.

[0159] On conclusion of its communications with the second provider's system <b>602</b>, the first provider's system <b>601</b> then sends a reply <b>675</b> to the customer's system <b>600</b> containing the status of the transaction and possibly containing a further links to the second provider's system <b>602</b> and the third provider's system <b>603</b> both of which contain the transaction identifier allocated by the second provider's system <b>602</b>. FIG. 6B-<b>675</b> shows the status-line and headers from such a reply made using the HTTP protocol. The links to the other providers' systems as discussed above would be conveyed in the body of the message and are not shown.

[0160] The customer's system <b>600</b> may use the further links in reply <b>675</b> (if present) to send requests to the second provider's system <b>602</b> and the third provider's system <b>603</b> containing the transaction identifier to obtain further information about the payment or delivery aspects of the transaction that were not disclosed to or passed on by the first provider's system <b>601</b>.

[0161] This example embodiment of the invention is preferred in circumstances where the customer is using a relatively slower means of accessing the network than the providers or where communications between the various parties are not wholly reliable. By managing the information that each provider might need and passing it along to the other providers as necessary the second provider's system <b>602</b> can take remedial action in the event that any one of the providers cannot be contacted or is unable to fulfil their part of the transaction. If the customer's system <b>600</b> were managing these interactions then it would likely have no alternative but to fail the entire transaction. By establishing second provider as an information manager, more transactions can be successfully completed. In addition, since the Providers are all likely to be connected to high-reliability, high speed networks, these interactions should take less time than if the customer's system <b>600</b> were in control of all the interactions.

[0162] One skilled in the art would appreciate that the process described in this example can be extended to any number of providers who perform any of a variety of services. For each additional provider the customer's system sends additional cookie data to the second provider's system as part of the request <b>660</b>. The second provider then passes the appropriate information from to the appropriate provider and negotiates the performance of the service on behalf of the customer and other providers. In this way the second provider fulfils the role of an information management agent. The second provider's system has the facility for constructing cookies, extracting information from cookies and sending requests to the customer's system <b>600</b> to store new cookies or update old ones. The second provider's system can become the location for any customer to visit to enter and update the information stored in the cookies on the customer's system <b>600</b>. This becomes more important if the cookies are encrypted to prevent network eavesdroppers from seeing the information they contain and where the customer does not necessarily hold the encryption key.

[0163] Flow Diagrams and Screenshots

[0164] The flow diagrams in FIGS. <b>7</b>-<b>11</b> relate to an embodiment of this invention which involves a customer and two providers in an arrangement such as that shown in FIG. 4. A first provider proposes a transaction but requires the involvement of a second provider to effect some part of the transaction. FIGS. 7, 8 and <b>9</b> show steps performed by the first provider's system. FIGS. 10 and 11 show steps performed by the second provider's system. The discussion below will follow as much as possible the order of the events rather than the order of the diagrams so the flow diagrams will be discussed in the order FIG. 7, FIG. 10, FIG. 8, FIG. 11 and then FIG. 9. The systems illustrated by these flow diagrams differ from the systems illustrated in FIG. 4 in that a number of additional pairs of replies and requests from the second provider's system <b>402</b> to the customer's system <b>400</b> (a reply) and from the customer's system <b>400</b> to the second provider's system <b>402</b> (a request) may occur between request <b>450</b> and reply <b>465</b>. These replies and requests are used when the customer has never before used the method of this invention for a particular piece of information which is needed for the transaction. They are used in order to provide the customer's system with the appropriate forms for entering the information and returning it to the second provider's system. The second provider's system then arranges for it's next reply to the customer's system to contain a cookie containing this information which will be stored at the customer's system for automatic disclosure to the second provider during future requests. The additional replies and requests are also used to obtain confirmation of the transaction from the customer if that is required. In the systems illustrated in FIGS. <b>7</b>-<b>11</b> this confirmation is always returned to the second provider's rather than allowing the transaction to immediately continue at the first provider's system as suggested by the discussion relating to FIG. 4. The subsequent and final reply from the second provider's system to the customer's system always instructs the customer's system to automatically continue with it's request at the first provider's system (it is a redirect message). These differences notwithstanding, references will be made to FIG. 4 where corresponding processes are described.

[0165] FIGS. <b>12</b>-<b>16</b> show screenshots of pages created by a second provider's system for display by a customer's system in an embodiment of this invention at a second provider similar to that illustrated by the flow diagram in FIG. 10. These will be referred to as appropriate in the description of FIG. 10.

[0166]FIG. 17 is an additional screenshot of a page created by an embodiment of this invention at a second provider's system that allows the customer to specify transaction preferences which will further streamline future transactions.

[0167] A First Provider's System Proposes One or More Transactions

[0168]FIG. 7 is a flow diagram of the steps taken by an embodiment of this invention at a first provider's system to propose one or more transactions to a customer. The customer's system initiates the interaction by sending a request for a web page to the first provider's system. In step <b>701</b> the first provider's system receives this request (this corresponds to request <b>450</b> in FIG. 4). In step <b>702</b> the first provider's system constructs a web page containing offers of transactions, each offer accompanied by a link to a second provider's system constructed so that it contains data identifying the transaction to the first provider, data identifying a page at the first provider's system at which the transaction might be continued and other information related to the transaction which might be required by the second provider to effect its part of the transaction. In the second example above which is illustrated by FIG. 4 these links might have the form:

[0169] http://www.P402.com/buy?cred=pc&amp;disc=da&amp;link=www.P401.com/buy?object=9217

[0170] In this example the page at the first provider's system at which the transaction is to be continued after the second provider has effected its part of the transaction is http://www.P401.com/buy. The data identifying the transaction to the first provider is ?object=9217 and the other information required by the second provider to effect its part of the transaction is ?cred=pc&amp;disc=da.

[0171] In step <b>703</b>, the first provider's system sends the page just constructed to the customer's system (this corresponds to reply <b>455</b> in FIG. 4).

[0172] The Customer's System Sends a Transaction Request to a Second Provider's System.

[0173]FIG. 10 is a flow diagram of the steps taken by an embodiment of this invention at a second provider's system to collect transaction data from a customer's system. When a customer selects a link such as that generated by the first provider's system described above, a transaction request is sent to the second provider's system. In step <b>1005</b> the second provider's system receives this request (this corresponds to request <b>460</b> in FIG. 4). Some information in the request may have been provided by the customer by filling in a form sent in an earlier stage of the transaction process (i.e. by step <b>1050</b> in an earlier cycle through this flow diagram). Step <b>1010</b> tests for the presence of data entered at the customer's system via a form and if there is none control moves on to step <b>1020</b>. If form data was found at step <b>1010</b> then step <b>1015</b> encodes the data into a cookie and queues the cookie for sending as part of the next message to the customer's system. The customer's system can store this cookie and provide it to the second provider's system automatically in future requests (FIG. 13 shows a customer's system displaying a cookie so received and requesting customer approval for storing the cookie; FIG. 14 shows a customer's system displaying a confirmation message to which the cookie was attached).

[0174] In order for the second provider to effect its part of the transaction it must have all the necessary information. Some of this information may have been provided automatically by the customer's system in the form of cookies accompanying the request. Step <b>1020</b> checks that all the necessary information is available at the second provider's system. If some information has not been provided then step <b>1050</b> sends a reply to the customer's system which prompts the customer to enter some or all of the missing data (FIGS. 12 and 15 show examples of forms displayed by the customer's system for entry and management of such data). The routine represented by the flow diagram in FIG. 10 is then complete though the customer may choose to continue with the transaction by entering the missing data into the form provided in the message and using a link also provided in the message to send a new transaction request to the second provider's system in which case the routine begins afresh with step <b>1005</b>.

[0175] If the tests at step <b>1020</b> determine that all the necessary data is present then control moves to step <b>1025</b> to see if the customer has asked for a confirmation step before committing to the transaction. This request for a confirmation step may be encoded as a preference in a cookie or it may accompany the transaction request in another form. If a confirmation step is required then control moves to step <b>1030</b>, otherwise it is assumed that the customer approves the transaction and control moves to step <b>1055</b>.

[0176] Step <b>1030</b> determines if a customer confirmation or rejection has accompanied the current transaction request. If not then control moves to step <b>1035</b> which sends a message to the customer's system detailing the proposed transaction and requesting a confirmation or rejection from the customer (FIG. 16 shows an example of a customer's system displaying such a request for confirmation). The routine represented by the flow diagram in FIG. 10 is then complete though the customer may choose to continue with the transaction by using either the confirmation or rejection link provided in the message to send a new transaction request to the second provider's system in which case the routine begins afresh with step <b>1005</b>.

[0177] If step <b>1030</b> finds a customer confirmation or rejection accompanying the transaction request then control moves to step <b>1040</b> where confirmation and rejection are distinguished. If a rejection accompanied the transaction request then step <b>1045</b> constructs a transaction failure message containing a re-direction to the continuation page at the first provider's system and this message is sent to the customer's system (this corresponds to Reply <b>465</b> in FIG. 4). The routine represented by the flow diagram in FIG. 10 is then complete. If the customer's system performs the redirect to the first provider's system then the transaction continues there as shown in FIG. 8.

[0178] If step <b>1040</b> determines that a confirmation message accompanied the transaction request then control moves to step <b>1055</b>. Step <b>1055</b> allocates an identifier for the proposed transaction and stores for a short period an association of data comprising this identifier and any other information necessary to effect the transaction. This association of data will contain only the information that is currently available to the second provider's system which may not be all the information necessary to effect the transaction. Any other information required to effect the transaction is expected to be supplied by the first provider within the period for which the second provider's system stores the association of data (perhaps a few seconds). This interaction is illustrated in FIGS. 8 and 11.

[0179] Finally, step <b>1060</b> sends a reply to the customer's system comprising the transaction identifier allocated in step <b>1055</b> and a re-direction to the continuation page at the first provider's system (this corresponds to Reply <b>465</b> in FIG. 4). The routine represented by the flow diagram in FIG. 10 is then complete. If the customer's system performs the redirect to the first provider's system then processing continues there as shown in FIG. 8.

[0180] The First Provider's System Continues the Transaction

[0181]FIG. 8 is a flow diagram of the steps taken by an embodiment of this invention at a first provider's system to continue a transaction after customer data has been provided to a second provider's system by a customer's system. In step <b>805</b> a request to continue or discontinue a transaction is received from the customer's system (this corresponds to Request <b>470</b> in FIG. 4). Step <b>810</b> distinguishes the customer's acceptance from their rejection of the transaction. If the transaction was accepted then control moves to step <b>820</b>. Otherwise (the customer rejected the transaction) step <b>815</b> sends a message to the customer's system confirming that the transaction was rejected (this corresponds to Reply <b>475</b> in FIG. 4) and the routine represented by the flow diagram in FIG. 8 is complete.

[0182] If the transaction was accepted (either explicitly by the customer or automatically) then the transaction request received in step <b>805</b> contains a transaction identifier allocated by the second provider's system. Step <b>820</b> extracts this transaction identifier from the transaction request and step <b>825</b> creates an association of data containing this transaction identifier along with any other information that the second provider requires from the first provider in order to effect its part of the transaction. This association of data is then sent to the second provider using whatever means are available. Different embodiments of the invention might use different means to send this message. An embodiment that uses the internet for communication between the customer and the first provider and between the customer and the second provider might use a private line leased from a phone company for communication between the first provider and the second provider. The routine represented by the flow diagram in FIG. 8 is then complete and transaction processing continues at the second provider's system as shown in FIG. 11.

[0183] The Second Provider's System Processes the Transaction

[0184]FIG. 11 is a flow diagram of the steps taken by an embodiment of this invention at a second provider's system to correlate transaction data from a first provider's system with temporarily stored data from a customer's system and then process the transaction. In step <b>1105</b> a message is received from the first provider's system containing details of the proposed transaction including a transaction identifier earlier allocated by the second provider's system using a routine such as that illustrated by the flow diagram in FIG. 10. Step <b>1110</b> examines the temporary store to see if it contains an aggregation of data containing this transaction identifier. If no such data is found in the store then control moves to step <b>1140</b> which sends an Invalid Transaction message back to the first provider's system. The routine represented by the flow diagram in FIG. 11 is then complete and transaction processing continues at the first provider's system as shown in FIG. 9.

[0185] If data with a corresponding transaction identifier is found at step <b>1110</b> then control moves to step <b>1115</b> where the data is retrieved from the temporary store and aggregated with the data received from the first provider's system in the transaction request. This aggregation of data is now everything that is needed for the second provider's system to effect its part of the overall transaction and step <b>1120</b> attempts to do so. There is no assurance that data supplied by the customer's system or by the first provider's system will be correct or will result in the second provider's system being successful in this attempt. For example, if the second provider is attempting to make a charge to a customer's credit card, this may fail because the bank that issued the credit card may not authorise the transaction. However, until the second provider's system makes the attempt to charge the credit card with all the data that might be necessary this result will not be know.

[0186] Step <b>1125</b> checks the result of the transaction performed in step <b>1120</b>. If the transaction failed then control moves to step <b>1130</b> and a message indicating a transaction failure is sent to the first provider's system. If the transaction succeeded then control moves instead to step <b>1135</b> and a message indicating the success of the transaction is sent to the first provider's system. This message might be accompanied by other data such as a transaction code or other data which the customer has authorised the second provider's system to disclose to the first provider. For example, a delivery address might be needed to enable a first provider to fulfil a purchase and the second provider might mediate the disclosure of this delivery address for transactions that succeed. In both cases (success or failure of the transaction) the routine represented by the flow diagram in FIG. 11 is then complete and transaction processing continues at the first provider's system as shown in FIG. 9.

[0187] The First Provider's System Concludes the Transaction

[0188]FIG. 9 is a flow diagram of the steps taken by an embodiment of this invention at a first provider's system to conclude a transaction after a second provider's system has attempted to effect part of the transaction. Step <b>905</b> receives a message from the second provider's system which contains an indication as to whether the second provider's part of the transaction was successful. Step <b>910</b> examines this indication and if it indicates failure then control moves to step <b>915</b> which sends a failure message to the customer's system (this corresponds to Reply <b>475</b> in FIG. 4).

[0189] If in step <b>910</b> the indication shows that the second provider's part of the transaction succeeded then control moves to step <b>920</b> and the first provider's system performs any additional parts of the transaction that have yet to be performed, such as arranging for the fulfilment of a purchase. Step <b>925</b> then sends a message containing confirmation and details of the successful transaction to the customer's system (this corresponds to Reply <b>475</b> in FIG. 4). This message (and also the failure message of step <b>915</b>) may refer the customer to the second provider for further details of the transaction which were not revealed to the first provider. The routine represented by the flow diagram in FIG. 9 is then complete and with the exception of any actions taken by the customer's system, so is the overall transaction.

[0190] Further Embodiments

[0191] It is anticipated that users of this invention will want to store many of their regularly used credentials using this method and will want access to their stored credentials in a variety of circumstances. While the initial embodiments will work with software that most internet users already have installed, it is anticipated that there will be a demand for additional functionality that can only be provided by an additional piece of software. This additional piece of software would allow the users to better manage the cookies that have been set on their system and may mediate all their interactions with the networks in order to better provide these management services. The additional software could also provide better integration with other software that the user regularly users, such as an email user-agent.

[0192] Another possible extension might be to add a smart-card reader to the customer's system and arrange for the smart-card to mediate access to the network. The cookies encoding the user's credentials could then all be stored in the smart-card and could then be carried from place to place and used through a variety of different network access terminals.

[0193] Cell-phones present another opportunity to store cookies for use on the move. Cell-phones that are equipped with WAP are ideal devices for the portable storage of credentials in cookies. With the recent addition of wireless networking to some of these devices they have the potential to be used to mediate transactions involving other equipment—vending machines, for example.

[0194] Conclusions, Ramifications and Scope of the Invention

[0195] A method and system have been described whereby a customer can enter into a transaction with one or more providers with a means of efficiently disclosing to each provider only the information necessary for that provider to effect their part of the transaction. The method allows the customer to retain custody of all their personal information and disclose it only as and when they choose. Additional advantages of the invention are that:

[0196] it allows a customer to store information required by particular providers once and use the stored information many times without re-entering;

[0197] it provides customers with a central location for the maintenance of their stored information;

[0198] it allows providers to discard customer information as soon as their need for it expires and thus avoid customer concerns over data security and simplify compliance with various data protection legislation;

[0199] it provides a streamlined method for carrying out online transactions which lowers the barriers to online purchasing and facilitates impulse buying.

[0200] Although the description of the invention above is in terms of various embodiments this should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of the invention. For example, a provider's system might instead be a collection of systems that together provide functionality equivalent to the system in the descriptions above; the cookies might be encrypted before being returned to protect them from network eavesdroppers; a customer's system might be enhanced to provide cookie-management functions some of which are the here described as part of a provider's system, etc.

[0201] Accordingly, the scope of the invention should be determined by the appended claims and their legal equivalents, rather than by the descriptions of the example embodiments.