Subclass 73	Subclass 74	Subclass 75
Anonymous user system

Payment and transactions in electronic commerce system

6029150

Abstract

A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent. A customer obtains an authenticated quote from a specific merchant, the quote including a specification of goods and a payment amount for those goods. The customer sends to the agent a single communication including a request for payment of the payment amount to the specific merchant and a unique identification of the customer. The agent issues to the customer an authenticated payment advice based only on the single communication and secret shared between the customer and the agent and status information which the agent knows about the merchant and/or the customer. The customer forwards a portion of the payment advice to the specific merchant. The specific merchant provides the goods to the customer in response to receiving the portion of the payment advice.

Claims

What is claimed:

1. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, wherein the quote is verifiable only by the customer;

sending from the customer to the agent in a single authenticated one-pass communication, a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer, in a single one-pass communication electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on (a) the single communication from the customer to the agent, (b) the secret shared between the customer and the agent, and (c) status information which the agent has;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message.

2. A method as in claim 1 wherein the respective secret shared between the customer and the agent is a dynamic secret.

3. A method as in claim 2 wherein the secret shared between the customer and the agent is modified based on a previous transaction between the customer and the agent.

4. A method as in claim 2 wherein the secret shared between the customer and the agent is modified based on information generated by the customer in a previous transaction with the agent.

5. A method as in claim 2 wherein the secret shared between the customer and the agent is modified based on information generated by the agent in a previous transaction between the customer and the agent.

6. A method as in claim 2 wherein the secret shared between the customer and the agent is modified based on information generated by the customer and on information generated by the agent in a previous transaction between the customer and the agent.

7. A method as in claim 1 wherein the payment request message includes customer-generated modification information for the shared secret.

8. A method as in claim 1 wherein the payment advice message includes modification information for the shared secret.

9. A method as in claim 1 wherein the payment request message includes first modification information for the shared secret and wherein the payment advice message includes second modification information for the shared secret.

10. A method as in claim 9 wherein a subsequent transaction between the customer and the merchant uses a new shared secret based on the current shared secret and on the first and second modification information.

11. A method as in claim 1 wherein the quote is authenticated using a key generated for a specific session between the customer and the merchant.

12. A method as in claim 11 wherein the key is generated using a Diffie-Hellman technique.

13. A method as in claim 1 where the payment advice indicates that payment will be made to the specific merchant.

14. A method as in claim 1 where the payment advice indicates that payment has been made to the specific merchant.

15. A method as in claim 1, wherein the payment request message identifies a particular transaction, and wherein the payment advice message identifies the same transaction.

16. A method as in claim 1 wherein the only representation of the goods to the agent is an irreversible unambiguous function of the quote within the payment request message.

17. A method as in claim 1 further comprising the merchant verifying the validity of the received portion of the payment advice message prior to providing the goods to the customer.

18. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

sending to the agent in a single authenticated communication from a customer of the plurality of customers, a payment request message as electronic signals representing a request for payment of a specific amount to a specific merchant and a unique identification of the customer, wherein the authenticated communication is indistinguishable by the agent from a communication which was generated solely by the customer without any customer/merchant interaction; and

the agent issuing a payment advice message based only on: (a) the payment request message, (b) the secret shared between the customer and the agent, and (c) status information which the agent has, the payment advice message bearing a verifiable digital signature of the agent over part of its content.

19. A method as in claim 18 wherein the agent issues the payment advice message to the customer, the method further comprising:

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message.

20. A method as in claim 19 further comprising:

the merchant verifying the validity of the digital signature contained in the received payment advice message portion.

21. A method as in claim 18 where the payment advice message indicates that payment will be made to the specific merchant.

22. A method as in claim 18 where the payment advice message indicates that payment has been made to the specific merchant.

23. A method as in claim 18, wherein the payment request message identifies a particular transaction, and wherein the payment advice message identifies the same transaction.

24. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

receiving at the agent from a customer of the plurality of customers, a single authenticated communication comprising electronic signals representing a payment request message comprising a request for payment of a specific amount to a specific merchant and a unique identifier of the customer, wherein the authenticated communication is indistinguishable by the agent from a communication which was generated solely by the customer without any customer/merchant interaction; and

issuing by the agent to the customer a payment advice message which bears a verifiable digital signature computed over part of its content, the issuing being based only on: (a) the payment request message, (b) the secret shared between the customer and the agent, and (c) status information known by the agent.

25. A method as in claim 24 wherein the agent issues the payment advice message to the customer, the method further comprising:

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing goods to the customer in response to receiving the portion of the payment advice message.

26. A method as in claim 24 where the payment advice indicates that payment will be made to the specific merchant.

27. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent and wherein each customer shares a respective secret between that customer and the agent, the method comprising, at a specific merchant:

forming a session key for a specific session between the customer and the specific merchant;

receiving from a customer electronic signals representing a portion of a payment advice message issued by the agent, the payment advice message indicating that payment will be made to the specific merchant, wherein the payment advice identifies an authenticated quote previously provided by the merchant to the customer, and wherein the quote is verifiable only by the customer; and

providing goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message.

28. A method as in claim 27 further comprising, by a customer:

receiving the electronic signals representing the payment advice message from the agent; and

forwarding electronic signals representing the portion of the payment advice message to the specific merchant.

29. A method as in claim 27 wherein the goods provided are goods specified in the quote.

30. An electronic payment system comprising:

an agent mechanism;

a plurality of merchant mechanisms;

a plurality of customer mechanisms having accounts with the agent mechanism, each customer mechanism sharing a respective secret with the agent mechanism; and

a mechanism constructed and adapted to send in a single authenticated communication to the agent mechanism, from a customer mechanism of the plurality of customer mechanisms, a payment request message as electronic signals representing an identifier for the customer mechanism and a request for payment of a specific amount from the customer mechanism to a specific merchant mechanism of the plurality of merchant mechanisms, wherein the authenticated communication is indistinguishable by the agent from a communication which was generated solely by the customer without any customer/merchant interaction; and

a mechanism constructed and adapted to issue, from the agent mechanism, electronic signals representing an authenticated verifiable payment advice message in response to only: (a) the payment request message received by the agent mechanism, (b) the secret shared between the customer mechanism and the agent, and (c) status information known by the agent mechanism.

31. A system as in claim 30 further comprising:

a mechanism constructed and adapted to forward electronic signals representing a portion of the payment advice from a customer mechanism to a merchant mechanism; and

a mechanism constructed and adapted to provide goods from the merchant mechanism to the customer mechanism in response to receipt of the electronic signals representing the payment advice.

32. An agent mechanism, in an electronic payment system comprising the agent mechanism, a plurality of customer mechanisms and a plurality of merchant mechanisms, the customer mechanisms having accounts with the agent mechanism and each customer mechanism sharing a respective secret with the agent mechanism, the agent mechanism comprising:

a mechanism constructed and adapted to receive, from each customer mechanism of the plurality of customer mechanisms, a payment request message as electronic signals representing a single authenticated communication comprising an identifier for the customer mechanism and a request for payment of a specific amount to a specific merchant mechanism of the plurality of merchant mechanisms, wherein the authenticated communication is indistinguishable by the agent from a communication which was generated solely by the customer mechanism without any customer/merchant interaction; and

a mechanism constructed and adapted to issue electronic signals representing an authenticated verifiable payment advice message in response to only: (a) a received payment message from a customer mechanism by the agent mechanism, (b) the respective secret shared between the customer mechanism and the agent mechanism, and (c) status information known by the agent mechanism.

33. A customer mechanism, in an electronic payment system comprising an agent mechanism, a plurality of customer mechanisms and a plurality of merchant mechanisms, the customer mechanisms having accounts with the agent mechanism and each customer mechanism sharing a respective secret with the agent mechanism, the customer mechanism comprising:

a mechanism constructed and adapted to send a payment request message as electronic signals in a single authenticated communication comprising an identifier for the customer mechanism and a request for payment of a specific amount to a specific merchant mechanism, wherein the authenticated communication is indistinguishable by the agent from a communication which was generated solely by the customer mechanism without any customer/merchant interaction; and

a mechanism constructed and adapted to receive electronic signals representing an authenticated verifiable payment advice issued by the agent mechanism in response to only: (a) a received payment request message from a customer mechanism by the agent mechanism, (b) the secret shared between the customer mechanism and the agent mechanism, and (c) status information known by the agent mechanism.

34. A customer mechanism as in claim 33 further comprising:

a mechanism constructed and adapted to obtain electronic signals representing an authenticated quote from a specific merchant mechanism of the plurality of merchant mechanisms; and

a mechanism constructed and adapted to forward electronic signals representing a portion of the payment advice message to the specific merchant mechanism, the portion of the payment advice message identifying the quote.

35. A customer mechanism as in claim 34, wherein said quote specifies goods, the customer mechanism further comprising:

a mechanism constructed and adapted to receive the specified goods from the specific merchant mechanism.

36. A customer mechanism as in claim 35 further comprising a mechanism constructed and adapted to re-forward the electronic signals representing the portion of the payment advice message to the specific merchant mechanism when the goods are not received from the specific merchant mechanism because of non-receipt of the payment advice message by the merchant mechanism.

37. A merchant mechanism, in an electronic payment system comprising an agent mechanism, a plurality of customer mechanisms and a plurality of merchant mechanisms, the customer mechanisms having accounts with the agent mechanism and each customer mechanism sharing a respective secret with the agent mechanism, the merchant mechanism comprising:

a mechanism constructed and adapted to provide electronic signals representing an authenticated quote to a customer mechanism, the quote specifying goods, wherein the authenticated quote is verifiably only by the customer mechanism; and

a mechanism constructed and adapted to receive electronic signals representing a verifiable portion of a digitally signed payment advice message issued by the agent mechanism in response to only: (a) electronic signals representing a received single communication from a customer mechanism by the agent mechanism, (b) the secret shared between the customer and the agent, and (c) status information known by the agent mechanism.

38. A merchant mechanism as in claim 37, wherein the portion of the payment advice message identifies a function of the goods, the merchant mechanism further comprising:

a provider mechanism constructed and adapted to provide the goods to the customer mechanism in response to receipt of the electronic signals representing the portion of the payment advice message.

39. A merchant mechanism as in claim 38 wherein the provider mechanism provides for authentication and encryption of portions of the goods which comprise electronic signals.

40. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective dynamic secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, the authenticated quote being verifiable only by the customer;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the dynamic secret shared between the customer and the agent and, (c) status information known by the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message.

41. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer, the authenticated quote being verifiable only by the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the secret shared between the customer and the agent, and (c) status information known by the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message, wherein the merchant is unable to associate the origin of this transaction with prior transactions from the same customer.

42. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, the authenticated quote being verifiable only by the customer;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the secret shared between the customer and the agent and (c) status information known by the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message,

wherein transactions cannot be linked to customers by anyone other than the agent.

43. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, the authenticated quote being verifiable only by the customer;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the secret shared between the customer and the agent, and (c) status information known to the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message, whereby

