Electronic commerce using a secure courier system

• US 5,671,279 A
• Filed: 11/13/1995
• Issued: 09/23/1997
• Est. Priority Date: 11/13/1995
• Status: Expired due to Term

• Current Assignee: Meta Platforms, Inc. (f/k/a Facebook, Inc.)
• Original Assignee: Netscape Communications Corporation (Apollo Global Management, Inc.)
• Inventors: Elgamal, Taher
• Primary Examiner(s): Cain, David C.
• Application Number:
  US08/555,976
• Time in Patent Office: 680 Days
• Field of Search: 380/23, 380/24, 380/25, 380/4, 380/3, 380/49, 380/29, 380/30
• US Class Current: 705/79
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/027 involving a payment switch or gateway
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/24 Credit schemes, i.e. "pay after"
• CPC Class Codes: G06Q 20/3823 combining multiple encryption tools for a transaction
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: H04L 2463/102 applying security measure for e-commerce
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/12 Applying verification of the received information cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32

Abstract

A courier electronic payment system provides customers, merchants, and banks with a secure mechanism for using a public network as a platform for credit card payment services. The system governs the relationship between a Customer, Merchant, and Acquirer Gateway to perform credit card purchases over such networks as the Internet. The system uses a secure connection to simplify the problem of Internet-based financial transactions in accordance with an electronic payment protocol that secures credit card payments and certifies infrastructure that is required to enable all of the parties to participate in the electronic commerce, as well as to provide the necessary formats and interfaces between the different modules and systems.

Claims

1. A system for implementing electronic commerce over a public network, comprising:

a secure transport layer including a channel security mechanism comprising a keyed message digest computation, wherein said secure transport layer supports data privacy and integrity for communications between any two network nodes, such that two secure channels are provided, where there is one channel between a customer and a merchant and another channel between said merchant and an acquirer gateway such that said merchant and said acquirer are authenticated to each other and to said customer; and

a secure courier message for implementing an electronic payment protocol that provides at least any of signature, non-repudiation, and secondary encryption terms wherein node-to-node authentication, privacy, and data integrity are automatically achieved by said secure transport layer.

2. The system of claim 1, wherein all channel communications between any two nodes in said system are encrypted.

3. The system of claim 1, wherein said customer is authenticated.

4. The system of claim 1, wherein each message is hashed to avoid early termination type attacks, and to assure that messages arrive at a recipient unaltered.

5. The system of claim 1, wherein confidential customer information is kept encrypted with regard to all parties, including a merchant that is handling a transaction.

6. The system of claim 1, wherein specific order information is maintained in confidence with regard to all parties other than said merchant.

7. The system of claim 1, wherein digital signatures are communicated between all parties to ensure authorship between two parties that are not necessarily communicating directly with each other.

8. The system of claim 1, wherein said secondary encryption term defines encryption of message data fields for decryption by a third party that is not necessarily a recipient of an entire message.

9. The system of claim 1, wherein each secure courier message has a message wrapper and a message body.

10. The system of claim 9, wherein the message wrapper consists of at least one or more of an order number, and routing information.

11. The system of claim 9, wherein for each message an acknowledge is generated by a recipient and sent to a sender to ensure receipt of the message.

12. The system of claim 11, wherein said acknowledge is a hash of said message that proves receipt by an appropriate recipient by using an SSL layer to guarantee an authenticated channel.

13. The system of claim 12, wherein time of receipt is concatenated to said hash and said concatenated message is used as an acknowledge.

14. The system of claim 1, wherein a message is considered to be expired if it is received after a message validity period is over;

and wherein a denial is optionally provided instead of an acknowledge.

15. The system of claim 1, further comprising:

a customer application that implements browsing and shopping functions, as well as generating purchase orders, payment information (PI), and signatures for transactions.

16. The system of claim 15, wherein said customer application receives price and product information from said merchant and encrypts a transaction ID supplied from said merchant with a credit card number, where such information is made accessible to said acquirer only using an acquirer'"'"'s public-key, which is extracted from an acquirer digital certificate.

17. The system of claim 15, wherein said customer application verifies signatures from said merchant to ensure origination of messages, such that an order as supplied in a receipt matches an original order generated by a customer earlier.

18. The system of claim 15, wherein said customer application generates signatures on payment messages using a public key certificate.

19. The system of claim 1, further comprising:

a merchant application for providing server functions for said customers to obtain product information and pricing.

20. The system of claim 19, wherein said merchant application generates a transaction ID for a customer order to track said order until it has been authorized by said acquirer, wherein said transaction IDs are generated sequentially and used only once.

21. The system of claim 19, wherein said merchant application verifies an acquirer signature on capture responses and a customer signature on receipts.

