I IIIII IIIIIIII Ill 11111 IIIII IIIII IIIII IIIII IIIII IIIII IIIII IIIIII Ill lllll llll
`
`
`
`
`
`
`
`
`
`
`
`
`US005671279A
`
`United States Patent
`5,671,279
`
`[19]
`Elgamal
`Sep.23, 1997
`[45]Date of Patent:
`
`[11]Patent Number:
`
`[54]ELECTRONIC COMMERCE USING A
`SECURE COURIER SYSTEM
`
`[75] Inventor:
`Taber Elgamal, Palo Alto, Calif.
`
`
`
`Secure Transaction Technology, Version 1.0, "Securing the
`
`Stein et al., 'The Green Commercial Model", Oct., 1994.
`
`
`
`
`
`"Encryption and Internet Commerce," First Vrrtual Hold­
`ings, Inc., 1995.
`
`
`
`'Net".
`"Secure Electronic Payment Protocol," Draft Version 1.1,
`
`
`
`Sep. 29, 1995, MasterCard.
`C. Cain
`Primary Examiner-David
`
`or Finn-Michael A. Glenn
`
`Attorney, Agent,
`[22]Filed:Nov. 13, 1995
`[57]
`ABSTRACT
`[51]fut. Cl.6 .......................................................
`H04K 1/00
`
`
`A courier electronic payment system provides customers,
`
`
`[52]U.S. Cl .................................... 380/23; 380/25; 380/4;
`
`
`
`
`merchants, and banks with a secure mechanism for using a
`
`
`380/49; 380/29; 380/30
`
`public network as a platform for credit card payment ser­
`
`[58]Field of Search .................................. 380/23, 24, 25,
`
`
`
`
`vices. The system governs the relationship between a
`
`380/4, 3, 49, 29, 30
`
`
`
`
`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 pay­
`Llnehan & Taudik, IBM Research, Jul., 1995, ''Internet
`
`
`
`ments and certifies infrastructure that is required to enable
`
`Keyed Payments Protocol".
`
`all of the parties to participate in the electronic commerce,
`
`Wrred, Oct. 1995, "Scans, Banking with First Virtual".
`
`
`as well as to provide the necessary formats and interfaces
`
`MacWorld, Nov. 1995, "Money on the Line", p. 114.
`between the different modules and systems.
`
`
`
`Borenstein & Rose, First Virtual Holdings, Oct., 1994, 'The
`
`application/green-commerce MIME Content-type".
`
`[73]Assignee:
`Netscape
`Communications
`View, Calif.
`Mountain
`Corporation,
`
`[21]Appl. No.: 555,976
`
`[56]
`
`
`
`References Cited
`
`PUBLICATIONS
`
`36 Claims, 3 Drawing Sheets
`
`
`
`Shopping, browsing etc.
`
`-----------------
`
`40
`
`
`
`
`
`
`
`Beginning of Payment Processing Protocol:
`
`19
`
`Purchase-Request
`
`---------------------------
`
`Offer for purchase
`
`
`
`----------------------------
`
`30
`
`31
`
`IPR2022-01239
`Apple EX1013 Page 1
`
`

`

`U.S. Patent
`Sep. 23, 1997
`Sheet 1 of 3
`
`5,671,279
`
`C
`
`M
`
`MERCHANT
`
`16 21
`
`18
`
`22
`
`20
`
`19
`
`
`
`Shopping, browsing etc.
`
`-------
`
`-------------------
`
`40
`
`
`
`
`
`
`
`Beginning of Payment Processing Protocol:
`
`19
`
`Purchase-Request
`
`--------------------------
`
`Offer for purchase
`
`--------------
`-------------
`
`30
`
`31
`
`FIG. f
`
`IPR2022-01239
`Apple EX1013 Page 2
`
`

`