the encrypted session between customer and merchant creates a unique customer/merchant shared secret which acts as the sole authenticated reference for this transaction.

44. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, the authenticated quote being verifiable only by the customer;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the secret shared between the customer and the agent, and (c) status information known to the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message,

wherein the agent issues the payment message without verifying the quote and wherein the customer does not send the full quote to the agent.

45. A method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, the method comprising:

each customer sharing a respective secret between that customer and the agent;

obtaining, by a customer of the plurality of customers, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods, the authenticated quote being verifiable only by the customer;

sending from the customer to the agent a payment request message as electronic signals representing a request for payment of the payment amount to the specific merchant and a unique identification of the customer;

the agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on: (a) the payment request from the customer to the agent, (b) the secret shared between the customer and the agent, and (c) status information known to the agent;

the customer forwarding electronic signals representing a portion of the payment advice message to the specific merchant; and

the specific merchant providing the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message, wherein

the merchant issues the quote verifiable only by the customer.

46. A method as in claim 1 further comprising

generating a session key for a specific session between the customer and the merchant.

47. A method as in claim 46 wherein the key is generated using a Diffie-Hellman technique.

Description

FIELD OF THE INVENTION

This invention relates to electronic commerce, and, more particularly, to a system and method for payment and transactions in an electronic payment system.

BACKGROUND OF THE INVENTION

In rapidly growing numbers, businesses and consumers are moving their routine commercial activities into the electronic marketplace. The growth of electronic networks has given businesses of all sizes unprecedented access to new markets. At the same time, networks reduce the need for market intermediaries and their associated costs. Increased competition among sellers has reduced buyer costs.

Commercial enterprises are developing technologies to take advantage of the electronic marketplace. However, one area that significantly lags others is the development of systems for executing financial transactions of all types across electronic networks.

Financial transactions today take many forms: cash, check, credit card, debit card, automated teller, etc. The nature of the transaction determines which payment system is the method of choice:

Financial Payments ($500K+): Transactions in this range are predominantly payments between financial institutions using electronic systems such as CHIPS, FedWire and SWIFT.

Commercial Payments ($1000 to $500K): These are usually procurement payments between businesses. Since these transactions often require the exchange of documents, e.g., bids and proposals, Electronic Data Interchange (EDI) is commonly used.

Consumer Payments ($20 to $1000): At the higher end of the range, credit cards are generally used. While checks are also used, they have significantly less wide-spread acceptance, particularly among merchants, and are more often used for bill payment. At the lower end of this range, consumers are most likely to use cash. Credit cards are sometimes used as a cash substitute.

Paper Currency Payments ($1 to $20): The vast majority of all financial transactions fall in this range. The primary use of cash is for these payments.

Coin Transactions (under $1): Although the value of each transaction is low, the volume of transactions is high. These transactions are also highly diverse, ranging from buying newspapers to feeding parking meters.

Financial and commercial payments are already handled somewhat adequately by the systems which serve them. While improvements are possible, change is likely to be gradual.

Transactions in the lower range are far less efficient. Consumer payments by credit card are appropriate where an extension of credit is required. However, because a credit card transaction is bundled with numerous supporting services, it is often ineffective as a substitute for cash, particularly for small value transactions.

Cash transactions themselves are highly inefficient. Last year for example, Americans executed 300 billion cash transactions for items costing less than $20. Banks and businesses spend over $60 billion annually to move, secure, and account for these transactions. Growing numbers of consumers feel burdened by the inconvenience and risk in carrying cash. Further, it is currently impossible to use cash in the electronic marketplace.

Low value cash and consumer transactions will likely be the heart of electronic commerce and electronic payment systems currently under development target this market.

While not all cash transactions will migrate to electronic transfer, the development of a global network such as the Internet itself will create many new on-line markets. A merchant will be any vendor who has Internet connectivity and offers goods for sale, whether they are durable goods, or information-based products such as reports and software entertainment. A customer will be anyone who subscribes to the Internet and browses the vendor web sites for information or tangible goods.

This will give rise to a new type of payment transaction called a "micropayment." These payments will be of very low value--fractions of a penny in some cases--but executed in very high volumes. Micropayments will purchase many of the new information-based products. Information utilities must be able to bill in precise increments for such services as information retrieval (search), cataloging, archiving, formatting, reproducing in various media, etc.

The many challenges faced by any electronic payment system include security as the paramount requirement. However, in addition to being secure, the successful electronic payment system must protect individual privacy without impeding legitimate inquiries by law enforcement and government agencies. This requires transactional anonymity with an audit trail. Transactions may also be non-appealable, emulating cash transactions.

Electronic payment systems are based on either a credit or a debit payment model. In the debit model, first an account is funded, then purchases are made by drawing down on those funds. In the credit model, the purchase is made in advance of payment as with a conventional credit card.

Electronic payment systems are either on-line or off-line systems. An on-line system is one where the parties to a transaction are joined through a network to a third party and communicate with this third party (server) during the course of the transaction. When transactions are executed on an on-line system, the server immediately records the transaction and updates various databases. It may also initiate funds movements.

In an off-line system, two parties exchange funds without any communication with a bank or other third party during the transaction. Off-line systems normally require hardware devices such as smartcards to provide adequate security. In order to download value (cash) onto the card, or to make a deposit, the card must be connected in some way to an electronic network to communicate with a bank or automated teller service. Until the device that receives a payment communicates with a bank over the network, the transaction is completely undocumented within the banking system.

At the time of this writing, a collection of proposed payment systems for the Internet included about fifty entries. These existing systems can be categorized into the following types: credit card based systems, electronic check systems, electronic coin systems, stored value cards, on-line payment systems, electronic scrip systems, and debit systems. These systems, including their benefits and disadvantages, are summarized here.

Credit Card Based Systems

There are several electronic payment systems that are essentially existing credit card systems adapted for operation over the Internet. The chief technical challenge they face in porting the functionality of the credit card system to the Internet is to securely obtain or transmit a customer's credit card information. As a way to lower overall transaction costs, some credit card systems accumulate customer charges and merchant payments up to a predetermined threshold before sending them out to processing agents.

All electronic payment systems based on the credit card model benefit from the familiarity and name recognition these franchises have carefully built up over many years of operation.

However, given the average charge of about $0.20 plus 2% to 3% transaction fees, most merchants would prefer to do business using an alternate and cheaper, payment transaction scheme.

Credit electronic payment systems are built around the conventional, bundled service credit card transaction processing systems. In the current environment, the only network transaction for which these electronic payment systems are optimized is a merchandise mail order purchase of significant value. Even with complicated cumulative charge and payment schemes, these systems are too costly and inefficient for the vast proliferation of low-value payments, including micropayments, that will be common to electronic commerce.

The privacy scheme for the credit electronic payment systems, in most cases, is much like conventional credit card systems. Except for withholding credit card numbers, merchants have access to the standard customer information. Some of the systems provide authentication using digital signatures.

Electronic Check Systems

There are electronic payment systems that are analogous to paper checks. An electronic check would typically consist of a document, signed by the payor using a certified digital signature key, which lists the information necessary for processing a paper check such as: the payor, the bank of the payor, the account number of the payor, the payee, the amount of the payment, and the date of the payment. The payee verifies the signature on the electronic check and then sends the electronic check to his bank for processing. The bank processing of an electronic check is essentially the same process as that used for paper checks today.

The advantage of electronic checks is that they take advantage of existing bank clearing processes, which reduces development time. In the basic model of electronic check, the payee would take the risk if the electronic check was not good. However, the merchant or payee would have two possible avenues to reduce his risk in the case of an on-line payment. If the bank was on-line, the payee could obtain approval from the bank that the check was good or he could require that the payor obtain a certified check from a bank.

The downside of electronic checks is their relatively high cost. Although they are expected to be considerably cheaper than the credit card based systems, most developers of electronic check systems expect the cost to be in the $0.10 to $0.50 range per electronic check. Part of this cost is because of the necessity of an ACH (automated clearing house) transaction for each interbank check, which costs about $0.15. Another problem with electronic checks is that they do not provide any privacy for the payor. The payee will know identifying information which is tied to the payor.

Electronic Coin Based Systems

There are numerous proposals for electronic payment systems that use electronic coins of fixed amounts as a means of exchange. A customer makes a withdrawal from his bank account and receives electronic coins from the bank. The customer can then use these coins to pay a merchant. The merchant can check the validity of the coins using cryptographic techniques. Then the merchant can deposit the coins into the bank. Some electronic coin systems can be used with a multitude of banks.

An advantage of electronic coins is that a coin can be validated by cryptographic techniques so a merchant can be convinced that the coin is indeed valid. However, the merchant has no way to determine on his own whether the coin has been spent before. In order to determine this, the coin has to be given to the bank, and the bank has to check to see if that coin has been deposited before. Some systems suggest the use of tamper resistant hardware for storing the coins so that the tamper resistance has to be broken in order for the customer to spend a coin more than once.

There are electronic coin based systems that provide a very high degree of anonymity. Even if the banks and merchants pool their information about transactions, the identity of the payor of a particular transaction cannot be determined. Because this degree of anonymity might not be acceptable by some governments, there are electronic coin payment systems in which the identity of payors can be determined by trustees who could be independent of the banks and merchants.

One problem with some electronic coin systems is that a single payment might require the use of multiple coins in order to add up to the correct value.

Electronic coin systems are designed to be used in off-line systems, but they could be used in an on-line system as well. The merchant could just deposit the coins and receive a confirmation of the validity of the coins before providing merchandise.

Digital cash transactions are much like cash transactions. Payments are immediate and non-appealable.

Regardless of the provisions the issuer makes to protect against lost or damaged tokens, anonymity means the consumer will be vulnerable to loss. To protect against fraud and loss, some electronic coin systems serialize the tokens that they issue. If the consumer cannot produce a record of the serial numbers, or if the tokens have already been redeemed by someone else, the consumer has indeed lost the "cash."

Anonymity imposes additional overhead on issuers because they must retain extensive records of serial numbers for tokens they have issued.

Stored Value Cards

Another approach to electronic payments uses devices that store a value on them. The device has a register in it that keeps an accounting of the amount of money stored in the device. A customer connects with a bank through an ATM or equivalent and withdraws money from his bank account and the value of the withdrawal is added to the register. The customer can authorize a movement of funds from his device to another device in the system. During this process, the value on his device is reduced and the value on the other device is increased by the same amount. In some systems, any device can accept payments, while in other systems only specified devices can accept payments.

An advantage of the stored value approach is that it requires little processing at the bank. Transactions can take place with no involvement from the bank.

A serious problem with stored value devices is the possibility that a customer could fraudulently add value to his device. One method for reducing the risk of this is to limit the scope of acceptability of the devices. For example, a metropolitan transit system may provide cards that can only be used in the transit system. Another method would be to make the devices extremely difficult to break into. However, this still leaves the system vulnerable to attack. If these devices were to become widely used, it could become financially profitable for an attacker to break into one or more devices and place some large amount of value into the device. If there was no method built into the system for detecting and recovering from such an attack, then losses could be huge.

