Electronic transfer system and method5870473
Abstract
A system and method relating to secure communications in a communication network is disclosed. The invention uses sessions having limited duration to enable parties to communicate securely in the communication network. The session of one party is independent from the session of another party. The sessions are linked at a server which confirms that the sessions are valid. In a preferred embodiment, the secure communications occur in an electronic transfer system. In the electronic transfer system, a customer and a merchant can conduct a transaction wherein the customer can purchase a product from the merchant and pay for the product using electronic funds.
Claims
We claim:
1. A method for securely communicating in a communication system, wherein the communication system comprises a first device at a first party's location, a second device at a second party's location, and a server in communication therewith, wherein the method comprises:
(a) creating a first session associated with the first party, wherein said first session has first use parameters for limiting the duration that said first session can be used and a first set of data, wherein said first use parameters and said first set of data are identifiable by the server;
(b) creating a second session associated with the second party, wherein said second session has second use parameters for limiting the duration that said second session can be used and a second set of data, wherein said second use parameters and said second set of data are identifiable by the server; and
(c) linking a portion of said first session with a portion of said second session in the communication system, wherein said portion of said first session includes said first set of data and said first use parameters and said portion of said second session includes said second set of data and said second use parameters;
(d) verifying the first and second parties based upon at least portions of said first and second sets of data by the server; and
(e) determining whether said first and second sessions can be used based upon said first and second use parameters by the server
so that when the server verifies the first and second parties and determines that said first and second sessions can be used, the first and second parties are assured of communicating securely in the communication system.
2. The method of claim 1 wherein certain of said first set of data is not transmitted between the first device and the server after said first session is created and certain of said second set of data is not transmitted between the second device and the server after said second session is created.
3. The method of claim 2 wherein said first and second sets of data include first and second keys, respectively, and wherein the server verifies the first and second parties using said first and second keys.
4. The method of claim 1 wherein said first use parameters are determined by the first party and said second use parameters are determined by the second party.
5. The method of claim 1 wherein said first and second use parameters are determined by the server.
6. The method of claim 1 wherein said amount of electronic funds have (a) an amount of electronic funds available to the first party for the duration of said first session, (b) a length of time that said first session will last and (c) a number of transactions that the first party may perform during said first session.
7. The method of claim 1 wherein said second use parameters comprise (a) a length of time that said second session will last and (b) a number of transactions that the second party may perform during said second session.
8. A method for securely communicating in a communication system, wherein the communication system has a device at a user's location and a server in communication therewith, wherein the method comprises:
a. transmitting a request from the device to the server for creating a session having use parameters associated therewith;
b. encrypting a first key with a second key by the server;
c. transmitting said encrypted first key and said use parameters associated with said session from the server to the device;
d. receiving said encrypted first key and said use parameters by the device and decrypting said encrypted first key so that the device can communicate securely in the communication system by using said decrypted first key according to said use parameters.
9. The method of claim 8, wherein said first key is a DES key.
10. The method of claim 9, wherein said second key is a DES key.
11. The method of claim 8, wherein said secure communication is at a security level greater than DES.
12. The method of claim 8, further comprising a second device at a second user's location wherein said second device is also in communication with the user's device and the server and wherein the method further comprises:
a. transmitting a second request from the second device to the server for creating a second session having second use parameters associated therewith;
b. encrypting a third key with a fourth key by the server;
c. transmitting said encrypted third key and said second use parameters from the server to the second device;
d. receiving said encrypted third key and said second use parameters by the second device and decrypting said third key so that the second device can communicate securely in the communication system by using said decrypted third key according to said second use parameters.
13. The method of claim 12, wherein said third key is a DES key.
14. The method of claim 12, wherein said fourth key is a DES key.
15. The method of claim 12, wherein said secure communication is at a security level greater than DES.
16. The method of claim 12, further comprising:
a. transmitting a first set of data from the user's device to the second device, wherein said first set of data includes an encrypted portion and an unencrypted portion, wherein said encrypted portion is encrypted using said decrypted first key and at least a portion of said unencrypted portion of said first set of data;
b. receiving said first set of data by the second device and transmitting a second set of data together with said encrypted portion of said first set of data from the second device to the server, wherein said second set of data includes an encrypted portion and an unencrypted portion, wherein said encrypted portion of said second set of data includes at least a portion of said unencrypted portion of said first set of data, and wherein said encrypted portion of said second set of data is encrypted using said decrypted third key and at least a portion of said unencrypted portion of said second set of data; and
c. receiving said second set of data transmitted from said second device by the server and decrypting said encrypted portion of said second set of data using said third key and said portion of said unencrypted portion of said second set of data so that said portion of said first set of data included in said encrypted portion of said second set of data is decrypted, and decrypting said encrypted portion of said first set of data using said first key and said portion of said decrypted portion of said first set of data,
so that the user is verified by the server using said first key and the second user is verified by the server using said third key.
17. An electronic transfer system in a communication network for processing a transaction between a customer having a customer device, a merchant having a merchant device, and a server connected therewith, wherein the transaction has terms associated therewith and wherein the server transfers electronic funds from the customer to the merchant so that the merchant can provide a product to the customer, wherein the electronic transfer system comprises:
a. the merchant device for
(1) obtaining a first session from the server,
(2) transmitting an invoice including at least a portion of the terms of the transaction to the customer device,
(3) receiving a customer response to said invoice from the customer device and transmitting a first set of data representing the transaction to the server, wherein said first set of data includes at least a portion of said customer response,
(4) receiving a second set of data from the server indicating whether the transaction has been approved by the server, wherein said second set of data includes a merchant part and a customer part, wherein said merchant part and said customer part of said second set of data include at least a portion of said first set of data; and
(5) transmitting said customer part of said second set of data to the customer device;
b. the customer device for
(1) obtaining a second session from the server,
(2) receiving said invoice including said portion of the terms of the transaction from said merchant device and transmitting said portion of said customer response to the merchant device, and
(3) receiving said customer part of said second set of data from the merchant device;
c. the server having a merchant persona and customer persona stored therein, wherein said merchant persona represents the merchant and said customer persona represents the customer, wherein said merchant persona has a merchant electronic funds storage structure associated therewith for storing electronic funds received by the merchant and said customer persona has a customer electronic funds storage structure associated therewith for storing electronic funds of the customer, wherein the server is for
(1) providing said first session to said merchant device and said second session to said customer device,
(2) receiving said first set of data representing the transaction from the merchant device and processing said first set of data to determine whether the transaction has been approved,
(3) transferring electronic funds from said customer electronic funds storage structure to said merchant electronic funds storage structure if the transaction has been approved, and
(4) transmitting said second set of data to the merchant device indicating whether the transaction has been approved
so that if the transaction has been approved, the merchant can provide the product to the customer.
18. The electronic transfer system of claim 17, wherein the merchant device further comprises communicating with the server to bind a first financial instrument to said merchant persona; and
wherein the customer device further comprises communicating with the server to bind a second financial instrument to said customer persona.
19. The electronic transfer system of claim 18, wherein the customer device further comprises transmitting a request to the server to transfer funds from said second financial instrument to said customer electronic funds storage structure; and
wherein the server further comprises receiving and processing said request to transfer funds and for transferring funds from said second financial instrument to said customer electronic funds storage structure.
20. The electronic transfer system of claim 19, wherein the customer device includes a customer session container for storing electronic funds of the customer during said second session, and further comprises transmitting a second request to the server for transferring electronic funds from said customer electronic funds storage structure to said customer session container; and
wherein the server further comprises processing said second request and transferring the electronic funds from said customer electronic funds storage structure to said customer session container.
21. The electronic transfer system of claim 20, wherein the use of said first session is limited by first use parameters comprising (a) a length of time that said first session may last and (b) a number of transactions that the merchant may perform during said first session; and
wherein the use of said second session is limited by second use parameters comprising (a) an amount of electronic cash available to the customer during said second session, (b) a length of time that said second session may last and (c) a number of transactions that the customer may perform during said second session.
22. The electronic transfer system of claim 21, wherein the merchant device further comprises transmitting a third request for transferring electronic funds from said merchant session container to said merchant electronic funds storage structure; and
wherein the customer device further comprises transmitting a fourth request for transferring electronic funds from said customer session container to said customer electronic funds storage structure; and
the server further comprising processing said third request and for transferring electronic funds from said merchant session container to said merchant electronic funds storage structure and for processing said fourth request and for transferring electronic funds from said customer session container to said customer electronic funds storage structure.
23. The electronic transfer system of claim 21, wherein the server further comprises
transferring electronic funds from said merchant session container to said merchant electronic funds storage structure when at least one of said first use parameters is satisfied; and
transferring electronic funds from said customer session container to said customer electronic funds storage structure when at least one of said second use parameters is satisfied.
24. The electronic transfer system of claim 22 wherein the server further comprises terminating said first and second sessions when at least one of said first and second use parameters have been satisfied.
25. The electronic transfer system of claim 23, wherein the merchant device further comprises transmitting a fifth request to the server for transferring electronic cash funds from said merchant electronic funds storage structure to said first financial instrument; and
the server for processing said fifth request and for transferring electronic funds from said merchant electronic funds storage structure to said first financial instrument.
Description
BACKGROUND OF THE INVENTION
1. Field of Invention
Public key encryption with large key sizes (e.g., RSA) is usually required for creating acceptable levels of security for message processing over an insecure network, such as the Internet. The present invention relates to a system and method for increasing the efficiency of secure message processing over such insecure networks. More specifically, the present invention relates to a system and method for reducing the level of encryption required in a network for message exchanges. Even more specifically, the present invention relates to processing electronic cash transactions in a secure manner while substantially reducing the computational requirements for encryption.
2. Description of the Prior Art
Various methods for increasing the security of communications over insecure networks, such as the Internet, have been disclosed. An insecure network does not protect messages from observation, interception, and manipulation. On the other hand, secure networks offer various means to reduce the opportunity for observation, interception, and/or manipulation of messages.
For example, channel message security schemes (such as secure HTTP ("S-HTTP") and Secure Socket Layer (SSL) protocol) are intended to create confidence in two communicating parties that they are who they say they are and that their communications are private. SSL utilizes digitally signed certificates to provide authentication and security by heavily encrypting each message. S-HTTP relies on digitally signed messages using a heavy encryption key to ensure security and authentication.
A number of multi-party protocols have been proposed for credit transactions, most notably Secure Transport Technology (STT), Internet Keyed Payments (IKP), and Secure Electronic Payment Protocol (SEPP). All of these approaches are built around a credential issuing authority and require that both merchants and customers be authenticated by the credential issuing authority which in turn has been authenticated by a higher authority. In STT, merchants and customers each have two sets of RSA of keys, one to be used to sign messages and one used to encrypt and decrypt symmetrical keys. Thus, in this system, each party needs two certificates (one for each key). A merchant will have a pair of credentials for each credit card it accepts. SEPP and IKP use RSA encryption differently; but, like STT, utilize multiple public key signatures and encryptions per transaction.
Another system has been described under the name "NetBill." While the NetBill approach is less reliant on public key encryption than others, it still requires public key signatures throughout a transaction.
Another approach is that of DigiCash. In the DigiCash model, the user creates a random number, which acts like a serial number for a digital coin. Like the other proposed systems, DigiCash achieves its primary objective of a secure, anonymous cash payment system by requiring heavy reliance on modular exponentiation (which is the basis for other public key techniques such as RSA encryption). It also requires a bank or third party to create tokens that have intrinsic value. It is uncertain how such a system will be treated under banking, tax, and currency laws in the United States and other jurisdictions.
Other systems, such as Mondex, implement security through the use of hardware connected to the user's computer. For Internet transactions, a proprietary card reader must be added to the computers of all customers and merchants who will use a particular card.
The reliance on encryption, especially public key encryption, whether based in software or hardware comes at a price: the greater the use of encryption, the greater the processing effort required to decrypt messages. Where message processing costs are important, such as in commercial network payment transaction, processor and hardware costs can become a significant deterrent to using networks such as the Internet for secure communications.
The current art can only achieve acceptable security with the concomitant high cost of processor time, additional hardware, or both. What is needed to encourage the development of insecure networks such as the Internet for commercial use is a software-based system that offers reduced processing costs of encrypted messages while maintaining an acceptable level of security for the communications being transmitted.
SUMMARY OF INVENTION
Therefore, the present invention aims to provide a system and method for very efficient, economic and secure transactions over the Internet, or other insecure networks. This provides the basis for implementing relatively small value, secure payment (including small cash payments) for products over the Internet or other insecure networks.
In accordance therewith, we herein disclose a method for securely communicating in a communication system. The communication system comprises a first device at a first party's location, a second device at a second party's location, and a server in communication therewith. The method comprises creating a first session associated with the first party, wherein the first session has first use parameters for limiting the duration that said first session can be used and a first set of data. The first use parameters and said first set of data are identifiable by the server. The method also comprises creating a second session associated with the second party. The second session has second use parameters for limiting the duration that the second session can be used and a second set of data. The second use parameters and said second set of data are identifiable by the server. The method further comprises linking a portion of the first session with a portion of the second session in the communication system. The portion of the first session includes said first set of data and said first use parameters and the portion of the second session includes the second set of data and the second use parameters. The method still further comprises verifying the first and second parties based upon at least portions of the first and second sets of data by the server, and determining whether the first and second sessions can be used based upon the first and second use parameters by the server. When the server verifies the first and second parties and determines that the first and second sessions can be used, the first and second parties are assured of communicating securely in the communication system.
Another aspect of the present invention is directed to a method for securely communicating in a communication system. The communication system has a device at a user's location and a server in communication therewith, and the method comprises transmitting a request from the device to the server for creating a session having use parameters associated therewith, encrypting a first key with a second key by the server, and transmitting the encrypted first key and the use parameters associated with the session from the server to the device. The method also comprises receiving the encrypted first key and the use parameters by the device and decrypting the encrypted first key so that the device can communicate securely in the communication system by using the decrypted first key according to the use parameters.
BRIEF DESCRIPTION OF DRAWINGS
Representative embodiments of the present invention will be described with reference to the following drawings:
FIG. 1 depicts the general architecture of the present invention.
FIG. 2 depicts the general processes of the present invention.
FIG. 3A more particularly depicts the processes shown in FIG. 2.
FIG. 3B depicts the flow of messages in the present invention.
FIG. 4A depicts the structure of the database of the server computer 100.
FIG. 4B depicts a customer persona 120.1 of server persona data structure 120.
FIG. 4C depicts the fields of cash container data 120G of FIG. 4B.
FIG. 4D depicts the fields of instrument binding data 120H of FIG. 4B.
FIG. 4E depicts a merchant persona 120.2 of server persona data structure 120.
FIG. 4F depicts the fields of cash container data 120GG of FIG. 4E.
FIG. 4G depicts the fields of instrument binding data 120HH of FIG. 4E.
FIG. 4H depicts customer session record 130.1 of server session data structure 130.
FIG. 4I depicts the fields of transaction data 130N of FIG. 4H.
FIG. 4J depicts merchant session record 130.2 of server session data structure 130.
FIG. 4K depicts the fields of transaction data 130NN of FIG. 4J.
FIG. 4L depicts a record 140.1 of message log data structure 140.
FIG. 5A depicts the structure of the database of the customer computer 200.
FIG. 5B depicts record 215.1 of customer application data structure 215.
FIG. 5C depicts record 220.1 of customer persona data structure 220.
FIG. 5D depicts record 230.1 of customer instrument binding data structure 230.
FIG. 5E depicts record 240.1 of customer active session data structure 240.
FIG. 5F depicts customer pending log data structure 250.
FIG. 5G depicts pending registration/update persona information record 251 of customer pending transaction data structure 250.
FIG. 5H depicts pending link/update instrument binding record 252 of customer pending transaction data structure 250.
FIG. 5I depicts pending cash payment record 253 of customer pending transaction data structure 250.
FIG. 5J depicts pending load/unload funds record 254 of customer pending transaction data structure 250.
FIG. 5K depicts pending open session record 255 of customer pending transaction data structure 250.
FIG. 5L depicts pending close session record 256 of customer pending transaction data structure 250.
FIG. 5M depicts customer log data structure 260.
FIG. 5N depicts persona registration/update response record 261 of customer log data structure 260.
FIG. 5O depicts link/update instrument response record 262 of customer log data structure 260.
FIG. 5P depicts cash payment response record 263 of customer log data structure 260.
FIG. 5Q depicts load/unload funds response record 264 of customer log data structure 260.
FIG. 5R depicts open session response record 265 of customer log data structure 260.
FIG. 5S depicts payment request record 266 of customer log data structure 260.
FIG. 5T depicts close session response record 267 of customer log data structure 260.
FIG. 5U depicts a record 280.1 of Customer cash container data structure 280.
FIG. 6A depicts the structure of the database of the merchant computer.
FIG. 6B depicts a record of the merchant application data structure of the database of the merchant computer.
FIG. 6C depicts a record of the merchant persona data structure of the database of the merchant computer.
FIG. 6D depicts a record of the merchant instrument binding data structure of the database of the merchant computer.
FIG. 6E depicts a record of the merchant session data structure of the database of the merchant computer.
FIG. 6F depicts a record of the merchant cash container data structure of the database of the merchant computer.
FIG. 7A depicts a record of the merchant amount data structure of the database of the merchant computer.
FIG. 7B depicts a record of the merchant sales session data structure of the database of the merchant computer.
FIG. 7C depicts a record of the merchant cash log data structure of the database of the merchant computer.
FIG. 7D depicts the format of a sample message.
FIG. 8 is a flow diagram illustrating registration process 401.
FIG. 9 is a flow diagram illustrating message assembly procedure 800.
FIGS. 10A and 10B depict the format of registration message R1.
FIGS. 11A and 11B is a flow diagram illustrating server message unwrap procedure 900.
FIG. 12 is a flow diagram illustrating server message assembly procedure 1000.
FIGS. 13A and 13B depict the format of registration message R2.
FIG. 14 is a flow diagram illustrating client message unwrap procedure 1100.
FIG. 15 is a flow diagram illustrating instrument binding process 403.
FIGS. 16A and 16B depict the format of binding message BI1.
FIGS. 17A and 17B depict the format of binding message BI4.
FIG. 18 is a flow diagram illustrating the load/unload funds process 405.
FIGS. 19A and 19B depict the format of load/unload message LU1.
FIGS. 20A and 20B depict the format of load/unload message LU2.
FIG. 21 is a flow diagram illustrating open session process 407.
FIGS. 22A and 22B depict the format of open session message OS1.
FIGS. 23A and 23B depict the format of open session message OS2.
FIGS. 24A, 24B and 24C depict a flow diagram illustrating transaction/payment process 409.
FIG. 25 depicts the format of payment request message PR1.
FIG. 26 depicts a flow diagram illustrating message unwrap procedure 3300.
FIG. 27 depicts a flow diagram illustrating message assembly procedure CA12.
FIG. 28 depicts FIGS 28A and B depict the format of cash payment message CA1.
FIG. 29 depicts a flow diagram illustrating CA-DES-key generation process 1600.
FIG. 30 depicts a flow diagram illustrating message unwrap procedure CA1.
FIGS. 31A, 31B and 31C depict the format of message CA2.
FIGS. 32A and 32B depict a flow diagram illustrating server message unwrap procedure 1660.
FIG. 33 depicts a flow diagram illustrating server message assembly procedure 3400.
FIGS. 34A, 34B and 34C depict the format of message CA3.
FIG. 35 depicts a flow diagram illustrating message unwrap procedure CA34.
FIG. 36 depicts a flow diagram illustrating message assembly procedure 3100.
FIGS. 37A and 37B depict the format of message CA4.
FIG. 38 depicts a flow diagram illustrating close session process 411.
FIGS. 39A and 39B depict the format of message CS1.
FIGS. 40A and 40B depict the format of message CS2.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Reference is now made to FIGS. 1-40 for the purpose of describing, in detail, the preferred embodiments of the present invention. The Figures and accompanying detailed description are not intended to limit the scope of the present invention.
I. Information And Information Flow
The present invention is generally depicted in FIG. 1. FIG. 1 shows three entities: server computer 100, customer computer 200 and merchant computer 300, connected to each other via the Internet 50. The connections are identified by lines 105, 205 and 305, respectively.
Customer computer 200 represents the computer of an individual, customer user 203, who wants to buy a product over the Internet 50. (A "product" includes goods, services, information, data, and the like.) Customer computer 200 includes customer database 202 and customer application software 210. Merchant computer 300 represents the computer of an individual, merchant user 303, who provides the product to customer user 203 over the Internet 50. Merchant computer 300 includes merchant database 302 and merchant application software 310. Information relating to merchant user 303 is stored within merchant database 302. Merchant application software 310 executes the processes of the present invention.
While the following detailed description is provided for a single customer user 203 and a single merchant user 303, it is noted that the present invention contemplates communication and transactions between both single and multiple customer users 203 and single and multiple merchant users 303.
Server computer 100 communicates securely--as will be described in detail later--with customer computer 200 and merchant computer 300 over the Internet 50 to effect transactions between customer user 203 and merchant user 303. Server computer 100 includes server database 102 and server software 110. Information relating to server computer 100, customer user 203 and merchant user 303 is stored within server database 102. Server software 110 executes the processes of the present invention.
Communication between server computer 100, customer computer 200 and merchant computer 300 is preferably carried out by hypertext transport protocol ("HTTP") over the World Wide Web ("WWW") services provided on the Internet 50. Of course, other protocols and networks may be used or desired.
FIG. 2 depicts the general processes performed by the present invention. The processes start at step 0.
Preliminarily, setup processes are performed at step 1. In the setup processes, customer user 203 and merchant user 303 (collectively "clients") are configured within database 102 of server computer 100. In this manner, clients can be recognized by and communicate with server computer 100. Customer database 202 and merchant database 302 are also configured at step 1.
An open session process is performed at step 2. Generally, a session is an opportunity (or window) in which customer user 203 may purchase a product from merchant user 303 over the Internet 50 or in which merchant user 303 may provide a product to customer user 203 over the Internet 50. Customer user 203 and merchant user 303 have their own independent sessions. Sessions are of limited duration. This duration is governed by parameters. These parameters are preferably set by customer user 203 and merchant user 303. Alternatively, server computer 100 may set such parameters.
A transaction/payment process is performed at step 3. In this step, customer user 203 and merchant user 303 agree upon a product to be provided at an agreed upon price. Customer user 203 pays for the product with electronic cash. Electronic cash is a representation of funds (real cash, credit, etc.) used in the present invention. The electronic cash is received by merchant user 303 who can provide the purchased product to customer user 203. Customer user 203 may conduct business with multiple merchant users 303 during a session. Customer user 203 and merchant user 303 are only able to transact business for the duration of sessions such as those created at step 2.
A close session process may be included in the present invention at step 4. This step ends the session created at step 2.
The processes performed by the present invention end at step 5.
Referring to FIG. 3A, the processes described above in steps 1 through 4 of FIG. 2 are now more particularly described. Initially, the setup processes performed at step 1 include download and installation process 400, registration process 401, instrument binding process 403 and load/unload funds process 405.
During the download and installation process 400, customer user 203 and merchant user 303 each download and install a copy of client application software 153 (FIG. 1) which preferably resides on the Internet 50. Within customer computer 200 and merchant computer 300, the copy of client application software 153 resides as customer application software 210 and merchant application software 310, respectively. (Merchant application software 310 includes other software to enable merchant computer 300 to perform the functions described below.) Using well known techniques, customer application software 210 and merchant application software 310 are linked to the web browser of customer computer 200 and merchant computer 300, respectively, and are accessed through the browser as necessary.
Next, at registration process 401, customer user 203 and merchant user 303 register with server computer 100. That is, "persona" for customer user 203 and merchant users 303 is created within database 102 of server computer 100. A "persona" is herein defined as a collection of data relating to a specific client. Therefore, by this registration process, each customer user 203 and merchant user 303 who has registered with server computer 100 has their own persona in server computer 100. (The details of personas will be described later.) The right of a persona to preform certain operations (e.g., load funds, unload funds, submit certain messages to server computer 100) may be enabled or disabled on a message or service basis.
During the instrument binding process 403 of FIG. 3A, a client (a customer user 203 or a merchant user 303) communicates information to server computer 100 which it uses to establish that the client may use a financial instrument. Financial instruments may include credit cards, debit cards, demand deposit accounts ("DDAs") or other financial instruments. The issuer of the instrument being bound or a third party guarantor sets whatever criteria are deemed necessary by it to determine if the client may use the instrument. For example, a bank issuing a credit card may find sufficient that the client provide a five digit postal code and his mother's maiden name in order to use the credit card. A list of these criteria may, for example, be provided to server computer 100 in which case server computer 100 can communicate with the client to establish whether the client meets these criteria so that the client can use the financial instrument.
Once the client establishes that the client may use the instrument by this process, the instrument is "bound" to or associated with the client's persona created during registration process 401. Once the instrument is bound, the client can use the instrument for transactions as will be described later.
Load/unload funds process 405 is discussed next. For customer user 203, a "load" is the process by which funds associated with a bound instrument are "loaded" (or transferred) to the persona of customer user 203. In the persona of customer user 203, the funds are represented as electronic cash. For customer user 203, an "unload" is the process by which electronic cash is "unloaded" (or transferred) from the persona of customer user 203 to a bound instrument. For merchant user 303, an "unload" is the process by which electronic cash is "unloaded" from the persona of merchant user 303 to a bound instrument. For merchant user 303, a "load" is the process by which funds associated with a bound instrument are "loaded" to the persona of merchant user 303. In the persona of merchant user 303, the funds are represented as electronic cash.
The open session process described for step 2 in FIG. 2 is further explained with regard to the open session process 407 of FIG. 3A. When customer user 203 creates a session, customer user 203 is enabled to transact business over the Internet 50 with one or more merchant users 303 who have each created their own independent sessions. (Of course, merchant users 303 may also act as customer users 203 if they so desire.) The transaction/payment process 409 is performed next. During this process, customer user 203 and merchant user 303 may negotiate and agree upon the elements of a transaction (e.g., a particular product and price). Then, merchant user 303 may request that customer user 203 pay the agreed upon price for the product. In response to the request of merchant user 303, customer user 203 may communicate to merchant user 303 that customer user 203 accepts the agreed upon price for the product. It is preferred that merchant user 303 cause information regarding the transaction to be submitted to server computer 100 for validation. If server computer 100 validates the transaction, electronic cash is transferred from the persona of customer user 203 to the persona of merchant user 303. Once notified of validation, merchant user 303 can provide the product to customer user 203.
At close session process 411, the session created during open session process 407 may be terminated. When customer user 203 (or merchant user 303) closes the session, server computer 100 disables customer user 203 (or merchant user 303) from transacting business over the Internet 50 with another merchant user 303 (or customer user 203) who has an open session unless customer user 203 has other open sessions.
Referring to FIG. 3B which depicts the flow of messages of the present invention, registration process 401 is carried out by customer computer 200 sending message R1 ("Registration 1") to server computer 100. In response to message R1, server computer 100 sends message R2 ("Registration 2") back to customer computer 200. The information included in these registration messages will be described later.
During instrument binding process 403, customer computer 200 sends message BI1 ("Bind Instrument 1") to server computer 100. The information in message BI1 is used by server computer 100 to confirm the authority of the binder of the instrument with the issuer of that instrument or a third party guarantor. The confirmation process could augmented by the exchange of messages (herein, messages BI2 and BI3) between server computer 100 and customer computer 200. Messages BI2 and BI3 would have a format similar to that of the other messages described herein. The content of message BI2 may include requests for additional information (prompted by the issuer of the instrument) or clarification of information as required by the issuer of the instrument or the third party guarantor. For example, message BI2 may cause customer user 203 to be prompted for customer user 203's mother's maiden name. Message BI3 may contain the response of customer user 203.
In response to message BI1, server computer 100 sends message BI4 ("Bind Instrument 4") back to customer computer 200. The information included in these binding messages will be described later. In the description which follows, messages BI1 and BI4 are the operative messages for instrument binding.
During load/unload funds process 405, customer computer 200 sends message LUI ("Load/Unload 1") to server computer 100. In response to message LU1, server computer 100 sends message LU2 ("Load/Unload 2") back to customer computer 200. The information included in these load/unload funds messages will be described later.
During open session process 407 customer computer 200 sends message OS1 ("Open Session 1") to server computer 100. In response to message OS1, server computer 100 sends message OS2 ("Open Session 2") back to customer computer 200. The information included in these open session messages will be described later.
During transaction/payment process 409, merchant computer 300 sends message PR1 ("Payment Request 1") to customer computer 200. In response to message PR1, customer computer sends back message CA1 ("CAsh payment 1") to merchant computer 300. After receiving message CA1, merchant computer sends message CA2 ("CAsh payment 2") server computer 100. In response to message CA2, server computer 100 sends back message CA3 ("CAsh payment 3") to merchant computer 300. In response to message CA3, merchant computer 200 sends message CA4 ("CAsh payment 4") to customer computer 200. The information included in these transaction/payment messages will be described later.
During optional close session process 411, customer computer 200 sends message CS1 ("Close Session 1") to server computer 100. In response to message CS1, server computer 100 sends message CS2 ("Close Session 2") to customer computer 200. The information included in these close session messages will be described later.2
It is noted that FIG. 3B depicts messages R1/R2, BI1/BI4, LU1/LU2, OS1/OS2 and CS1/CS2 passing between customer computer 200 and server computer 100. Merchant user 303 causes these same messages to flow between merchant computer 300 and server computer 100. It follows that merchant user 303 executes registration process 401, instrument binding process 403, load/unload funds process 405, open session process 407 and close session process 411 in the same way as customer user 203, unless otherwise noted. In the case of merchant user 303, data associated with these processes is manipulated with regard to the merchant database and merchant data structures included in server computer 100.
The databases and data structures used in the preferred embodiments of the present invention are described next.
II. Databases
Referring to FIG. 1, server computer 100, customer computer 200, and merchant computer 300 include databases 102, 202 and 302, respectively. While the following description of databases 102, 202 and 302 refer to specific data structures and formats, those skilled in the art will readily appreciate that such specific data structures and formats are not critical to and are not considered part of the present invention. Therefore, any modifications to the data structures and formats would be within the scope of the appended claims.
It is preferred that values be stored in databases 202 and 302 when a response message is received by customer computer 200 and merchant computer 300, respectively. However, where it enhances clarity, values are described as being stored prior to the receipt of such a response message.
A. Server Database 102
Server database 102 stores data enabling server computer 100 to communicate with and process transactions between customer computer 200 and merchant computer 300. FIG. 4A depicts the general structure of server database 102.
As shown in FIG. 4A, server database 102 includes server persona data structure 120, server session data structure 130, message log data structure 140, message data structure 150 and public key data structure 160 and application data structure 170. Each of these data structures is now described in detail.
1. Server Persona Data Structure 120
Server persona data structure 120 stores data relating to the universe of customer users 203 and merchant users 303 who have registered with server computer 100. Referring to FIG. 4B, persona data structure 120 includes one or more customer personas 120.1. It is preferred that customer persona 120.1 be recorded having fields 120A-120H. Server persona data structure 120 contains a customer persona 120.1 for each registered customer user 203. The fields of customer persona 120.1 are now described.
Field 120A stores a persona id for customer user 203. The persona id identifies particular customer user 203. In order to increase system security, server database 102 does not store recognizable information for customer user 203. For example, the actual name and address of customer user 203 is not stored within server database 102. Rather, the persona id is used for identification. The persona id field is optional in that the information stored in public key field 120C (described below) may also be used to locate records associated with customer user 203. Because a persona id is shorter than a public key it is more efficient, and thus preferred, to use the persona id for this purpose.
Field 120B contains an email address for customer user 203. Using the email address of field 120B, server computer 100 is able to send email to customer user 203 over the Internet 50.
Field 120C stores an RSA public key for customer persona 120.1. As is more fully described below, the RSA public key of field 120C is generated by customer application software 210. The RSA public key of field 120C is the public component of an RSA public/private key pair. Both the RSA public and private key for a customer computer 200 are stored in customer computer 200, as described later. In the preferred embodiment, RSA keys are 768 bits in length. This length reflects a balance between increasing security (achieved using longer keys) and decreasing processing costs (achieved using shorter keys). As processor power increases in the future, longer RSA keys may be used to increase security without compromising system performance.
If the customer RSA public key is encapsulated in a certificate by appropriate certification authority, the key from the certificate is used in place of the public key and the persona id field 120A is no longer optional as previously described. Certificate based systems are well known in the art and are not described.
The date that customer user 203 registered with server computer 100 is stored in field 120D. The date of field 120D permits the running of promotions (e.g., if you register before this date, then this will happen) and assists in the resolution of disputes.
Field 120E contains a preferred language of communication for customer user 203.
Field 120F stores an autoclose passphrase for customer user 203. The autoclose passphrase is a passphrase which allows customer user 203 to close customer persona 120.1 in certain circumstances as described later.
Data 120G represents a data structure containing fields 120G.1-120G.4, shown in FIG. 4C. Fields 120G.1-120G.4 store data for each cash container established by customer user 203. Server persona data structure 120 contains a set of fields 120G.1-120G.4 for each cash container established by customer user 203. The cash container stores electronic cash. It is contemplated that multiple cash containers can be used, e.g., one for each currency that customer user 203 intends to transact business in.
Fields 120G.1-120G.4 are now described in detail with reference to FIG. 4C.
Field 120G.1 stores the currency associated with the amount of electronic funds stored in fields 120G.2 and/or 120G.3.
Field 120G.2 stores the available-balance of the cash container.
Field 120G.3 stores the on-hold-balance of the cash container.
Electronic cash stored in fields 120G.2 and/or 120G.3 is preferably deposited into an agency account (a form of banking instrument in which funds are held by one party for the benefit of the other). The account number of this agency account is stored in field 120G.4.
Data 120H represents a data structure containing fields 120H.1-120H.28, shown in FIG. 4D. Fields 120H.1-120H.28 store data for instruments bound to customer persona 120.1. Server persona data structure 120 contains a set of fields 120H.1-120H.28 for each instrument bound to a customer persona 120.1. Fields 120H.1-120H.28 are now described in detail with reference to FIG. 4D.
Field 120H.1 stores the persona id of field 120A (FIG. 4B). The persona id of field 120H.1 indicates the persona 120.1 to which the instrument having data stored in fields 120H.1-120H.28 is bound.
Field 120H.2 contains an instrument type for the bound instrument. Instrument types preferably include bank accounts, debit cards and credit cards.
Field 120H.3 stores an instrument subtype for the bound instrument. The instrument subtype is a sub-classification of an instrument type (e.g., "VISA" for the instrument type credit card").
Customer user 203 may elect to activate an "autoclose" feature when registering its persona 120.1. The autoclose feature permits customer user 203 to provide a passphrase (described later) to close customer persona 120.1 and to unload all electronic cash associated with that persona to an autoclose instrument. If the instrument being bound is the autoclose instrument, field 120H.4 contains an instrument number for the bound instrument. The instrument number identifies the instrument. It is preferred that the instrument number be encrypted before it is stored. Alternatively, the instrument number could be saved in a separate store device not connected to server computer 100. If the instrument being bound is not the autoclose instrument, the instrument number is used to compute field 120H.9 (as described later) and the instrument number is not stored in field 120H.4.
Bound instruments may have a secondary number further identifying the bound instrument, for example, an American Express CID or a US-DDA account R/T number. Such secondary numbers, referred herein to as instrument sub-numbers, are stored in field 120H.5.
Bank accounts are created in a single currency. The native currency of a bank account instrument is stored in field 120H.6.
Field 120H.7 stores one or more integers representing legal agreements. In the preferred embodiment, the operator of server computer 100 determines what legal agreements must be agreed to by customer user 203 in order for customer user 203 to use the bound instrument to perform certain operations.
Field 120H.8 contains an instrument prefix. The instrument prefix of 120H.8 is subset of the instrument number described in reference to field 120H.4. In the preferred embodiment, the instrument prefix of field 120H.8 (for credit cards, debit cards, and bank accounts) is the first two and the last four digits of the instrument number of field 120H.4.
Field 120H.9 stores an instrument hash value, preferably an MD5 hash of the instrument number described with reference to field 120H.4. (The term "hash" as used in this application refers to cryptographic hashes, as opposed to other mathematical hashing functions such as algebraic hashes.) The instrument number represented by the hash is preferably made more difficult to guess by concatenating the instrument number with a random number generated and provided to server computer 100 by customer computer 200 (such number commonly referred to as a "salt") before hashing. The instrument salt is stored in field 230Q of customer instrument binding data structure 230 as discussed below. The instrument hash of field 120H.9 is used to verify the instrument number without requiring the instrument number to be stored at server computer 100. This reduces the attractiveness of server computer 100 as a target for thieves and scoundrels.
Field 120H.10 contains an identification number of the issuer of the bound instrument, also known as a "BIN", or bank id number.
If the instrument being bound is to be used as autoclose instrument, fields 120H.11 and 120H.12 contain the name and address of a holder of the bound instrument. It is preferred that this information be encrypted before being stored. Alternatively, the instrument number could be saved in a separate store device not connected to server computer 100.
Fields 120H.13 and 120H.14 store dates that the bound instrument was bound and was first used, respectively.
Field 120H.15 contains a status of a bound instrument. The content of binding status field 120H.15 is dependent upon the instrument being bound. For example, to bind a DDA, customer user 203 may be required to sign a form and authorize the operator of server computer 100 to initiate a pre-notification ("pre-note") process with an automated clearing house ("ACH"). Before receiving the signed form or the response to the pre-note, server computer 100 may show that the binding was "created". Upon receiving the signed form, status field 120H.15 may contain "pending pre-note". If the pre-note is sent before the signed form, field 120H.15 may contain "pending-signature". If both have been received and are acceptable, field 120H.15 may contain "enabled". If there were a problem with either, or if a specified time period for receiving either requirement expires, field 120H.15 may contain "disabled". Field 120H.15 may also contain "disabled" if the instrument is subsequently determined not to be usable (e.g., an account is frozen by a bank). The status of other bound instruments will depend on the instrument type and the steps necessary to bind a particular type of instrument. Of course, the prenote process may be performed on-line.
Field 120H.16 is a flag indicating whether the bound instrument is enabled for sale transactions. A sale transaction is where customer persona 120.1 is used to pay for something using a bound instrument directly, as in the use of a debit card.
If field 120H.16 indicates that the bound instrument is enabled for sale transactions, a limit in customer user 203's chosen (native) currency is stored in field 120H.17. If a native currency does not exist, the sale transaction limit of 120H.17 is U.S. dollars. A special value may be used to indicate that there is no sale transaction limit for the bound instrument. This special value may be any value that is not within the set of acceptable values of the field. For example, if the limit of field 120H.17 is expressed as a positive number, the special value could be negative one.
Field 120H.18 is a flag indicating whether the bound instrument is enabled for credit/return transactions. A credit/return transaction is an operation where a merchant credits customer persona 120.1 in lieu of providing the product originally agreed to.
If field 120H.18 indicates that the bound instrument is enabled for credit/return transactions, a limit in customer user 203's chosen native currency, per credit/return transaction is stored in field 120H.19. If a native currency does not exist, the credit/return transaction limit of field 120H.19 is U.S. dollars. A special value, may be used to indicate that there is no credit/return transaction limit for the bound instrument, as previously described.
Field 120H.20 is a flag indicating whether a bound instrument is enabled for load operations, as previously described.
If field 120H.20 indicates that the bound instrument is enabled for load operations, a limit is stored in field 120H.21. The load cash transaction limit of field 120H.21 represents a limit, in native currency. If a native currency does not exist, the load cash transaction limit of field 120H.21 may default to U.S. dollars. A special value may be used to indicate that there is no load cash transaction limit for the bound instrument as previously described.
Field 120H.22 is a flag indicating whether the bound instrument is enabled for unload operations, as previously described.
If field 120H.22 indicates that the bound instrument is enabled for unload cash transactions, a limit for cash transactions is stored in field 120H.23. The unload cash transaction limit of field 120H.23 represents a limit, in native currency. If a native currency does not exist, the unload cash transaction limit of field 120H.23 may preferably default to U.S. dollars. A special value may be used to indicate that there is no unload cash transaction limit for the bound instrument, as previously described.
Field 120H.24 is a flag indicating whether the bound instrument is designated as the autoclose binding for customer persona 120.1. An autoclose binding must have its unload cash transaction flag (field 120H.22) enabled.
Field 120H.25 stores a number of hours over which the sales transaction limit stored in field 120H.17 applies.
Field 120H.26 stores a number of hours over which the credit transaction limit stored in field 120H.19 applies.
Field 120H.27 stores a number of hours over which the load cash transaction limit stored in field 120H.21 applies.
Field 120H.28 stores a number of hours over which the unload cash transaction limit stored in field 120H.23 applies.
Field 120I stores legal agreements as previously described.
While the foregoing description of customer persona 120.1 was set forth with respect to data relating to customer user 203, it is noted that a merchant user 303 has merchant persona 120.2 stored in server persona data structure 120. Merchant persona 120.2 is shown in FIGS. 4E, 4F, and 4G where fields 120AA-120HH, 120GG.1-120GG.4, and 120HH.1-120HH.28 correspond to fields 120A-120H, 120G.1-120G.4, and 120H.1-120H.28 of FIGS. 4B, 4C and 4D.
2. Server Session Data Structure 130
Server session data structure 130, shown generally in FIG. 4A, stores data associated with a session. Server session data structure 130 is now described for customer user 203.
Referring to FIG. 4H, server session data structure 130 includes one or more customer session records 130.1. Server session data structure 130 contains one record 130.1 for each active session of customer user 203.
Server computer 100 identifies a session by a unique session identification number ("session id"). The session id is stored in field 130A.
Messages exchanged between server computer 100 and customer computer 200 during a session includes encrypted data. Field 130B contains an encryption key (known as a "session key"). The session key of field 130B is used by server computer 100 to calculate a key to decrypt encrypted messages received from customer computer 200.
Field 130C stores a session salt, preferably 8-bytes in length. As will be described below, messages exchanged inside a session between server computer 100, customer computer 200 and merchant computer 300 are not authenticated using digital signatures. Instead, messages exchanged inside a session are authenticated by knowledge of the session key and session salt described above. To ensure that the unencrypted part of a message is not altered, it is hashed and the hash value is included in the encrypted part of the message. Use of the session salt of field 130C ensures that the hash values are more secure.
In the present invention, customer user 203 may transact business in one or more currencies. Field 130D indicates a denomination of currency (for example, U.S. dollars) that customer user 203 will use during the session.
Field 130E represents a maximum amount of electronic cash (in the currency of field 130D) available to customer user 203 at the start of the session.
Field 130F represents an amount of electronic cash (in the currency of field 130D) available to user 203 at a particular instant during the session. The initial value of field 130F is the value stored in opening amount field 130E. Thereafter, the value of current amount of field 130F is determined by subtracting each amount spent for products during the session from the previous value of 130F.
Field 130G indicates a date and time that the session was created. Field 130H indicates the date and time that the session actually closed.
Field 130I represents the maximum number of times (key use limit) that server computer 100 will recognize customer computer 200's use of the session key of field 130B.
Field 130J represents a length of time (key lifetime) that the session key of field 130B is valid.
Field 130K stores the persona id of customer user 203. It is through the persona id of field 130K that a session is associated with a persona 120.1.
Field 130L stores the status of a session associated with the session id in field 130A. The status is either "open" or "closed".
Field 130M stores an optional string (memo) provided by customer user 203 describing the session associated with the session id in field 130A. Field 130M may contain a string provided by customer user 203 at the opening of a session and a string provided at the close of a session.
Transaction data 130N comprises fields 130N.1-130N.5. Fields 130N.1-130N.5, shown in FIG. 4I, are maintained for each transaction initiated by customer user 203 during the session identified by the session id in field 130A. The maximum number of such transactions is equal to the key-use limit stored in field 1301. Fields 130N.1--130N.5 are now described in detail with reference to FIG. 4I.
Field 130N.1 contains the amount charged to customer user 203 for a particular transaction.
Field 130N.2 stores the session id stored in field 130A.
Field 130N.3 stores an order identification number ("order id") generated by merchant computer 300 to identify a particular order.
Field 130N.4 stores the session id of merchant 303 from which the product associated with a particular transaction as purchased.
Field 130N.5 contains the index value assigned by customer computer 200 to a particular transaction. The index value must be within the key use-limit established as set forth in field 130I. Because the transactions executed by customer persona 120.1 may not be received by server computer 100 in the order that they are executed, the index value is stored in a manner, such as bit map of permitted index values, which allows server computer 100 to determine if a permitted index has been used and to take appropriate action should that occur.
While the foregoing description of server session data structure 130, customer session record 130.1 was set forth with respect to data relating to customer user 203, it is noted that a merchant 303 user has corresponding data stored in server session data structure 130. Such a merchant session record 130.2 is shown in FIGS. 4J and 4K where fields 130AA-130NN correspond to fields 130A-130N, and fields 130NN.1-130NN.5 correspond to fields 130N.1-130N.5.
3. Message Log Data Structure 140
Message log data structure 140 (FIG. 4A) tracks messages received and sent by server computer 100. This permits server computer 100 to identify duplicate messages and respond accordingly. Duplicate messages are used to ensure consistent state between a client and server computer 100 in the face of unpredictable communications over the Internet 50. For example, a duplicate of a valid message could be responded to with the original response. Server computer 100 might not, however, duplicate the processing of the duplicate message. A record 140.1 of message log data structure 140 is now described with reference to FIG. 4L.
Field 140A contains the persona id included in the message received by server computer 100.
Field 140B contains the session number included in a message CA2 (described later) received by server computer 100. For all other messages received by server computer 100, this field is preferably null.
Field 140C contains the transaction number included in a message R1, BI1, LU1, OS1, or CS1 (described later) received by server computer 100. For any message CA2 received by server computer 100, this field is preferably null.
Field 140D contains the index included in message CA2 received by server computer 100. For all other messages received by server computer 100, this field is preferably null.
Field 140E contains a hash of, or copy of, the message received (incoming) by server computer 100 associated with fields 140A-140D.
Field 140F contains a copy of a message sent by server computer 100 in response to the message saved in field 140E.
4. Message Data Structure 150
Message data structure 150 (FIG. 4A) includes templates indicative of the format and contents of messages used in the present invention by type and version. For example, a particular message may differ between one or more supported versions of customer application software 210 or merchant application software 310. When a message is received by server computer 100, it is compared to a template for that message. As described later, if the message does not conform to the template, an error message is returned to the sender of the message.
5. Private Key Data Structure 160
Private key data structure 160 maintains a list of the RSA public/private key pairs of server computer 100 that are used in supported versions of customer application software 210 or merchant application software 310. As will be described later, encrypted messages sent to server computer 100 include a pointer which informs server computer 100 which RSA public key of server computer 100 was used by customer application software 210 or merchant application software 310 to encrypt the message. In this manner, server computer 100 can find the corresponding RSA private key to decrypt the encrypted message.
6. Application Data Structure 170
Application data structure 170 tracks existing version(s) of customer application software 210 and merchant application software 310. Application data structure 170 is also used to determined whether an update to customer application software 210 or merchant application software 310 is available or necessary. For example, server computer 100 may advise a customer computer 200 that customer application software 210 is non-current yet usable, or that the software is no longer usable and must be replaced.
B. Customer Database 202
FIG. 5A depicts the general structure of customer database 202. Customer database 202 includes customer application data structure 215, customer persona data structure 220, customer instrument binding data structure 230, customer session data structure 240, customer pending transaction data structure 250, customer log data structure 260, message template data structure 270 and customer cash data structure 280. Each of these data structures is now described in detail.
1. Customer Application Data Structure 215
Customer application data structure 215 stores data relating to server computer 100. Referring to FIG. 5B, customer application data structure 215 includes record 215.1, shown there in detail.
Field 215A contains an RSA public key for server computer 100. The RSA public key of field 215A is used by customer computer 200 to encrypt data in messages sent by customer computer 200 to server computer 100.
Field 215B stores a uniform resource locator for ("URL") for server computer 100. The URL of field 215B is the address of server computer 100 on the world wide web of the Internet 50.
While the foregoing description of customer application data structure 215 and record 215.1 was set forth with respect to data relating to customer user 203, it is noted that a merchant user 303 has corresponding data stored in merchant application data structure 315, shown in FIG. 6B. A merchant record 315.1 is shown in FIG. 6B where fields 315A-315B correspond to fields 215A-215B.
2. Customer Persona Data Structure 220
Customer persona data structure 220 stores data relating to customer user 203. Referring to FIG. 5C, customer persona data structure 220 includes record 220.1, shown there in detail.
Fields 220A-220C correspond to and contain the same information as fields 120A-120C (FIG. 4B).
Field 220D stores an autoclose passphrase for customer user 203. The autoclose passphrase is a passphrase which allows customer user 203 to close customer persona 120.1 in certain circumstances as described later.
Field 220E contains a preferred language of communication for customer user 203.
A default name and address of customer user 203 is stored in field 220F. The default name and address of field 220F is the name and address of the individual whose customer persona 120.1 is indicated by the persona id of field 220A. The default name and address of field 220F facilitates providing such information when it is requested.
Field 220G retains preferred customer application software 210 settings (options), for example, the communication preferences (e.g., time-out range in seconds), alert preferences (e.g., show alerts before submitting transactions off-line and/or when logging on), and security preferences (e.g., ask for passphrase before a payment operation).
Field 220H stores the RSA private key for a customer persona 120.1. The RSA private key of field 220H is the complement to RSA public key of field 120C, stored in server database 102.
Cash container data 220I represents fields 280A-280C shown in FIG. 5U.
Instrument binding 220J represents fields 230A-230S shown in FIG. 5D.
Field 220K retains the autoclose account number associated with the autoclose password stored in field 220D.
Field 220L stores one or more integers representing legal agreements. In the preferred embodiment, the operator of server computer 100 determines what legal agreements must be agreed to by customer user 203 in order for customer user 203 to create a persona.
Active sessions data 220M represents fields 240A-240K.
Pending log data 220N represents records 251-256 of pending log data structure 250.
Transaction log data 2200 repressents records 261-267 of transaction log data structure 260.
While the foregoing description of customer persona data structure 220 and record 220.1 was set forth with respect to data relating to customer user 203, it is noted that merchant user 303 has corresponding data stored in merchant persona data structure 320, shown in FIG. 6C. A merchant record 320.1 is shown in FIG. 6C where fields 320A-3200 correspond to fields 220A-220O.
3. Customer Instrument Binding Data Structure 230
Customer instrument binding data structure 230 retains information at customer computer 200 regarding bound instruments. Referring to FIG. 5D, customer instrument binding data structure 230 includes one or more records 230.1. Customer database 202 contains one record 230.1 for each instrument bound to customer persona 120.1. A detailed record 230.1 of customer instrument binding data structure 230 is shown in FIG. 5D where:
Field 230A stores the instrument number.
Field 230B contains a description of the bound instrument.
Fields 230C-230J respectively represent the name, address, city, country, postal code, country code, area code and telephone number of the holder of the bound instrument.
Field 230K stores a default currency associated with the bound instrument.
Fields 230L-230O are flags indicating whether the bound instrument is enabled for sale transactions, credit return transactions, unload and load operations. Fields 230L-230O correspond to fields 120H.16, 120H.18, 120H.22 and 120H.20, respectively (FIG. 4D).
Field 230P contains a status of the bound instrument. The binding status of field 230P corresponds to the binding status of field 120H.15 of FIG. 4D.
Field 230Q stores a salt for the bound instrument. The salt of field 230Q represents a random number generated by customer application software 210. As previously described, is used by server to strengthen the result of the instrument hash value stored in field 120H.9.
Field 230R stores certain information associated with a bound instrument and is referred to as "instrument recurring data". The recurring data is a data string which is used by customer application software 210 to reconstruct a set of label-value pairs identified by server computer 100 at the time an instrument is bound. The fields are returned to server computer 100 by customer computer 200 during operations that require use of the instrument associated with the recurring data. In this way, server computer 100 may receive information regarding the instrument when necessary without storing that information in its data structures. The particular label-value pairs that are contained within recurring data depend on the type of the bound instrument and the requirements of the issuer of the instrument. For example, a credit card might require the card number, the card expiration date, and the name and address of the card holder to be returned to the server each time the card is used to load funds into persona 120.1. The recurring data would contain data which would allow customer application software 210 to return this information in the proper label-value pair format.
Field 230S corresponds to and stores the same information as field 120H.7 (FIG. 4D) relating to legal agreements.
While the foregoing description of customer instrument binding data structure 230 and record 230.1 was set forth with respect to data relating customer user 203, it is noted that a merchant user 303 has corresponding data stored in merchant persona data structure 330, shown in FIG. 6D. A merchant record 330.1 is shown in FIG. 6D where fields 330A-330S correspond to fields 230A-230S.
4. Customer Session Data Structure 240
Customer session data structure 240 maintains information at customer computer 200 relating to a session. Referring to FIG. 5E, customer session data structure 240 includes one or more records 240.1. Customer session data structure 240 contains one record 240.1 for each active session of customer user 203. A detailed record 240.1 of customer session data structure 240 is shown in FIG. 5E.
Fields 240A-240F correspond to and contain the same information relating to a session as fields 130A-130F (FIG. 4H). Field 240G contains the last index used by customer computer 200 during the session. Field 240H contains the same information as field 130M. Fields 240J-240K contain the same data as fields 1301-130J, respectively.
While the foregoing description of customer session data structure 240 and record 240.1 was set forth with respect to data relating a customer user 203, it is noted that a merchant user 303 has corresponding data stored in merchant persona data structure 340, shown in FIG. 6E. A merchant record 340.1 is shown in FIG. 6E where fields 340A-340K correspond to fields 240A-240K (FIG. 5E).
5. Customer Pending Transaction Data Structure 250
Customer pending transaction data structure 250 stores (1) data necessary to create messages sent by customer computer 200 and (2) a copy of each message sent by customer computer 200. Referring to FIG. 5F, customer pending transaction data structure 250 includes the following records: pending persona registration/update persona information 251, pending link/update financial instrument binding 252, pending cash payment 253, pending load/unload funds 254, pending open session record 255, and pending close session record 256. Each record 251-256 is now described in detail with reference to FIGS. 5G-5L. It is preferred that a pending record 251-256 be deleted upon receipt by customer computer 200 of a response message unless customer user 203 has indicated otherwise.
a. Pending Persona Registration/Update Persona Information Record 251
Pending persona registration/update persona information record 251 stores data relating to processes by which customer user 203 creates customer persona 120.1. Referring to FIG. 5G, record 251 is shown in detail.
Field 251A indicates a code which represents a type (transaction type) of action being performed. For example, field 251A may contain "creation" which would indicate that user 203 is creating persona 120.1. If a persona 120.1 already exits and the action being performed is to change something associated with that persona, field 251A may contain "modification".
Field 251B stores a transaction number, that is, a unique number indicative of a particular action. The transaction number of field 251B is generated by client application software 210. The transaction number of field 250B allows server computer 100 to send an associated reply message. Because transaction numbers are unique, the transaction number of field 251B also permits server computer 100 to determine whether a message R1 is a duplicate message.
Field 251C represents the date and time that message R1 was assembled and sent to server computer 100.
Field 251D stores the version of the application software 210 used to assemble message R1. As further described later, the software version number of field 251D is used to determine whether customer application software 210 is outdated.
Field 251E contains a preferred language for customer user 203, corresponding to field 220E (FIG. 5B).
Field 251F contains a preferred currency for customer user 203, corresponding to field 240D (FIG. 5E).
Field 251G stores a persona id requested by customer user 203. It should be noted that the requested persona id of field 251G may not be the same as the persona id of field 120A finally assigned to customer user 203. For example, server computer 100 may reject the requested persona id of field 251G if it is already in use by another customer user 203.
Field 251H contains the email address for customer user 203, corresponding to field 220B (FIG. 5C).
Field 251I contains an autoclose passphrase, corresponding to field 120F (FIG. 4B).
Field 251J stores an original transaction string which is a copy of original message R1 sent from customer computer 200 to server computer 100.
b. Pending Link/Update Instrument Record 252
Pending link/update record 252 stores data relating to processes by which customer user 203 binds an instrument to customer persona 120.1 or updates an existing bound instrument. Referring to FIG. 5H, a record 252 is shown in detail.
Field 252A indicates a code which represents a type of action (transaction type) being performed. For example, field 252A may contain "link" which would indicate that user 203 is linking an instrument to customer persona 120.1. If the action being performed is to change something associated with an instrument already linked with that persona, field 252A may contain "update".
Fields 252B-252D correspond to and store the same information as field 251B-251D of FIG. 5G. These fields relate to the transaction number, transaction date and time, and software version, respectively.
Field 252E contains the persona id of customer user 203, corresponding to field 220A (FIG. 5B).
Field 252F stores the number of the instrument being bound to persona 120.1.
Field 252G stores additional customer identification information needed to use the instrument being bound, for example, American Express card customer identification number.
Field 252H stores the name of the person to whom the instrument being bound was issued.
Field 252I stores the expiration date of the instrument being bound.
Fields 252J-252Q respectively store the street address, city, state, postal code, country, country code, area code and telephone number of the person to whom the instrument being bound was issued.
Field 252R contains customer user 203's selected description of the instrument being bound.
Instrument recurring data field 252S stores information stored in field 230R as relates to bound instruments.
Field 252T stores the type of instrument being bound, for example, VISA, American Express, etc.
Field 252U contains a random number salt, generated by customer computer 200. The salt of field 252U is used to strengthen the instrument number hash mainatined at server 100.
Field 252V stores a flag which if set indicates that the instrument is the autoclose account instrument.
Field 252W stores an original transaction string which is a copy of the original message BI1 sent by customer computer 200 to server computer 100.
c. Pending Cash Payment Record 253
Pending cash payment record 253 stores data relating to transactions involving cash payments. Referring to FIG. 51, a record 253 is shown in detail.
Field 253A indicates a code which represents a type of action (transaction type) being performed. For example, if a session is open, then field 254A may indicate "cash payment" indicating that customer user 203 is sending a message CA1 (described later).
Fields 253B-253D correspond to and store the same information as fields 251B-251D (FIG. 5G). These fields relate to the transaction number, transaction date and time, and software version, respectively.
Field 253E contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 253F stores an order identification number ("order id"). The order id of field 254F is generated by merchant computer 300 to identify a particular order.
Field 253G contains merchant user 303's persona id 120AA (FIG. 4E).
Field 253H stores an amount of electronic cash that a customer user 203 is paying for a product which is the subject of the current transaction.
Field 253I provides a location for an optional customer user 203 generated memo that describes this particular transaction.
Field 253J contains the URL of a merchant computer 300 to which customer user 203 wishes to direct a cash payment. Customer application software 210 uses the URL field 253J to direct pay cash requests in the form of message CA1 to merchant computer 300 for forwarding to server computer 100.
Field 253K stores the session-id of the session during which the current transaction was initiated.
Field 253L stores the index associated with current transaction.
Field 253M stores an original transaction string which is a copy of message CA1 sent by customer computer 200, through merchant computer 300, to server computer 100. <cr> Field 253N contains the URL of merchant computer 300 on which customer user 203 wishes to cancel a transaction. Customer application software 210 uses the URL field 253N to cancel transaction requests in the form of message CA1.
Field 253O contains the URL of merchant computer 300 to indicate a successful cancellation of a transaction by customer user 203. Customer application software 210 uses the URL field 253O to indicate a successful cancellation in the form of message CA4.
Field 253P stores the URL of merchant computer 300 to indicate a failure of a transaction. Customer application software 210 uses the URL field 253P to indicate a failure of a transaction in the form of message CA4.
d. Pending Load/Unload Funds Record 254
Pending load/unload funds record 254 stores data relating to transactions involving loading and unloading of electronic cash. Referring to FIG. 5J, a record 254 is shown in detail.
Field 254A indicates a code which represents a type of action (transaction type) being performed. For example, field 254A may contain "load" which would indicate that user customer 203 is "transferring" funds into the cash container field 280B of record 280.1 from the instrument identified in field 254F. Alternatively, field 254A may contain "unload" which would indicate that customer user 203 is "transferring" electronic cash funds from cash container field 280B to the instrument identified in field 254F.
Fields 254B-254D correspond to and store the same information as fields 251B-251D (FIG. 5G). These fields relate to the transaction number, transaction date and time, and software version, respectively.
Field 254E contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 254F stores an account number identifying a bound instrument from which funds are to be loaded or to which funds are to be unloaded.
Field 254G stores an amount of funds to be loaded from or unloaded to a bound instrument.
Field 254H stores the type of account from which funds are being load or to which funds are being loaded.
Field 254I stores an original transaction string which is a copy of message LU1 sent by customer computer 200 to server computer 100.
e. Pending Open Session Record 255
Pending session record 255 stores data relating to processes by which customer user 203 creates a session. Referring to FIG. 5K, a record 255 is shown in detail.
Field 255A indicates a code which represents a type of action (transaction type) being performed. For example, field 255A may contain "open-session" which would indicate that user customer 203 is creating a session.
Fields 255B-255D correspond to and store the same information as fields 251B-251D (FIG. 5G). These fields relate to the transaction number, transaction date and time, and software version, respectively.
Field 255E contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 255F stores an amount of electronic cash to be made available during a session.
Field 255G stores a value representing the maximum number of transactions (key use limit) that customer user 203 may request during a session.
Field 255H stores a value representing the maximum amount of time (key lifetime) the session will remain open.
Field 255I stores the text of an optional description of a session as entered by customer user 203.
Field 255J stores the currency associated with the amount value stored in field 255F.
Field 255K stores an original transaction string which is a copy of message OS1 sent by customer computer 200 to server computer 100.
f. Pending Close Session Record 256
Pending close-session record 256 stores data relating to processes by which customer user 203 closes a session. Referring to FIG. 5L, a record 256 is shown in detail.
Field 256A indicates a code which represents a type of action being performed. For example, field 256A may contain "close-session" which would indicate that user customer 203 is closing a session.
Fields 256B-256D correspond to and store the same information as fields 251B-251D (FIG. 5G). These fields relate to the transaction number, transaction date and time, and software version, respectively.
Field 256E contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 256F contains either "yes" or "no". The value of field 257 determines whether customer user 203 has elected to receive a log of the transactions initiated by customer user 203 during the session to be closed.
Field 256G stores the session-id of the open session to be closed. Alternatively, if all open sessions are to be closed, field 256G will be null.
Field 256H stores the text of an optional description related to the session closing as entered by customer user 203.
Field 256I stores an original transaction string which is a copy of message CS1 sent by customer computer 200 to server computer 100.
6. Customer Log Data Structure 260
Referring to FIG. 5A, customer log data structure 260 maintains a copy of each message received by customer computer 200. Customer log data structure 260 stores data received by customer computer 200 from server computer 100. Referring to FIG. 5M, customer log data structure 260 includes the following records: persona registration/update persona information response 261, link/update financial instrument binding response 262, cash payment response 263, load/unload funds response 264, open session response 265, payment request 266, and close session response 267. Each record 261-267 is now described in detail with reference to FIGS. 5N-5U.
a. Persona Registration/Update Response Persona Information Record 261
Persona registration/update persona information record 261 stores data relating to the response of server computer 100 to a request to create a customer persona 120.1 by customer user 203. Referring to FIG. 5N, a record 261 is shown in detail.
Field 261A indicates a type of action that was requested and is the same as the value of field 251A of record 251. Field 261B stores a transaction number that is the same as the value stored in 251B.
Field 261C represents the date and time that message R1 was assembled and sent to server computer 100.
As will be discussed later, messages from customer computer 200 to server computer 100 convey a code containing the version number of the customer application software 210 used to create the message. At server computer 100, each software version is associated with one of three "status" labels: current, warning, or fatal. Server computer 100 checks the software version reported in customer's messages and includes in its reply message one of the three possible status labels. The status label returned in message R2 is stored in software severity field 261D. A text message regarding the content of software severity field 261D may also be returned by server computer 100 and, if so, is stored in field 261E.
A code representing the success or failure of message R1 is returned by server computer 100 and is stored in response code field 261F. A text message regarding the content of the response code field 261F, if sent by server computer 100, is stored in field 261G.
Field 261H stores a persona id requested by customer user 203. As described below, if the requested persona id is in use, server computer 100 will suggest a persona id to customer user 203. The persona id suggested by server computer 100 is stored in field 261I.
Field 261J contains the email address for customer user 203 corresponding to field 220B (FIG. 5C).
Field 261K contains a preferred language for customer user 203, corresponding to field 220E (FIG. 5C).
Field 261L contains a preferred currency for customer user 203, corresponding to field 240D (FIG. 5E).
b. Link/Update Response Instrument Record 262
Link/update instrument record 262 stores data relating to the response by server computer 100 to a request by customer user 203 to bind an instrument to customer persona 120.1. Referring to FIG. 5O, a record 262 is shown in detail.
Field 262A indicates a type of action (transaction) that was requested and is the same as the value of field 252A of record 252.
Fields 262B-262G correspond to and store the same information as field 261B-261G of FIG. 5N. These fields relate to the transaction date and time, software severity code, software message, response code, and response message respectively.
Field 262H contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 262I stores the number of the instrument being bound to customer persona 120.1. Field 262J stores the type of instrument being bound, for example, VISA, American Express, etc. to customer persona 120.1.
Field 262K stores customer identification information needed to use the instrument being bound, for example, American Express card customer identification number <cr>.
Field 262L stores the name of the customer to whom the instrument being bound was issued.
Field 262M stores the expiration date of the instrument being bound.
Fields 262N-262U respectively store the street address, city, state, postal code, country, country code, area code and telephone number of the person to whom the instrument being bound was issued.
Field 262V stores the text of a description of the instrument being bound as entered by customer user 203.
Field 262W stores the native currency, if any associated with an instrument which is returned by server computer 100.
Field 262X stores the name of the issuer of the instrument which is returned by server computer 100.
Field 262Y stores the country of issuance of the instrument.
Field 262Z stores a flag which if set indicates that the instrument is the autoclose account instrument.
c. Cash Payment Response Record 263
Cash payment response record 263 stores data relating transactions involving cash payments and sessions. Referring to FIG. 5P, a record 263 is shown in detail.
Field 263A indicates a type of action (transaction type) that was requested and is the same as the value of field 253A of record 253.
Fields 263B-263E correspond to and store the same information as field 261B-261C and 261F-261G of FIG. 5N. These fields relate to the transaction number, date and time, response code, and response message respectively.
Field 263F contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 263G stores an order identification number ("order id"). The order id of field 263I is generated by merchant computer 300 to identify a particular order.
Field 263H contains a merchant user 303 persona id 120AA.
Field 263I provides a location to store a message from merchant user 303.
Field 263J stores an amount of electronic cash that a customer user 203 is paying for a product which is the subject of the current transaction.
Field 263K provides a location for an optional customer user 203 generated memo.
Field 263L stores the session-id of the session during which the current transaction was initiated.
Field 263M stores the index associated with the current transaction.
d. Load/Unload Funds Response Record 264
Load/unload funds response record 264 stores data relating to the response of server computer 100 to a request to load or unload funds by customer user 203. Referring to FIG. 5Q, a record 264 is shown in detail.
Field 264A indicates a type of action (transaction type) that was requested and is the same as the value of field 254A of record 254.
Fields 264B-264G correspond to and store the same information as field 261B-261G of FIG. 5N. These fields relate to the transaction date and time, software severity code, software message, response code, and response message respectively.
Field 264H contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 264I stores an account number identifying a bound instrument from which electronic cash is to be loaded or to which electronic cash is to be unloaded.
Field 264J stores an amount of electronic cash to be loaded from or unloaded to a bound instrument.
Field 264K stores an amount of any fee charged by the operation of server computer 100 to load or unload funds from customer persona 120.1.
Field 264L stores an amount equal to the available balance of the funds held by customer persona 120.1 as determined by server computer 100, corresponding to the value stored in field 120G.2 (FIG. 4C).
Field 264M stores an amount of funds which have been loaded (or unloaded) but are not available to customer user 203. These funds are awaiting processing, corresponding to the value stored in field 120G.3 (FIG. 4C).
e. Open Session Response Record 265
Create session response record 265 stores data relating to the response of server computer 100 to a request to create a session by customer user 203. Referring to FIG. 5R, a record 265 is shown in detail.
Field 265A indicates a type of action that (transaction type) was requested and is the same as the value of field 255A of record 255.
Fields 265B-265G correspond to and store the same information as field 261B-261G of FIG. 5N. These fields relate to the transaction date and time, software severity code, software message, response code, and response message respectively.
Field 265H contains the persona id of customer user 203, corresponding to field 220A of FIG. 5C.
Field 265I stores an amount of electronic cash made available during a session.
Field 265J stores a value representing the maximum number of transactions (key use limit) that customer user 203 may request during a session.
Field 265K stores a value representing the maximum amount of time (key lifetime) the session will remain open.
Field 265L stores a session id number.
Field 265M stores the text of an optional description of the session to be opened as entered by customer user 203.
Field 265N stores an amount of any fee charged by the operation of server computer 100 to create a session.
Field 265O stores the available balance remaining in the cash container (field 120G.2) after the value in amount field 265I is subtracted.
f. Payment Request Record 266
Payment request record 266 stores data relating to a request from merchant user 303 for payment for the product. The request is in the form of a message PR1 (described later) which is sent by merchant computer 300 to customer computer 200. Referring to FIG. 5S, a record 266 is shown in detail.
Field 266A contains a merchant user 303 persona id 120AA.
Field 266B stores an order identification number ("order id"). The order id of field 266B is generated by merchant computer 300 to identify a particular order.
Field 266C stores an amount of electronic funds that a customer user 203 is paying for the product which is the subject of the current transaction.
Field 266D stores a list of credit cards accepted by merchant 203 for payment.
Field 266E provides a location to store a message (note) from merchant user 303.
Field 266F stores the pay-to-URL. The value of label-value pair 5013I is an Internet 50 uniform resource locator. The Internet 50 uniform resource locator of label-value pair 5013I is the address on the Internet 50 to which customer computer 200 is to sends message CA1, described later.
g. Close Session Response Record 267
Close session response record 267 stores data relating to the response of server computer 100 to a request to close a session by customer user 203. Referring to FIG. 5T, a record 267 is shown in detail.
Field 267A indicates a type of action (transaction type) that was requested and is the same as the value of field 256A of record 256.
Fields 267B-267G correspond to and store the same information as field 261B-261G of FIG. 5N. These fields relate to the transaction date and time, software severity code, software message, response code, and response message respectively.
Field 267H contains the persona id of customer user 203, corresponding to field 220A (FIG. 5C).
Field 267I stores an amount of electronic cash remaining in the session after the close of a session after all payments and fees have been deducted.
Field 267J stores the transaction log returned by server computer 100 if requested by customer user 203 in message CS1. This would also indicate whether or not a transaction log was returned.
Field 267K stores an amount of any fee charged by the operation of server computer 100 to close the session.
7. Message Template Data Structure 270
Referring to FIG. 5A, message template data structure 270 tracks the format and contents of messages that customer user 203 sends and receives. A message which contains all the required labels with valid values (e.g., syntax, etc.) as determined by reference to message template data structure 270 will be processed even if there are extraneous label-value pairs. A message which does not contain all the required label-value pairs, or which includes labels associated with invalid values as determined by reference to message template data structure 270 will fail as to form.
While the foregoing description of message templates 270 was set forth with respect to data relating a customer user 203, it is noted that a merchant user 303 has corresponding data stored in message templates 380, shown in FIG. 6A.
8. Cash Container Data Structure 280
Customer cash container data structure 280 maintains information at customer computer 200 relating to cash containers. Referring to FIG. 5U, cash container data structure 280 includes one record 280.1 for each cash container established by customer user 203. A detailed record 280.1 of customer cash container data structure 280 is shown in FIG. 5U.
Fields 280A-280C correspond to and contain the same information relating to a cash container as fields 120G.1-120G.3 (FIG. 4C).
While the foregoing description of customer cash container data structure 280 and record 280.1 was set forth with respect to data relating a customer user 203, it is noted that a merchant user 303 has corresponding data stored in merchant cash container data structure 345, shown in FIG. 6F. A merchant record 345.1 is shown in FIG. 6F where fields 345A-345C correspond to fields 280A-280C (FIG. 5U).
C. Merchant Database 305
The database 305 of merchant computer 300 is described next.
FIG. 6A depicts the general structure of the merchant database 302 of merchant computer 300. FIG. 6A, depicts merchant application data structure 315 (previously described), merchant persona data structure 320 (previously described), merchant instrument binding data structure 330 (previously described), merchant session data structure 340 (previously described), merchant amount data structure 350, merchant sales session data structure 360, merchant cash log 370, message template data structure 380 (previously described), and merchant cash container data structure 345 (previously described). Data structures 350, 360 and 370 are now described.
1. Merchant Amount Data Structure 350
Merchant amount data structure 350 tracks the amount of electronic cash merchant user 303 expects to receive from customer user 203 for an order. Referring to FIG. 7A, record 350 is shown in detail.
Field 350A stores an order id, corresponding to field 253F of FIG. 5I.
Field 350B stores an amount of electronic cash (amount of transaction) corresponding to field 253H of FIG. 5I.
Field 350C is a flag indicating whether an order has been paid for by customer user 203.
2. Merchant Sales Session Data Structure 360
Merchant sales session data structure 360 tracks the sessions of merchant user 303. Referring to FIG. 7B, record 360 is shown in detail.
Fields 360A-360D correspond to fields 340A-340D (FIG. 6E). Field 360E corresponds to field 340H (FIG. 6E). Fields 360F corresponds to field 340F (FIG. 6E). Fields 360J-360K correspond to fields 340J-340K (FIG. 6E). Field 360G stores the date that the merchant sales session identified by session id field 360A was opened. Field 360H stores the date that such session was closed.
3. Merchant Cash Log Data Structure 370
Merchant cash log 370 tracks electronic cash transactions and session data not retained in merchant sales session data structure 360. More specifically, merchant cash log data structure 370 stores data relating to collections and sessions initiated by a merchant user 303. Referring to FIG. 7C, a record 370 is shown in detail.
Fields 370A-370M store data relating to collection messages CA2 submitted by merchant computer 300 to server computer 100. Those fields are now described in detail.
Field 370A indicates a type of action being performed. In this case, the type stored in field 370A is "collection".
Field 370B stores a status of the current collection request. The status of field 370B may include "attempt", "success" or "failure". The label "attempt" will be returned when the request has been sent to server computer 100 but no response has been received. If the request is processed by server computer 100 and the collection request is honored, field 370B will contain the label "success". If server computer 100 denies the request, field 370B will contain the label "failure" and field 370M will include a code identifying the reason for such failure.
Field 370C stores an order identification number ("order id"). The order id of field 370A is generated by merchant computer 300 to identify a particular order.
Field 370D stores the session id of field 240A used by customer computer 200 in the current collection request.
Field 370E stores the index of field 240G used by customer computer 200 in the current collection request.
Field 370F stores the currency of field 240D used by customer computer 200 in the current collection request.
Field 370G stores the session id of field 340A used by merchant computer 300 in the current collection request.
Field 370H stores the index of label-value pair 5213D used by merchant computer 300 in the current collection request.
Field 370I stores the currency of field 340D used by merchant computer 300 in the current collection request.
Field 370J stores an amount of electronic cash funds requested to be paid to merchant user 303 in the current collection request.
Field 370K stores an amount of electronic cash credited to merchant cash container field 345B for the current collection. The amount of electronic cash credited is null if the status of field 370B is null.
Field 370L stores an amount of electronic cash funds paid to the operator of server computer 100 for processing the current collection request (i.e., a fee).
If the content of status field 370B is "failure", field 370M stores a result code. The result code is used by merchant application software 310 to associate a message with the failure reported in status field 370B. Thus, the code returned in field 370M could prompt merchant application software to display a message such as "collection failed due to inadequate funds."
Fields 370N-370T store data relating to sessions initiated by merchant computer 300 (message OS1). Those fields are now described in detail.
Field 370N indicates a type of action being performed. In this case, the type stored in field 370N is "OS".
Field 370O stores a status of the current collection request. The status of field 370O may include "attempt", "success" or "failure". The label "attempt" will be returned when the request has been sent to server computer 100 but no response has been received. If the request is processed by server computer 100 and the collection request is honored, field 370O will contain the label "success". If server computer 100 denies the request, field 370O will contain the label "failure" and field 370T will include a code identifying the reason for such failure.
Field 370P stores a transaction number, that is, a unique number indicative of a particular session initiated by merchant computer 300.
Field 370Q stores a merchant user 303's requested amount of time that the current session should last (i.e., requested session duration).
Field 370R stores a merchant user 303's requested number of times that the session key of field 340J can be used (i.e., requested session court).
If the status of field 370O is "success", field 370S stores a session id for merchant computer 300 for the current session.
If the content of status field 370O is "failure", field 370T stores a result code. The result code is used by merchant application software 310 to associate a message with the failure reported in status field 370T.
III. General Information
The preferred format of messages used in the present invention is now described.
Due to the nature of the Internet 50, the present invention uses a message transmission independent mechanism so that messages can be transmitted using several different protocols. These protocols may include e-mail (simple mail transport protocol) and world wide web (hyper text transport protocol or other protocols, such as remote procedure protocol (RPC)). Therefore, messages used in the present invention have a particular and preferred format that is not specific to the transport protocol. The particular and preferred format is based on RFC 822, which is well known in the art and therefore, only briefly described.
FIG. 7D depicts the format of a sample message 4000. Sample message 4000 includes header 4005, body 4010 and trailer 4050. Body 4010 includes transparent (unencrypted) label-value pairs 4013A, 4013B, etc. and may include opaque (encrypted) label-value pair 4017. (Label-value pairs consist of a label and data relating to the label, separated by a label terminator, for example, "name: Brian".)
Header 4005 defines the start of sample message 4000. Header 4005 may include a system identifier, for example, "CyberCash" (the assignee of the present invention) and a number of the message protocol ("protocol number") in which sample message 4000 was assembled.
Transparent label-value pairs 4013A, 4013B, etc. include any clear (non-encrypted) text associated with sample message 4000. Encryption and decryption are described below.
Opaque label-value pair 4017 includes the label "opaque". The value of opaque label-value pair 4017 is a block of encrypted data. The value of opaque label-value pair 4017 includes a predetermined set of label-value pairs encrypted with a DES key. After encryption, the value is preferably base-64 encoded. The predetermined set of label-value pairs is referred to herein as the "opaque section contents" of sample message 4000. For request messages sent outside of a session (R1, BI1, LU1 and CS1), the value of opaque label-value pair 4017 begins with that DES key, RSA encrypted under a public RSA key of server computer 100. RSA encryption is computationally expensive. For reply messages (R2, BI4, LU2, OS2 and CS2) and messages inside a session (CA1, CA2, CA3 and CA4), no additional information, beyond the opaque section contents, is required in the value of opaque label-value pair 4017, thus avoiding the expense of RSA encryption. The opaque section contents varies in length and represents data encrypted with the DES key used.
Trailer 4050 closes sample message 4000. Trailer 4050 preferably includes a transmission checksum. It is preferred that the transmission checksum of field 4050D be an MD5 hash performed on all printable characters in header 4005 and those appearing in body 4010. Thus, all white space, including new-lines, spaces, tabs, carriage returns, etc. are omitted from the checksum hash. In this manner, the correctness of the message transmission can be checked while avoiding sensitivity to gateways or processing that might, for example, change the line terminator sequence or convert tabs to spaces.
Encryption and decryption techniques used in the present invention are now described.
The present invention preferably uses both RSA and DES methods for data encryption and decryption. Such methods are well known in the art. RSA is fully described in U.S. Pat. No. 4,405,829. The present invention preferably relies on 768-bit RSA keys reflecting a balance between concerns relating to security, execution time, and export control. The size of the RSA key may change as high-end computers with fast processing speeds become more prevalent in customer installations and the export requirements are relaxed. As is known to those skilled in the art, other public/private asymmetric key systems (such as Rabin, and ElGamal) could be used in the current invention for authentication purposes.
In the present invention, digital signatures are used to authenticate information. The details of digital signatures are widely discussed in computer security literature. The present invention utilizes two methods for authentication: RSA/MD5 digital signatures and knowledge of shared information (e.g., a salt value and/or a key value).
As mentioned above, the present invention also depends on hashing hashing of data. A has preferably is calculated using the well-known MD5 algorithm which is described in Internet publication RFC 1321, applied to a "synthetic message".
If a label-value pair is specified in a hash input, but is not present in a message, the label and label terminator are preferably omitted from the hash.
IV. Processes of the Present Invention
A. Download And Installation Process 400
During the download and installation process 400 as previously described with respect to FIG. 3A, an RSA public key of server computer 100 is stored in field 215A of customer application data structure 215. Merchant computer 300 obtains a copy of user application software 153 in the same manner as customer user 203 using download and installation process 400. In such case, user application software 153 resides on merchant computer 300 as a component of merchant application software 310 and an RSA public key of server computer 100 is stored in field 315A of merchant application data structure 315.
B. Registration Process 401
FIG. 8 depicts a flow diagram illustrating registration process 401 which begins at step 1201.
At step 1202, customer application software 210 prompts or requests customer user 203 to enter information relating to customer user 203. This information will be included in message R1 sent to server computer 100 and will become part of customer persona 120.1. In the preferred embodiment, customer user 203 enters a preferred language of communication, a currency in which transactions will be processed, a requested persona id, an email address and an autoclose passphrase.
At step 1202A, customer application software 210 generates an RSA public/private key pair for customer computer 200. The RSA public key is stored in field 220C of customer persona data structure 220 (FIG. 5C). The RSA private key is stored in field 220H of customer persona data structure 220 (FIG. 5C).
At step 1203, message R1 is assembled in accordance with message assembly procedure 800, depicted in FIG. 9. Message R1 will be sent from customer computer 200 to server computer 100 and will include the information entered by customer user 203 at step 1202. Message assembly procedure 800 is now described with reference to FIG. 9.
Message assembly procedure 800 begins a step 801. Steps 802A-802B create transparent label-value pairs 4213A-4213D of message R1, shown in FIG. 10A. Steps 802C-813 create opaque label-value pair 4217 of message R1, based upon the opaque section contents of message R1, shown in FIG. 10B. Steps 814-817 assemble header 4205, transparent label-value pairs 4213A-4213D, opaque label-value pair 4217 and trailer 4250 of message R1.
At step 802A, customer application software 210 accesses message template data structure 270 (FIG. 5A) to obtain a list of labels, which, when matched up with associated values, make up transparent label-value pairs 4213A-4213C of message R1. At step 802B, values are associated with each label as follows:
Label-value pair 4213A has the label "transaction". The value of field 4213A is a transaction number, generated by client software 210, which uniquely identifies message R1. The value of label-value pair 4213A allows server computer 100, upon receipt of message R1, (1) to send an associated reply message R2, described later, and (2) to determine if message R1 is a duplicate message (i.e., already received by server computer 100). The value associated with label-value pair 4213A is stored in field 251B of pending persona registration/update persona information record 251 (FIG. 5G).
Label-value pair 4213B has the label "date". The value of label-value pair 4213B indicates the date and time that message R1 was assembled and sent to server computer 100, according to the clock of customer computer 200. The value associated with label-value pair 4213B is stored in field 251C.
Label-value pair 4213C has the label "serverkey". As described below, a DES key/IV pair used by customer computer 200 to encrypt the opaque label-value pair 4217 of message R1 is encrypted using an RSA public key of server computer 100. The value of label-value pair 4213C points to the corresponding RSA private key stored in server private key data structure 160 (FIG. 4A).
Label-value pair 4213D has the label "service-category". The value of label-value pair 4213D is a label which may be used to route message R1 to a processor within server computer 100 that handles messages of a particular service category. This option permits the functions of server computer 100 to be distributed among multiple processors thereby improving capacity of the system.
At step 802C, customer application software 210 uses well known techniques to generate a random 128-bit quantity. It is preferred that the first 64-bits of the quantity so generated be treated as a 56-bit DES key and the second 64-bits be treated as a 64-bit initialization vector ("IV"). The 56-bit DES key is represented as a 64-bit quantity having the least significant bit of each eight bit byte ignored. This 128-bit quantity may be viewed as a DES key/IV pair. The DES key/IV pair is stored in a temporary register.
Next, at step 804, customer application software 210 retrieves the RSA public key for server computer 100 from field 215A of client application data structure 215 (FIG. 5B). As stated previously, the RSA public key for server computer 100 is preferably 768-bits in length. Of course, other length RSA keys may be used. At step 806, the RSA public key retrieved at step 804 is used to encrypt the DES key/IV pair created at step 802.
At step 807, customer application software 210 accesses message template data structure 270 (FIG. 2B) to obtain a list of labels, which, when matched up with associated values, make up the opaque section contents of message R1, shown in FIG. 10B. At step 808, values are associated with each label as follows:
Label-value pair 4217A has the label "type". The value of label-value pair 4217A references a record in message data structure 270 (FIG. 2B) which sets forth the labels of message R1. The value of label-value pair 4217A is obtained from customer application software 210 which generates the label when customer user 203 initiates the registration process.
Label-value pair 4217B has the label "server-date". The value of label-value pair 4217B indicates the date and time message R1 was assembled as measured by customer computer 200's perception of the date of server computer 100's clock.
Label-value pair 4217C has the label "swversion" (software version). The value of label-value pair 4217C indicates the version of customer application software 210 communicating with server computer 100. The value of label-value pair 4217C is obtained from data embedded in customer application software 210. The value associated with label-value pair 4217C is stored in field 25 ID.
Label-value pair 4217D has the label "content-language". The value of label-value pair 4217D indicates a preferred language of communication for customer user 203. The value of label-value pair 4217D is obtained from customer user 203 during registration process 401 at step 1202. The value associated with label-value pair 4217D is stored in field 251E.
Label-value pair 4217E has the label "default-currency". The value of label-value pair 4217E indicates a default currency in which transactions of customer user 203 will be processed, unless changed by customer user 203. The value of label-value pair 4217E is obtained from customer user 203 during registration process 401 at step 1202 of FIG. 8. The value associated with label-value pair 4217E is stored in field 251F.
Label-value pair 4217F has the label "requested-id". The value of label-value pair 4217F indicates the persona id requested by customer user 203. The value of label-value pair 4217E is obtained from customer user 203 during registration process 401 at step 1202 of FIG. 8. The value associated with label-value pair 4217F is stored in field 251G.
Label-value pair 4217G has the label "email". The value of label-value pair 4217G indicates an email address for customer user 203. The value of label-value pair 4217G is obtained from customer user 203 during registration process 401 at step 1202 of FIG. 8. The value associated with label-value pair 4217G is stored in field 251H.
Label-value pair 4217H has the label "agreements". The value of label-value pair 4217H indicates legal agreements which customer user 203 has accepted in order to use the present invention. Legal agreements are presented to customer user 203 at step 1202 of FIG. 8. The value of label-value pair 4217H is generated when an agreement is accepted by customer user 203 and stored in field 220L of customer instrument persona data structure 220 (FIG. 5C).
Label-value pair 4217I has the label "autoclose-passphrase". The value of label-value pair 4217I indicates an autoclose passphrase for customer user 203. The value of label-value pair 4217I is provided by customer user 203 during registration process 401 at step 1202 of FIG. 8. The value associated with label-value pair 4217I is stored in field 220D of customer persona data structure 220 and field 251I of customer pending data structure 250.
Label-value pair 4217J has the label "pubkey". The value of label-value pair 4217J represents the RSA public key for customer persona 120.1 generated by customer application software 210 during registration process 401 at step 1202A of FIG. 8.
Referring again to FIG. 9, at step 810, the digital signature for message R1, represented by label-value pair 4217K of FIG. 10B, is created. Label-value pair 4217K has the label "signature". The value of label-value pair 4217K represents the digital signature of customer persona 120.1. For message R1, the value of label-value pair 4217K is a hash of the printable U.S. ASCII characters in the the label-value pairs 4213A-4213C, and label-value pairs 4217A-4217J in alphabetical order, encrypted with the RSA private key of customer persona 120.1. The RSA private key of customer persona 120.1 is obtained from field 220H (FIG. 5C.)
At step 812A, label-value pair 4217K, created in step 810, is appended to label-value pairs 4217A-4217J. Label-value pairs 4217A-4217K are encrypted with DES key/IV pair stored in the temporary register at step 802C. At step 812B, the result of step 812A is appended to the RSA-encrypted DES key/IV pair created in step 806.
At step 813, data assembled at step 812B is encoded using well known techniques (preferably base-64), completing assembly of the opaque section contents of message R1.
Message R1 is assembled at steps 814-818. At step 814, header 4205 is created using the message template found at customer message template data structure 270 (FIG. 5A) and a protocol number embedded in customer application software 210.
Next, at step 815, transparent label-value pairs 4213A-4213C as described above are appended.
At step 816, opaque label-value pair 4217 is appended. Label-value pair 4217 has the label "opaque" signifying that the value which follows is encrypted data. The value of label-value pair 4217, shown in FIG. 10A, represents the data which was encoded at step 813.
Trailer 4250 is assembled at step 817. The checksum of trailer 4250 is calculated as described above with respect to sample message 4000. Trailer 4250 is added to message R1. At step 818, a copy of message R1 is saved in field 251J.
The assembly of message R1 is now complete. Message assembly process 800 ends at step 819.
Referring again to FIG. 8, registration process 401 continues at step 1204. There, customer computer 200 transmits message R1 to server computer 100. Customer computer 200 waits for a reply message R2 from server computer 100.
At step 1205, server computer 100 receives message R1 from customer computer 200 and unwraps message R1 by executing server message unwrap procedure 900. Server message unwrap procedure 900 is now described with reference to FIGS. 11A and 11B, where it begins at step 901.
At step 901 A, a copy of message R1 is stored in field 140E (FIG. 4L).
At step 902, server software 110 extracts the protocol number from field 4205C of header 4205 of message R1. Next, based upon the protocol number extracted at step 902, server message data structure 150 (FIG. 4A) is accessed to determine the expected format of message R1. The expected format may include message syntax (e.g., permitted end-of-line characters) and message coding (e.g., ASCII or hex). Message R1 is parsed in accordance with the expected format as follows.
At step 903 server computer 100 calculates a checksum using the same data used by customer computer 200 at step 817 of message assembly procedure 800. At step 904, the checksum calculated at step 903 is compared to the checksum 4250D of trailer 4250 of message R1. If the checksums are not equal, message R1 is discarded at step 904A where server message unwrap procedure 900 also terminates.
If the checksums are equal at step 904, processing continues at step 906A where the message is checked to determine if it is appropriate for message unwrap procedure 900. If a message includes a label "serverkey", message unwrap procedure 900 is appropriate. Messages received by server computer 100 for which unwrap procedure 900 is inappropriate will not contain the "serverkey" label but will instead include a label "type" in the transparent part of the message. Such messages will be unwrapped using other procedures as described later. If a message is inappropriate, processing continues at step 906B where the message is diverted to another unwrap procedure. Message R1 is appropriate; therefore, processing continues at step 906C where the value of opaque label-value pair 4217 is decoded.
At step 907, the RSA public key used by customer computer 200 to encrypt the DES key/IV pair at step 806 of message assembly procedure 800 is determined. To do this, server software 110 obtains the value of label-value pair 4213C associated with the label "serverkey". The value of label-value pair 4213C is a pointer to a field in private key data structure 160 which stores the RSA private key component corresponding to the RSA public key used by customer computer 200 at step 806.
At step 909, the RSA private key determined at step 907 is used t |