22. The system of claim 19, wherein said merchant application generates receipts for customer signature.

23. The system of claim 19, wherein said merchant application generates digests of order information for said acquirer to verify authenticity of a purchase order.

24. The system of claim 1, further comprising:

an acquirer application for receiving order amounts and transaction ID with customer financial information and for performing credit card authorizations.

25. The system of claim 24, wherein said acquirer application receives capture requests and performs capture confirmation.

26. The system of claim 24, wherein aid acquirer application translates a standard message format from said merchant into proper formats used by an existing authorization network.

27. The system of claim 1, wherein messages used in said payment protocol may include any of the following:

PAN;

a personal account number for a customer card;

Expiration Date;

an expiration date of said card;

Merchant ID;

a unique number for each merchant assigned by said acquirer upon signing up said merchant, said merchant ID being unique for each acquirer, and including an acquirer ID as part of it to generate a globally unique number;

Transaction ID;

a unique number assigned by said merchant for each transaction, wherein said merchant and said customer can use this number in conjunction with said merchant ID to identify any particular transaction;

Acquirer Certificate;

Merchant Certificate;

Total Amount;

H(Order);

PIN;

Billing address;

Shipping Address;

Resp-Code;

a response code from an authentication process;

Auth-Code;

a number returned by a banking network to use for clearing/capture steps;

CaptureResp;

a response for a capture process;

Validity Period;

start and expiration dates for a message;

Date;

date and time stamp; and

Digital Signature;

a digital signature comprising the following;

SIGNx(data)=Sx(data, nonce, date), nonce, date, signer'"'"'s certificate.

28. The system of claim 1, wherein a transaction ID (TxID), in which said PI value is encrypted so that a merchant server does not have any clear credit card numbers that can be accessed remotely, is used to prevent a merchant from replaying authorization requests.

29. The system of claim 28, wherein said transaction ID (TxID) is combined with credit card information and encrypted in a PI message to ensure that each such message is different when the merchant uses a unique TxID for each transaction.

30. In an authorization group consisting of a customer, a merchant, and an acquirer, a transaction method comprising the steps of:

sending a purchase-order, payment Instruction (PI) message to a merchant; and

said merchant to responding with;

S_M (H(Purchase-Order, PI), Date, Time);

where;

H(value)=a message digest of value using a negotiated message digest algorithm.

31. The transaction method of claim 30, further comprising the step of:

assigning a transaction ID (TxID) used for book keeping purposes and optionally to prevent a merchant from replaying authorization requests.

32. The transaction method of claim 31, wherein said transaction ID TxID is combined with credit card information and encrypted in a PI message to ensure that each message is different if said Merchant uses a unique TxID for each transaction.

33. The transaction method of claim 30, wherein an offer from a merchant to a customer comprises the form:

SIGNM(Validity Period, Items, Payment Method, zip code or country (for shipping charges computation), Amount, Currency, Merchant ID (MID), Acquirer'"'"'s certificate (CERTA), and transaction ID (TxID)).

34. The transaction method of claim 30, wherein a purchase order from a customer to a merchant comprises the form:

Name, Validity Period, Items, Total Amount, Currency, Merchant ID (MID), transaction ID (TxID), and shipping address.

35. The transaction method of claim 30, wherein a PI message is a signed message from said customer using a Slip having the form:

Version, current date, expiration date (Validity Period), Total Amount, Currency, Orderhash, MerAcqHash, Credit Card information (CardInfo);

where;

Order=Hash of an order description including any salt for minimizing attacks on said hash;

MerAcqhash=hash of a merchant ID, transaction ID, and other merchant or acquirer data specific to a merchant-acquirer pair and not needed by the customer other than for inclusion in a PI message;

CardInfo=(Personal account number (PAN, expiration date, other optional information that may be needed by a payment processor/acquirer.

36. The transaction method of claim 30, further comprising the steps of:

sending said PI encrypted to said acquirer using an acquirer'"'"'s public key; and

encrypting said PI message using a following digital envelope construction as follows;

space="preserve" listing-type="equation">E(Slip)=PA{DES key K}, K(Slip);

such that a final message sent is formatted as follows;

space="preserve" listing-type="equation">PI=SINCE(E(Slip));

where;

K{value}=value encrypted under K using a symmetric-key algorithm;

Cx, CERTx=a certificate of entity x;

PKx{key}=key encrypted under a public key (PK) for x using a public-key algorithm, where x can be C for customer, M for Merchant or A for Acquirer;

E{value}=encryption of value under a data encryption key that is encrypted under a public key of a recipient and referred to as a digital envelope; and

Sx(Value)=a value combined with the digital signature of the entity x using its private key, such that if entity x does not have a public-private key-pair, then a low grade signature can be generated using a hash of a value with information from x.