Electronic commerce using a secure courier system

Claim 3

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

Claim 4

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

Claim 5

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.

Claim 6

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.

Claim 7

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

Claim 8

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.

Claim 9

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.

Claim 10

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

Claim 11

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

Claim 12

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.

Claim 13

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.

Claim 14

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

Claim 15

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.

Claim 16

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.

Claim 17

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.

Claim 18

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.

Claim 19

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

Claim 20

The system of claim 1, further comprising: a merchant application for providing server functions for said customers to obtain product information and pricing.

Claim 21

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.

Claim 22

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

Claim 23

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

Claim 24

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

Claim 25

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.

Claim 26

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

Claim 27

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.

Claim 28

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.

Claim 29

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.

Claim 30

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.

Claim 31

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.

Claim 32

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.

Claim 33

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.

Claim 34

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.

Claim 35

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)).

Claim 36

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.

Claim 37

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.

Claim 38

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: E(Slip)=PA{DES key K}, K(Slip); such that a final message sent is formatted as follows: 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.