UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_______________________
`
`APPLE INC.,
`
`Petitioners
`
`v.
`
`RFCYBER CORP.,
`Patent Owner
`
`_______________________
`
`Case No. IPR2022-01239
`Patent No. 10,600,046
`_______________________
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`
`_______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_______________________
`
`APPLE INC.,
`
`Petitioners
`
`v.
`
`RFCYBER CORP.,
`Patent Owner
`
`_______________________
`
`Case No. IPR2022-01239
`Patent No. 10,600,046
`_______________________
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`Table of Contents
`INTRODUCTION ............................................................................................. 1
`I.
`II. ARGUMENT ..................................................................................................... 3
`A. The Proposed Combination Renders Obvious Maintaining an e-Purse on a
`Mobile Device ….……………………………………………………………… 3
`i. When a dynamic checkout token is used, the mobile device need not
`request account information from the TMS ....................................................... 6
`ii. Account information is maintained on the mobile device ........................ 10
`iii. The proposed combinations all ensure the locally maintained balance is
`updated and stored on the mobile device at the conclusion of a transaction ... 12
`B. Each of PO’s Arguments Turns Critically on an Elaborate Misreading of
`Laracey ………………………………………………………………………...14
`i. There is no support for concluding that Laracey’s mobile device deleting
`account information at the conclusion of a transaction ................................... 15
`
`ii. Each of the POR’s arguments fall with Dr. Weaver’s flawed interpretation
`of Laracey ........................................................................................................ 20
`a) PO does not dispute that maintaining an account balance on Laracey’s
`mobile device satisfies the claimed e-purse ................................................. 20
`b) Laracey’s system is not limited to storing proxy information on the
`mobile device ................................................................................................ 21
`c) PO’s motivation to combine critiques fall with its mischaracterization of
`Laracey ......................................................................................................... 23
`III. CONCLUSION ................................................................................................ 25
`
`i
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`I.
`
`
`INTRODUCTION
`
`Patent Owner’s (“PO”) Preliminary Response (“POPR”) targeted a single
`
`issue in the Petition. It alleged that Petitioner’s primary reference, Laracey, failed to
`
`teach verifying a purchase amount with a balance on the mobile device, arguing that
`
`Laracey’s verification takes place exclusively on the payment server. Paper 6, POPR
`
`at 5-7. The Board correctly rejected this at institution, finding PO’s “argument is not
`
`persuasive because it addresses Laracey individually and does not address
`
`Petitioner’s proposed combination of Laracey and Jogu.” Paper 7, Institution
`
`Decision (“ID”) at 16-18.
`
`PO’s Response (“POR”) abandons the verifying critique and instead advances
`
`a new set of arguments that each turn on a fundamental mischaracterization of
`
`Laracey. Namely, the POR argues that Laracey’s mobile device doesn’t maintain an
`
`e-purse at all. Instead, it insists that Laracey’s device receives an e-purse balance
`
`from a server at the beginning of the transaction and deletes the balance when the
`
`transaction concludes, failing to maintain an e-purse as the claims require. See
`
`generally Paper 11, POR.
`
`PO’s interpretation of Laracey is created of whole cloth and should be
`
`rejected. Laracey never teaches or suggests deleting any information at the
`
`conclusion of a transaction. PO’s expert, Dr. Weaver, attempts to justify this theory,
`
`despite Laracey’s silence, by insisting that a POSITA would understand that the data
`
`1
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`is useless at the conclusion of a transaction and should be deleted. In support, he
`
`contends that Laracey seeks to allow multiple devices access to the same financial
`
`account. From this, he argues that a locally retained balance becomes stale at the
`
`conclusion of a transaction and should be deleted to avoid conflicting with balances
`
`retained on other devices that have access to the same account. But this theory also
`
`finds no support in Laracey. Indeed, Laracey says nothing about multiple devices
`
`accessing a single account or about stale data. Laracey simply suggests, without
`
`elaboration, that a customer can register “one or more devices.” From this benign
`
`statement, Dr. Weaver manufactures an elaborate narrative (1) that “Laracey’s
`
`system is intended to allow multiple devices to utilize the same customer payment
`
`data[,]” (2) that “it would be difficult to synchronize that data with other devices”
`
`“if the financial information were stored on a mobile device,” and (3) that “the
`
`context of Laracey suggests that the data is no longer of value and that a POSITA
`
`would understand at that point that the data should1 be purged.” Ex. 2001 (Weaver
`
`Dec.), ¶65; Ex. 1029 (Weaver Trans.), 43:4-7. Tellingly, even Dr. Weaver’s
`
`narrative does not go so far as to say that Laracey mandates deleting account data,
`
`suggesting only that it would be best practice to do so.
`
`As set forth in the Petition, Laracey’s teachings are far broader than PO
`
`suggests. Further, PO’s arguments ignore that every proposed ground modifies
`
`
`1 All emphases added unless noted otherwise.
`
`2
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`Laracey’s mobile device pursuant to Jogu’s teachings that a locally maintained
`
`balance is updated and stored at the conclusion of a transaction. So, even if PO’s
`
`narrow view of Laracey were correct (it is not), the proposed grounds nonetheless
`
`teach an e-purse maintained on the mobile device as claimed.
`
`II. ARGUMENT
`
`
`For PO’s argument to succeed, it must convince this Board that every
`
`embodiment in Laracey requires maintaining account information exclusively on
`
`the TMS server such that it is deleted from mobile device at the conclusion of a
`
`transaction. PO’s interpretation is simply not reasonable. It ignores Laracey’s much
`
`broader teachings and that the proposed grounds modify Laracey with Jogu’s
`
`teachings that a locally maintained balance is updated and stored at the conclusion
`
`of a transaction to provide the user an accurate balance for the next transaction.
`
`Only Petitioner’s interpretation—supported by its expert—gives weight to
`
`Laracey’s full teachings, complying with the Federal Circuit’s directive that “a
`
`reference must be considered not only for what it expressly teaches, but also for what
`
`it fairly suggests.” Bradium Techs. LLC v. Iancu, 923 F.3d 1032, 1049 (Fed. Cir.
`
`2019) (internal quotation marks omitted).
`
`A. The Proposed Combination Renders Obvious Maintaining
`an e-Purse on a Mobile Device
`
`Laracey’s system is composed of three key components: the user’s mobile
`
`
`
`device 102, a merchant 108, and a transaction management system (TMS) 130:
`
`3
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`
`
`Laracey, Fig. 1; Petition, 11-12 (describing the same at a high level).
`
`Fig. 4B illustrates an exemplary transaction flow from the mobile device’s
`
`perspective. After the user launches the payment application and provides
`
`authentication information, the mobile device captures a checkout token from the
`
`merchant at step 430. The mobile device sends the token to the TMS in a transaction
`
`lookup request at step 432, and, in response, the TMS sends a list of available
`
`financial accounts to the mobile device at step 434. The mobile device then receives
`
`a user’s financial account selection and transmits a payment authorization request to
`
`the TMS, which is used to complete the transaction. The following Fig. 4B illustrates
`
`this process flow and is annotated to indicate the direction of communications
`
`between the mobile device and TMS:
`
`4
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`Laracey, Fig. 4B (annotated to indicate direction of communication between mobile
`
`device and TMS), [0077-0104] (describing the same).
`
`
`
`5
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`i. When a dynamic checkout token is used, the mobile device need
`not request account information from the TMS
`Laracey describes numerous variations and modifications to the process flow
`
`depicted in Fig. 4B. Some embodiments utilize a dynamic checkout token, which
`
`can eliminate entirely the mobile device sending a transaction lookup request and
`
`receiving account information from the TMS, i.e., steps 432 and 434. Specifically,
`
`Laracey teaches that the merchant’s POS terminal may generate a dynamic checkout
`
`token that contains “all of the transaction details.” Laracey, ¶38, ¶55 (teaching that
`
`“a dynamic checkout token . . . may [] be used to communicate transaction details
`
`from the merchant 208 to the mobile device 202.”); Petition, 20. In some
`
`embodiments, all relevant transaction data is received by the mobile device from the
`
`POS terminal such that “no transaction details need be received by the mobile device
`
`202 from the transaction management system 230.” Laracey, ¶60. Indeed, the
`
`dynamic checkout token allows “checkout processing [to] proceed without a need
`
`for a customer transaction lookup request message to be transmitted to the
`
`transaction management system 130.” Id. at ¶38; see also id. at ¶54 (“dynamic
`
`check out token may be generated to include transaction information (e.g., such as
`
`the purchase amount, etc.) and may, in some embodiments, involve fewer messages
`
`between the mobile device 202 and the transaction management system 230 during
`
`a payment transaction.”).
`
`6
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`
`Petitioner’s expert, Gerald Smith, addressed these embodiments in his original
`
`declaration. He explained that, when a dynamic checkout token is used, “the
`
`checkout process occurs without a need for a customer transaction lookup request
`
`being sent to the [TMS].” Ex. 1003, ¶92 (emphasis in original). He also contrasted
`
`this embodiment from the static checkout token scenario in which “details of the
`
`purchase transaction were received as a response message from the [TMS].” Id.
`
`Directly rebutting the POR’s flawed interpretation of Laracey, Mr. Smith clarifies
`
`that a POSITA would have interpreted these specific embodiments of Laracey to
`
`mean that neither step 432 (transaction lookup request) nor responsive step 434
`
`(TMS responding with account information) occurs. Ex. 1028, ¶¶4-8. Mr. Smith
`
`explains that the express benefit Laracey ascribes to these embodiments is
`
`minimizing communications between the mobile device and TMS during a
`
`transaction. Id. (discussing Laracey at ¶54). He also notes that Laracey
`
`unambiguously teaches that the dynamic checkout token avoids the need entirely to
`
`send a transaction lookup request to the TMS. Id. (discussing Laracey at ¶38).
`
`Finally, he explains that a POSITA would have understood that, if there is no step
`
`432 transaction lookup request sent to the TMS, there would be no responsive step
`
`434 communications in which the TMS provides account information to the mobile
`
`device. Id. In support, he explains that Laracey describes no other transaction-related
`
`messages that cause the TMS to send account information to the mobile device. Id.
`
`7
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`Indeed, post-authorization, the TMS sends account information to the mobile device
`
`exclusively in response to a transaction lookup message from the mobile device. Id.
`
`(discussing Laracey at Fig. 4B, ¶¶ 35-36, 58, 98-99, and 109-110).
`
`Mr. Smith notes that Laracey includes a single specific example in which “a
`
`list of available payment accounts may be transmitted to” the mobile device after
`
`authentication. Id. (discussing Laracey at ¶¶ 112-113). Even in this specific example,
`
`however, detailed account information for the specific transaction is sent by the TMS
`
`to the mobile device in response to receiving a checkout token from the mobile
`
`device. Id. (explaining that Laracey at ¶113 teaches that the TMS uses the token
`
`obtained in a transaction lookup request “to retrieve a subset of Jane’s available
`
`payment accounts that are appropriate for use in making this particular purchase”).2
`
`Accordingly, a POSITA would have understood, in Laracey’s embodiments
`
`that do not send a transaction lookup request from the mobile device to the TMS
`
`(e.g., step 432 in Fig. 4B), there is also no responsive communication from the TMS
`
`to the mobile device that includes account information (e.g., step 434 in Fig. 4B).
`
`Id., ¶8. Instead, all necessary transaction information is received from the POS
`
`terminal and the first transaction-specific communication to the TMS is a payment
`
`
`2 He also explains that Fig. 6 similarly suggests that account information may be sent
`to the mobile device incident to authorization, but it also teaches that transaction-
`specific account information is later sent to the mobile device in response to the TMS
`receiving a checkout token from the mobile device. Ex. 1028, ¶7.
`
`8
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`authorization message (e.g., step 440 in Fig. 4B). Id. Fig. 4B below is annotated to
`
`reflect the communications involved in this embodiment:
`
`
`
`9
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`Laracey, Fig. 4B (annotated); Ex. 1028, ¶8 (discussing the same).
`
`ii. Account information is maintained on the mobile device
`As set forth above, a POSITA would have understood that Laracey’s dynamic
`
`checkout token embodiments need not retrieve account information from the TMS
`
`for a given transaction. In these embodiments, the account information, including
`
`available balances, would instead be maintained on the mobile device. Ex. 1028,
`
`¶¶9-10. Mr. Smith explains that a POSITA would have understood that there are
`
`three possible arrangements: Account information can be maintained (1) on the
`
`TMS exclusively, (2) on the mobile device exclusively, or (3) on both the TMS and
`
`the mobile device. Id. He explains that there is no teaching or suggestion in Laracey
`
`that would lead a POSITA to conclude that the account information is maintained
`
`exclusively on the TMS. Id. Such an interpretation demands that all account
`
`information is deleted from the mobile device at the conclusion of a transaction, and
`
`nothing in Laracey teaches or suggests such a deletion/purge. Id. Indeed, as
`
`discussed in more detail below, PO’s theory that Laracey’s mobile device deletes
`
`account information at the conclusion of a transaction is wholly unsupported.
`
`Nor would a POSITA read Laracey to suggest that account balances are
`
`maintained on the mobile device exclusively. Id. (conceding that Laracey repeatedly
`
`and consistently teaches that the TMS has access to a user’s account information).
`
`10
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`Instead, a POSITA would understand that Laracey’s system fairly suggests
`
`maintaining account information on both the mobile device and the TMS. Id., ¶10.
`
`Such an arrangement was a well-established best practice with mobile payments and
`
`was, as PO’s expert admits, the precise arrangement described by Jogu—the
`
`secondary reference combined with Laracey in each proposed ground. Ex. 2001,
`
`¶¶78-79 (explaining that Jogu stores an account balance on both the mobile phone
`
`and on financial servers, permitting transactions to occur when the mobile device
`
`cannot communicate with the servers, but synchronizing the balances when service
`
`is regained). Consistent with Jogu’s approach of maintaining account balances in
`
`multiple places and synchronizing them as necessary, Mr. Smith explains that a
`
`POSITA would have understood that Laracey’s disclosure fairly suggests precisely
`
`this arrangement. Ex. 1028, ¶10. Indeed, Laracey explains that the TMS may utilize
`
`a “payment account management system,” which “contain[s] a list of all of the
`
`payment accounts the customer had registered with the system, including balance
`
`information and other details cached on the system.” Laracey, ¶134. This payment
`
`account management system is used by Laracey to update and synchronize account
`
`balances maintained in separate locations. Id.
`
`Accordingly, like Jogu, Laracey expressly contemplates maintaining account
`
`balances in multiple places and updating them as necessary. Ex. 1028, ¶10. As Mr.
`
`Smith explains, maintaining balances locally and server-side was routine and even
`
`11
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`required by many e-purse systems. Id. In his original declaration, Mr. Smith walked
`
`through examples of smart card payments systems that stored account balances
`
`locally and on the server. Ex. 1003, ¶¶53-54 (discussing U.S. Patent Publication No.
`
`2008/0166997 to Sun et al. (“Sun”) (Ex. 1008)). Sun describes an audit process
`
`where transactions records, including balances, are maintained both on the mobile
`
`device and server to enhance security. Ex. 1008; see also Ex. 1028, ¶10 (further
`
`noting that the widely recognized e-purse specification, CEPS (Ex. 1029), also
`
`explains that e-purse systems include audit logs storing balances after a transaction
`
`completes). Laracey’s setup, therefore, adheres to these same principles and logs
`
`balances in multiple locations, including at the mobile device. Ex. 1028, ¶¶9-10.
`
`iii. The proposed combinations all ensure the locally maintained
`balance is updated and stored on the mobile device at the
`conclusion of a transaction
`PO critically ignores that every proposed ground specifically modifies
`
`Laracey pursuant to Jogu’s teachings such that the local balance is updated and
`
`stored at the conclusion of a transaction. Accordingly, even if PO were correct about
`
`Laracey (it is not), the combination of Laracey and Jogu indisputably teaches an e-
`
`purse maintained on the mobile device.
`
`Mr. Smith explains that a POSITA would have understood Laracey’s locally
`
`maintained balance must be refreshed/updated when a transaction occurs to ensure
`
`the balance in the mobile device matches that maintained on the server(s). Ex. 1028,
`
`12
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`¶¶11-13. He also explains that this process would occur (1) when the device is
`
`authorized before the transaction begins, (2) after the transaction completes, or (3)
`
`both. Id. The Petition expressly accounted for this process. Indeed, the combination
`
`of Laracey and Jogu presented by the Petition relied on “Jogu’s teaching that the
`
`mobile device’s local balance should be updated after a successful transaction” and
`
`included a lengthy discussion of why a POSITA would have been motivated to
`
`implement Laracey’s system with “Jogu’s balance updating process[.]” Ex. 1003,
`
`¶¶118-122; Petition, 36-42 (explaining “a POSITA would understand that Jogu’s
`
`balance update process is particularly well-suited to Laracey’s system, which
`
`depends on maintaining an accurate balance for its accounts”).
`
`As set forth below, PO’s argument that Laracey’s system must accommodate
`
`multiple devices accessing a single account finds no support in the record and must
`
`be rejected. Under a correct read of Laracey—that each account is accessed by only
`
`one device—the proposed combination, which updates the local balance at the
`
`conclusion of a transaction avoids the stale data issues at the heart of PO’s argument.
`
`Ex. 1028, ¶¶11-13.
`
`But even if Laracey were incorrectly read to require supporting multiple
`
`devices accessing a single account, a POSITA would have found it obvious to use
`
`Laracey’s expressly contemplated balance update process upon authentication,
`
`ensuring that the mobile device begins a transaction with an accurate (i.e., not stale)
`
`13
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`account balance. Id. (noting that some embodiments in Laracey (e.g., ¶134) send
`
`account balance information to the mobile device upon authentication before a
`
`transaction proceeds and concluding that updating the local balance in this manner
`
`ensures that no balance conflicts are experienced even if multiple devices use the
`
`same account). Adding this authentication balance update to the combination of
`
`Laracey and Jogu resolves any concerns with multiple devices accessing a single
`
`account. As set forth in the Petition, pursuant to Jogu, Laracey’s mobile device
`
`updates its e-purse balance transaction data when the balance changes, and these
`
`changes are automatically reflected at the server. Petition, 36-42. Should multiple
`
`devices be registered to a single account, refreshing account balance at the start (e.g.,
`
`upon authentication) and end of a transaction ensures that the mobile device balance
`
`is always consistent with any server balance, obviating any “stale” data concerns.
`
`Ex. 1028, ¶¶11-13.
`
`In sum, Laracey alone and in combination with Jogu (as presented in the
`
`Petition), renders obvious an e-purse balance maintained in the mobile device.
`
`B.
`
`Each of PO’s Arguments Critically Turns on an Elaborate
`Misreading of Laracey
`
`Each substantive critique in the POR turns on the same mischaracterization of
`
`
`
`Laracey’s teachings. First, in Section VI.A, PO argues that Laracey’s mobile device
`
`doesn’t maintain an e-purse at all. Instead, it insists that Laracey’s device receives
`
`an e-purse balance from a server at the beginning of the transaction and deletes the
`
`14
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`balance when the transaction concludes. See, e.g., Paper 11, POR at 16 (arguing that
`
`“Laracey’s transaction flow makes clear that the device only has access to this
`
`information for the duration of a transaction”); Ex. 1029, 41:10-42:1 (testifying on
`
`cross examination that the account information should be “purged by the mobile
`
`device” when a transaction concludes). Second, in Section VI.B, PO argues a
`
`POSITA would not combine Laracey and Jogu. Paper 11, POR at 28-32. Each of
`
`these arguments turns critically on PO’s mischaracterization of Laracey as a system
`
`that never maintains an account balance on the mobile device.
`
`PO’s interpretation of Laracey finds no support in the record and should be
`
`rejected.
`
`i.
`
`There is no support for concluding that Laracey’s mobile
`device deletes account information at the conclusion of a
`transaction
`The entire POR turns on Dr. Weaver’s testimony that account information
`
`should be deleted from Laracey’s mobile device at the conclusion of a transaction.
`
`Critically, Laracey never teaches or suggests this concept. Conceding Laracey’s
`
`silence on this point, Dr. Weaver insists that a POSITA would understand from
`
`Laracey’s “context” that the data is useless and should be deleted:
`
`Q. Does Laracey ever discuss purging or deleting [account] information
`from the mobile device?
`A. I don't remember those -- seeing those words in Laracey.
`. . .
`Q. And I want to be clear about my question. I'm not asking about
`specific terminology. Just the general concept of deleting, removing,
`
`15
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`[or] purging that financial information at the conclusion of a
`transaction. Does Laracey say anything that teaches or suggests that
`general concept?
`. . .
`A.
`I believe the context of Laracey suggests that the data is no longer
`of value and that a POSITA would understand at that point that the data
`should be purged.
`
`Ex. 1029, 42:6-43:7. But the critical “context” of Laracey on which Dr. Weaver
`
`relies also finds no support in the record. Dr. Weaver admitted that the sole rationale
`
`underlying his interpretation is that “Laracey’s system is intended to allow multiple
`
`devices to utilize the same customer payment data” and “it would be difficult to
`
`synchronize that data with other devices” if it were not purged at the conclusion of
`
`a transaction. Ex. 2001, 65; Ex. 1029, 43:9-44:16.
`
`Dr. Weaver’s theory is the linchpin of the POR. Indeed, each of the POR’s
`
`substantive arguments are premised on this opinion. Paper 11, POR at 21 (in support
`
`of its theory that Laracey doesn’t teach an e-purse at all, PO proposes that
`
`“[d]ownloading the payment information to the mobile device, rather than
`
`maintaining it in the device, is critical to Laracey’s functionality” because
`
`“Laracey’s system is intended to allow multiple devices to utilize the same customer
`
`payment data”); id. at 25-26 (supporting its theory that an e-purse is not maintained
`
`on the mobile device, PO contends that “it is a central aspect of Laracey’s system to
`
`avoid maintaining financial information locally on a mobile device” and that “[a]
`
`POSITA would understand that Laracey adopted this approach consistent with its
`
`16
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`objective to implement a solution across different mobile devices”); id. at 30-31
`
`(insisting Laracey and Jogu are incompatible, arguing that, “because Laracey allows
`
`multiple users to use the same payment accounts, . . . it is critical that the Laracey
`
`system download the payment information, including a balance, from the server in
`
`response to the customer transaction request” and that “[a] POSITA would not seek
`
`to introduce [Jogu’s] balance verification before receiving the information from the
`
`server, as the verification would be against stale data”).
`
`Despite the paramount importance of Dr. Weaver’s theory to PO’s case, there
`
`is no support for his interpretation. Dr. Weaver cites three paragraphs in support—
`
`Laracey at ¶¶ 18, 43, and 67. Ex. 2001, ¶65. ¶43 is wholly irrelevant. It simply states
`
`that Laracey’s overall system is broader than the single user and single merchant
`
`depicted in Fig. 1. ¶18 and ¶¶66-67 are the allegedly supportive teachings Dr.
`
`Weaver identified on cross examination. Ex. 1029, 44:17-49:2. But even these
`
`teachings fail to support Dr. Weaver’s interpretation. They simply suggest, without
`
`elaboration, that a customer can register “one or more devices” with the described
`
`system. Laracey, ¶18 (generally referring to “one of the authorized devices”), ¶¶ 66-
`
`67 (noting the customer may register “one or more mobile devices”). Laracey never
`
`elaborates on a scenario in which a single user may register more than one device.
`
`Fig. 9 is the sole illustration of user account information, and it depicts two separate
`
`users, each with multiple accounts, but each having registered only a single device.
`
`17
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`
`
`Laracey, Fig. 9 (annotated). From these benign statements about a user registering
`
`“one or more devices,” Dr. Weaver manufactures an elaborate narrative (1) that
`
`“Laracey’s system is intended to allow multiple devices to utilize the same customer
`
`payment data[,]” (2) that “it would be difficult to synchronize that data with other
`
`devices” “[i]f the financial information were stored on a mobile device,” and (3) that
`
`“the context of Laracey suggests that the data is no longer of value and that a
`
`POSITA would understand at that point that the data should be purged.” Ex. 2001,
`
`¶65; Ex. 1029, 41:10-43:8.
`
`In fact, a POSITA would not interpret Laracey as Dr. Weaver describes. As
`
`Mr. Smith explains, Dr. Weaver correctly notes that stale data is a problem when
`
`18
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`multiple devices have access to the same account. Ex. 1028, ¶¶11-13. Although
`
`Laracey briefly alludes to the possibility of a user registering multiple devices, it
`
`never once discusses or even alludes (1) to allowing multiple devices to access a
`
`single account or (2) to the problem of stale data. Laracey’s silence on these points
`
`strongly suggests that the reference does not contemplate allowing multiple devices
`
`to access a single account. Id. Given this, a POSITA would have interpreted Laracey
`
`to contemplate a system in which each account is used by only a single device. Id.
`
`(noting that a user might register multiple devices and assign different accounts to
`
`each device, but concluding that nothing in Laracey suggests accommodating the
`
`more complicated scenario in which the system allows multiple devices, potentially
`
`simultaneously, to access a single account).
`
`As discussed above in Section II.A.ii, each proposed ground relies on a
`
`combination of Laracey and Jogu in which the e-purse account balance maintained
`
`in Laracey’s mobile device is updated and stored at the conclusion of a transaction,
`
`ensuring that Laracey’s mobile device always has an accurate account balance. See
`
`Petition, 40-41 (explaining that “a POSITA would understand that Jogu’s balance
`
`update process is particularly well-suited to Laracey’s system, which depends on
`
`maintaining an accurate balance for its accounts”). Accordingly, even if PO were
`
`correct that Laracey must accommodate multiple devices access the same account
`
`(it is not), the proposed combination still renders obvious the Challenged Claims.
`
`19
`
`
`
` Petitioner’s Reply to Patent Owner’s Response
`IPR2022-01239
`
`
`
`
`ii.
`
`Each of the POR’s arguments fall with Dr. Weaver’s flawed
`interpretation of Laracey
`Because the remaining POR arguments each depend on Dr. Weaver’s flawed
`
`opinion that Laracey’s mobile device deletes account balance information after each
`
`transaction, they are easily disposed of.
`
`a) PO does not dispute that maintaining an account balance on
`Laracey’s mobile device satisfies the claimed e-purse
`PO first argues that the Petition fails to identify an e-purse in Laracey’s mobile
`
`device that satisfies PO’s proposed construction—“software” that “stores electronic
`
`financial information in a local device.” Paper 11, POR at 14-22. Neither PO nor Dr.
`
`Weaver dispute that Laracey’s mobile device utilizes software for its transaction
`
`functionality. Ex. 1029, 60:19-24 (agreeing that “Laracey's mobile device executes
`
`software to perform its transaction functionality”). Instead, this argument rises and
`
`falls with Dr. Weaver’s theory that a POSITA would understand account data should
`
`be deleted from Laracey’s mobile device at the conclusion of a transaction. Paper
`
`11, POR at 15 (“Laracey does not store financial information locally . . . [i]nstead,
`
`it stores financial information in a database on a server.”), 16 (“Laracey’s transaction
`
`flow makes clear that the device only has access to [financial] information for the
`
`duration of a transaction – this is not ‘maintained’ in a mobile device.”), 21
`
`(“Downloading the payment information to the mobile device, rather than
`
`maintaining it in the device is critical to Laracey’s functionality” bec
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