There is another type of electronic payment that is strictly an off-line system using tamper resistant trusted devices. In this system, a device would have a signature key authorized by a bank. By taking the device to an ATM, or through some other communication with the bank, the customer can withdraw money from his bank account and the balance would be placed on the device together with an identifying number that is unique to this particular withdrawal. When the customer wants to pay a merchant, the device would use the signature key to sign an order to pay the merchant for a specified amount, the balance on the customer's device would be debited by that amount, and the balance on the merchant's device would be credited by that amount. There could be a multiplicity of balances on the customer's device.

One problem with this system is that it requires the bank to keep all records corresponding to a particular withdrawal until the entire withdrawal has been accounted for. Since the transactions could go to many merchants, all of these records must be held until all of the merchant's devices have been to an ATM.

Another problem with the system is that if a transaction has gone through several hands, then a receiver has to check all signatures to validate the cash.

A further problem with this system is that the privacy of a transaction is protected only by the security of the trusted device. Therefore, if this system were to be adopted to low value payments with a lower security level on the devices, the privacy could be more easily compromised as well.

Electronic Scrip

Electronic scrip refers to a type of electronic currency which has a merchant identified at the time of issuance of the cash and such that the electronic currency can only be spent with that merchant. When a customer identifies a new merchant that he wishes to pay, or if he runs out of scrip with a previous merchant, he obtains scrip from a broker for some specified total amount that can be divided into discrete pieces to pay that particular merchant. The payment to the broker for the scrip could involve another type of electronic payment. The customer can then make payments to the specified merchant until the total is reached or until the customer does not want to make any more payments to that merchant during the current time period, for instance a day. The merchant must deposit the scrip with the broker. The broker then pays the merchant through some other payment mechanism.

Because this system uses some other electronic payment system for the customer to purchase scrip from the broker and for the broker to pay the merchant for redeemed scrip, it will only be beneficial in instances in which a customer has many transactions with a single merchant. In these cases, it is more efficient than other electronic payment systems, because of the reduced computational complexity that is required for a scrip payment.

Debit Systems

Debit systems rely on the existing infrastructure of highly efficient ACHs and ATMs for initial funding. Therefore, they have relatively lower transaction costs as compared to credit systems. Typically, an ATM transaction costs $0.50, or less, and an ACH transaction costs less than $0.15. Only a single transaction is needed to fund an account.

Debit systems execute payment transactions by exchanging electronic tokens. These tokens are digitally signed by a participating bank and delivered to the consumer in exchange for a debit to the consumers checking account. The debited funds are held in an escrow account, so that the amount of digital cash or tokens issued is backed by an equivalent amount of cash.

Debit systems today generally use stronger security and authentication techniques than credit systems. Debit systems may employ public key cryptography schemes for security and a variety of digital signature algorithms for authentication. This level of security allows debit systems to operate freely over open unsecured networks.

Debit systems are an attractive alternative to cash for many reasons. Transactions will occur faster because there is no need to wait for change. Debit systems eliminate the operational costs of handling cash. They improve security and reduce losses because businesses are able to transmit value to their bank at any time instead of having to wait for business hours to deposit cash.

In addition, a key feature of the debit system is anonymity. However, only the payer receives complete anonymity. The payee can always be traced.

It is generally believed that governments and law enforcement agencies will not accept security schemes that do not make provision for a so-called back door. Moreover, it is not clear that customers prefer complete anonymity in place of personalized contact with a merchant and protection against loss. The latter is only possible if records of tokens issued to consumers are kept on file.

Common to all off-line debit systems is the use of proprietary, special purpose hardware, including smartcards and the accompanying readers, wallets and smart phones. Smartcards offer an added degree of freedom in dispensing with cash. A one-on-one transaction can be completed without a computer link provided the necessary hardware is available.

Problems with Existing Proposed Solutions

None of these existing or proposed electronic payment systems provide for payment that is non-appealable, does not need extensive records, is relatively anonymous for the consumer, and has low enough processing cost so that it can adequately deal with micro-payments to individual merchants. As noted, micro-payments are very low-value payments that are likely to occur in high volumes on digital communication networks. For example, on a network such as the Internet, merchants such as stock brokers may wish to sell stock quotes at $0.01 per quote. While the cost per sale item is very low, the number of items sold per day may be very high.

With credit card or check-based payment systems, the recipient and/or the system must assume some credit risk, since the buyer can repudiate or simply become unable to pay. The associated insurance component necessarily raises the cost of the payment service. Consumer anonymity is desirable in view of fears expressed by privacy advocates and others that in the future, it will become possible to collect and analyze huge amounts of data concerning every purchase or road toll payment a person makes, thereby creating potential privacy problems.

A problem with payment systems that make an instantaneous payment to merchants is that if a fraudulent merchant is accepting many fraudulent transactions, he might not be detected until he had already received much money.

For these and other reasons, it is desirable to provide a payment system that is non-appealable, does not need extensive records, is relatively anonymous for the consumer, and would adequately deal with micropayments to individual merchants.

Other desirable aspects of a payment system include high performance, low cost, minimum maintenance, easy scaleabiliy according to volume, significant security with moderated anonymity and strong authentication, standards-based and open architecture and adaptability for anomaly detection for detection of fraud.

SUMMARY OF THE INVENTION

This invention relates to an electronic commerce and transaction system, its components and methods for their use.

In one aspect, the invention is a method of payment in an electronic commerce system wherein customers have accounts with an agent and where each customer shares a respective secret between that customer and the agent. This secret is set up prior to the actual transaction or payment and, in preferred embodiments, is a dynamic secret.

According to the method of this invention, a customer obtains an authenticated quote from a specific merchant, the quote including a specification of goods and a payment amount for those goods. The customer then sends to the agent, in a single authenticated one-pass communication, a payment request message representing a request for payment of the payment amount to the specific merchant along with a unique identification of the customer. The agent, after processing the payment request, issues and sends to the customer, in a single one-pass communication, an authenticated verifiable payment advice message. The issuing by the agent is based only on:

the single communication from the customer to the agent,

the secret shared between the customer and the agent and

non-cryptographic customer information ("customer status information") and/or non-cryptographic merchant information ("merchant status information") which the agent has.

The customer and merchant status information are referred to collectively herein as "status information."

Upon receipt of the payment advice message, the customer forwards a portion of the payment advice message to the merchant. The merchant then provides the goods to the customer in response to receiving the portion of the payment advice message.

The payment advice indicates that payment has or will be made to the specific merchant.

In preferred embodiments of the invention the secret shared between the customer and the agent is a dynamic secret which changes per transaction based on a previous transaction between the customer and the agent. Preferably the secret is modified based on information generated by the customer in a previous transaction with the merchant. The modification information could be generated by the customer, the agent or both and is provided from the customer to the agent in the payment request message and from the agent to the customer in the payment advice message.

The shared secret is modified based on the current shared secret and on the modification information sent from the customer to the agent and from the agent to the customer. If the agent rejects the customer's payment advice request, the shared secret may still be updated. The choice of whether or not to update the shared secret depends on other implementation choices and on why the request was rejected.

In another aspect, the customer and the merchant generate a specific session key per transaction and the quote from the merchant is authenticated using this key. Preferably the key is generated using a Diffie-Hellman technique.

The goods can be digital goods (which can be supplied electronically) or they can be any other form of goods, including pre-approved financial transactions. Preferably the only representation of the goods to the agent is an irreversible unambiguous function of the quote within the payment request message. By an "unambiguous" function is meant one such that it is computationally infeasible to determine two different inputs to the function that will produce the same output value of the function. By an "irreversible" function is meant one such that given an output of the function it is computationally infeasible to find an input that produced that output.

Using an unambiguous function of the quote prevents a customer or a merchant from having two quotes with the same function value. Using an irreversible function of the quote means that the actual quotes cannot be obtained from the agent, thereby enhancing privacy.

In preferred embodiments the merchant verifies the validity of the received portion of the payment advice message prior to providing the goods to the customer.

In another aspect, this invention is a method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent, each customer sharing a respective secret between that customer and the agent. The customer sends to the agent, in a single authenticated communication, a payment request message for payment of a specific amount to a specific merchant, along with a unique identification of the customer. The agent issues a payment advice message to the customer based only on the payment request message, the secret shared between the customer and the agent and the customer and merchant status information, the payment advice message bearing a verifiable digital signature of the agent over part of its content.

The customer then forwards a portion of the payment advice message to the specific merchant who then provides goods to the customer in response to receiving the portion of the payment advice message. The merchant can verify the validity of the digital signature contained in the received payment advice message portion.

In another aspect, this invention is a method of achieving payment in an electronic payment system wherein a plurality of customers have accounts with an agent and wherein each customer shares a respective secret between that customer and the agent. The invention includes the steps of, by the agent, receiving from a customer a single authenticated communication representing a payment request message. The payment request message includes a request for payment of a specific amount to a specific merchant as well as a unique identifier of the customer. The agent then issues to the customer a payment advice message which bears a verifiable digital signature computed over part of its content, the issuing by the agent being based only on the payment request message, the secret shared between the customer and the agent and on the customer and/or merchant payment information.

In another aspect, the method includes, at a specific merchant, receiving from a customer a portion of a payment advice message issued by the agent, where the payment advice message indicates that payment will be made to the specific merchant, and then the merchant providing goods to the customer in response to receiving the portion of the payment advice message.

In some preferred embodiments the payment advice identifies a quote previously provided by the merchant to the customer, and the goods provided are goods specified in the quote.

In another aspect, this invention is an electronic payment system including an agent, a plurality of merchants, and a plurality of customers having accounts with the agent, where each customer shares a respective secret with the agent. The system includes a mechanism constructed and adapted to send from a customer, in a single authenticated communication to the agent, a payment request message representing an identifier for the customer and a request for payment of a specific amount from the customer to a specific merchant. The system also includes a mechanism constructed and adapted to issue, from the agent to the customer, an authenticated verifiable payment advice message in response to only the payment request message received by the agent, the secret shared between the customer and the agent and customer and/or merchant status information known by the agent.

In some embodiments the system includes a mechanism constructed and adapted to forward a portion of the payment advice from a customer to a merchant and a mechanism constructed and adapted to provide goods from the merchant to the customer in response to receipt of the payment advice.

In yet another aspect, this invention is an agent in an electronic payment system comprising the agent, a plurality of customers and a plurality of merchants, the customers having accounts with the agent and each customer sharing a respective secret with the agent. The agent has a mechanism constructed and adapted to receive, from each customer, a payment request message representing a single authenticated communication comprising along with an identifier for the customer and a request for payment of a specific amount to a specific merchant. The agent also has a mechanism constructed and adapted to issue an authenticated verifiable payment advice message in response to only a received payment message from a customer by the agent, the respective secret shared between the customer and the agent and customer and/or merchant status information known by the agent.