`5,671,279
`U.S. Patent Sep. 23, 1997 Sheet 2 of 3
`
`16
`
`18
`
`GATEWAY
`CUSTOMER
`MERCHANT
`G
`
`C
`
`M
`
`
`
`Purchase-Order (including Pl)
`
`
`
`---------------------------
`
`Acknowledge opt ion
`
`
`
`--------------------------
`
`
`
`Order-Inquiry option
`
`----------------
`----------
`
`option
`Order-Status
`
`
`
`
`
`--------------------------
`
`19
`
`Au th-Request
`
`---------------
`------
`
`Au th-Response
`
`---------------------
`
`
`Inquiry opt ion
`0 rde r-
`
`------------
`---------------
`
`
`
`Order-Status option
`
`
`
`--------------------------
`
`
`
`Receipt option
`
`----------------------
`
`----
`
`FIG. 2
`
`IPR2022-01239
`Apple EX1013 Page 3
`
`

`

`1997 Sheet 3 of 3 5,671,279
`U.S. Patent Sep.23,
`
`GATEWAY
`CUSTOMER
`MERCHANT
`C
`
`M
`
`G
`
`Capture-Request
`
`
`
`
`
`------------------------
`
`Jg
`
`Cap tu re-Confirm
`
`------------------------
`
`
`
`Receipt opt ion
`
`-------------------------
`
`FIG. 3
`
`16
`
`GATEWAY
`CUSTOMER
`MERCHANT
`C
`
`G
`
`M
`
`Settlement-Request
`
`------------------------
`
`19
`Settlement-Confirm
`
`-------------------------
`
`FIG. 4
`
`IPR2022-01239
`Apple EX1013 Page 4
`
`

`

