`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`
`
`APPLE, INC.
`Petitioner
`
`v.
`
`RFCYBER CORP.,
`Patent Owner
`_________________
`
`
`
`Inter Partes Review Case No. IPR2022-01239
`U.S. Patent No. 10,600,046
`
`
`
`
`
`SUPPLEMENTAL DECLARATION OF GERALD W. SMITH
`
`
`
`
`
`
`
`
`IPR2022-01239
`Apple EX1028 Page 1
`
`
`
`
`
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`
`IPR2022-01239
`Apple EX1028 Page 2
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`
`I, Gerald Smith, declare as follows:
`
`I.
`
`INTRODUCTION
`
`1. My name is Gerald Smith, and I am over 21 years of age and otherwise
`
`competent to make this Declaration. I make this Declaration based on facts and
`
`matters within my own knowledge and on information provided to me by others.
`
`2.
`
`I submitted an original declaration (Ex. 1003) in support of Petitioner’s
`
`Petition for Inter Partes Review of U.S. Patent No. 10,600,046 (the “’046 Patent”).
`
`I understand the PTAB instituted the requested review and that the proceeding
`
`involves the full scope of the proposed grounds addressed in my initial declaration.
`
`I have been asked to address a few additional issues raised by Patent Owner in Patent
`
`Owner’s Response dated May 19, 2023 and the accompanying expert declaration of
`
`Dr. Alfred C. Weaver (Ex. 2001). All of my opinions expressed in my original
`
`declaration (Ex. 1003) remain the same.
`
`3.
`
`As part of my work and in forming my opinions in connection with this
`
`proceeding, I have reviewed the following materials. For any prior art listed below,
`
`it is my opinion persons of ordinary skill in my field would reasonably rely upon
`
`such prior art in forming opinions regarding the subject matter of this proceeding:
`
`• Materials relied on for my previous Declaration
`• Institution Decision (“ID”) (Paper 7)
`• Patent Owner’s Response (“POR”) (Paper 11)
`• Declaration of Alfred C. Weaver (Ex. 2001)
`• Transcript of Deposition of Alfred C. Weaver (Ex. 1028)
`
`
`
`11
`
`IPR2022-01239
`Apple EX1028 Page 3
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`
`II.
`
`• Any other materials cited below
`
`SUPPLEMENTAL OPINIONS REGARDING THE COMBINATION
`OF LARACEY AND JOGU
`A.
`In Laracey’s dynamic checkout token embodiments, the mobile
`device need not request account information from the TMS
`4.
`As I explained in my original declaration, while Laracey contemplates
`
`two types of checkout tokens, (1) static checkout tokens, and (2) dynamic checkout
`
`tokens, my analysis—and the proposed grounds in the petition—focused on the
`
`teachings of Laracey that pertain to dynamic checkout tokens. I made a number of
`
`observations about Laracey’s dynamic checkout token embodiments. In ¶79 of my
`
`original declaration, I observed that Laracey teaches embodiments in which “all of
`
`the transaction details may be encoded in a dynamic checkout token [so that]
`
`when captured and processed by the mobile device 102, provides the transaction
`
`details to the mobile device 102,” Laracey, ¶38 (emphasis added), see also ¶55
`
`(teaching dynamic checkout tokens are used to communicate transaction details from
`
`the merchant 208 to the mobile device 202). Similarly, I noted that, when dynamic
`
`checkout tokens are used to transmit transaction details from the POS to the user’s
`
`mobile device, Laracey expressly teaches that “no transaction details need be
`
`received by the mobile device 202 from the transaction management system
`
`230[.]” Id., ¶60 (emphasis added).
`
`
`
`12
`
`IPR2022-01239
`Apple EX1028 Page 4
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`In ¶¶ 80-82 and 92 of my original declaration, I contrasted the static
`
`5.
`
`checkout token as taught by Laracey with its dynamic checkout token teachings. As
`
`I explained, in the case of a static checkout token, “the mobile device 102 transmits
`
`the token to the transaction management system 130 in a customer transaction
`
`lookup request message [...].” Laracey, ¶35. The transaction management system
`
`130 will then match the information in the customer transaction lookup request with
`
`information received from the merchant 108 that was also sent to the transaction
`
`management system 130. Once a match is found the transaction management system
`
`130 will then “transmit[] a transaction detail message (via path 114) to the
`
`customer’s mobile device 102[,]” thus providing the customer with details about the
`
`transaction. Id., ¶36. In contrast, when a dynamic checkout token is used, the mobile
`
`device need not obtain transaction details from the TMS. Once a dynamic token is
`
`captured, Laracey teaches that the mobile device processes the dynamic token to
`
`reveal transaction information related to the transaction for which the dynamic token
`
`was created (i.e., capture data directly from a tag). Id., ¶19 (teaching that “the term
`
`‘capture’ further includes any decoding or image processing of a checkout token
`
`required to retrieve or otherwise obtain information from the checkout token.”), ¶38
`
`(teaching “when captured and processed by the mobile device 102, [a dynamic
`
`checkout token] provides the transaction details to the mobile device 102”), ¶ 82
`
`(teaching a dynamic checkout token will reveal “the total transaction amount and
`
`
`
`13
`
`IPR2022-01239
`Apple EX1028 Page 5
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`other transaction details associated with the transaction for which the dynamic
`
`checkout token was generated”). Indeed, the express benefit Laracey ascribes to
`
`dynamic checkout token embodiments is minimizing communications between the
`
`mobile device and TMS during a transaction. For example, Laracey at ¶54 teaches
`
`the dynamic checkout token embodiments “involve fewer messages between the
`
`mobile device 202 and the transaction management system 230 during a payment
`
`transaction.” Confirming this goal and benefit of minimizing communications,
`
`Laracey at ¶38 unambiguously teaches that the dynamic checkout token avoids the
`
`need entirely to send a transaction lookup request to the TMS (e.g., step 432 in Fig.
`
`4B).
`
`6.
`
`Supported by the teachings noted above, a POSITA would have
`
`understood from Laracey’s teachings 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. Indeed, Laracey
`
`repeatedly and exclusively teaches that the TMS containing a checkout token (step
`
`432 in Fig. 4B) is the transaction-related message (i.e., after the device has been
`
`authenticated) that causes the TMS to send account information to the mobile device.
`
`Id. For example, annotated Fig. 4B below illustrates the post-authorization
`
`communications between the mobile device and TMS, showing that a user’s account
`
`
`
`14
`
`IPR2022-01239
`Apple EX1028 Page 6
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`information is sent to the mobile device in response to receiving a transaction lookup
`
`request with checkout token to the TMS:
`
`
`
`15
`
`
`
`IPR2022-01239
`Apple EX1028 Page 7
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`Laracey, Fig. 4B (annotated to indicate direction of communication between mobile
`
`device and TMS). Similarly, Laracey at ¶¶ 35-36 teaches the mobile device
`
`transmitting a transaction lookup request with checkout token to the TMS and the
`
`receiving account information in response. Laracey at ¶58 notes that “the list of
`
`accounts . . . from the transaction management system” are received by the mobile
`
`device “after it processes the customer transaction lookup request[.]” Laracey’s
`
`teachings at ¶¶ 98-99 and at 109-110 follow the same pattern. In each case, the
`
`mobile device received account information from the TMS in response to
`
`transmitting a transaction lookup request with checkout token.
`
`7.
`
`It is worth noting that Laracey includes a single specific example in
`
`which “a list of available payment accounts may be transmitted to” the mobile device
`
`after authentication. Laracey, ¶¶ 112-113. But even in this specific example, 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. Indeed,
`
`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.” A similar, though less specific, example
`
`is described with reference to Fig. 6. There, too, Laracey suggests that account
`
`information may be sent to the mobile device incident to authorization (e.g., Laracey
`
`at ¶134), but it also teaches that transaction-specific account information is later to
`
`
`
`16
`
`IPR2022-01239
`Apple EX1028 Page 8
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`the mobile device in response to the TMS receiving a checkout token from the
`
`mobile device. See Laracey, ¶139 (describing step 13 in which the mobile device
`
`sends the TMS a checkout token), ¶ 140 (describing step 16 in which the TMS sends
`
`the mobile device a response with transaction details).
`
`8.
`
`Accordingly, 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). Instead, all necessary
`
`transaction information is received from the POS terminal and the first transaction-
`
`specific communication to the TMS is a payment authorization message (e.g., step
`
`440 in Fig. 4B). Fig 4B below is annotated to reflect the communications involved
`
`in this embodiment:
`
`
`
`17
`
`IPR2022-01239
`Apple EX1028 Page 9
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`
`Laracey, Fig. 4B (annotated).
`
`
`
`
`
`18
`
`
`
`IPR2022-01239
`Apple EX1028 Page 10
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`B.
`token embodiments, account
`In Laracey’s dynamic checkout
`information is maintained on the mobile device
`9.
`I understand PO and its expert, Dr. Weaver, contend that account
`
`information should be deleted from the mobile device at the conclusion of a
`
`transaction. I disagree. As I explain below, PO’s theory finds no support in Laracey.
`
`As importantly, however, it also conflicts with well-established best practices in the
`
`industry. As a starting point, a POSITA would have understood that there are three
`
`possible arrangements for where account balances are maintained in Laracey’s
`
`system. It can be maintained (1) on the TMS exclusively, (2) on the mobile device
`
`exclusively, or (3) on both the TMS and the mobile device. As to (1), 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. 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. Indeed, as discussed in more detail below, responding directly to
`
`PO’s theory, there is no teaching or suggestion in Laracey that its mobile device
`
`deletes account information at the conclusion of a transaction. Turning to (2), a
`
`POSITA would also not read Laracey to suggest that account balances are
`
`maintained on the mobile device exclusively. Indeed, Laracey repeatedly and
`
`consistently teaches that the TMS has access to a user’s account information.
`
`
`
`19
`
`IPR2022-01239
`Apple EX1028 Page 11
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`10. Consistent with Laracey’s express teachings and well-established
`
`practices in the industry, a POSITA would have understood that Laracey’s system
`
`fairly suggests maintaining account information on both the mobile device and the
`
`TMS—option (3) identified in the prior paragraph. Such an arrangement was
`
`commonplace with mobile payment and was the precise arrangement described by
`
`Jogu—the secondary reference combined with Laracey in each of the Petition’s
`
`proposed grounds. In fact, Dr. Weaver acknowledges in his declaration 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. Ex. 2001, ¶¶78-
`
`79. Consistent with Jogu’s approach of maintaining account balances in multiple
`
`places and synchronizing them as necessary, a POSITA would have understood that
`
`Laracey’s disclosure fairly suggests precisely this arrangement. 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. Consistent with
`
`
`
`20
`
`IPR2022-01239
`Apple EX1028 Page 12
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`Laracey’s teachings, storing account balances both on the mobile device and on one
`
`or more servers was well accepted best practice in the industry. As I explained in my
`
`original declaration at ¶53-54, it was well known to maintain account balances on
`
`mobile devices. I specifically discussed U.S. Patent Publication No. 2008/0166997
`
`to Sun et al. (“Sun”) (Ex. 1008), which teaches a stored value account contained
`
`within the secured memory portion of a SIM card that is designed to fit in the SIM
`
`card slot of a mobile phone. As I noted, Sun teaches an audit process where
`
`transaction records, including balances, are maintained both on the mobile device
`
`and server-side, which provides a level of security, allowing the system to detect
`
`fraud or tampering. Sun explains that stored value (i.e., account balance) records are
`
`used in this auditing process:
`
`[T]he operation server is adapted to receive periodically transmitted
`stored value audit records delivered from mobile devices via the
`telecommunication provider network to the operation server. The
`operation server also includes programs adapted to review and monitor
`the stored value audit records and account activity to detect fraud or
`tampering with the stored value memory on the mobile devices, and to
`otherwise improve security of the mobile payment system.
`
`Sun, [0033]. Such audit capability was routine and even required by many e-purse
`
`systems. For example, The March 2001 (V2.3) Common Electronic Purse
`
`Specification (“CEPS”) defines information that must be included in such audit logs,
`
`including a balance of the account after the transaction completes. Ex. 1029, 85-86.
`
`CEPS was a widely recognized and implemented standard for e-purses. Indeed, the
`
`
`
`21
`
`IPR2022-01239
`Apple EX1028 Page 13
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`Proton Prisma documents I discussed in my original declaration repeatedly refer to
`
`CEPS compliance (e.g., Ex. 1012, 17) and notes that Prisma transactions are “fully
`
`traceable and auditable (e.g., Ex. 1023, 2), confirming my opinion that all this
`
`functionality was not only well understood, but also important in e-purse systems.
`
`C.
`The proposed combination of Laracey and Jogu ensures that an
`accurate e-purse balance is maintained on the mobile device
`11.
`I understand that Dr. Weaver opined that Laracey’s mobile device
`
`should delete account data at the conclusion of a transaction because (1) Laracey’s
`
`system allows multiple devices to access a single account and (2) a locally
`
`maintained balance would be “stale” if other devices were deducting value from the
`
`same account. Dr. Weaver correctly notes that stale data is a problem when multiple
`
`devices have access to the same account. However, Laracey never once discusses or
`
`even alludes to the problem of stale data, which strongly suggests that the reference
`
`does not contemplate allowing multiple devices to access a single account. Instead,
`
`a POSITA would have interpreted Laracey to contemplate a system in which each
`
`account is used by only a single device. I acknowledge that Laracey suggests a user
`
`may register one or more device within Laracey’s system (e.g., Laracey, [0018]),
`
`but a POSITA would not interpret this to mean that a user might register multiple
`
`devices and assign different accounts to each device. Nothing in Laracey’s
`
`disclosure suggests accommodating the more complicated scenario in which the
`
`
`
`22
`
`IPR2022-01239
`Apple EX1028 Page 14
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`system allows multiple devices, potentially simultaneously, to access a single
`
`account.
`
`12. A POSITA would, however, have understood that 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). A
`
`POSITA would have understood that the occurs (1) when the device is authorized
`
`before the transaction begins, (2) after the transaction completes (e.g., via Laracey’s
`
`“transaction complete message”), or (3) both. Id. The Petition and my original
`
`declaration expressly accounted for this process. Indeed, the combination of Laracey
`
`and Jogu that I discussed in my original declaration relied on “Jogu’s teaching that
`
`the mobile device’s local balance should be updated after a successful transaction,”
`
`and I 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. At ¶120 of my original declaration, I explained that “Jogu’s teaching that
`
`the mobile device’s local balance should be updated after a successful transaction
`
`would also be well-suited to Laracey’s system.”). 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. Indeed, where only one device uses a given
`
`account, refreshing/updating the locally stored balance at the conclusion of a
`
`
`
`23
`
`IPR2022-01239
`Apple EX1028 Page 15
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`transaction ensures the balance maintained at the mobile device and at the server(s)
`
`matches (i.e., is not stale).
`
`13. 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)
`
`account balance. Indeed, 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 experience 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 my original declaration, 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. Ex. 1003, ¶¶ 119-122. 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.
`
`D.
`
`Laracey’s “proxy” feature is optional
`
`
`
`24
`
`IPR2022-01239
`Apple EX1028 Page 16
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`I’ve been asked to consider whether Laracey’s financial account proxy
`
`14.
`
`feature is mandatory of all embodiments. It is not. Laracey is clear that using proxy
`
`representations of financial accounts on the mobile device, rather than full financial
`
`credentials, is an optional feature to increase security. See Laracey, ¶45 (“Pursuant
`
`to some embodiments, . . . the mobile device 102 stores or has access to a proxy
`
`associated with actual payment credentials[.]”), ¶99 (teaching “[t]he data identifying
`
`the customer's payment account(s) may
`
`include proxies or non-sensitive
`
`identifiers”), ¶100 (“In some embodiments, the actual payment account information
`
`is not stored in the mobile device; instead, a non-confidential or non-sensitive
`
`identifier is used to identify the account[.]”). Given that only some embodiments use
`
`these account proxies, a POSITA would have understood that their use is optional,
`
`i.e., that other embodiments do not use proxies and instead use full account
`
`credentials.
`
`E.
`The combination of Laracey and Jogu does not depend on Laracey
`operating offline
`15.
`I understand that PO has suggested Jogu’s process—which permits a
`
`transaction to occur while offline and updating the balances when service is
`
`regained—is incompatible with Laracey because Laracey’s system can’t function
`
`while offline. The proposed combination does not in fact rely on Jogu’s offline
`
`transaction functionality. Instead, as I explained in my original declaration, the
`
`combination proposes Laracey’s system would have been improved by specific
`
`
`
`25
`
`IPR2022-01239
`Apple EX1028 Page 17
`
`
`
`Declaration of Gerald W. Smith
`Patent No. 10,600,046
`features from Jogu, including (1) performing a balance check, (2) displaying a denial
`
`when the account balance is insufficient, (3) generating a payment request only when
`
`sufficient funds exist, and (4) reducing the account balance on the mobile device
`
`after a successful transaction to ensure the local balance is accurate. Ex. 1003, ¶¶
`
`119-130. None of these functionalities requires Laracey’s process to be offline. Nor
`
`do the benefits derived from the proposed combination depend on any offline usage.
`
`Instead, the proposed combination retains specific communications between the
`
`mobile device and TMS, including the mobile device’s payment request and a
`
`successful transaction confirmation message that includes a balance update. Id. at
`
`¶105-107, 121.
`
`III. CONCLUSION
`
`16.
`
`I declare that all statements made herein of my knowledge are true, and
`
`that all statements made on information and belief are believed to be true, and that
`
`these statements were made with the knowledge that willful false statements and the
`
`like so made are punishable by fine or imprisonment, or both, under Section 1001 of
`
`Title 18 of the United States Code.
`
`Date: ______________________
`
`By: ______________________
` Gerald W. Smith
`
`26
`
`IPR2022-01239
`Apple EX1028 Page 18
`
`
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