In yet another aspect, this invention is a customer, in an electronic payment system comprising an agent, a plurality of customers and a plurality of merchants, the customers having accounts with the agent and each customer sharing a respective secret with the agent. The customer has a mechanism constructed and adapted to send a payment request message in a single authenticated communication comprising an identifier for the customer and a request for payment of a specific amount to a specific merchant of the plurality of merchants. The customer also has a mechanism constructed and adapted to receive an authenticated verifiable payment advice issued by the agent in response to only a received payment request message from a customer by the agent, the secret shared between the customer and the agent and customer and/or merchant status information known by the agent.

In some embodiments, the customer also has a mechanism constructed and adapted to obtain an authenticated quote from a specific merchant of the plurality of merchants and a mechanism constructed and adapted to forward a portion of the payment advice message to the specific merchant, where the portion of the payment advice message identifies the quote.

In some embodiments the quote specifies goods and the customer includes a mechanism constructed and adapted to receive the specified goods from the specific merchant. In some embodiments, the customer also has a mechanism constructed and adapted to re-forward the portion of the payment advice message to the specific merchant when the goods are not received from the specific merchant because of non-receipt of the payment advice message by the merchant.

In yet another aspect, this invention is a merchant in an electronic payment system comprising an agent, a plurality of customers and a plurality of merchants, the customers each having accounts with the agent and each customer sharing a respective secret with the agent.

The merchant has a mechanism constructed and adapted to provide an authenticated quote to a customer, the quote specifying goods. The merchant also has a mechanism constructed and adapted to receive a verifiable portion of a digitally signed payment advice message issued by the agent in response to only electronic signals representing a received single communication from a customer by the agent, to the secret shared between the customer and the agent and to customer and/or merchant status information known by the agent.

In some embodiments the portion of the payment advice message identifies a function of the goods, and the merchant also has a provider mechanism constructed and adapted to provide the goods to the customer in response to receipt of the portion of the payment advice message.

The provider mechanism can provide for authentication and encryption of portions of the goods which comprise electronic signals.

In another aspect, this invention is a method of payment in an electronic payment system wherein a plurality of customers have accounts with an agent. Each customer shares a respective dynamic secret between that customer and the agent. The method includes obtaining, by a customer, electronic signals representing an authenticated quote from a specific merchant of a plurality of merchants, the quote including a specification of goods and a payment amount for those goods. The customer then sends to the agent a payment request message for payment of the payment amount to the specific merchant and a unique identification of the customer. The agent issuing and sending to the customer electronic signals representing an authenticated verifiable payment advice message, the issuing being based only on the payment request from the customer to the agent and on the dynamic secret shared between the customer and the agent. The customer forwards a portion of the payment advice message to the specific merchant and then the merchant provides the goods to the customer in response to receiving the electronic signals representing the portion of the payment advice message.

In another aspect of this invention, a merchant is unable to associate the origin of any particular transaction with prior transactions from the same customer. This is because the merchant is not provided with information which would enable such an association to be made.

In yet another aspect of this invention, transactions cannot be linked to customers by anyone other than the agent.

In a further aspect, the encrypted session between customer and merchant creates a unique customer/merchant shared secret which acts as the sole authenticated reference for the current transaction.

In still a further aspect, the agent issues the payment message without verifying the quote and the customer does not send the full quote to the agent.

In yet another aspect of this invention, the merchant issues the quote verifiable only by the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which the reference characters refer to like parts throughout and in which:

FIG. 1 shows an overview of an electronic commerce system according to the present invention;

FIG. 2 depicts a flowchart of the operation of the system of FIG. 1;

FIG. 3 is a more detailed depiction of a customer of the system of FIG. 1;

FIGS. 4A-4K depict fields in the customer's database;

FIG. 5 is a more detailed depiction of a merchant of the system of FIG. 1;

FIGS. 6A-6C depict fields in the merchant's database; and

FIGS. 7A-7N, 7P and 7Q depict messages passed between parties in the system during its operation.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS

I. Symbols and Nomenclature

The following symbols and nomenclature are used herein.

    ______________________________________
    .sym.       Denotes the logical exclusive-or operator
    .parallel.  Denotes the bit string concatenation
                operator
    .about.     Denotes the logical complement operator
                ( "ones complement" )
    SHA(message)
                Denotes the 160-bit result of applying
                the (revised) Secure Hash Algorithm, SHA-
                1, to "message". The SHA algorithm is
                defined in Federal Information Processing
                Standards (FIPS) Pub. 180 and FIPS Pub.
                180-1, the contents of which are hereby
                incorporated herein by reference.
    DSA(X,Y)    Denotes Y's DSA signature on the message
                X.
    DSAs(X,Y)   Denotes the `s` portion of DSA(X,Y),
                where computation of DSA(X,Y) includes
                computation of SHA(X). The DSA algorithm
                is defined in FIPS 186, the contents of
                which are hereby incorporated herein by
                reference.
    DSAr(X,Y)   Denotes the `r` portion of DSA(X,Y)
    Bits(X,O,L) Denotes the string of L consecutive bits
                at offset O from the start of X
    X.sub.CTA   Denotes the Diffie-Hellman private key
                (exponent) of the CTA 102
    X.sub.MERCHANT
                Denotes the Diffie-Hellman private key
                (exponent) of some merchant
    Y.sub.MERCHANT
                Denotes the Diffie-Hellman public key
                component of some merchant
    Y.sub.CTA   Denotes the Diffie-Hellman public key
                component of the CTA 102
    ______________________________________

II. Overview

A. Components of the System

An embodiment of the present invention is described with reference to FIG. 1 wherein an electronic commerce system 100 consists of one or more customer transfer applications (CTAs) 102 connectable to customer network software 104 via communications channels 106 which need not be secure. Customer network software 104 is associated with a customer C. In preferred embodiments the system 100 operates on a global computer network such as the Internet and the customer network software 104 is, for example, built into a customer's Internet access/browsing software.

Each customer has a bank 108, to which the CTA 102 is connectable via some standard mechanism such as an automated clearing house (ACH).

Customer network software 104 can also interact with a merchant M via merchant network server (MNS) 110. Interaction between customer C and merchant M, that is, between customer network software 104 and merchant network server 110, is performed via a communications channel 112 which may be insecure.

Merchant M is connectable to merchant clearing corporation (MCC) 114 via a possibly insecure channel 116. The CTA 102 is also connectable to MCC 114.

Merchant M has a bank 118 with which either the MCC 114 or the MCC's designated bank interacts via traditional financial networks 120. The merchant's bank 116 and the customer's bank 108 can be the same bank. The merchant M has an account with the MCC 114. The MCC 114 may designate accounts at one or more banks through which to execute payments to merchant banks 118 and/or to receive payments from customer banks 108, and/or there may be multiple MCCs 114. There may be multiple CTAs 102.

Preferably the CTA 102 is made up of a group of dedicated processors at a secure location. The CTA 102 executes electronic payments from customers to merchants within the system 100, as well as providing customer services such as database searches, records and customer receipts and allocation and/or collection of fees. The CTA 102 may designate an account at one or more banks through which to receive fees from customer banks 108.

The MCC 114, like the CTA 102, is preferably made up of a group of dedicated processors at a secure location. The MCC 114 collects and disperses funds due to merchants, possibly through the MCC's designated bank. The CTA 102 and the MCC 114 are not necessarily autonomous and may share accounts at designated banks.

B. The System Protocol

The electronic transfer system 100 operates according to the following protocol (described with reference to FIGS. 1 and 2) which defines the electronic exchange of messages which effect a payment within the system.

First, in order to access the electronic transfer system 100, a customer C must subscribe to the service and establish an account within a particular CTA 102. This customer account must typically be funded before purchases can be made, for example through ATM 122, although actual funding is outside the scope of the payment system. The customer's bank 108 and the CTA 102 negotiate the availability of funds with respect to customer transactions within the payment system. The customer's bank 108 may send opening balances to the CTA 102 on some regular basis. The customer setup process is described in more detail below.

Having established an account with the system 100, a customer C shops with various merchants over electronic networks such as the Internet using the customer's existing software such as desktop Internet browser software and the like (step S202). A payment sequence begins after the customer C has selected goods for purchase from a merchant M. The merchant's network server 110 sends a digital message, quote 126, to the customer network software 104 which identifies the goods to be purchased and quotes the price for those goods to the customer (step S204). The customer must confirm the desire to execute a payment in the amount quoted in quote 126. This confirmation by the customer triggers the transmission of a digital payment request message 128 from the customer network software 104 to the customer's designated CTA 102 (step S206).

In response to receipt of the customer's digital payment request message 128 (step S208), the CTA 102 processes the request and, if the request is acceptable, executes an "intent to transfer" of funds from the customer C's account to the merchant M's MCC account (step S210). This intent to transfer has the characteristics of an exchange of cash in that it is instantaneous, final and non-appealable. The CTA 102 may perform certain checks during the process which may include a check that the CTA 102 has not been apprised that the designated merchant is not currently in good standing. At some point an actual transfer of funds is executed from the customer's bank 108 to the MCC 114 possibly into an account held by the MCC 114 at a designated bank. These fund transfers may be batched over multiple transactions per customer account and over multiple customer accounts for reasons of efficiency. The customer's bank 108 initiates these funds transfers in response to detailed records and transfer requests it receives from the CTA 102. In a similar manner the MCC 114 may transfer refunds from a merchant's bank 118 to a customer's bank 108.

The CTA 102 returns to the customer network software 104 an authenticated digital payment advice 130 confirming the intent to transfer of funds (step S212). In preferred embodiments, upon receipt of this authenticated digital payment advice 130 by C's customer network software 104 (step S214), the authenticated digital payment advice 130 is automatically forwarded from the customer network software 104 to the merchant's MNS 112 (step S214). The customer can and should also retain a copy of the authenticated digital payment advice 130 for proof of transaction. With respect to record checking and reconciliation of accounts, in the currently preferred embodiment data distinct from the payment advice is actually used to authenticate the transaction status from the CTA 102 to the customer network software 104.

Because the advice is created only after a successful intent to transfer of funds by the CTA 102 (from the customer's CTA account to the merchant's MCC account), a merchant is assured that an authenticated payment advice which the merchant successfully verifies represents a real payment into the merchant's system account. Accordingly, once an authenticated payment advice 130 is received and successfully verified by MNS 112 (step S216), the merchant M is then responsible for providing to the customer C (step S218) the goods or services 132 indicated in the original quote 126 (step S204).

The goods and services 132 can be anything that can be arranged for sale over a network such as the Internet. In one application, the goods and services 132 will be very low-cost items for which micropayments will be made. For example, the goods and services 132 could include a page of text, a digital image, digital sound, access to an on-line search mechanism and the like. Digital goods are deliverable over the Internet, while hard goods are delivered via conventional means to an address which was possibly indicated to the merchant by the customer during the quote consideration process.