`5,671,279
`
`
`
`BACKGROUND OF THE INVENTION
`
`1
`
`ELECTRONIC COMMERCE USING A
`SECURE COURIER SYSTEM
`
`2
`that supports merchants by providing service for processing
`
`
`
`
`
`credit card based transactions, a certificate management
`
`
`
`
`system that provides for the creation and distribution of
`
`
`
`
`electronic certificates for merchants, financial institutions,
`
`
`
`5 and cardholders, and a network to interface the merchants,
`1.Technical Field
`
`
`
`
`
`financial institutions, cardholders, and certificate manage­
`The invention relates to the processing of commercial
`
`
`
`
`
`
`
`ment system; see http://www.mastercard.com). Payments in
`
`
`
`
`transactions. More particularly, the invention relates to the
`
`
`the real world are accomplished via such mechanisms as
`
`
`
`
`secure processing of on-line commercial transactions.
`
`cash, checks, credit and debit cards, money, and postal
`
`2.Description of the Prior Art
`
`
`
`
`systems of all these payment 10 orders. Electronic equivalents
`
`
`
`A fast-growing trend on the Internet is the ordering and
`
`
`
`
`are being developed. For example, iKP, ibid., addresses a
`provision of information, goods, and services via the World
`
`
`
`
`
`
`subset of these mechanisms that involve direct payment
`
`Wide Web, electronic mail, and other means. A key issue for
`
`
`
`
`
`
`transfers among accounts maintained by banks and other
`
`
`related to such electronic commerce is the authorization and
`
`
`
`
`financial organizations. This includes credit and debit card
`
`
`
`satisfaction of payment for such goods and services in an
`
`
`
`transactions, as well as electronic check clearing, but
`15
`
`
`
`
`efficient, reliable, and secure manner. A number of organi­
`
`
`
`excludes electronic cash and money orders because these
`
`
`
`zations have addressed this issue by establishing proprietary
`
`
`
`require very different mechanisms. The stated goal of iKP is
`
`
`
`
`payment systems which vary widely in design, performance,
`
`
`
`
`to enable Internet-based secure electronic payments while
`and security features.
`
`
`
`
`using the existing financial infrastructure for payment autho­
`
`
`See, for example M. Linehan, G. Tsudik,
`
`Internet Keyed 20
`
`
`
`rization and clearance. The intent is to avoid completely, or
`
`
`
`<draft-tsudik-ikp--Payments Protocol (iKP), Internet-Draft
`
`
`
`
`at least minimize, changes to the existing financial infra-
`
`
`
`00.txt> (July 1995) (an architecture for secure payments that
`
`
`structure outside of the Internet.
`
`
`involves three or more participants in which a base protocol
`
`
`
`Payment systems incorporate tradeoffs among cost,
`
`
`
`includes a number of options that can be selected to meet
`
`
`
`
`timeliness, efficiency, reliability, risk management, and con­
`
`
`
`varying business or security requirements, for example by 25
`
`
`venience. For example, some systems attempt to suppress
`
`
`
`applying cryptographic techniques to minimize potential
`
`
`
`
`fraud by inducing payment delays. Security in payment
`
`
`
`risks concerning payments over the open Internet).
`
`
`
`systems means minimizing risk to a level acceptable to
`
`
`See, also L. Stein, E. Stefferud, N. Borenstein, M. Rose,
`
`
`
`
`participants. Risk management in existing systems is accom­
`
`
`
`Inc., Vutual Holdings, The Green Commerce Modei First
`
`
`plished by varying combinations of technology, payment
`
`
`October 1994 (http://www.infohaus.com); N. Borenstein,
`
`
`
`
`practices, insurance, education, laws, contracts, and enforce­
`30
`M.Rose, The application/green-commerce
`MIME Content­
`
`ment. The state of the art uses cryptographic technology,
`type, First Vutual Holdings, Inc., October 1994 (http://
`
`
`
`such as public-key cryptography, to support payments
`
`www.infohaus.com); and Encryp tion and Internet
`
`
`among parties who have no preexisting relationship in a
`
`
`First Virtual Holdings, Inc., 1995 (http://
`Commerce,
`scalable manner.
`
`
`
`
`
`www.infohaus.com); and First Vrrtual Holdings, Inc., W ired, 35
`
`
`
`Many existing cryptographic protocols, such as SSL (K.
`
`
`
`pp. 51 (October 1995), MacWorld, pp. 114 (November
`
`
`E. B. Hickman, The SSL Protocoi Internet Draft <draft­
`
`
`1995) (an on-line transaction clearing house in which
`
`
`
`hickman-netscape-ssl-00.txt>, April 1995), SIITTP (E.
`
`
`
`
`accounts are established off-line via telephone, and in which
`
`
`Rescorla, A. Schiffman, The Secure HyperText Transfer
`
`
`
`a transaction requires an account number, where each trans­
`
`
`Internet Draft <draft-rescorla-shttp-0.txt>,
`Protocol,
`action is confirmed by the clearing house via email);
`
`
`
`
`
`
`40 December 1994), PEM (J. Linn, Privacy Enhancement for
`CyberCash, MacWorld, pp. 114 (November 1995) (an elec­
`
`
`
`
`
`
`Internet Electronic Mail: Part I: Message Encryption and
`tronic payment system that uses cryptography to prevent
`
`
`
`
`RFC 1421, February 1993),
`
`Authentication Procedures,
`
`eavesdroppers from stealing and unscrupulous merchants
`
`
`
`
`MOSS (S. Crocker, N. Freed, J. Galvin,
`MIME Object
`from overcharging); NetCheque, University of Southern
`
`
`
`
`Internet Draft <draft-ietf-pem-mime-
`
`Security Services,
`
`
`
`California, Mac World, pp. 114 (November 1995) (an on-line
`
`08.txt>, March 1995), and IPSP (R. Atkinson,
`45
`Security
`
`
`
`checking system in which an account holder can send an
`
`Internet Draft <draft­
`
`
`Architecture for the Internet Protocoi
`
`
`
`
`electronic document that a recipient can deposit electroni­
`
`
`
`
`ietf-ipsec-arch-02.txt>, May 1995), provide security func­
`
`
`cally into a bank account as a check, where the document
`
`
`tions for pairwise communication. For example, SSL pro-
`
`
`
`
`contains the name of the payer, financial institution, payer's
`
`vides privacy and authentication, but no non-repudiation,
`
`
`
`account number, payee's name, and amount of check, and 50
`
`
`
`
`between clients and servers of application-layer protocols
`
`
`
`which includes a digital signature of the payer and which
`
`such as HITP and FTP. Many payment systems involve
`
`
`
`
`may include a digital signature of a payee); and DigiCash,
`
`three or more parties, i.e. buyer, seller, and bank. In such
`
`
`
`MacWorld, pp. 114 (November 1995) (an Internet payment
`
`
`
`systems, certain types of risk can be ameliorated by sharing
`
`
`
`
`
`systems, referred to as eCash, that provides digital money
`
`
`
`sensitive information only among a subset of the parties. For
`
`
`
`
`without an audit trail, thereby protecting the privacy of 55
`
`
`
`example, credit card fraud can be reduced by transmitting
`parties to the transaction).
`
`
`
`
`credit card account numbers between buyers and banks
`
`
`
`Additionally, electronic commerce systems have been
`without revealing them to sellers.
`
`
`
`
`proposed by Visa International Service Association in col­
`As the Internet continues to grow, a significant portion of
`
`
`
`
`
`
`
`laboration with Microsoft Corporation (Secure Transaction
`
`
`
`the economy may become inextricably interwoven with
`
`
`
`
`Technology, using digital signature to authenticate a credit 60
`
`
`
`
`Internet-based on-line transactions. It would therefore be
`
`
`
`
`card and merchant decal; see http://www.visa.com); and
`
`
`
`
`advantageous to provide a secure, reliable, and efficient
`
`
`
`
`
`MasterCard (Secure Electronic Payment Protocol, a collec­
`
`
`
`
`mechanism for implementing transactions associated with
`
`
`
`
`tion of elements including an authorized holder of a bank­
`on-line commerce.
`
`
`
`card supported by an issuer and registered to perform
`SUMMARY OF THE INVENTION
`
`
`
`
`and/or services, electronic commerce, a merchant of goods,
`65
`
`
`
`information who accepts payment from the holder
`
`
`
`
`
`A courier electronic payment system provides customers,
`
`
`
`electronically, a MasterCard member financial institution
`
`
`
`merchants, and banks with a secure mechanism for using a
`
`IPR2022-01239
`Apple EX1013 Page 5
`
`

