`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`
`Patent Owner.
`
`
`Patent No. 10,600,046
`Filing Date: June 2, 2015
`Issue Date: March 24, 2020
`
`Inventors: Xiangzhen Xie, Liang Seng Koh, and Hsin Pan
`Title: METHOD AND APPARATUS FOR MOBILE PAYMENTS
`
`
`__________________________________________________________________
`
`PATENT OWNER’S RESPONSE
`
`Case No. IPR2022-01239
`
`__________________________________________________________________
`
`
`
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`TABLE OF CONTENTS
`
`I.
`II.
`
`Page(s)
`INTRODUCTION ........................................................................................... 1
`THE ’046 PATENT ......................................................................................... 2
`A.
`The ’046 Patent’s Disclosure ................................................................ 2
`III. THE ALLEGED PRIOR ART ........................................................................ 6
`A.
`Laracey (U.S. Pat. App. Pub. No. 2011/0251892) ................................ 6
`B.
`Jogu (Japanese Patent No. 4901053) .................................................... 8
`C.
`Tang (PCT No. WO 2009/116954) .....................................................10
`D. Dorsey (U.S. Patent No. 9,916,581) ....................................................10
`IV. CLAIM CONSTRUCTION ..........................................................................11
`V.
`LEGAL STANDARD ...................................................................................12
`VI. GROUND 1: APPLE’S COMBINATION DOES NOT DISCLOSE
`OR RENDER OBVIOUS ANY CHALLENGED CLAIM ..........................13
`A.
`The Combination Does Not Disclose or Render Obvious “an
`electronic purse (e-purse) maintained locally in the mobile
`device,” as Recited by Independent Claims 1, 12, and 18 ..................13
`1.
`“e-purse” ...................................................................................14
`2.
`“maintained locally in the mobile device” ................................22
`The Combination Does Not Render Obvious “verifying the
`total amount with a balance in the e-purse, wherein said
`verifying the total amount with a balance in the e-purse is
`performed within the mobile device without sending the
`payment request to a paymen gateway” Because a POSITA
`Would Not Combine Laracey with Jogu .............................................28
`VII. GROUND 2: LARACEY WITH JOGU AND TANG DOES NOT
`RENDER CLAIM 17 OBVIOUS .................................................................32
`
`B.
`
`i
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`VIII. GROUND 3: LARACEY WITH JOGU AND DORSEY DOES
`NOT RENDER OBVIOUS CLAIM 18 ........................................................32
`A.
`“electronic purse (e-purse) maintained locally in the mobile
`device” .................................................................................................33
`“wherein the payment request is denied within the mobile
`device without sending the payment request to the payment
`gateway” ..............................................................................................33
`IX. CONCLUSION ..............................................................................................34
`
`
`B.
`
`ii
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Apple Inc. v. Samsung Elecs. Co.,
`839 F.3d 1034 (Fed. Cir. 2016) .......................................................................... 13
`Forest Lab’ys, LLC v. Sigmapharm Lab’ys, LLC,
`918 F.3d 928 (Fed. Cir. 2019) ............................................................................ 12
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) .......................................................................................... 12, 13
`KSR Int’l Co. v. Telefex Inc.,
`550 U.S. 398 (2007) ............................................................................................ 12
`RFCyber Corp. v. Apple Inc.,
`No. 6:21-cv-00916-ADA, Dkt. 100 (W.D. Tex. Sep. 13, 2022) ........................ 11
`RFCyber Corp. v. Google LLC,
`No. 2:20-cv-274-JRG, 2021 WL 5357465 (E.D. Tex. Nov. 17,
`2021) ................................................................................................................... 11
`Statutes
`35 U.S.C. § 103 ........................................................................................................ 12
`
`
`iii
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`EXHIBIT LIST
`
`Exhibit No. Description of Document
`
`2001
`
`2002
`
`2003
`
`Declaration of Alfred C. Weaver, Ph.D.
`
`CV of Alfred C. Weaver, Ph.D.
`
`Transcript of May 11, 2023 Deposition of Gerald W. Smith
`
`
`
`
`
`
`
`
`iv
`
`
`
`
`I.
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`INTRODUCTION
`On July 20, 2022, Apple Inc. (“Petitioner” or “Apple”) filed a petition
`
`requesting inter partes review of claims 1-5, 12-14, 17, and 18 (“challenged claims”)
`
`of U.S. Patent No. 10,600,046 (Ex. 1001, “’046 Patent”). Paper 1. (“Petition” or
`
`“Pet.”). The Declaration of Gerald W. Smith (Ex. 1003, “Smith Decl.”) accompanied
`
`the Petition. On July 25, 2022, the Board issued a Notice of Filing Date Accorded
`
`for the post-grant Petition and set the time for filing patent owner’s preliminary
`
`response. Paper 3.
`
`The Board should issue a Final Written Decision finding all Challenged
`
`Claims to be not unpatentable. As discussed in detail below, Apple fails to show any
`
`disclosure of “an electronic purse (e-purse),” and further fails to show that any e-
`
`purse is “maintained locally in a mobile device” as required by every claim. Apple
`
`relies solely on Laracey with respect to that limitation and does not raise any
`
`obviousness arguments. Apple’s combination also fails to render obvious “verifying
`
`the total amount with a balance in the e-purse, wherein said verifying the total
`
`amount with a balance in the e-purse is performed within the mobile device without
`
`sending the payment request to a payment gateway,” because a POSITA would not
`
`have any motivation to combine Laracey with Jogu.
`
`1
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`II. THE ’046 PATENT
`A. The ’046 Patent’s Disclosure
`The ’046 Patent describes methods and apparatuses for secure contactless
`
`
`
`payment using mobile devices. The inventors, Xiangzhen Xie, Liang Seng Koh, and
`
`Hsin Pan, recognized that existing payment methods were inefficient and time-
`
`consuming:
`
`For many credit or debit card transactions, the payment process is
`started by a customer asking for a bill when checking out a purchase. A
`cashier or service member brings a bill to the customer for verification.
`The customer then hands out a credit/debit card to the service member.
`The service member brings the card to a Point of Sales (POS) counter
`to initiate a transaction payment. The service member then brings back
`a receipt to the customer for signature to authorize the transaction. It is
`a lengthy process that typically takes a couple of minutes or much
`longer when the service member has to take care of multiple payment
`transactions at a time. In addition, in the case for the debit card
`transactions, the process may be even more troublesome when a PIN is
`needed to authorize the transaction at the POS.
`
`Ex. 1001 (the “’046 Patent”) at 1:25-39. The inventors realized that the growing
`
`ubiquity of personal mobile devices allowed for the use of those devices in sales
`
`transactions:
`
`2
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`With the advancement in mobile devices, it is anticipated that many
`
`consumers will carry one with them. Thus there is an opportunity of
`
`using a mobile device to quickly settle the payment at a point of sale
`
`(POS).
`
`Id. at 1:40-44.
`
`
`
`To solve these problems and address these needs, the inventors of the ’046
`
`Patent developed an apparatus and method for using mobile devices to quickly and
`
`efficiently settle payments:
`
`The present invention is related to techniques for mobile devices
`configured to support settlement of charges in electronic invoices or
`bills. According to one aspect of the present invention, a mobile device
`embedded with a secure element generates or is loaded with an
`electronic invoice. When the mobile device is brought to a consumer
`with an NFC mobile device, the data including the electronic invoice
`and other information regarding the mobile device or an owner thereof
`is read off wirelessly into the NFC mobile device. After the user verifies
`the amount being charged and authorizes the payment, the NFC mobile
`device communicates with a payment gateway or network for payment
`that is configured to proceed with the payment in accordance with a
`chosen payment method.
`
`Id. at 1:54-67.
`
`3
`
`
`
`The system of the ’046 Patent makes use of a mobile device with a locally
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`maintained e-purse and an installed application to capture data from a tag associated
`
`with a POS device, thereby facilitating mobile payments:
`
`
`
`’046 Patent, Fig. 1A; see also id. at 5:29-7:3.
`
`The e-purse of the ’046 Patent facilitates mobile payments, for example, using
`
`an installed application in the form of an applet that is provisioned, personalized,
`
`and installed on the mobile device:
`
`4
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`Id. at Fig. 3C; see also id. at 6:58-7:3, 8:43-43. The e-purse of the ’046 Patent locally
`
`maintains financial information, for example an e-purse with a personalized applet
`
`uses a secure element (“SE”) to maintain “personalized data for the application . . .
`
`[including] various personalized transaction keys generated based on the device
`
`information (e.g. CPLC info) of the SE . . . [and] Mifare access keys derived from
`
`an identifier (ID) of the Mifare card.” Id. at 11:17-28.
`
`5
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`III. THE ALLEGED PRIOR ART
`A. Laracey (U.S. Pat. App. Pub. No. 2011/0251892)
`U.S. Patent App. Pub. No. 2011/0251892 (Ex. 1004, “Laracey”) is directed to
`
`“means for using mobile devices to conduct payment transactions at merchant
`
`locations.” Laracey, Abstract. Laracey identified difficulties in utilizing payment
`
`cards “associated with a single payment account” and in using “RFID chips or tags
`
`installed on mobile phones as a way to allow payment card information to be
`
`presented” in conjunction with “RFID readers installed” at a point of sale. Id. at
`
`[0004-5]. Laracey further identifies an objective of allowing “users to choose among
`
`a variety of payment accounts” for a given transaction irrespective of the mobile
`
`device that they use. Id. at [0024-5] (“Sam has a mobile phone that has a web
`
`browser, and Jane has an Apple iPhone®. Sam will access and use the payment
`
`system of the present invention using his phone’s browser, while Jane will access
`
`and use the payment system of the present invention by downloading and
`
`configuring an iPhone® application. . . . Using features of the present invention,
`
`customers such as Jane and Sam may use their mobile devices to pay for products or
`
`services at [POS] locations. . . . Embodiments allow users to choose among a variety
`
`of payment accounts to use the most appropriate or most desirable payment account
`
`for a given transaction.”) To overcome these difficulties and address these
`
`objectives, Laracey adopts an approach in which a customer’s financial information
`
`6
`
`
`
`
`is maintained on a server (e.g. a Transaction Management System, Customer
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`Management System, or Payment Account Management System) rather than on a
`
`mobile device. Id. at [0018], [0041].
`
`Instead of utilizing locally maintained financial information, Laracey utilizes
`
`a system of authentication based on “checkout tokens” based on which remotely-
`
`stored account or proxy information is accessed during a transaction. Laracey
`
`contemplates “a checkout token printed or otherwise displayed at a point of sale”
`
`which may be obtained by a user’s mobile device. Id., [0017], [0032]. Obtaining
`
`Laracey’s checkout token begins an authentication process which, if successful,
`
`results in a transaction management system (TMS) sending a “transaction detail
`
`message” to the mobile device. In addition, the TMS may send a “list of payment
`
`accounts the customer has registered with the system, including credit, debit,
`
`checking, prepaid and other types of accounts” based on which the customer can see
`
`“a list of their payment accounts they can use to pay the merchant 108”. Id. at [0036].
`
`Laracey’s mobile device “never stores, sends or receives actual payment
`
`credentials. Instead, the mobile device 102 stores or has access to a proxy associated
`
`with actual payment credentials, and the proxy is used to identify a desired payment
`
`account for use in a given transaction.” Id. at [0041]. The proxy is transmitted to the
`
`TMS, and the TMS does a lookup to identify the actual payment credentials to be
`
`submitted to a payment gateway. Id. at Fig. 6, [0134], [0142-3]. Laracey’s system
`
`7
`
`
`
`
`ultimately completes a transaction once a payment processing network confirms the
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`availability of funds, and the transaction management system sends authorization
`
`messages (i.e. a “merchant payment authorization response message” and “customer
`
`payment authorization response message”) to both the merchant and mobile device,
`
`respectively. Id. at [0040], [0062], [0084].
`
`
`
`Id., Fig. 6.
`
`Jogu (Japanese Patent No. 4901053)
`
`8
`
`
`
`Japanese Patent No. 4901053 (Ex. 1005 or “Jogu”) is directed to “a service
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`that mediates payments at virtual stores and brick-and-mortar stores on the internet.”
`
`Jogu at 3, Technical Field. Jogu identifies difficulties in conducting mobile
`
`payments where a “credit inquiry is required at the time of payment, and payment
`
`data need to be sent,” “in that it is necessary to emit radio waves at the time of
`
`payment, it cannot be used outside the radio wave range, and it takes time to
`
`complete the payment.” To address these difficulties, Jogu adopts the approach of
`
`“mediating payment between a seller and a buyer” where “the mobile phone receives
`
`and stores the balance of the account sent from the mobile phone office” “wherein
`
`an account for accumulating the user’s money is set up on the server computer for
`
`each user.” Id. at 3, Disclosure of Invention.
`
`Jogu’s system requires that a customer preestablish one or more payment
`
`vehicles with the telephone company, and then prior to any use of the mobile phone
`
`to effect a mobile payment, the customer instructs the telephone company to transfer
`
`some amount of money from one or more preestablished financial accounts to a
`
`virtual account associated with a customer’s telephone number. Id., Fig. 1; id. at 4,
`
`2. Advanced Payment Method (“As shown in FIG. 1, the mobile phone company
`
`(mobile phone office) 10 is provided with a personal information database 11. The
`
`personal information of each user 12 is registered in the personal information
`
`database 11. Specifically, a virtual account 110 is set up to accumulate advance
`
`9
`
`
`
`
`payments (advance payments for mobile phone companies) . . . the user 12 uses the
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`mobile phone 13 to transmit the desired prepaid amount and the payment method
`
`(here, ’added to the call charge’) to the mobile phone company 10.”). That
`
`transferred amount is a prepayment against future purchases.
`
`
`
`
`
`Id., Fig. 1.
`
`Tang (PCT No. WO 2009/116954)
`
`PCT Application No. WO 2009/116954 (Ex. 1006 or “Tang”) bears an
`
`international filing date of March 18, 2009, and is directed to “distributing
`
`information encoded in a barcode to perform a transaction via a network.” Tang,
`
`Abstract.
`
`Dorsey (U.S. Patent No. 9,916,581)
`
`10
`
`
`
`U.S. Patent No. 9,916,581 (Ex. 1007 or “Dorsey”) was filed on November 17,
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`2011 and issued March 13, 2018. Dorsey is directed to “[a] method of reconstructing
`
`a packet that includes financial card information from a mobile device that uses a
`
`card reader.” Dorsey, Abstract.
`
`IV. CLAIM CONSTRUCTION
`Petitioner submits that the term “e-purse” should be construed as “software
`
`that stores electronic financial information, includ[ing] electronic value, in a local
`
`portable device” but argues that “[t]he distinction between the parties’ respective
`
`proposals need not be resolved for this proceeding.” Pet. at 9. Patent Owner submits
`
`that the proper construction of e-purse is “software that stores electronic financial
`
`information in a local device,” as it has been construed in the district courts for both
`
`the Eastern and Western District of Texas.1 In short, however, the parties agree that
`
`an e-purse must be “software”; and that the software “stores financial information in
`
`a local device.”
`
`The Board need not resolve the distinction between the parties’ proposals for
`
`this proceeding because Petitioner fails to show that Laracey discloses “an electronic
`
`
`1 See RFCyber Corp. v. Google LLC, No. 2:20-cv-274-JRG, 2021 WL 5357465, at
`*6-*9 (E.D. Tex. Nov. 17, 2021); RFCyber Corp. v. Apple Inc., No. 6:21-cv-00916-
`ADA, Dkt. 100 (W.D. Tex. Sep. 13, 2022)
`
`11
`
`
`
`
`purse (e-purse) maintained locally in the mobile device” under the agreed portions
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`of the construction.
`
`Patent Owner believes that claim construction is not otherwise required to
`
`resolve any issues.
`
`V. LEGAL STANDARD
`The question of obviousness is resolved on the basis of underlying factual
`
`determinations, including: (1) the scope and content of the prior art, (2) any
`
`differences between the claimed subject matter and the prior art, (3) the level of skill
`
`in the art, and (4) where in evidence, so called secondary considerations. Graham v.
`
`John Deere Co. of Kansas City, 383 U.S. 1, 17–18 (1966). A claim is only
`
`unpatentable under 35 U.S.C. § 103 if “the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a whole
`
`would have been obvious at the time the invention was made to a person having
`
`ordinary skill in the art to which said subject matter pertains.” KSR Int’l Co. v.
`
`Telefex Inc., 550 U.S. 398, 406 (2007) (quoting 35 U.S.C. § 103).
`
`“An invention is not obvious simply because all of the claimed limitations
`
`were known in the prior art at the time of the invention. Instead, we ask
`
`‘whether there is a reason, suggestion, or motivation in the prior art that would
`
`lead one of ordinary skill in the art to combine the references, and that would
`
`also suggest a reasonable likelihood of success.’” Forest Lab’ys, LLC v.
`
`12
`
`
`
`
`Sigmapharm Lab’ys, LLC, 918 F.3d 928, 934 (Fed. Cir. 2019). “Of course,
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`concluding that the references are within the scope and content of the prior art
`
`to be considered for obviousness does not end the inquiry. Graham makes clear
`
`that the obviousness inquiry requires a determination whether the claimed
`
`invention would have been obvious to a skilled artisan.” Apple Inc. v. Samsung
`
`Elecs. Co., 839 F.3d 1034, 1050 n.14 (Fed. Cir. 2016).
`
`VI. GROUND 1: APPLE’S COMBINATION DOES NOT
`DISCLOSE OR RENDER OBVIOUS ANY CHALLENGED
`CLAIM
`A. The Combination Does Not Disclose or Render Obvious “an
`electronic purse (e-purse) maintained locally in the mobile
`device,” as Recited by Independent Claims 1, 12, and 18
`Every independent claim of the ’046 Patent requires “an electronic purse (e-
`
`purse) maintained locally in the mobile device.” Petitioner relies solely on Laracey
`
`for this limitation and does not assert that it is rendered obvious in combination with
`
`any other reference. See Pet. at 29-32. As explained above, under the parties’
`
`proposed constructions, both parties agree that an e-purse is “software” and that it
`
`“stores electronic financial information in a local device.” Supra § IV; see also Pet.
`
`at 9.
`
`Laracey does not (whether or not in combination with Jogu) render this
`
`limitation obvious. Laracey does not disclose or render obvious an e-purse under
`
`13
`
`
`
`
`either party’s construction. Further, Laracey does not disclose or render obvious an
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`e-purse that is “maintained locally in the mobile device” as claimed.
`
`“e-purse”
`1.
`Under both parties’ constructions, an e-purse is “software” that “stores
`
`electronic financial information in a local device.” Supra § IV; see also Pet. at 9.
`
`At the outset, Petitioner does not identify any software as an e-purse. Instead,
`
`it identifies “Laracey’s ‘stored value’ account” as the e-purse. Pet. at 29 (“A POSITA
`
`would have understood that Laracey’s ‘stored value’ account is an e-purse that stores
`
`electronic financial information, including electronic value, as claimed.”). Petitioner
`
`and Mr. Smith further explain that the gift card account “PetPlace Gift…3518”
`
`shown in Fig. 8B is the claimed e-purse. Pet. at 30-31; Smith Decl., ¶ 101. Mr. Smith
`
`confirmed at his deposition that he was specifically identifying the “PetPlace
`
`Gift…3518” account as the e-purse of the claims. Ex. 2003, “Smith Dep.” 67:11-
`
`68:12, May 11, 2023. Petitioner and Mr. Smith have not shown that the “PetPlace
`
`Gift…3518 account” is software. Indeed, a POSITA would not recognize a
`
`customer’s account as software. Ex. 2001, “Weaver Decl.”, ¶ 56. Instead, it is simply
`
`a visualization of a collection of information. Id. Laracey simply displays the gift
`
`card account balance 884n on the mobile phone 102 after that account balance has
`
`been received from the Transaction Management System (TMS) 130. Laracey does
`
`not maintain “financial information” locally in an e-purse, as required by all claims.
`
`14
`
`
`
`
`Similarly, the concept of a stored value account is not software either. Id. And while
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`Mr. Smith and Petitioner do not suggest that the credit or debit accounts referenced
`
`in Laracey would qualify as the claimed e-purse, for the same reasons, those
`
`accounts would not. Id. Accordingly, a POSITA would not understand Laracey’s
`
`accounts to disclose or render obvious an e-purse that is maintained locally in the
`
`mobile device. Id.
`
`Moreover, Laracey does not store financial information locally as required by
`
`the parties’ constructions. Id., ¶ 57. Instead, it stores its financial information in a
`
`database on a server. E.g., Laracey [0034] (“Once the customer is successfully
`
`authenticated, then the system has access to a variety of attributes about the
`
`customer, including a list of payment accounts that the customer previously
`
`identified to the transaction management system 130 as part of the registration
`
`process.”); [0036] (“[T]he transaction management system may also send to the
`
`phone a list of payment accounts the customer has registered with the system,
`
`including credit, debit, checking, prepaid and other types of accounts.”); [0056]
`
`(“receiving transaction details and a payment account list or list of preferred or
`
`eligible accounts from the transaction management system 230”) (emphasis added);
`
`[0067]-[0068] (describing storing account details in a database on a server at
`
`registration); Fig. 9. See also [0058]. Thus, in the Laracey system, electronic
`
`financial information related to a customer’s accounts are stored (maintained) in
`
`15
`
`
`
`
`remote servers (e.g., in customer management 612 and transaction management
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`system 630), not locally in the mobile device. Weaver Decl., ¶ 57.
`
`The only information which the mobile device has access to at all is “a proxy
`
`or representation of the payment account,” and Laracey’s transaction flow makes
`
`clear that the device only has access to this information for the duration of a
`
`transaction – this is not “maintained” in a mobile device. Weaver Decl., ¶ 58. When
`
`a customer seeks to make a purchase under the Laracey system, the customer must
`
`first authenticate themselves to the TMS 130 before using the mobile payment
`
`system. Laracey, [0038], [0057], [0082], [0108], [0112], [0132-33], and [0141].
`
`Upon authentication, the transaction management system may transmit a list of
`
`payment accounts. Id., [0112]. The customer’s mobile device then receives a
`
`checkout token from the merchant’s system. Laracey, [0036], [0056]. The checkout
`
`token may be static or dynamic. Id., [0053]. A dynamic token includes details about
`
`the transaction. Id., [0038]. The mobile device receives a payment account list from
`
`the transaction management system, which includes available balances, as well as
`
`the “proxies” for the accounts. Id., [0056], [0099], [0165]. The user then selects the
`
`desired account and the mobile device transmits a customer payment authorization
`
`request to the transaction management system. Id., [0056]. Figure 4B illustrates this
`
`process from the mobile device’s point of view.
`
`16
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`Id., Fig. 4B.
`
`During a transaction, the mobile device sends a customer transaction lookup
`
`request to the transaction management system. Id., [0098]. The customer transaction
`
`lookup request includes both the checkout token and other information from the
`
`mobile device. Id. The transaction management system “uses the checkout token and
`
`17
`
`
`
`
`additional information received from the mobile device 202 to retrieve the
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`transaction details received from the merchant (transmitted from the merchant at step
`
`408 of FIG. 4A), and to retrieve a list of the customer’s payment accounts that are
`
`suitable for the transaction.” Id. The “mobile device 202 then receives the transaction
`
`details and payment account information from the transaction management system
`
`230.” Id., [0099]. The downloaded payment account information includes “proxies
`
`or non-sensitive identifiers used by the transaction management system 230 to
`
`identify each account (rather than the actual payment credentials).” Id; see also
`
`Weaver Decl., ¶ 59. The mobile device uses that information to display the payment
`
`account choices to the customer. Id., [0100].
`
`Even Laracey’s embodiments that utilize a “dynamic checkout token” still
`
`retrieve payment accounts from the transaction management system 130 server and
`
`do not maintain financial information on the local mobile device. Id., Fig. 4B,
`
`[0098]-[0100]; see also Weaver Decl., ¶ 60.
`
`Laracey explains that a dynamic checkout token includes information about
`
`the transaction and can thus reduce the number of messages sent between the mobile
`
`device and the transaction management system or remove the need for a customer
`
`transaction lookup request. Id., [0038], [0054] (“A dynamic checkout token . . .
`
`may, in some embodiments, involve fewer messages between the mobile device 202
`
`and the transaction management system 230 during a payment transaction.”
`
`18
`
`
`
`
`However, a dynamic token cannot remove the need for the mobile device to receive
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`the payment account information from the TMS 130. Weaver Decl., ¶ 61. This is
`
`apparent because the merchant does not have any of the customer’s payment account
`
`information. Id. Moreover, all disclosed embodiments explain that the payment
`
`account details are transmitted to the mobile device either at authentication or during
`
`processing, or both. Id.
`
`For example, Laracey provides a sample transaction flow for a purchase at
`
`Starbucks using a Starbucks gift card. Laracey, [0112]-[0114]. In that example, upon
`
`activating the payment application on her phone, the customer Jane must perform an
`
`authentication process. Id., [0112]. After doing so, “a list of available payment
`
`accounts may be transmitted to and displayed on a display screen of her iPhone.”
`
`Id. (emphasis added.) “A checkout token may be generated by the merchant systems
`
`at Starbucks and displayed on a point of sale display so Jane can then capture an
`
`image of the checkout token with her mobile phone.” Id.¸ [0113]. Laracey’s use of
`
`“generated” indicates to a POSITA that the token is a dynamic token. Weaver Decl.,
`
`¶ 62 (citing Laracey, [0038] (explaining that a dynamic token “is generated by either
`
`the merchant 108 or the transaction management system 130. . . .”)).
`
`The payment application then captures the checkout token and transmits a
`
`customer transaction lookup message to the transaction management system. Id.,
`
`[0113]. The system uses the token to “retrieve a subset of Jane’s available payment
`
`19
`
`
`
`
`accounts that are appropriate for use in making this particular purchase.” Id. The
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`mobile device then receives the list of payment applications, including Jane’s
`
`Starbucks gift card and balance, and displays them. Id.
`
`As shown above, Laracey explicitly includes its prepaid accounts—i.e., stored
`
`value accounts or gift card accounts—as accounts stored on and received from the
`
`server. Weaver Decl., ¶ 64 (citing, e.g., Laracey, [0036] ((“[T]he transaction
`
`management system may also send to the phone a list of payment accounts the
`
`customer has registered with the system, including credit, debit, checking, prepaid
`
`and other types of accounts.”) (emphasis added), [0058, 0134]] (explaining that
`
`“current available account balance” is sent to phone), [0067]-[0068], [0113], Fig. 9.
`
`20
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`Laracey, Fig. 9.
`
`Downloading the payment information to the mobile device, rather than
`
`maintaining it in the device, is critical to Laracey’s functionality. Weaver Decl., ¶ 65.
`
`Laracey’s system is intended to allow multiple devices to utilize the same customer
`
`payment data. Id. (citing Laracey at [0018] (discussing “one of the authorized
`
`devices that has been designated by the customer as having access to the customer’s
`
`payment credentials”), [0043], [0067] (“the customer provides information about
`
`one or more payment devices”)). If the financial information were stored on a mobile
`
`device, it would be difficult to synchronize that data with other devices. Id.
`
`21
`
`
`
`Accordingly, Petitioner’s combination does not disclose or render obvious an
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`“e-purse” under either party’s construction
`
`“maintained locally in the mobile device”
`2.
`Similarly, Laracey does not teach or disclose any “e-purse” that is
`
`“maintained locally in the mobile device.” To the extent Laracey discloses any
`
`software that stores financial information, that software is maintained on a server,
`
`not “locally in the mobile device.” Weaver Decl., ¶ 67. Laracey explains that
`
`electronic financial information is maintained in a “transaction management system
`
`130” or related servers. Laracey, [0062] (“The actual payment credentials may be
`
`obtained by using the payment account selection information and performing a
`
`lookup of actual payment account credentials previously stored in a database or
`
`location accessible to the transaction management system 230.”) (emphasis
`
`added), [0064]-[0069]; see also id. at [0121] (“A payment account management
`
`module 514 is provided to manage payment accounts of customers.”).
`
`The transaction management system must maintain the storage of financial
`
`information. First, as explained above, Laracey allows for multiple devices to use
`
`the same accounts. Thus, under Laracey’s implementation, the transaction
`
`management system must maintain those accounts so that the data remains
`
`synchronized. Weaver Decl., ¶ 68.
`
`22
`
`
`
`Indeed, in Laracey’s system, the mobile device itself “never stores, sends or
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`receives actual payment credentials. Instead, the mobile device 102 stores or has