(12) United States Patent
`Fox et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,003,480 B2
`Feb. 21, 2006
`
`USOO70034.8OB2
`
`5,764,789 A * 6/1998 Pare, Jr. et al. ......... 340/825.34
`5,790,677 A * 8/1998 Fox et al. ..................... 705/78
`
`(Continued)
`FOREIGN PATENT DOCUMENTS
`
`JP
`
`(54) GUMP: GRAND UNIFIED META-PROTOCOL
`FOR SIMPLE STANDARDS-BASED
`ELECTRONIC COMMERCE
`TRANSACTIONS
`(75) Inventors: Barbara L. Fox, Seattle, WA (US);
`* 10/1983
`58168179
`Brian A. LaMacchia, Seattle, WA
`OTHER PUBLICATIONS
`(US); Brian C. Beckman, Newcastle,
`WA (US)
`Bruce Schneier, Applied Cryptography, 2d. (New York: John
`(73) Assignee: Microsoft Corporation, Redmond, WA Wiley & Sons, Inc., 1996). pp. 58-59, Jan. 1, 1996.*
`(US)
`(Continued)
`Subject to any disclaimer, the term of this
`Trinary Examiner James W. Myhre
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 812 days.
`(74) Attorney, Agent, or Firm-Ronald M. Anderson
`(21) Appl. No.: 09/032,407
`(57)
`ABSTRACT
`
`(*) Notice:
`
`(22) Filed:
`
`Feb. 27, 1998
`
`A method for facilitating two-party electronic commerce
`transactions between trading partners on an unsecure net
`work, Such as the Internet. In one example, a client makes
`application for registration by a financial institution in which
`the client has one or more accounts. The client Submits
`Satisfactory proof of identity and a public key portion for a
`digital Signature to the financial institution. The financial
`institution may provide the client a one time Secret by a
`Secure route, Such as conventional mail, which can then be
`used by the client to show proof of its identity. The financial
`institution authenticates the one time Secret and combines it
`with the client's public key in a GUMP Relationship Cer
`S. For Classification search- - - - - - - - 705/26; E. tificate (GRC), which it issues to the client over the network.
`Once issued, the GRC can be used by the client to authen
`705/76, 69, 75, 78; 380/24, 23, 25, 21, 280;
`ticate its right to access its account(s) or other products or
`723/200; 235/380; 382/100
`Services at the financial institution and when conducting
`See application file for complete Search history.
`other electronic transactions over the network. The client
`digitally signs any such transaction to authenticate its right
`References Cited
`to conduct the transaction. A delegate may be enlisted by the
`client to negotiate the purchase of goods from a Seller or for
`other purposes, using a GUMP Delegate Certificate. The
`2. A :
`5, ME al - - - - - - - - - - - - - - 3. concept can be extended to other three party transactions,
`5,455,407 A * 10/1995
`yet alm
`such as issuing an electronic Letter of Credit (LOC).
`2- - -a-
`aWaS C all. . . . . . . . . . . . . . . . .
`5,557,518 A
`9/1996 Rosen ......................... 705/69
`5,717.989 A * 2/1998 Tozzoli et al. ................ 705/37
`25 Claims, 14 Drawing Sheets
`
`(65)
`
`Prior Publication Data
`US 2002/0069174 A1
`Jun. 6, 2002
`Related U.S. Application Data
`(60) Provisional application No. 60/039,176, filed on Feb
`pp
`s-u-
`s/s
`27, 1997.
`(51) Int. Cl.
`G06F I 7/60
`
`(2006.01)
`
`(56)
`
`U.S. PATENT DOCUMENTS
`
`
`
`BEQUESTIGDoE
`
`RECUESTHGC-CNT
`KEY
`
`12
`
`34
`(FYP)
`
`TERMs
`RMS
`
`w
`
`
`
`147
`
`CLINT
`PUBLC
`KEY
`
`sun
`
`SELLER |
`
`w
`
`EyRCHASE
`
`CENT
`
`157
`
`158 (OPTIONAL
`CEN
`
`
`
`-4 157
`48
`
`12
`
`LeGATE
`
`CENT - GDC-1147
`UBC
`KY
`
`SELLER ||
`w
`
`SE
`KY
`
`2
`
`12
`
`EGATE
`
`157
`
`T
`
`SeLLR
`
`y
`
`ceNT
`PUBLC
`KY
`
`IPR2022-00412
`Apple EX1047 Page 1
`
`

`

`US 7.003480 B2
`Page 2
`
`U.S. PATENT DOCUMENTS
`5,799,086 A
`8/1998 Sudia .......................... 705/76
`5,832,089 A * 11/1998 Kravitz et al. ..
`... 705/69
`5,832,100 A * 11/1998 Lawton et al. ..
`... 382/100
`5,878,139 A * 3/1999 Rosen .........
`... 705/75
`5,892.900 A * 4/1999 Ginter et al.
`... 713/200
`5.987,132 A * 11/1999 Rowney ...................... 380/24
`
`
`
`OTHER PUBLICATIONS
`Fox, B. and Beckman, B. “GUMP Grand Unified Meta
`Protocols recipes for Simple, Standards-based financial cryp
`tography.” (Berlin: Springer-Verlag, 1997) Abstract. pp.
`1-2.*
`
`* cited by examiner
`
`IPR2022-00412
`Apple EX1047 Page 2
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 1 of 14
`
`US 7,003,480 B2
`
`DELEGATION
`(OPTIONAL)
`----------- V
`
`
`
`
`
`TRANSACTION
`
`O4
`
`06
`
`100
`
`IPR2022-00412
`Apple EX1047 Page 3
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 2 of 14
`
`US 7,003,480 B2
`
`SART
`
`114
`
`16
`
`APPLICATION FOR
`GRC
`
`
`
`DENTIFICATION OF
`CLENT TO FI
`
`
`
`118
`
`KEY
`(OPTIONAL)
`
`
`
`
`
`
`
`REQUEST GRC
`
`120
`
`
`
`
`
`SSUE GRC
`
`122
`
`
`
`FIG. 2
`
`IPR2022-00412
`Apple EX1047 Page 4
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 3 of 14
`
`US 7,003,480 B2
`
`APP. CATION
`
`
`
`114
`
`REO UEST
`
`11
`
`
`
`CENT
`
`12
`(TYP.)
`
`-------------------------------------------
`DENTIFICATION
`121
`116f N
`
`
`
`
`
`
`
`CENT
`PUBLC
`KEY
`
`KEY
`(OPTIONAL STEP)-1- 118
`CLENT
`
`117
`
`OTS
`
`RECQUEST
`
`119
`
`117
`
`121
`
`y
`
`w
`
`20
`
`
`
`
`
`
`
`
`
`CLENT
`PUBLC
`KEY
`
`F
`PUBLC
`KEY
`
`108
`
`FIG. 3
`
`IPR2022-00412
`Apple EX1047 Page 5
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 4 of 14
`
`US 7,003,480 B2
`
`
`
`
`
`
`
`F
`PUBLC
`KEY
`
`CENT
`PUBLC
`KEY
`
`117
`
`131
`
`
`
`121
`
`F
`PUBLC
`KEY
`
`CLIENT
`PUBLC
`KEY
`
`CLENT
`PUBLC
`KEY
`
`
`
`131'
`
`F
`PRIVATE
`KEY
`
`FIG. 3A
`
`
`
`
`
`CL ENT
`PUBLC
`KEY
`
`141
`
`
`
`DELEGATE
`PUBLIC
`KEY
`
`CLENT
`PRVATE
`KEY
`
`121
`
`FIG. 5A
`
`CENT
`PUBLIC
`KEY
`
`DELE GATE
`PUBLC
`KEY
`
`
`
`
`
`121
`
`CLENT
`PRVATE
`KEY
`
`FIG. 7A
`
`
`
`121'
`
`CLENT
`PRIVATE
`KEY
`
`FIG. 9A
`
`IPR2022-00412
`Apple EX1047 Page 6
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 5 of 14
`
`US 7,003,480 B2
`
`
`
`NEGOTATE
`PRICE FOR
`PRODUCT
`
`126
`
`PURCHASE
`PRODUCT
`
`130
`
`CONFIRM
`PURCHASE
`(OPTIONAL)
`
`132
`
`101
`
`FIG. 4
`
`IPR2022-00412
`Apple EX1047 Page 7
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 6 of 14
`
`US 7,003,480 B2
`
`125
`
`123
`
`134.
`(TYP.)
`
`131
`
`F
`PUBLC
`KEY
`
`NEGOTATION
`- M - 1 in V ly-126'
`
`
`
`CLENT
`
`(TYP.)
`
`PURCHASE
`
`CLENT
`
`
`
`
`
`
`
`123
`
`121
`
`131
`
`CLENT
`PUBLC
`KEY
`
`F
`PUBLC
`KEY
`
`CONFIRMATION
`(OPTIONAL)
`
`132
`
`
`
`133
`
`
`
`
`
`124
`
`CENT
`PUBLC
`KEY
`
`w
`
`W
`
`:
`w
`
`IPR2022-00412
`Apple EX1047 Page 8
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 7 of 14
`
`US 7,003,480 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`START
`
`ENLIST
`DELEGATE
`
`SHARE KEY
`(OPTIONAL)
`
`REQUEST GDC
`FROM CLENT
`
`ISSUE GDC TO
`DELEGATE
`
`136
`
`138
`
`40
`
`42
`
`149
`
`FIG. 6
`
`IPR2022-00412
`Apple EX1047 Page 9
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 8 of 14
`
`US 7,003,480 B2
`
`ENLIST
`
`(TYP.)
`
`
`
`KEY
`(OPTIONAL STEP)
`CLENT
`
`38
`
`4.
`
`REQUEST
`
`143
`
`41
`
`145
`
`14 O'
`
`CLENT HREO UEST
`
`DELEGATE
`PUBLC
`KEY
`
`TYP.)
`
`DELE GATE
`
`
`
`DEEGATE
`
`:
`
`y
`
`y
`
`ISSUE
`
`142
`
`CLENT
`
`147
`
`121
`
`
`
`CLENT
`PUBLC
`KEY
`
`
`
`DELEGATE
`
`46
`
`FIG. 7
`
`IPR2022-00412
`Apple EX1047 Page 10
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 9 of 14
`
`US 7,003,480 B2
`
`NEGOTATE PRICE
`BETWEEN DELE GATE
`AND SELLER
`
`152
`
`REQUEST GDC Ir'
`FROM CLENT
`
`
`
`
`
`
`
`PURCHASE
`PRODUCT
`
`156
`
`CONFIRM
`PURCHASE
`(OPTIONAL)
`
`158
`
`129
`
`FIG. 8
`
`IPR2022-00412
`Apple EX1047 Page 11
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 10 of 14
`
`US 7,003,480 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Z9||NOILVW HI-NOO
`
`(TVNOILdO)
`
`IPR2022-00412
`Apple EX1047 Page 12
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 11 of 14
`
`US 7,003,480 B2
`
`
`
`APPLICATION
`FOR LOC BY
`CLENT
`
`OPENING BANK
`SGNS AND ISSUES
`GRC THAT
`REFERENCES LOC
`
`PURCHASE
`PRODUCT WITH
`GRC
`
`COLLECT PAYMENT
`WITH GRC SG NED
`BY ADWSNG BANK
`
`160
`
`FIG. I. ()
`
`IPR2022-00412
`Apple EX1047 Page 13
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 12 of 14
`
`US 7,003,480 B2
`
`
`
`
`
`NOI LOETTOO
`
`
`
`
`
`
`
`IPR2022-00412
`Apple EX1047 Page 14
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 13 of 14
`
`US 7,003,480 B2
`
`OPENING
`PUBLIC
`KEY
`
`
`
`
`
`CLENT
`PUBLC
`KEY
`
`
`
`
`
`165
`
`OPENING
`PRIVATE
`KEY
`
`FIG. I. IA
`
`
`
`78
`
`ADWSNG
`PUBLC
`KSY
`
`
`
`
`
`
`
`176
`
`OTS
`
`CLENT
`PUBLIC
`KEY
`
`ADWSNG
`PRIVATE
`KEY
`
`
`
`178"
`
`FIG. I. IB
`
`IPR2022-00412
`Apple EX1047 Page 15
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 14 of 14
`
`US 7,003,480 B2
`
`ALOWSY
`
`YALNdNOD
`
`NOILVOMddV¥
`
`SNVeDOud
`
`(LYVYOINd)
`COMCeca),
`
`WIHaS“°9'3)]})SOVSHSLNI
`
`
`
`
`
`
`
`YHOLINOWOAQIAONISSSAOOWd||Ly|
`
` Saindow
` ANN
`
`
`AOVAYALNI
`
`
`
` MYHOMLAN ISYaLdvayLINN
`
`ONILVYSdO
`
`WALSAS
`
`_SWVedD0ud
`
`NOILVONddV¥
`
`
`
`Wv¥d90u"dYSHLO
`
`
`
`
`
`ADIARGO/WolLdOOLLANDVAYSIGGHYVH
`
`
`
`AOVAYSLNIAAIMSIOAAIHOSIGSAOVivdWvdS0u’"d
`
`AOVAYALNI
`JOVSAYALNI
`
`IPR2022-00412
`Apple EX1047 Page 16
`
`IPR2022-00412
`Apple EX1047 Page 16
`
`
`
`
`
`
`
`

`