`

`5,671,279
`
`3
`public network as a platform for credit card payment ser(cid:173)
`vices. 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 pay(cid:173)
`ments 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.
`
`BRIEF DESCRilTION OF TIIE DRAWINGS
`FIG. 1 is a schematic representation of a transaction
`enterprise including flow diagram showing a payment pro-
`cessing protocol according to the invention;
`FIG. 2 is a flow diagram showing a transaction according
`to the invention;
`FIG. 3 is a flow diagram showing a capture protocol
`according to the invention; and
`FIG. 4 is a flow diagram showing a settlement protocol
`according to the invention.
`
`DEfAJLED DESCRilTION OF THE
`lNVENTION
`The invention herein described implements a secure cou(cid:173)
`rier electronic payment system that provides customers,
`merchants, and banks with a secure mechanism for using a
`public network as a platform for credit card payment ser(cid:173)
`vices. The described system governs the relationship
`between the Customer, Merchant. and Acquiring bank
`(referred to herein as the Acquirer Gateway) to perform
`credit card purchases securely over such networks as the
`Internet. The system uses a secure connection (transport) to
`simplify the problem of Internet-based financial transac(cid:173)
`tions.
`The electronic payment protocol described herein is a
`three-, four-, or more-way communications protocol. The
`primary parties are the Customer (buyer), the Merchant
`(seller), and the payment gateway (representing the Acquir(cid:173)
`ing bank.) The issuing bank's
`involvement herein is
`assumed to be through the private networks in use by such
`bank today. Because such private networks are well under(cid:173)
`stood in the art, the discussion herein does not address issues
`that are related to having the issuing bank attached to the
`Internet.
`The protocol herein described is used to secure credit card
`payments and to certify infrastructure that is required to
`enable all of the parties to participate in the electronic
`commerce by using the internet, as well as to provide the
`necessary formats and interfaces between the different mod(cid:173)
`ules and systems. The system is designed to use the inter(cid:173)
`active model of the World Wide Web in common use today
`for client-server transactions on the Internet. However, the
`preferred embodiment of the invention is applicable to other
`delivery mechanisms, such as store-and-forward
`type
`mechanisms.
`Electronic Commerce Using Credit and Debit Cards
`The following discussion outlines the security issues
`involved in an electronic credit/debit card payment mecha(cid:173)
`nism using the Internet. The security requirements can be
`divided into two classes:
`connection (or channel) security, and
`payment specific security.
`Channel security can be provided by a secure transport
`layer (10; FIG. 1). while a higher layer electronic payment
`
`5
`
`15
`
`20
`
`4
`protocol (11) is needed to provide such features as signature,
`non-repudiation, and secondary encryption. The secondary
`encryption term defines encryption of certain data fields for
`decryption by a third party, not necessarily the recipient of
`the entire message. The payment protocol uses two secure
`channels, one channel between the customer and the
`merchant, and the other channel between the merchant and
`the acquirer or payment gateway. However, the payment
`specific financial messages communicated between the cus-
`10 tamer and the merchant are protected as part of the payment
`protocol without assumptions for a secure channel.
`The protocol is designed to use an underlying secure
`transport layer for the following reasons:
`Simplify the payment protocol because node-to-node
`authentication, privacy, and data integrity are automati(cid:173)
`cally achieved by the transport layer. This removes the
`conditions of guaranteeing message integrity and pri(cid:173)
`vacy from the payment protocol.
`Separate connection encryption, authentication, and
`integrity from the payment protocol provides for more
`flexibility in supporting future secure Internet Protocol
`(IP) or similar mechanisms.
`The secure transport layer supports data privacy and
`integrity for the communications between any two nodes.
`25 This implies that two secure channels are setup, one channel
`between the customer and the merchant (12; FIG. 1) and the
`other channel between the merchant and the payment gate(cid:173)
`way (14). Also, authentication of the appropriate nodes is a
`function of the secure transport. In particular, the payment
`30 protocol assumes the following properties of the underlying
`secure transport:
`Privacy
`All channel communications between any two nodes in
`the system should be encrypted. This guards against any
`35 network snooping and does not give any information to
`possible attackers.
`Authentication
`There are two distinct forms of authentication that need to
`be addressed:
`First, all merchants and acquirers should be authenticated
`to each other and to customers. Customer authentica(cid:173)
`tion is supported as an option.
`Second, support for signature for proof of authorship and
`receipt for non-repudiation purposes may be necessary
`for some applications.
`The first form of authentication can be achieved by a
`reliable secure transport mechanism. The second form must
`access the fields and values that need to be signed, and
`50 therefore should be performed in the application.
`Data Integrity
`Integrity is maintained at all times using a keyed message
`digest computation. This should be a part of the channel
`security mechanism. An extra layer of integrity is added to
`55 the message level using a hash of each message to avoid
`early termination type attacks, and to make sure that the
`messages arrive at the recipient unaltered.
`The payment protocol, on the other hand, is concerned
`with payment specific issues. These issues are outlined
`60 below:
`Confidentiality of the credit card number, PJN, and other
`customer information. These items are kept encrypted
`with regard to all parties, including the merchant han(cid:173)
`dling the transaction.
`Confidentiality of the specific order information from all
`parties other than the Merchant. This includes, for
`example the acquiring and issuing banks.
`
`40
`
`45
`
`65
`
`IPR2022-01239
`Apple EX1013 Page 6
`
`

`

`5,671,279
`
`6
`
`Unauthorized entities should not have any access to
`
`5
`The Customer Application (16; FIG. 1).
`
`
`Digital signatures on the various messages communicated
`
`
`
`
`
`
`between the different parties to ensure authorship. It is
`
`
`
`The customer possesses the following information:
`
`important to point out that this is different from node
`
`
`
`Personal Account (Credit Card) Number (PAN), billing
`
`
`
`
`authentication because, in several cases, message
`
`
`
`address information, PJN for various accounts, and any
`
`
`
`authorship proof is needed between two parties that are 5
`
`
`other confidential information that may be required for
`
`
`not directly communicating with each other.
`
`authorization purposes.
`Notation
`
`Name and shipping address information.
`K { value }=value encrypted under K using a symmetric­
`
`
`
`
`Optionally, one or more digital certificates.
`key algorithm.
`
`
`
`PKx{key}=key encrypted under the Public Key (PK) for
`
`
`
`A connection to a network, such as an interactive (World
`10
`
`
`
`x using a public-key algorithm, where x can be C for
`
`
`
`Wide Web for example) connection can exploit all of
`
`
`customer, M for Merchant or A for Acquirer.
`
`
`the features of the herein described system.
`
`E{ value }=encryption of value under a data encryption
`
`Customer Requirements
`
`
`key that is encrypted under the public key of the
`
`
`
`
`
`
`recipient. This construction is commonly referred to as 15
`
`transactions on the wire.
`
`a digital envelope.
`
`
`The credit card information can be hidden from the
`
`
`
`H(value )=The message digest of value using a negotiated
`
`
`
`
`merchant to prevent attacks on the Merchant's server
`
`
`message digest algorithm.
`
`
`by hackers on the Internet, as well as to prevent
`
`Cx. CERfx=The certificate of entity x.
`
`unauthorized charges by Merchants.
`
`
`
`Sx(Value)=The value combined with the digital signature
`20
`
`
`
`
`Optional receipts signed by the merchant to allow the
`
`
`of the entity x using its private key. The signature could
`
`customer to obtain proof of the transaction.
`
`be verified using the public key PKx from the certifi­
`
`
`
`Prevention of unauthorized transactions, such as transac­
`cate Cx. If entity x does not have a public-private
`
`
`
`tion replays by an attacker, modified transactions, or
`
`
`key-pair, then a low grade signature can be generated
`fake transactions.
`using a hash of the Value with some information from
`25
`
`
`
`The customer application implements all of the browsing
`x.for example a credit card number, some personal
`
`
`
`and shopping functions, as well as generating Purchase
`
`
`information about x, such as social security number,
`
`
`
`
`Orders, payment information (PI), and signatures for trans­
`
`
`
`billing address information, or a PJN.
`
`
`
`actions. Additional functions needed to support electronic
`
`
`
`
`The protocol description herein applies to any account
`
`credit card transactions are listed below:
`
`
`
`based payment mechanism, with an emphasis on credit 30
`
`
`
`Receive price and product information from the merchant
`
`
`cards. Thus, the basic protocol also applies to other payment
`
`
`
`and encrypt the transaction ID supplied from the mer­
`methods.
`
`chant with the credit card number or other financial
`Interactive Vs. Store-and-Forward Design Methodologies
`
`
`
`
`
`
`
`information. This information is made accessible to the
`
`
`
`
`The system described herein uses the advantages that an
`
`
`
`
`acquirer only using the acquirer's public-key, which is
`
`
`
`
`interactive environment provides to the customer and mer-35
`
`
`extracted from the acquirer digital certificate.
`
`
`
`chant. However, the basic scheme is usable for a store and
`
`
`
`Verify signatures from the merchant to ensure the origi­
`
`
`forward mechanisms as well. An interactive environment,
`
`
`nation of messages. Make sure the Order as supplied in
`
`
`such as available using the World Wide Web, provides all
`
`
`
`the receipt matches the original order generated by the
`
`
`
`
`parties with an immediate response that indicates the status
`
`customer earlier.
`
`
`of the messages communicated. An immediate acknowledge
`40
`Generate signatures on payment messages using an
`
`
`
`
`
`
`
`
`for the delivery of a payment message, for example, pro­
`
`
`optional public key certificate.
`
`
`
`vides the customer with feedback as to the status of an order.
`
`
`The Merchant application (18; FIG. 1)
`
`
`Such facility is not available with a store-and-forward
`
`
`
`The Merchant possesses the following information:
`
`
`
`environment. It is considered important for a successful
`
`
`
`system to support state of the art mechanisms, such as the 45
`
`
`
`Merchant ID number (MID) assigned by the acquirer to
`
`
`
`World Wide Web, because such system provides the user
`
`
`
`each Merchant. These MIDs may be globally unique or
`
`
`with an immediate feedback as to the status of the order,
`
`
`
`unique to a specific acquirer, depending on the imple­
`
`
`
`somewhat similar to a customer in the store payment model.
`mentation.
`
`
`Protocol Design Requirements
`
`Merchant name and address.
`
`
`
`
`The following discussion describes the requirements that 50
`
`
`Merchant digital certificate(s).
`
`
`
`the electronic payment system has to satisfy to meet the
`
`
`Name and information about the Merchant's Acquirer(s),
`
`
`
`Business requirements of electronic commerce. There are
`
`
`
`
`including the Acquirer' s financial certificate and infor­
`
`
`
`
`
`different requirements for each of the entities involved. The
`
`
`mation about how to communicate with the Acquirer' s
`
`
`
`
`following sections describe the requirements of the payment
`Gateway.
`
`
`
`
`protocol applications. The protocol presented herein is simi-55
`A database of all open transactions with corresponding
`
`
`
`
`lar to systems proposed by several other protocols from
`
`
`Transaction IDs and AuthIDs with customer informa­
`
`
`
`
`other vendors (see the discussion above), but supports a
`tion.
`
`
`
`complete suite of credit/debit card transactions and uses a
`
`Merchant Requirements
`
`
`
`
`secure transport layer. The intention is to provide an
`Efficient and automated operation of payment authoriza­
`
`
`
`
`
`
`
`
`efficient, secure protocol for processing payment transac-60
`
`
`
`tion and capture through the Internet or using existing
`
`
`tions that is readily adopted by merchants and financial
`
`
`internal capture systems.
`institutions.
`Authenticated (signed) authorization and capture
`
`
`
`
`
`
`
`In general, the protocol also includes an acknowledge for
`
`responses from the acquirer.
`
`
`
`
`each message to provide the message sender with feedback
`
`
`
`The Merchant's application provides all the server func­
`
`
`
`as to the status of the message. Thus, the sender is expected
`65
`
`
`
`tions for the customers to obtain product information and
`
`
`
`
`to resend a message if an acknowledge is not received within
`
`
`
`
`pricing. It also serves as an intermediate between the cus-
`
`a specified period of time.
`
`IPR2022-01239
`Apple EX1013 Page 7
`
`