Payment records are forwarded routinely (e.g., daily) from the CTA 102 to the Merchant Clearing Corporation (MCC) 114 which provides a clearinghouse to manage merchant accounts. Merchants periodically receive the proceeds of all system payments by direct deposit from the MCC 114, or through an intermediary such as a bank designated by the MCC 114, into an account at a bank of their choice (merchant's bank 118).

III. Detailed Description of System Components

A. Description of Customer

Customer C is described in more detail with reference to FIG. 3. As noted above, customer C has customer network software 104 which is connectable to a network such as the Internet. Preferably that customer network software 104 is implemented as an applet (customer applet) in the customer's network browsing application.

1. Customer Network Software Database

The customer network software 104 maintains a local database 136, the primary function of which is to permit the customer to reconcile his records with those of the CTA 102. The database 136 is organized according to a relational model and contains the following tables (each table is described in detail below):

    ______________________________________
    1                Transactions 138
    2                Quotes 140
    3                Merchants 142
    4                Payment Advices 144
    5                Payment Requests 146
    6                Service Requests 148
    7                Shipping Advices 150
    8                Goods 152
    9                Pending 154
    10               States 156
    11               Errors 158
    ______________________________________

The customer network software 104 also maintains local operating parameters 160 which are also described in detail below.

The Transactions table 138 provides a short synopsis of every transaction which includes the CTA 102 that may affect the customer's balance. Each row in the table contains the following fields (FIG. 4A):

    ______________________________________
    PCSEQUENCE sequence number assigned by the
               customer network software 104
    CTRANS     customer transaction number.
    TRANSTYPE  type of transaction (explained
               below), one of "PMT", "REF",
               "FUNDING", "EVIDENCE", "STATEMENT".
    MID        merchant identifier if applicable,
               otherwise zero.
    MTRANS     merchant transaction identifier if
               applicable, otherwise zero.
    DATE       date of transaction.
    TIME       time of transaction.
    AMCUNT     amount of transaction.
    BALANCE    balance of the customer's account
               after the transaction.
    ______________________________________

The PCSEQUENCE field of the Transactions table 138 uniquely identifies the transaction to the customer network software 104. CTRANS is shared between the customer network software 104 and the CTA 102. The same value of CTRANS may appear in multiple rows in the Transactions table 138, for example, in cases where the CTA 102 does not increment the value of CTRANS.

The Quotes table 140 (FIG. 4B) stores the merchant quote for every item the customer has chosen to buy using his system account. Each row in the Quotes table 140 contains the following fields:

    ______________________________________
    MID           merchant identifier if applicable,
                  otherwise zero.
    MTRANS        merchant transaction identifier if
                  applicable, otherwise zerq.
    QUOTE         the complete text of the quote as
                  prepared by the merchant.
    RETAIN160     a 160-bit segment of the Diffie-
                  Hellman payment transaction key
                  shared between the merchant and
                  customer.
    PI NUMBER     a counter value which indicates the
                  number of times Previous Transaction
                  Mode has been executed with respect
                  to this transaction
    ______________________________________

The Merchants table 142 (FIG. 4C) stores information about merchants from whom the customer has bought goods with his system account. Each row in the table contains the following fields:

    ______________________________________
    MID            merchant identifier if applicable,
                   otherwise zera.
    MNAME          merchant name.
    MADDR1         merchant address line 1.
    MADDR2         merchant address line 2.
    MADDR3         merchant address line 3.
    ______________________________________

The Payment Advices table 144 (FIG. 4D) stores the complete text of every merchant's payment advice message transmitted from CTA 102 to a merchant M through the customer's computer. Each row in the Payment Advices table 144 contains the following fields:

    ______________________________________
    CTRANS          customer transaction number.
    MID             merchant identifier if
                    applicable, otherwise zero.
    MTRANS          merchant transaction identifier
                    if applicable, otherwise zero.
    PADVICE         the complete text of the
                    merchant's payment advice
                    message.
    ______________________________________

The Payment Requests table 146 (FIG. 4E) temporarily stores the complete text of the last payment request message transmitted to the CTA 102 from the customer C. The Payment Requests table 146 exists only so that a payment request message may be retransmitted to the CTA 102 in the event of communications or system failure. As soon as the response to a request message is successfully received or the final allowed request attempt has failed, the single row of this table 146 is overwritten. The single row of the Payment Request Table 146 contains the following fields:

    ______________________________________
    CTRANS         customer transaction number.
    PREQUEST       the complete text of the payment
                   request message.
    ______________________________________

The Service Requests table 148 (FIG. 4F) temporarily stores the complete text of the last service request message transmitted to the CTA 102. Like the Payment Requests Table 146, the Service Requests table 148 exists only so that a service request message may be retransmitted to the CTA 102 in the event of communications or system failure. As soon as the response to a service request message is successfully received or the final allowed service request attempt has failed, the single row of this table is overwritten. The single row of the Service Requests Table 146 contains the following fields:

    ______________________________________
    CTRANS         customer transaction number.
    SREQUEST       the complete text of the service
                   request message.
    ______________________________________

The Shipping Advices table 150 (FIG. 4G) stores the complete text of every shipping advice transmitted from a merchant to the customer C. Each row in the Shipping Advices table 150 contains the following fields:

    ______________________________________
    CTRANS          customer transaction number.
    MID             merchant identifier if
                    applicable, otherwise zero.
    MTRANS          merchant transaction identifier
                    if applicable, otherwise zero.
    SADVICE         the complete text of the
                    shipping advice.
    ______________________________________

The Goods table 152 (FIG. 4H) stores information about every purchase of electronic goods made by the customer C. The Goods table 152 does not store information about pending non-electronic goods shipments. The Goods table 152 is used in conjunction with the shipping advice to insure that the customer receives the goods for which he has paid. Each row in the Goods table 152 contains the following fields:

    ______________________________________
    CTRANS        customer transaction number.
    FILENAME      name of the file to contain the
                  electronic goods on the customer's
                  computer.
    CHUNKS        segments required to transmit the
                  goods from merchant to customer.
    LAST          last segment transmitted successfully
                  from merchant to customer.
    ______________________________________

The Pending table 154 (FIG. 4I) stores information about statements, refunds, funding information and external evidence (described below) that have been requested by the customer C but have not yet been received. These transactions are described below. In addition, some quantities related to the pay/service request CTA-customer Diffie-Hellman session key and the merchant-customer Diffie-Hellman session key must also be held temporarily in the Pending table 154. The Pending table 154 contains the following fields:

    ______________________________________
    CTRANS         customer transaction number
    DELIVERED      Boolean indication of whether or
                   not the information has been
                   received.
    MAGICNO        unique number assigned by the
                   CTA 102 to this request for
                   information.
    DECRYPTKEY     a forty-bit key used in a bulk
                   cipher algorithm to decrypt the
                   data.
    AUTHKEY        a 320-bit key used to verify the
                   authenticity of the received
                   information.
    CTABITS1       160 bits of the CTA's Diffie-
                   Hellman session key starting at
                   bit 448.
    CTABITS2       160 bits of CTA's Diffie-Hellman
                   session key starting at bit 608.
    MERBITS1       160 bits of the merchant's
                   Diffie-Hellman session key
                   starting at bit 320.
    MERBITS2       160 bits of the merchant's
                   Diffie-Hellman session key
                   starting at bit 480.
    MERBITS3       40 bits of the merchant's
                   Diffie-Hellman session key
                   starting at bit 640.
    ______________________________________

Because of the sensitive nature of the CTA and merchant Diffie-Hellman session keys, the five fields above which are derived from these keys (CTABITS1-2 and MERBITS1-3) should be overwritten at the earliest moment at which they are no longer needed.

The State table 156 (FIG. 4J) stores information about the current state of every pending transaction. It is used for recovery in the event that a transaction is not completed in one session. Each row in the State table 156 contains the following fields:

    ______________________________________
    CTRANS          customer transaction number.
    ADD             a quantity that is used to
                    adjust the PIN transmitted to
                    the CTA 102.
    RANDOM          a quantity that adjusts ADD.
    RETRANS         the number of retransmissions
                    left until the current
                    transaction is aborted.
    NEXTTRANS       the number to be assigned to the
                    next transaction, initially one.
    STATE           the most recent transaction
                    state.
    STATUS          the Boolean status of a
                    transactionwithin a state.
    TEXT            free form text assbciated with
                    the state.
    ______________________________________

The transaction states are predefined as follows:

    ______________________________________
    State
    Value   Meaning
    ______________________________________
    10      customer confirms the purchase
    20      merchany authenticated by customer's computer
    30      customer computer composed payment request
    40      customer computer sent payment request to CTA 102
    50      payment advice sent by the CTA 102 to the customer
            computer
    60      customer computer sends payment advice to merchant
    70      merchant responds with a shipping advice
    80      merchant begins sending electronic goods to
            customer computer
    90      transaction completed
    100     transaction aborted
    ______________________________________

The Errors table 158 (FIG. 4K) stores information about errors that may have occurred while processing transactions. Each row in the Errors table 158 contains the following fields:

    ______________________________________
    CTRANS       customer transaction number if applicable,
                 otherwise zero.
    DATE         date of error.
    TIME         time of error.
    SEVERITY     severity of the error.
    MSGNUM       unique number assigned to the error.
    MSGTEXT      text associated with the error.
    Possible SEYERITY codes are:
    F            fatal, the session is aborted;
    E            error, the transaction is aborted;
    W            warning; and
    I            informational.
    ______________________________________

Certain of these tables in the customer's local database 136 contain sensitive data and may be encrypted. If necessary a forty-bit cryptographic key may be embedded into the customer network software 104 executable at setup time. This key and a weak bulk cipher encryption algorithm may be used to inhibit snooping of the customer local database 136 and other customer information, e.g., operating parameters 160.

B. Description of a Merchant

Merchant M is described in more detail with reference to FIG. 5. As noted above, merchant M has a merchant network server 110 which is connectable to a network such as the Internet.

1. Merchant Network Server Database

The merchant network server 110 maintains a local database 162 organized according to a relational model. The merchant's local database 162 contains the following tables:

    ______________________________________
    1                Quotes 164
    2                Addresses 166
    3                Payment Advices 167
    ______________________________________

The Quotes table 164 stores the merchant quote for every item a customer has chosen to buy using his account. Each row in the Quotes table 164 (FIG. 6A) contains the following fields:

    ______________________________________
    MTRANS      merchant transaction identifier.
    QUOTE       the complete text of the quote as
                prepared by the merchant.
    RETAIN160   a 160-bit segment of the Diffie-
                Hellman payment transaction key, D-H
                Key.sub.MERCHANT, shared between the merchant
                and customer.
    PI NUMBER   a counter value which indicates the
                highest-valued countersetting within
                an intact execution of Previous
                Transaction Mode with respect to this
                transaction.
    ______________________________________

In addition, Bits (D-H Key.sub.MERCHANT, 320, 360), that is, the string of 360 consecutive bits of D-H Key.sub.MERCHANT, starting at offset 320, are saved until the conclusion of processing of a transaction.

The Addresses table 166 (FIG. 6B) stores name and address information for every transaction for which the merchant requires that the customer reveal his identity. The Address table 166 contains the following fields:

    ______________________________________
           CUSTNAME customer name
           CUSTADDR1 customer address, line 1.
           CUSTADDR2 customer address, line 2.
           CUSTADDR3 customer address, line 3.
    ______________________________________

The Payment Advices Table 167 (FIG. 6C) stores merchant transaction identifier and merchant's payment advice message information for every transaction for which a valid merchant's payment advice message has been received. For this purpose a merchant's payment advice message is valid if it can be proved to have been authenticated by the CTA and intended for that merchant, independent of the other contents of the message. This table is optional in the sense that its entries would only be used for potential dispute resolution.

The merchant network server 110 also maintains local operating parameters 168 which are also described in detail below.

C. The CTA Databases

The CTA 102 maintains a number of databases with customer account information. In particular, the CTA maintains for each customer, based on the customer's system account number, the number of the last transaction for that customer and the value of PIN* for the customer.

IV. Version Control

Each executable component which participates in transactions, including the customer network software 104 and the merchant network server 110, has an embedded version number. Every message transmitted between executable components contains both the software version of the sender and the oldest version of the receiver with which it is compatible. It is the responsibility of the receiver to compare its version against that in the message. Upon receipt of an unacceptable message the receiver responds with an incompatible version message.

V. Cross Platform Note

Executable components that participate in system transactions run on hardware from many different manufacturers. In order easily to accommodate the differences every message transmitted from one component to another will be encoded in Base64 format by the sender. This encoding scheme translates all data to seven bit ASCII characters. On the World Wide Web, a content encoding type is intentionally not specified. In all cases it is the responsibility of the receiving component, rather than an associated Web browser to decode the message.

In some embodiments, messages are encoded with one extra byte per element so as to ensure that every string in a message is terminated with a null byte.

VI. Assumptions

Messages transmitted between customer network software 104 and the CTA 102 are authenticated by means of a Diffie-Hellman key exchange mechanism. Messages exchanged between customer network software 104 and merchants are authenticated by the same kind of Diffie-Hellman key exchange as is used between the customer and the CTA 102.

The merchant network server 110 uses a fixed Diffie-Hellman public key component.

The Diffie-Hellman system parameters, p and g described below, are the same for exchanges between customer and merchant and between customer and CTA 102.

The CTA 102 uses a fixed Diffie-Hellman public key component. The customer network software 104 uses a randomly generated exponent and Diffie-Hellman public key component pair which is used within a single transaction.

The randomly generated Diffie-Hellman exponent and public key component pair used by the customer network software 104 to communicate with the merchant is the same as that used to communicate with the CTA 102 for the same transaction. This dual use of the exponent is for efficiency only and should be considered optional.

As stated in the Digital Signature Standard FIPS document, DSA parameters can be generated in such a way as to allow mutually distrustful entities to check that the system parameters were not generated in a way which would allow the party who generated the parameters some advantage, with respect to cryptanalysis, over the other users of those parameters. The Diffie-Hellman parameters can be generated by a similar procedure. A system administrator specifies both the DSA and Diffie-Hellman parameter generation procedures. These procedures need not be implemented within either the customer or merchant software.

The certification authority 124 (CA) (see FIG. 1) issues an X.509 certificate to each merchant, which includes the merchant's Diffie-Hellman public key component. The notion of digital certificates issued by certifying authorities (public key certificates) is well-known and is described in various standards, including CCITT Recommendation X.509. The Directory--Authentication Framework, November 1988, which is hereby incorporated herein by reference. Although X.509 certificates are specified within the preferred embodiment, other certificate structures or formats may be used without sacrificing interoperability, since these certificates are used only internally to the payment system.

The merchant network server 110 also needs to access the Diffie-Hellman parameters as certified by the CA 124. These parameters are used to compute the merchant's Diffie-Hellman public key component from the private exponent. The private exponent is initially generated by the merchant software. The merchant's X.509 certificate need not include the Diffie-Hellman system parameters, since these are accessible to the customer via the CTA 102 Diffie-Hellman certificate. Neither the customer nor merchant DSA public key need be certified. The CA 124 also issues X.509 certificates to the CTA 102 and the merchant clearing corporation 114. The CTA 102 is issued a Diffie-Hellman and a DSA certificate. The MCC 114 is issued a DSA certificate.

The public keys of the CA 124 and the CTA 102 may be embedded in the customer network software 104 executable. Also embedded within the customer network software 104 executable may be the two sets of system parameters:

1. DSA parameters corresponding to the CA 124, CTA 102, MCC 114, merchant, and customer signatures; and

2. Diffie-Hellman parameters for use between the customer and CTA 102, and between the customer and merchant.

The customer network software 104 does not require access to the CTA 102 DSA public key for routine processing. The CTA 102 keys, the merchants'Diffie-Hellman keys, and the Diffie-Hellman parameters are verified by means of the certificates issued by the CA 124. The verification is done by a software setup program which creates the executable. The CA public DSA key and the DSA parameters may be fixed for the lifetime of the software edition.

The public DSA keys of the CA 124, the MCC 114, and the CTA 102 may be embedded in the merchant network server executable. Also embedded within the merchant network server executable may be the two sets of system parameters:

1. DSA parameters corresponding to CA 124, CTA 102, MCC 114, merchant M, and customer C signatures; and Diffie-Hellman parameters for use between the customer and CTA 102, and between the customer and merchant.

To provide for non-repudiation, time-stamped versions of the CA DSA public key, the DSA and Diffie-Hellman system parameters and the hashing and signature verification algorithms may be registered with a third-party disinterested agent. The registration agent may also be able to provide the parameter generation protocols and seed material. In particular, given this information, an arbitrator would be able to check the validity of the signatures presented to it for dispute resolution.

The customer network software 104 can be enabled to output data which has been hashed and signed by the CTA 102, as well as the corresponding CTA 102 DSA signature(s) and the CA-certification of the appropriate CTA 102 DSA public key(s). The customer network software 104 must also be able to output complete merchant quote information as saved in the reconciliation database.

All public keys are 768 bits long. These include a DSA key for the CA 124, DSA and Diffie-Hellman keys for the CTA 102, DSA and Diffie-Hellman keys for the merchant, a DSA key for the MCC 114, and a DSA key for the customer. The merchant and customer DSA keys are not used in communications between the customer and merchant.

All security-related quantities, especially private keys, should be held in memory for as short a time as is possible. After their use they should be overwritten to prevent compromise. They should not be written to the hard drive unless and until required, and should be overwritten on disk as soon as feasible.

The merchant network server 110 can be enabled to output data which has been hashed and signed by the CTA 102 and/or MCC 114, as well as the corresponding CTA/MCC DSA signature(s) and the CA-certification of the appropriate CTA 102/MCC 114 DSA public key(s). The merchant network server 110 must also be able to output complete merchant quote information as saved in the merchant database 162. More particularly, the seller applet (the merchant network server 110) may be able to output information from the local data bases to a disk file in a format that is readable by common spreadsheet or database programs (for example, comma delimited ASCII dBase II), where data for dispute resolution consists of two classes: (1) Merchant-MCC/CTA disputes and (2) Merchant-Customer disputes. For class (1) disputes, the statements which have been hashed and signed by the MCC, as well as the corresponding payment advice from the local data base which is signed by the CTA may be written to a disk file. The CA-certification of the appropriate CTA/MCC DSA public key(s) provides solid evidence. For class (2) disputes, the merchant can output the payment advice and CTA signature from the local data base.

VII. Setup and Initialization

Recall that messages transmitted between customer network software 104 and the CTA 102 are authenticated by means of a Diffie-Hellman key exchange mechanism and that the merchant network server 110 uses a fixed Diffie-Hellman public key component. The Diffie-Hellman system parameters, p and g described below, are the same for exchanges between customer and merchant and between customer and CTA 102.

To set up a key pair, two Diffie-Hellman parameters p and g are generated in advance by the CTA 102. These parameters are public. The first parameter, p, is a prime number of exactly 768 bits, (that is, less than 2.sup.768 and greater than 2.sup.767) with the property that

p-1=2 p'

where p' is prime.

The second parameter, g, is chosen as an integer between 2 and p-1 with the following two properties:

g.sup.2 is not congruent to 1 modulo p

g.sup.(p-1)/2 is not congruent to 1 modulo p

The CTA 102 picks a random 160-bit exponent denoted by X.sub.CTA. It then computes

Y.sub.CTA=g.sup.Xcta modulo p.

The value Y.sub.CTA then becomes the public key component of the CTA 102 for Diffie-Hellman exchanges. The value of X.sub.CTA must be held securely by the CTA 102.

The values of g, p, and Y.sub.CTA (the CTA's public key component) are contained in a digital certificate issued to the CTA 102 and signed by the CA 124. The certificate is transmitted initially to the customer as part of the customer setup procedure which is addressed below.

For each customer, the CTA 102 maintains the current value of a Transaction-PIN quantity called PIN* (described below). The value of PIN* is initialized to the Logon-PIN quantity called PIN, which is assigned to the customer via an out-of-band procedure.

The quantity ADD is set to zero each time the customer indicates that he has been assigned a new value of PIN. Customer PINs are assigned during calls to a voice response unit (VRU) both at customer setup time and in response to loss of PIN* synchronization between the customer and CTA 102 thereafter. Customer calls to the VRU are authenticated by means of a long-term PIN and a customer subscriber identifier (SID) which appears on a card that is mailed to customers at the time they open their accounts.

The DSA parameters are generated in advance, and are public.

1. Setup of Merchant

As with the CTA 102, two Diffie-Hellman parameters p and g are generated in advance. They are public, and are available to the merchant as certified by the CA 124. The first parameter, p, is a prime number of exactly 768 bits, (that is, less than 2.sup.768 and greater than 2.sup.767) with the property that

p-1=2 p'

where p' is prime.

The second parameter, g, is chosen as an integer between 2 and p-1. It must have the following two properties:

g.sup.2 is not congruent to 1 modulo p

g.sup.(p-1)/2 is not congruent to 1 modulo p

The merchant picks a random 160-bit exponent which is denoted by X.sub.MERCHANT. It then computes

Y.sub.MERCHANT=g.sup.Xmerchant modulo p.

The value of Y.sub.MERCHANT then becomes the public key component of the merchant for Diffie-Hellman exchanges. Note that the value of X.sub.MERCHANT must be held securely by the merchant, and Y.sub.MERCHANT must be transmitted securely to the MCC 114, so as not to allow undetected substitution.

The value of Y.sub.MERCHANT is contained in a certificate issued to the merchant and DSA-signed by the CA 124. The certificate is transmitted initially as part of the merchant setup procedure which is addressed separately. As part of merchant setup, the merchant network server 110 can check that the received certificate includes the correct merchant information and merchant public key, and that the CA signature verifies. The DSA parameters are generated in advance, and are public.

The merchant private DSA key is randomly generated as part of the customer setup procedure. The corresponding public DSA key is securely transmitted to the MCC 114, so as not to allow undetected substitution.

The generation of the merchant DSA private key relies on the DSA system parameter q. The computation of the merchant DSA public key relies on the private DSA key and on the DSA system parameters g.sub.DSA and p.sub.DSA.

2. Initial Customer Setup

Prior to describing the operation of the system 100 in more detail, set up of customer and merchant accounts with the system is described. At the end of the initial customer setup process the customer has certain cryptographic keys and other values stored on his computer.

A customer C sets up a system account at a participating bank 108 and is given a unique system account number.

The customer network software 104 is then delivered on a bank-provided diskette or is downloaded from a system distribution server over the public telephone network. A sixteen-digit long-term PIN is either delivered with the diskette or is mailed later by the bank 108 with the public key, described below. The long-term PIN is used for the distribution site's voice response unit (VRU).

The customer then runs a setup program on the customer's computer. The program brands the software to this particular customer and generates a public/private key pair. The private key is used by the customer to generate digital signatures. The public key is used by the CTA 102 to verify digital signatures from the customer.

The customer private DSA key is randomly generated as part of the customer setup procedure. The corresponding public DSA key is securely transmitted to the CTA 102, so as not to allow undetected substitution. The generation of the customer DSA private key relies on the DSA system parameter q. The computation of the customer DSA public key relies on the private DSA key and on the DSA system parameters g.sub.DSA and P.sub.DSA.

In addition the customer is assigned a subscriber identifier and an account identifier. These two quantities taken together uniquely identify the customer. In any transaction between the customer and the CTA 102 the two quantities are always transmitted together and encrypted under Diffie-Hellman.

A supported Web browser is configured so that it routes messages with MIME types of "ec/quote" to the customer network software 104.

The customer software uploads the public key to the system distribution server. The customer is also prompted to enter the customer's bank system account number. The distribution site and server are not part of the CTA 102. The server is preferably a direct-dial host. At end-of-day the distribution server sends a batch message to the CTA 102 listing all newly applied-for account numbers. The CTA 102 creates an internal account flagged inactive and sends an out-of-band batch message to the bank 108 listing all accounts to be approved.

The bank 108 returns to the customer a physical form (typically a fax or postal letter) containing the customer's hashed public key. The customer compares the delivered hashed public key to a readable version of the hashed public key already stored in the customer's software. The two hashes must match in order to be valid. The customer signs the physical form and returns it through regular postal mail to the bank 108. The bank 108 performs a physical signature verification, which binds the public key to the customer's identity.

Routinely, e.g., nightly, the bank 108 sends a batch transfer of all verified, rejected, and revoked accounts to the CTA 102. Upon receipt of the verification message, the CTA 102 binds the public key to the customer's account number and activates the customer's account.

Next the customer telephones the PIN server. A voice response unit at the PIN server requests the customer's long-term PIN and subscriber identifier and responds with a seven-character logon PIN. The customer uses the logon PIN each time the customer authenticates a transaction to the CTA 102.

3. Merchant Initialization

Initial merchant setup is as follows:

System merchant software enabling merchants to offer goods for purchase by system customers is delivered on diskette. The merchant's identity is verified when the merchant account is activated.

Like the customer software, the merchant software setup program brands the software for use by a particular merchant. Unlike the customer, however, the merchant is issued a digital certificate signed by the MCC 114. This certificate conveys the MCC's trust in the identity of the merchant.

The certificate includes a Diffie-Hellman key used to authenticate communications between merchant and customer.

At initialization, the merchant network server 110 determines its version number, the DSA parameters, and the DSA public key of the CA 124. These quantities are embedded (hardwired) in the executable version of the merchant network server software. This guarantees that the merchant network server stops functioning if the CA 124 is issued a new key/parameters or if the merchant's network server becomes stale. The merchant network server 110 then verifies the CTA's DSA certificate and the MCC DSA certificate with the CA's public key. If the certificates are valid then the CTA's public DSA key and the MCC public DSA key are saved. Otherwise the merchant network server 110 logs the error and exits. The certified Diffie-Hellman parameters are also saved, if they verify correctly. If the system includes multiple CTAs and/or MCCs, the merchant network server 110 would hold multiple public keys.

4. Customer Initialization

Each time the customer network software 104 is launched it will ask the customer for his seven character PIN which will be stored in memory while the program is executing. The PIN must be reentered after some number of transactions have been completed, after some amount of goods have been bought, after some amount of time has elapsed or after some combination of the foregoing. In some embodiments the customer will be asked to enter his PIN every time he makes a purchase or requests information from the CTA 102.

VII. Detailed Operational Description

A detailed description of the operation of the present invention is now given.

1. Customer Shops with Merchant

First the customer shops with a merchant (step S202), identifies goods or services and receives a quote 126 (FIG. 7A) from the merchant (step S204). In operation of the system, when the customer clicks a "Buy" button on a merchant's Web page, the merchant transmits the quote 126 which includes a merchant certificate. The customer's Web browser interprets the message type and activates the customer network software 104 to process the quote.

An example of a quote message 126 is shown in FIG. 7A and includes "Merchant ID," a unique merchant identifier, "Merchant Transaction ID," a unique merchant-assigned transaction identifier, an indication of whether the customer's address is required, a transaction summary (for example, "Two pairs of jeans @ $29.95 each"), the number of items quoted, an array for description of each item quoted, arrays with corresponding item quantities and costs, a quote subtotal, additional costs, and a quote total. Other fields include one for additional information, the currency for the quote (e.g., USD), and an indication of whether or not the merchant allows refunds.

The quote 126 also includes the time of the offer (in the quote) and an expiration time for the offer. The quote has two URLs, a key exchange URL and a payment URL. Finally, the quote includes the merchant's certificate.

The customer views the quote information in a dialogue box. The customer's software has extracted the merchant's Diffie-Hellman system parameters initially sent by the CTA 102 to both merchant and customer when they set up their software. If the customer elects to confirm the quote, the customer network software 104 enters into a Diffie-Hellman key exchange based on those mutual system parameters to authenticate the origin and integrity of the merchant quote and the customer information.

If the customer wants physical goods, the customer is prompted to enter the appropriate name and address. This information is encrypted and sent to the merchant. If the customer wants information (digital) goods, the customer's identity remains anonymous to the merchant.

The Diffie-Hellman key exchange between the customer and the merchant generates a shared secret (described in detail below). The shared secret is a long number linking the merchant's quote and the CTA's payment advice (described later). The secret is used by the merchant to encrypt digital goods.

Because the shared secret has an element of randomness and is unique to a transaction, even if it were possible for an adversary to determine this number, it would be of no use in attacking future transactions. If, for any reason, the Diffie-Hellman key exchange fails, the purchase is aborted.

The customer network software 104 prompts the customer to enter the logon PIN. The logon PIN is never written to the customer's hard disk. The logon PIN is verified later in the transaction process by the CTA 102. The PIN resides only in memory in an attempt to make its compromise difficult.

The customer network software 104 uses the logon PIN as part of a function generating a per transaction PIN. Each transaction has a unique transaction PIN, modified on-the-fly by an unpredictable random number securely delivered by the CTA 102 and by a value randomly generated and sent encrypted by the customer network software 104. The transaction PIN is hashed and encrypted using the SHA-1 and the Diffie-Hellman technique and then the thus processed PIN is transmitted to the CTA 102 to enable the next step of communications.

2. Customer Gets QUOTE from Merchant

Each merchant maintains a page on the network on which goods are offered for sale. The customer uses a supported browser to view an HTML form which resides on the Web server belonging to a merchant who offers goods for sale. The customer clicks a "BUY" button, in response to which the merchant server composes a quote message 124 and encodes it in base 64. The HTTP content type of the quote 126 is "ec/quote". Content encoding is intentionally not specified so that the browser passes the customer network software 104 character data rather than binary. The browser then decodes the quote message. The format of the quote message 126 is shown in FIG. 7A and was described above. The quote must contain the merchant's Diffie-Hellman certificate and must uniquely identify a single transaction ("Merchant Transaction ID").

The customer's browser receives the message and routes it to the customer network software 104.

The customer network software 104 decodes the quote message from Base 64 to binary, verifies the merchant's Diffie-Hellman certificate with the CA's public key and, if successful, then presents all pertinent information to the customer. If the merchant's certificate can not be verified then an entry is written to the customer's transaction log and the customer is informed of the failure.

The customer must either confirm or cancel the purchase. If the purchase is canceled then no further processing is required. If the purchase is confirmed then the customer network software 104 generates 160 bits of randomness, R.sub.c, using some well-known approach. Next the customer network software 104 computes the customer's Diffie-Hellman public key component, Z:

Z=g.sup.Rc modulo p

The customer network software 104 then computes the Diffie-Hellman transaction key that it shares with the merchant:

D-H Key.sub.MERCHANT=Y.sub.MERCHANT.sup.Rc modulo p,

where

Y.sub.MERCHANT=g.sup.Xmerchant modulo p

This is the same as (g.sup.Xmerchant).sup.Rc modulo p which is the same as (g.sup.Rc).sup.Xmerchant modulo p which is the same as Z.sup.Xmerchant modulo p. To reiterate,

Y.sub.MERCHANT.sup.Rc =Z.sup.Xmerchant modulo p

This allows the merchant and the customer to hide D-H Key.sub.MERCHANT from others because R.sub.c is known only to the customer network software 104 and X.sub.MERCHANT is known only to the merchant. They can share it between themselves, however, as soon as the merchant receives the value Z from the customer.

After computing D-H Key.sub.MERCHANT, if the merchant quote indicates that further information is required from the customer, such as, e.g., address information for delivery of hard goods, the customer network software 104 extracts Bits(D-H Key.sub.MERCHANT, 640, 40) for use with the 40-bit key bulk-cipher encryption algorithm (to be specified). The customer is prompted to enter in the appropriate information, denoted P40, which is then encrypted, resulting in cipher, denoted C40.

The values of Z and C40 are then inserted into a key exchange message 170 (FIG. 7B) and posted to the merchant.

In response to receipt of the key exchange message 170, the merchant network server 110 computes D-H Key.sub.MERCHANT (from Z) and uses Bits (D-H Key.sub.MERCHANT, 640, 40) (which were used to encrypt P40) to decrypt C40. The resulting plaintext, P40, is appropriately stored in the merchant database 162. The merchant network server 110 then computes two 160-bit quantities: a number denoted QuoteCheck, which lets the customer network software 104 verify the origin and integrity of the merchant quote as well as the proper receipt and decryption of C40 by the merchant's network server 110, and a number, denoted QPAL (Quote-Pay Advice Link), which will be used later to link the quote to a payment advice:

QPAL=SHA(Quote)

QuoteCheck=SHA(.about.Quote.parallel.P40.parallel.Bits(D-H Key.sub.MERCHANT, 0, 160))

An encrypted form of QuoteCheck is inserted into a key response message 172 (FIG. 7C) which the merchant returns to the customer:

Encrypted QuoteCheck=Bits(D-H Key.sub.MERCHANT, 160,160).sym. QuoteCheck

The merchant saves the full text of the quote and the 160 bits Bits(D-H Key.sub.MERCHANT, 0, 160) in the quotes table 164 its database 162. The 360 bits, Bits(D-H Key.sub.MERCHANT, 320, 360), are saved until the completion of processing of this transaction.

Upon receipt of the key response message 172 from the merchant, the customer compares the results of its own computation of the value of Encrypted QuoteCheck to that value in the message 172.

If the check fails then the failure is logged, the customer is informed, the values of PIN, R.sub.c, Z, D-H Key.sub.MERCHANT, C40, QuoteCheck and Encrypted QuoteCheck within memory are overwritten and processing of this transaction ends.

On the other hand, if the check succeeds then the full text of the quote message as well as the 160 bits Bits(D-H Key.sub.MERCHANT, 0, 160) are saved in the customer database 136 in the Quotes table 140. Three quantities are computed from D-H key.sub.MERCHANT and saved in the Pending table 154 until the conclusion of the processing of this transaction:

MERBITS1=Bits(D-H Key.sub.MERCHANT, 320, 160)

MERBITS2=Bits(D-H Key.sub.MERCHANT, 480, 160)

MERBITS3=Bits(D-H Key.sub.MERCHANT, 640, 40)

Then the values of C40, QuoteCheck, Encrypted QuoteCheck and Bits(D-H Key.sub.MERCHANT, 160, 160) are overwritten in memory.

It should be noted that in other embodiments, the information exchanged between the customer and merchant may be grouped differently, particularly in terms of when it is communicated and/or when it is verified. For example, the merchant certificate may be transmitted with the authenticated quote rather than as part of the original quote. The fact that in the preferred embodiment the merchant certificate is received and verified by the customer prior to the confirmation or cancellation of the purchase allows for safeguarding the customer's shipping address information against delivery to unintended parties, although this may not be considered a particularly significant breach of security.

3. Customer Composes Payment Request

At this point the customer network software 104 is ready to make a payment request 128 (step S206) to the CTA 102. Accordingly, the customer network software 104 then computes a Diffie-Hellman key, D-H Key.sub.CTA, to be used to communicate with the CTA 102.

D-H Key.sub.CTA =(Y.sub.CTA).sup.Rc modulo p

The value of R.sub.c is the same value which was used to compute D-H Key.sub.MERCHANT. The value of R.sub.c should be overwritten as soon as the computation of D-H Key.sub.CTA is made and should never be written to the disk.

As was the case with the merchant, the CTA 102 will be able to compute the Diffie-Hellman key it shares with the customer network software 104 just as soon as the customer network software 104 transmits its Diffie-Hellman public key component Z to the CTA 102. Unlike the merchant case however, there is only one communication in each direction. The Diffie-Hellman public key component of the CTA 102, Y.sub.CTA, is known to the customer network software 104 prior to the start of communications. If the current CTA Diffie-Hellman public key component is not known to the customer network software 104, the communication discussed below will fail if the CTA 102 uses its current private Diffie-Hellman exponent. This is because the CTA 102 will be unable to determine the customer identity, which is encrypted under the Diffie-Hellman key. The Diffie-Hellman public key component of the customer will be included in the payment request message which will be discussed shortly.

Next the customer network software 104 has the customer generate 56 random bits, denoted RANDOM, e.g., with key strokes or mouse movements. Alternatively some hardware random source may be used. The value of RANDOM is temporarily written to the States table 156 of the customer database 136.

Next the customer network software 104 computes the value of PIN* using the typed-in value of PIN:

PIN*=PIN.sym.ADD

where ADD is either retrieved from the hard drive, or reset to zero if the customer indicates that this is the first-time use of a new PIN value. The typed-in value of PIN should be overwritten at this point.

Then the customer network software 104 updates the value ADD by replacing its current value with

ADD.sym.RANDOM

The new value of ADD is stored in the States table 156 of the customer's local database 136. After the value of ADD is updated, the customer network software 104 fetches the number to be assigned to the next transaction (from field NEXTTRANS of the states table 156). The customer then creates an unsigned payment request, PR (FIG. 7D). The unsigned payment request PR is formed by concatenating the following:

the merchant identifier, denoted MID

the merchant transaction identifier, denoted Tm

the transaction amount, denoted T$

the Quote-Pay Advice Link, QPAL

the customer subscriber identifier, denoted SID

the customer transaction identifier, denoted Tc

the customer account identifier, denoted AID

the value of RANDOM

the value of PIN*

The value of PIN* should be overwritten at this point.

Then the customer creates a 160 bit hash:

H.sub.PC =SHA(PR), after which PR should be overwritten.

This is followed by computation of

H.sub.Final =SHA(H.sub.PC .parallel.DSAr(PR, customer).parallel.DSAs(PR, customer))

In other embodiments the customer signature DSA (PR,customer) may be suppressed if non-repudiation is not a system requirement, since the transaction security is based primarily on the combined use of the customer PIN and Diffie-Hellman. It may be adequate in such an embodiment to let H.sub.FINAL =H.sub.PC.

The randomly generated per-message DSA exponent used to compute the DSA signature should be overwritten in memory as soon as the values DSAr (PR, customer) and DSAs (PR, customer) are computed. The hash value H.sub.PC should be overwritten after the calculation of H.sub.Final.

Next the customer creates E, the portion of the message to be encrypted:

E=SID.parallel.Tc.parallel.AID.parallel.RANDOM.parallel.H.sub.Final DSAs(PR, customer)

The values of H.sub.Final and DSAs(PR, customer) should be overwritten at this point.

Because the physical lengths of the quantities above are fixed, namely:

    ______________________________________
    SID                   32     bits
    Tc                    32     bits
    AID                   8      bits
    RANDOM                56     bits
    H.sub.Final           160    bits
    DSAs(PR, customer)    160    bits,
    ______________________________________
     the result E is 448 bits long.

Then E is encrypted with the first 448 bits of the Diffie-Hellman key D-H Key.sub.CTA to yield the value E'

E'=Bits(D-H Key.sub.CTA, 0, 448).sym.E

After E is encrypted Bits(D-H Key.sub.CTA, 0, 448) used to encrypt it should be overwritten.

Next the customer network software 104 computes two 160-bit quantities which will be used to verify the authenticity of the response to its payment request

CTABITS1=Bits(D-H Key.sub.CTA, 448, 160)

CTABITS2=Bits(D-H Key.sub.CTA, 608, 160)

Both CTABITS1 and CTABITS2 are temporarily stored in the Pending table 154 so that a payment advice message can be verified for authenticity even if it is received after a restart of the customer network software 104.

Finally a payment request message 128 that contains Z, MID, Tm, T$, QPAL, DSAr (PR, customer) and E' is composed. The payment request message is temporarily written to the database 136 (in Payment Requests 146) to address failures in transmission. Then it is Base64 encoded and posted to the URL of the CTA 102 that is embedded in the customer network software 104 executable.

4. CTA Processes Payment Request

Upon receipt of the payment request message 128 (step S208), the CTA 102 performs the following processing:

First the CTA 102 uses the value Z from the payment request message 128 to calculate the Diffie-Hellman key D-H Key.sub.CTA as follows:

D-H Key.sub.CTA =z.sup.Xcta modulo p

Next the CTA 102 extracts E from the message and computes E:

E=Bits(D-H Key.sub.CTA, 0,448).sym.E'

Because the lengths and locations of the fields SID (the customer subscriber identifier, 32 bits), Tc (the customer transaction identifier, 32 bits), AID (the customer account identifier, 8 bits), RANDOM (56 bits), H.sub.Final (160 bits) and DSAs (PR, customer) (160 bits) are known, the CTA 102 is able to recover these values from the calculated value of E.

The value of SID is then used to find the current value of PIN* and other values for this customer in the CTA database. If the recovered value of SID does not correspond to an actual customer subscriber ID, processing of the customer-specific data stops here.

Then the CTA 102 recomputes the hash value H.sub.PC (denoted H'.sub.PC) from the values MID, Tm, T$ and QPAL which are in the plaintext portion of the message and SID, Tc, AID and RANDOM which were hidden in the message by Diffie-Hellman encryption, and PIN* from the CTA database. Recall that the customer computed the value of H.sub.PC as H.sub.PC =SHA(PR), where PR was formed by the concatenation of MID, Tm, the transaction amount, T$, QPAL, the customer subscriber identifier, SID, the customer transaction identifier, Tc, the customer account identifier, AID, RANDOM and PIN*. The value H.sub.Final =SHA(H.sub.PC .parallel.DSAr(PR, customer).parallel.DSAs(PR, customer)).

Then the CTA 102 computes H.sub.Final ' from H.sub.PC ', from DSAr(PR, customer) [within plaintext], and from DSAs(PR, customer) [after Diffie-Hellman decryption]. The values of H.sub.Final and H.sub.Final ' are then compared.

The customer signature may be reconstituted from its parts DSAs (PR, customer) and DSAr(PR, customer). In the event of a later attempted transaction repudiation by the customer, the CTA 102 can check the customer's signature if it is stored along with MID, Tm, T$, QPAL, SID, Tc, AID, RANDOM and PIN*. In the event of a dispute of the signature which causes the signature to be presented outside the CTA 102, the customer is expected to refresh the value of the logon-PIN, PIN. The CTA 102 enforces this by rejecting subsequent transactions.

Alternatively, if in the formation of H.sub.PC and H.sub.FINAL, RANDOM and PIN* had been removed from PR, and if H.sub.PC within the computation of H.sub.FINAL had been replaced by H.sub.PC .parallel.RANDOM.parallel.PIN*, then it would no longer be necessary for the CTA to force the customer to obtain a new value of the logon-PIN in the event the signature needs to be presented outside of the CTA. Whether data is input by the customer network software 104 as an input parameter to SHA within H.sub.PC or as an input parameter to SHA within H.sub.FINAL, it has the same effect with respect to the CTA detecting whether the data integrity has been maintained. Alternatively, if in the formation of H.sub.PC and H.sub.FINAL, if RANDOM and PIN* had been removed from PR, and if H.sub.PC within the computation of H.sub.FINAL had been replaced by H.sub.PC .parallel.RANDOM.parallel.PIN*, then it would no longer be necessary for the CTA to force the customer to obtain a new value of the logon-PIN in the event the signature needs to be presented outside of the CTA. Whether data is input by the customer network software 104 as an argument of SHA within H.sub.PC or as an argument of SHA within H.sub.FINAL, it has the same effect with respect to the CTA detecting whether the data integrity has been maintained.

The customer signature data needs to be stored only if H.sub.Final