`US 7,003,480 B2
`
`1
`GUMP: GRAND UNIFIED META-PROTOCOL
`FOR SIMPLE STANDARDS-BASED
`ELECTRONIC COMMERCE
`TRANSACTIONS
`
`RELATED APPLICATION
`
`This application is a continuation-in-part of prior now
`abandoned provisional Application Ser. No. 60/039,176,
`filed Feb. 27, 1997, priority in the filing date of which is
`hereby claimed under 35 United States Code Section 119(e).
`FIELD OF THE INVENTION
`
`The present invention generally relates to a method for
`performing electronic commerce transactions, and more
`Specifically, to a method or protocol that Simplifies two-party
`electronic commerce transactions between trading partners,
`So as to ensure the authenticity of a trading partner during a
`transaction conducted over a network.
`
`15
`
`BACKGROUND OF THE INVENTION
`
`Electronic commerce is a relatively new term used to
`describe any form of computerized financial transaction
`between business trading partners, both by consumerS and
`from company to company. These financial transactions are
`performed by the exchange of electronic versions of com
`merce instruments and documents. Examples of commerce
`instruments include credit cards, checks, and forms of
`currency. Examples of commerce documents include
`receipts, bills of lading, purchase orders, contracts, and
`Letters of Credit. Generally, the computerized exchange of
`a commerce instrument and/or document is implemented
`through the transfer of Structured data by electronic means
`from one computer application to another computer appli
`cation over Some type of network, Such as a local area
`network (LAN), wide area network (WAN), or the Internet,
`using mutually agreed upon message Standards.
`A growing number of financial applications are migrating
`to networks, Such as the Internet. Some applications, like
`home banking and bill payment, are already commonly
`conducted as electronic transactions over networks. Other
`newer applications, like brokerage account management and
`business-to-business purchasing, are being adapted for
`implementation over the Internet. In each of these applica
`tions, there is a common need to protect certain interests of
`the trading partners and minimize the risks to all participants
`in regard to the following concerns.
`If electronic transactions over public networks are to be
`accepted, there must be Some assurance that the participants
`are authentic (each participant must be who they claim to
`be), and the documents and instruments electronically
`eXchanged between parties must have integrity. Further, all
`participants must have a reasonable expectation that the
`transaction may not be repudiated at a later date. There is
`also a need for privacy, So that the knowledge of a transac
`tion may be kept Solely among the participants and not
`accessible by any unauthorized party. Furthermore, a finan
`cial application must coexist with the existing legacy elec
`tronic financial Systems.
`Historically, most of these requirements were met in
`legacy Systems by the employment of a proprietary and
`closed electronic commerce System that had a high Security
`protocol. In Such a System, the participants and the elec
`tronic instruments and documents are authentic and private
`by definition and by the Steps taken to prevent access to the
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Secure System by others. Further, the integrity of instruments
`and documents and their non-repudiation were controlled by
`the proprietary nature of the closed commerce System.
`However, interaction with other Secure commerce Systems
`was typically not provided.
`The transition from closed commerce Systems to transac
`tions conducted over a public network Such as the Internet
`has been eased by the availability of public-key cryptogra
`phy. Virtually all web servers and client browsers support
`Secure-channel protocols and public-key authentication, at
`least on the server. With the recent deployment of the Secure
`Sockets Layer (SSL) protocol, public-key authentication by
`the client is now also widely available. Thus, many of the
`requirements noted above to enable the use of financial
`applications on the Internet (or other public access network)
`are becoming commonplace protocols, which are readily
`available.
`However, as the number for electronic financial transac
`tions conducted over public networks continues to increase,
`there has developed a need for a simplified (computationally
`less intensive) method or meta-protocol that will facilitate
`two-party financial transactions between trusted and non
`anonymous trading partners. In financial transactions,
`“trust' does not have a moral connotation. Instead, financial
`trust indicates that a trading partner has shown either by
`previous activities or Submission of documents/instruments
`that the trading partner will be responsible for financial
`obligations arising from the transaction. Trusted trading
`partners can provide each other with a reasonable expecta
`tion of integrity, privacy and non-repudiation. Since the
`amount of encryption required to guarantee integrity and
`privacy for a two-party transaction between trusted partners
`is less than transactions between Strangers, the computa
`tional overhead should be reduced. Thus, there is a need in
`the financial community for a simplified method or protocol
`that will facilitate two-party electronic commerce transac
`tions between trading partners connected on a public net
`work. This method should enable two parties to become
`trusted trading partners by defined Series of Steps that
`provide the required assurance of authenticity, privacy, and
`non-repudiation.
`
`SUMMARY OF THE INVENTION
`
`In accord with the present invention a method is defined
`for enabling a user to perform an electronic commerce
`transaction over an unsecure network without requiring
`encryption. The user (first party) applies for registration with
`a Second party, the first party having access to financial
`resources through the Second party. A certified identifier of
`the first party is presented to the Second party for enabling
`the Second party to confirm a true identity of the first party.
`The Second party transferS a certificate to the first party over
`the unsecure network. The certificate is digitally signed by
`the Second party and includes the certified identifier, which
`provides an indeX to the financial resources accessible to the
`first party through the Second party. The certificate is digi
`tally signed by the first party and provided to a Seller over
`the unsecure network. The signed certificate indicates that
`the first party agrees to make a payment for goods provided
`by the seller in an amount indicated in the certificate. The
`Seller presents the Signed certificate to the Second party over
`the unsecure network in exchange for the payment for
`goods. The Second party employs the amount indicated in
`the signed certificate to make the payment to the Seller from
`the financial resources accessible by the first party.
`
`IPR2022-00412
`Apple EX1047 Page 17
`
`

`

`US 7,003,480 B2
`
`15
`
`25
`
`35
`
`40
`
`3
`Preferably, the identifier is a one time secret (OTS) that
`enables the Second party to initially confirm the identity of
`the first party. The OTS is associated with a public key of the
`first party's digital Signature that is Submitted by the first
`party to the second party. Next, the OTS becomes an
`unsecret and Serves as the indeX to the financial resources
`accessible to the first party through the Second party. Also,
`the unsecret is bound to the public key of the digital
`Signature of the first party in the certificate. Further, the
`unsecret may be a hash value of data known to the Second
`party. In one embodiment, the unsecret is the result of
`hashing reference numbers for the financial resources acces
`Sible to the first party. In another embodiment, the unsecret
`is a hash value computed over any data known to the Second
`party that may be unambiguously linked to the financial
`resources of the first party. In yet another embodiment, the
`unsecret is derived from information shared between the first
`party and the Second party.
`Additionally, the digital Signature is unique to the first
`party and includes both the public key and a private key, the
`private key being employed by the first party to transform
`the certificate, creating an encoded certificate, and the public
`key being employed by others to verify the encoded certifi
`Cate.
`The first party may apply to a registry for registration of
`the first party's digital Signature. The registry will attempt to
`confirm the true identity of the first party. If confirmed, the
`digital Signature of the first party will be registered with the
`registry. The registry will continue to register the digital
`Signature until the registry is informed that the private key
`asSociated with the digital Signature is not Secure. Also, the
`first party may provide to the registry a certificate issued by
`another registry. The registry will employ the certificate
`issued by the other registry to confirm the identity of the first
`party.
`In one embodiment, the first party Submits a certificate
`issued by a third party to the Second party as the certified
`identifier to prove the true identity of the first party, each
`additional different certificate thus submitted tending to
`increase a measure of confidence by the Second party that the
`identity of the first party is true. For another embodiment,
`the Second party will employ a replay detector to determine
`if the certificate digitally signed by the first party has been
`reused since it was signed.
`In another embodiment, the first party issues a delegation
`certificate to a delegate over the unsecure network. The
`delegation certificate provides the delegate with an authority
`to negotiate with the seller on behalf of the first party. When
`the first party digitally signs the delegation certificate, the
`payment for the goods provided by the Seller in an amount
`indicated in the certificate is authorized. The delegate pre
`Sents the Signed delegation certificate to the Seller in
`eXchange for the goods. The Seller redeems the delegation
`certificate with the Second party to obtain the payment from
`the financial resources accessible by the first party.
`In yet another embodiment, the first party is a client and
`the Second party is a financial institution, Such as a bank. For
`another embodiment, the first party is a customer and the
`Second party is a non-financial institution, including a Ser
`Vice provider and a merchant.
`Another embodiment enables the first party (user) to
`obtain a certificate employed to facilitate transactions with
`the Second party over an unsecure network. The certificate is
`issued by the Second party and assures an authenticity of the
`first party. The first party provides proof of its identity to the
`Second party by Submitting a public key for the first party's
`digital Signature to the Second party over the unsecure
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`network. The second party confirms the identity of the first
`party and combines the public key with a unique reference
`identifying the first party in connection with business trans
`acted between the first and the second parties. The combi
`nation of the public key and the unique reference is
`employed to produce the certificate, which is digitally
`signed by the Second party. The certificate is issued to the
`first party over the unsecure network by the Second party.
`The first party is enabled to digitally sign and Submit the
`certificate to the Second party over the unsecure network to
`prove a right of the first party to transact busineSS with the
`Second party.
`A further embodiment enables a buyer to perform an
`electronic commerce transaction for goods on an unsecure
`network without requiring encryption, using a Letter Of
`Credit (LOC). The buyer applies for a LOC with an opening
`bank, which approves the LOC when the true identity of the
`buyer and terms of the LOC have been authenticated.
`Typically, the opening bank is associated with accessing the
`financial resources of the buyer. An identifier is provided to
`the opening bank that enables the opening bank to indepen
`dently determine the true identity of the buyer. The opening
`bank issues a certificate that is digitally signed by the
`opening bank and which includes the identifier and a refer
`ence to the LOC. The opening bank Sends the certificate to
`the client and a beneficiary, Such as a Seller, over the
`unsecure network. The beneficiary sends the certificate to an
`advising bank that is associated with the beneficiary. The
`Seller Sends a digitally signed commerce document to the
`advising bank over the unsecure network when the terms of
`the LOC have been met. The advising bank digitally signs
`and transmits the certificate over the unsecure network, to
`the opening bank for payment of the LOC. The Signing of
`the certificate by the advising bank indicates that the advis
`ing bank guarantees the Seller has met all of the terms of the
`LOC. The opening bank Sends the payment for the goods to
`the advising bank for dispersal to the beneficiary.
`Further, the advising bank may confirm that the certificate
`is valid with the opening bank prior to completion of the
`transaction. Also, the advising bank and the opening bank
`may confirm the terms of the LOC that must be completed
`before the certificate may be redeemed at the opening bank.
`The terms of the LOC may identify a type for the document,
`including a bill of lading and a receipt. The advising bank
`may review the performance of the terms of the LOC and
`negotiate with the Seller to ensure performance of the terms.
`If the advising bank determines that the seller has not met
`the terms of the LOC, the advising bank may advise the
`opening bank that the terms of the LOC have not been met.
`In addition, if the advising bank determines that the Seller
`has only partially completed the terms of the LOC, the
`advising bank may accept liability for completion of all
`terms of the LOC and digitally sign the certificate to confirm
`acceptance of the liability.
`Another aspect of the present invention is directed to a
`computer-readable medium having computer-executable
`instructions for enabling a user to perform an electronic
`commerce transaction over an unsecure network without
`requiring encryption. The computer-readable medium Stores
`a plurality of logical Steps that a digital computer System
`employs to implement a plurality of functions that are
`generally consistent with the Steps of the method described
`above.
`
`IPR2022-00412
`Apple EX1047 Page 18
`
`

`

`S
`BRIEF DESCRIPTION OF THE DRAWING
`FIGURES
`
`US 7,003,480 B2
`
`15
`
`6
`encryption channel. Second, as explained in detail below,
`GUMP provides a generic, “fill-in-the-blanks' financial
`application Suite that leverages TLS client authentication to
`accommodate financial-institution relationship certificates,
`which should be distinguished from generic identity certifi
`cates, which have no binding to a relationship between a
`client and a financial institution. Lastly, GUMP provides a
`non-cryptographic technique for “Internet-Safe” transactions
`with delegation, by building on the relationship certificate
`feature.
`A primary design goal for GUMP was that it be built with
`available components, which is especially important in
`regard to financial applications. Because GUMP starts with
`well understood, mature, Standards-based Secure protocols,
`such as SSL/TLS, it has the following advantages:
`Interoperability and access to a broad, cross-platform
`installed base;
`Reduced cost to understand, analyze, and approve;
`Reduced cost to design, implement, integrate, and deploy;
`Built-in evolution path through the Internet Engineering
`Task Force's (IETF) TLS standards process; and
`Presumption that a cryptographic bedrock like random
`number generation, key exchange, and authentication
`are done correctly.
`The following premises drive the GUMP approach. First,
`HTTP is, by far, the most important transport for Internet
`financial applications for the foreseeable future. TLS, with
`its proposed extensions and using embedded signed docu
`ments, can Service Virtually all Security requirements of
`financial applications, when those requirements are Suffi
`ciently simplified. These proposed extensions to TLS pro
`vide Secure shared-secret authentication to Support registra
`tion. SSL version 3.0 provides mutual authentication and
`moderate privacy. Embedded signed documents can ensure
`non-repudiation for transactions and Support Store-and-for
`ward backend applications.
`Second, transactions are fundamentally two-party affairs.
`Multi-phase, multiplexed, staged, forwarded, and nested
`transactions can all be designed out of two-party elements.
`Third, public-key authentication protocols are easier to
`implement and deploy than are shared-Secret authentication
`protocols. Use of shared-Secret protocols should be mini
`mized and eliminated where possible; however, integration
`with legacy Systems will require their use in Some circum
`StanceS.
`Fourth, clients should sign all transactions digitally. By
`employing digital signatures, a transaction protocol provides
`assurances against repudiation and freedom from managing
`Secret authentication data. Account numbers, PINs, and
`passwords become worthless to a third party, Since they
`cannot be used without also creating a valid digital Signa
`ture, assuming replay protection exists. The third party
`cannot create a valid Signature without controlling the
`client's private key. This premise implies that each client
`must have a certified Signature key.
`Fifth, financial institutions will (or should) insist on
`managing their own client name data. In a public-key
`Setting, this requirement implies that financial institutions
`will issue their own certificates for client Signature keys,
`Since they need to bind their own attributes-like account
`numbers-to principals that they recognize.
`Financial Applications-Basics:
`ASSume, as a baseline, that clients of any financial appli
`cation demand a private channel, insist on mutual authen
`tication, and agree to sign every transaction. Of these
`assumptions, mutual authentication is the least understood.
`
`The foregoing aspects and many of the attendant advan
`tages of this invention will become more readily appreciated
`as the Same becomes better understood by reference to the
`following detailed description, when taken in conjunction
`with the accompanying drawings, wherein:
`FIG. 1 is a functional block overview of the main steps in
`a grand unified meta-protocol (GUMP) electronic commerce
`transaction in accord with the present invention;
`FIG. 2 is a functional block providing an overview of the
`registration steps in the GUMP transaction;
`FIG. 3 is a detailed Schematic diagram illustrating the
`registration steps in the GUMP transaction;
`FIG. 3A is a detailed Schematic diagram depicting a
`GUMP relationship certificate;
`FIG. 4 is a functional block diagram providing an over
`view of the transaction steps in the GUMP transaction;
`FIG. 5 is a detailed Schematic diagram showing the
`transaction steps in the GUMP transaction;
`FIG. 5A is a detailed Schematic diagram portraying a
`digitally signed GUMP relationship certificate;
`FIG. 6 is a functional block diagram showing an overview
`of the optional delegation steps in the GUMP transaction;
`FIG. 7 is a detailed schematic diagram of the optional
`delegation steps in the GUMP transaction;
`FIG. 7A is a detailed schematic diagram of a GUMP
`delegation certificate;
`FIG. 8 is a functional block diagram showing an overview
`of the transaction Steps performed by a delegate in the
`GUMP transaction;
`FIG. 9 is a detailed schematic diagram of the transaction
`steps performed by the delegate in the GUMP transaction;
`FIG. 9A is a detailed schematic of a digitally signed
`GUMP delegation certificate;
`FIG. 10 is a functional block diagram providing an
`overview of the steps employed to use a Letter of Credit
`(LOC) in the GUMP transaction;
`FIG. 11 is a detailed Schematic diagram of the Steps used
`to employ the LOC in the GUMP transaction;
`FIG. 11 A is a detailed Schematic of a GRC that references
`the LOC;
`FIG. 11B is a detailed schematic of a digitally signed
`GRC that references the LOC; and
`FIG. 12 (Prior Art) is a block diagram of a typical digital
`computer System Suitable for use with a preferred embodi
`ment of the present invention.
`
`25
`
`35
`
`40
`
`45
`
`DESCRIPTION OF A PREFERRED
`EMBODIMENT
`
`Secure Sockets Layer (SSL) is a de facto standard for
`secure Hyper Text Transport Protocol (HTTP) connections
`over the Internet (or other networks). Presently, there are at
`least 40 million web browsers and web servers on the
`Internet that are capable of running SSL as Transport Layer
`Security (TLS). The present invention, which is referred to
`as a Grand Unified Meta-Protocol (GUMP), provides a
`Standardized and interoperable application protocol for
`facilitating electronic transactions between parties by build
`ing on well known TLS protocols, such as SSL and Secure
`HyperText Protocol (SHTTP).
`GUMP provides several functional features. First, it
`enables authentication of a party using passwords or per
`sonal identification numbers (PINs) without requiring that
`they be transmitted over a limited Security (e.g., 40-bit)
`
`50
`
`55
`
`60
`
`65
`
`IPR2022-00412
`Apple EX1047 Page 19
`
`

`

`15
`
`7
`In the paper-and-ink World, possession of a government
`issued document-presumed uncopyable-often Suffices,
`but this presumption does not apply in the electronic World
`where almost anything can be copied. In the electronic
`World, one party authenticates the other by getting the other
`party to prove current possession of one or more Secrets: a
`password, PIN, shared secret key, or the private half of a
`public-private key pair. In financial protocols, and especially
`on public networks like the Internet, requirements for each
`of these types of proof of authenticity often coexist within
`the same Session. The term certification is used herein to
`mean establishing a way for this proof to be made So that
`authentication can proceed later on in a manner mutually
`acceptable to the client and the financial institution. It will
`be helpful to first describe a traditional, non-electronic
`certification protocol as a prelude to describing GUMP's
`meta-protocols.
`Traditional, Non-Electronic Certification Protocol:
`A typical client makes use of a number of products and
`Services provided by a financial institution. For example, the
`client may have demand-deposit accounts, mortgages, unse
`cured loans, annuities, insurance accounts, credit cards,
`debit cards, check cards, ATM cards, and brokerage accounts
`at a single institution. The institution and client agree on an
`account number for each distinguishable product or Service
`provided the client by the institution, but the set of account
`numbers are bound to a single client identity-indeed, they
`constitute the client identity from the point of view of the
`institution. No mere name and address, etc., would Suffice to
`identify the client, without the account numbers. This defi
`nition of identity benefits both the client and the institution.
`The client will have freedom to readily access the various
`accounts, and the institution can track the client's activities
`for legal and business purposes.
`The traditional certification protocol generally proceeds
`as follows:
`MEETING: The client and an official of the financial
`institution meet face-to-face.
`IDENTIFY. The client provides satisfactory proof of
`identity-at least as defined by the applicable laws-to the
`official of the institution. This proof may be in the form of
`a birth certificate, driver's license, passport, employer pic
`ture ID, etc.
`PRESENT: The official copies some of the identity infor
`mation and other information to a paper Signature card and
`presents the card to the client for Signature (in anticipation
`of the digital analog of this protocol, the card is referre