`

`5,671,279
`
`8
`
`PIN
`Billing address
`Shipping Address
`Resp-Code: Response code from the authentication pro(cid:173)
`cess.
`Auth-Code: A 6-digit number returned by the banking
`network to use for clearing/capture steps.
`Icdata
`CaptureResp: A response for the capture process.
`Validity Period: Start and expiration dates for a message.
`Date: Date and time stamp.
`Digital Signature: A digital signature as defined in this
`document comprise the following:
`
`SIGNx(data)=Sx(data, nonce, date), nonce, date, signer's certifi(cid:173)
`cate.
`
`10
`
`15
`
`30
`
`7
`tomer and the acquirer. The merchant application should
`also include the following to allow performance of credit
`card transactions:
`Generate a transaction ID for each customer order. The
`transaction IDs are generated sequentially and used 5
`only once. The transaction ID is used to track an order
`until it has been authorized by the acquirer.
`Verify the acquirer signature on capture responses and the
`customer signature on receipts.
`Generate receipts for customer signature optionally.
`Generate digests of order information for the acquirer to
`verify authenticity of the purchase order.
`The Acquirer (Gateway) Application (20; FIG. 1)
`The Acquirer possesses the following information:
`Acquirer name and address.
`Acquirer digital certificate.
`Names and information, including certificates, about the
`Merchants that are signed up with the Acquirer. This
`can be implemented as a database of merchants stored 20
`encrypted on the gateway machine.
`A table with each merchant's current open Transaction
`IDs and corresponding AuthlDs tagged with each mer(cid:173)
`chant's MID.
`Acquirer' s Requirements
`Support for different methods of managing transactions,
`one time, recurring, and partial shipment included.
`Authenticated transactions by signed-up merchants.
`The acquirer application is typically an addition to a set of
`products that are needed to complete financial transactions
`over the Internet. The acquirer application performs the
`following functions:
`Receive order amount and Transaction ID with customer
`financial information and perform credit card authori(cid:173)
`zations.
`Receive capture requests and perform capture confirma(cid:173)
`tion.
`Translate a standard message format from the Merchant
`into the proper formats used by the existing authoriza(cid:173)
`tion network (40; FIG. 1).
`The Credit Card Based Electronic Commerce Payment
`Protocol
`Message Definitions
`This following discussion outlines and defines all the
`needed quantities and message components for the messages
`used in the payment protocol:
`PAN: The personal account number for the card holder.
`Normally this is a credit card number.
`Expiration Date: The 5 digit expiration date of the card.
`Merchant
`ID: A unique number for each merchant
`assigned by the acquirer signing up the merchant. The
`merchant ID is unique for each acquirer, and thus
`includes the acquirer ID as part of it to generate a
`globally unique number. The acquirer ID is assigned by
`the card associations and is not transmitted alone as
`part of this system.
`Transaction ID: A unique number assigned by the mer(cid:173)
`chant for each transaction. The merchant and the card 60
`holder can use this number in conjunction with the
`merchant ID to identify any particular transaction.
`Acquirer Certificate
`Merchant Certificate
`Total Amount
`H(Order)
`
`The above format ensures that all signatures are fresh and
`dated. Providing the certificates with the signatures simpli(cid:173)
`fies the exchange of the certificates.
`Message Flow and Definition
`The protocol described below assumes that merchants and
`credit card acquirers possess digital certificates. The client
`( customer) may possess one or more digital certificates as an
`25 option.
`The protocol divides the needed operations into a set of
`basic protocols that are described first. The following dis(cid:173)
`cussion describes how each type of financial transaction is
`accomplished. All protocols
`support
`full privacy,
`authentication, non-repudiation, and integrity. The underly-
`ing Session layer provides all connection security functions,
`e.g. privacy, authentication, and integrity, from the channel's
`point of view. Any document or field (data element) level
`security operations are preferably performed at the applica-
`35 tion level.
`The contents of each message depend on the actual
`operation (purchase, return, etc ....
`) performed. Therefore,
`these contents are discussed under each operation section
`below.
`The protocols outlined below start as the customer is
`ready to purchase some items from the merchant using a
`credit card. It is assumed that the customer is already
`finished with his shopping and has made the decision to
`purchase something.
`The customer sends a message (19; FIG. 1) to the mer-
`chant requesting a price quote for the items of choice before
`the payment instruction message start.
`The Date and Time fields in all the following messages are
`newly attached by the node creating the message. This
`50 allows the different entities to get higher assurance about the
`freshness of the transaction.
`The Capture and settlement groups described below can
`replace modem methods, that use lease lines or private
`networks, without disrupting the protocol. This enables
`different acquirers to implement portions of the protocol in
`steps, while maintaining backwards compatibility with
`existing systems throughout the phase-in process. Initial
`implementations do not have to implement those sections.
`Each Secure Courier message 19 includes two parts:
`the message wrapper (30; FIG. 1), and
`the message body (31; FIG. 1).
`The contents of the message body of each message are
`described below. The message wrapper consists of the
`65 following elements:
`Order Number, and
`routing information.
`
`40
`
`45
`
`55
`
`IPR2022-01239
`Apple EX1013 Page 8
`
`

`

`5,671,279
`
`9
`Each of the messages below consists of two parts. The
`forward part is described in detail for each message, while
`an optional acknowledge is generated by the recipient and
`sent to the sender to ensure the receipt of the message. The
`acknowledge is a hash of the message, which actually proves 5
`the receipt by the appropriate recipient because of the use of
`the SSL layer that guarantees an authenticated channel. The
`time of receipt is concatenated to the hash and the concat(cid:173)
`enated message is used as an acknowledge.
`In addition, each message is considered to be expired if it
`is received after the message's validity period is over.
`To authenticate further the acknowledge messages, a
`digital signature can be used instead of a hash and the time
`stamp. If the original message has expired, then a denial is
`received instead and the sender is asked to repeat the
`operation.
`In an authorization group (see FIG. 1) consisting of a
`customer C. a merchant M, and a Gateway G, a transaction
`(FIGS. 2 and 3) that includes the Purchase-Order, Payment
`Instruction (PI) message below causes the Merchant to
`respond with:
`
`15
`
`20
`
`10
`
`10
`
`PI: C(cid:157) M
`The PI message is a signed message from the Card Holder
`using the Slip described below.
`Slip
`Version, current date, expiration date (Validity Period),
`Total Amount, Currency, Orderhash, MerAcqHash,
`Credit Card information (Cardlnfo).
`where:
`Order=Hash of the order descript