Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper 22
`Date: November 21, 2023
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`Patent Owner
`____________
`
`IPR2022-01239
`Patent 10,600,046 B2
`____________
`
`Record of Oral Hearing
`Held: October 24, 2023
`____________
`
`
`Before JOSIAH C. COCKS, PATRICK R. SCANLON, and KEVIN W.
`CHERRY, Administrative Patent Judges.
`
`
`
`
`
`
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`PAUL R. HART, ESQUIRE
`ERISE IP, P.A.
`717 17th Street, Suite 1400
`Denver, CO 80202
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`RICHARD COWELL, ESQUIRE
`FABRICANT, LLP
`411 Theodore Fremd Avenue,
`Suite 206 South,
`Rye, New York 10580
`
`
`The above-entitled matter came on for hearing on October 24,
`2023, commencing at 1:00 p.m., via video teleconference.
`
`
`
`
`
`
`
`
`
`2
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE SCANLON: Okay, good afternoon and welcome to the
`Patent and Trial and Appeal Board. We are here today for a consolidated
`hearing in IPR2022-01239 and 01256 between Petitioner, Apple, Inc., and
`Patent Owner, RFCyber Corp. The 1239 case involves patent number
`10,600,046, and the 1256 case involves patent number 11,018,724. I'm
`Judge Scanlon and joining me today are Judge Cherry and Judge Cocks.
`Let's start with appearances. Who is here for Petitioner, please?
`MR. HART: Thank you, Your Honor. Paul Hart with ERISE IP
`for Petitioner Apple Inc.
`JUDGE SCANLON: All right. Thank you. And for Patent
`
`Owner?
`
`MR. COWELL: Good afternoon, Your Honor. Richard Cowell of
`FABRICANT LLP for Patent Owner RFCyber Corp.
`JUDGE SCANLON: All right. Very good. I'd like to go over
`some brief guidelines for this video hearing. If at any time during you
`encounter technical or other difficulties, please let us know immediately so
`we can try to address the issue. If you get disconnected completely please
`contact the hearing staff who provided you with the contact information.
`Please make every effort to speak clearly and avoid speaking over others.
`That will assist our court reporter in making a clear record. Also please
`mute your line when not speaking. We do have access to the entire record,
`including the demonstratives. It's helpful for you to provide us with the page
`number for the slides to improve the clarity of the record. And likewise, if
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`3
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`you're citing to exhibits or papers. Please be aware that we have a public
`access line open for the hearing. I don't believe there's any confidential
`information in this -- in the record for these proceedings, but if there's
`something that's confidential that you want to discuss, let us know so we can
`make accommodations. As set forth in the hearing order, each party is
`permitted 90 minutes to present their arguments. Because it bears the
`burden of persuasion, Petitioner will go first and may reserve no more than
`half of its time for rebuttal. Patent Owner will then have an opportunity to
`respond and may also reserve time for a sur-rebuttal. We'll keep time to the
`best of our ability and I will try to provide updates about remaining time as
`the hearing progresses. With that, we'll start with Petitioner, and please let
`us know how much time, if any, you would like to reserve for rebuttal.
`MR. HART: Thank you, Your Honor. Just as a point of
`clarification, the parties addressed the 1239 proceeding first in their
`demonstratives. I assumed that we were going to split up the proceeding as
`such that we would address the '046 Patent proceeding first, and then
`transition to the '724 proceeding. Is that consistent with Your Honors'
`preferences here?
`JUDGE SCANLON: That would be fine, yes. Are you saying go
`through -- are you proposing that each party presents their cases for the 1239
`and then transition to the next case?
`MR. HART: Exactly. These are unrelated patents using different
`prior art. It seems like bucketing them in that way might help clarify the
`issues for everybody. So if you're amenable to that approach, I would
`reserve 15 minutes of my first 45 minutes for the 1239 proceeding regarding
`the '046 Patent, and I'll plan to start with that proceeding.
`4
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`
`JUDGE SCANLON: Okay, that should be fine. Before we
`proceed, I guess, just so we're clear, I would like to ask Mr. Cowell, is that
`procedure acceptable to the Patent Owner?
`MR. COWELL: Yes, Your Honor. I have no objection to that.
`JUDGE SCANLON: Okay, then we will proceed in that manner.
`So then Mr. Hart you said -- I guess in that case you would have 45 minutes
`for your case in the 1239 case which we'll address first, and I believe you
`said you would like to reserve 15 minutes.
`MR. HART: Yes, Your Honor.
`JUDGE SCANLON: Okay. With that then, please proceed.
`MR. HART: Thanks very much, Your Honor. I'd like to start with
`Petitioner's DX-3 from its demonstratives just to provide an overview of the
`subject matter here. The '046 claims describe a process for using a mobile
`phone to make a purchase. The phone captures an invoice from the
`merchant. The phone presents the invoice to the user, allows the user to add
`a tip. The phone then allows the user to choose an e-purse account for the
`purchase. The phone confirms their sufficient balance and sends a payment
`request to the payment gateway. Finally, if the transaction was successful,
`the device receives a confirmation of successful transaction from the
`payment gateway and displays that to the user.
`Now, relevant to the parties' disputes in this proceeding, it's
`important to point out that the claims require some steps that are performed
`locally in the device without involving the payment gateway and some steps
`that are performed in a connected arrangement via communications with the
`payment gateway. For example, in Claim 1 that I have up here on DX-3, the
`verifying step requires checking the transaction total against a balance of the
`5
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`e-purse without resending a request to the payment gateway. In other words,
`when the balance verification step occurs, the mobile phone must already
`have the e-purse balance locally in the device to check against the
`transaction total. In contrast, the payment request step requires a connected
`arrangement. The mobile device must send a payment request to the
`payment gateway and then receive a confirmation from the gateway. So two
`different types of steps in these claim methods, some connected, some fully
`contained within the mobile device.
`Now in the proposed combination, Petitioner relies on a Laracey,
`its base reference, for a mobile device that captures an invoice, allows the
`user to add a tip, allows the user to select an e-Purse account for the
`transaction, and sends a payment request to the gateway. Jogu is relied upon
`for performing the balance check on the device to ensure that the user
`receives an indication of whether the balance is sufficient to cover the
`transaction. Then the mobile device in Laracey, as modified by Jogu,
`updates that locally stored balance at the conclusion of the transaction to
`ensure that the locally stored balance is accurate, matching the balance
`stored on the server.
`Turning to DX-4, it's important to address two different types of
`embodiments in Laracey. So one of the key concepts in Laracey that
`underlies many of the parties' disputes in this proceeding is Laracey's
`distinct teachings with regard to static versus dynamic checkout tokens.
`Now checkout tokens in Laracey are the mechanism by which the merchant
`communicates with the mobile device. DX-4 illustrates and describes the
`static checkout token example. The key feature of a static checkout token in
`Laracey is that the static token does not provide pricing or other transaction
`6
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`information to the mobile device. And so because the merchant did not
`provide pricing or transaction information to the device, we see a process
`flow as illustrated in Figure 4B of Laracey on DX-4 that allows the system
`to connect the dots and to ultimately provide the transaction details to the
`mobile device. Specifically, after authentication, the checkout token is
`obtained from the merchant by the mobile device. That's step 430. Then the
`mobile device transmits a customer transaction -- or I'm sorry, lookup
`request to the transaction management system, the TMS, the server in the
`Laracey arrangement. The server, the TMS, then takes that token, connects
`with the merchant on the back end, finds the transaction, and then looks up
`the user's account and figures out which accounts are viable for the
`transaction. The TMS then sends the transaction details, as well as all viable
`accounts to the mobile device, and then the process proceeds by the mobile
`device allowing the user to select which of those accounts it would like to
`use for the transaction and ultimately sending a payment request back to the
`TMS server. So that's the static checkout token example where no
`transaction information is provided from the merchant directly to the mobile
`device.
`
`Turning to DX-5, the major difference with a dynamic token is that
`the full transaction details can be contained within the dynamic checkout
`token received from the merchant. As Laracey explains here on DX-5 in
`paragraph 38, in embodiments using a dynamic checkout token, checkout
`processing may proceed without the need for a customer transaction lookup
`request message to be transmitted to the TMS at all. Some or all of the
`transaction details are contained in that checkout token. In paragraph 54 of
`Laracey, Laracey continues and explains that the benefit of using a dynamic
`7
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`checkout token is that it involves fewer messages between the mobile device
`and the TMS during a payment transaction. So when the token is received,
`the mobile device has all the information it needs to present options to the
`user and to generate a payment request pursuant to the user's selection.
`Importantly, turning to DX-6, the Petition focuses entirely on
`Laracey's dynamic token embodiment. Pursuant to these teachings in
`Laracey that I just covered in DX-5, the proposed grounds assume that no
`transaction-specific communications occur with the TMS until the payment
`request is sent. That is, the verification occurs on the device, the balance
`check occurs on the device, all of that occurs locally without communicating
`with the TMS. It is not until the payment request is prepared and ready to be
`sent that the mobile device first contacts the TMS. The proposed grounds
`also assume --
`JUDGE SCANLON: Excuse me, Mr. Hart. I'm sorry to interrupt.
`MR. HART: Yes, Your Honor.
`JUDGE SCANLON: My question along this line is did the
`Petition rely on a distinction between the static and dynamic tokens with
`respect to the payment request step or just the verification step?
`MR. HART: The Petition relied upon the dynamic checkout token
`throughout its mapping, starting early on in its mapping of Claim 1,
`including where it is pointing out the first limitations of Claim 1, where the
`mobile device is receiving transaction information, invoice information,
`directly from the merchant. Again, that only occurs in the dynamic checkout
`token example. It does not occur in the static dynamic, I'm sorry, the static
`checkout token example. And so from the beginning of our mapping, we
`were clear that the proposed grounds in the Petition relied on Laracey's
`8
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`dynamic checkout token. The only embodiment in Laracey that does
`actually provide those invoice details, the payment information, I'm sorry,
`the pricing information, and the transaction details directly from the
`merchant.
`JUDGE SCANLON: Okay. Thank you.
`MR. HART: Yes, Your Honor. Thanks for the question. Coming
`back to DX-6, so per Laracey's teachings on the dynamic checkout token,
`the proposed grounds assume that no transaction-specific communications
`occur with the TMS until the payment request, and that the mobile device
`has locally stored account information, including balances, when that token
`is received. The proposed grounds then point to Jogu for its teachings
`related to checking the balance on the mobile device, informing the user
`whether the balance is sufficient, and then updating that locally stored
`balance after the transaction concludes to ensure that local balance on the
`mobile device remains accurate, in essence matches the balance that is
`maintained on the server, the TMS server.
`Turning to DX-7, I've summarized the remaining disputes between
`the parties here. The first dispute relates to whether Laracey's e-purse
`functionality is software. As I'll cover in the next few slides, it
`unquestionably is. Next, the parties dispute whether the proposed
`combination satisfies maintaining an e-purse in the mobile device. Now,
`Patent Owner's arguments have shifted significantly on this issue through the
`course of the proceeding. In its Patent Owner Response, Patent Owner
`argued that maintaining an e-purse did not require storing value at all, but
`merely required storing account information on the mobile device between
`transactions. The Patent Owner Response insisted that a POSITA would
`9
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`have understood Laracey's mobile device deletes all account information at
`the conclusion of a transaction, and from that, the Patent Owner Response
`argued that no account information is maintained as required by the claims.
`The sur-reply appears to have abandoned this argument. It does not argue
`that any account information is deleted at the conclusion of a transaction.
`Instead, despite the Patent Owner Response having argued that maintaining
`an e-purse doesn't require storing value at all, the sur-reply newly argues that
`the mobile device must not only maintain an account balance, but that the
`account balance maintained in the mobile device must be accurate and non-
`stale at all times. As I'll cover today, Petitioner prevails under either of
`Patent Owner shifting theories.
`The proposed grounds modify Laracey pursuant to Jogu such that
`an account balance is updated at the conclusion of every transaction,
`ensuring the balance on the mobile device is always accurate and not stale.
`Finally, on DX-7, Patent Owner raises a number of motivation to combine
`arguments. Now, as I'll get into in the subsequent slides, Patent Owner is
`maintaining an e-purse argument and its motivation to combine arguments
`all turn on the same flawed theory of Laracey. Namely, Patent Owner insists
`that Laracey requires permitting multiple devices to access a single account.
`It argues that if multiple devices access the same account, none of the
`individual devices can ever maintain an accurate, non-stale account balance,
`it must instead rely on the TMS to rely on the one and only accurate copy of
`the account balance. Now, as I've explained in the prior slides, the proposed
`grounds do not take such a narrow view of Laracey. They assume that an e-
`purse is accessed by only one device, and they rely on Jogu to make sure
`that balance is updated at the conclusion of the transaction, ensuring that it is
`10
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`always accurate and not stale. Now, Patent Owner in this proceeding can
`only prevail if it convinces the Board that Laracey is so narrow that it
`excludes scenarios like that in the proposed combination, where an e-purse
`is accessed by only one device. Laracey is not so narrow. In fact, the
`proposed combination tracks the only specific user account examples
`illustrated in Laracey, each of which teach accounts accessible by only one
`device.
`
`Turning to the first dispute, DX-8 through DX-10 address whether
`Laracey's e-purse functionality is software. In DX-8, this argument really
`boils down to Patent Owner seeking to limit Petitioner's reliance on Laracey,
`far more limited than Patent Owner actually relied on Laracey. The Petition
`proposed a construction of e-purse, that is software that stores electronic
`financial information including an electronic value in a local portable device.
`Patent Owner argues that Petitioner exclusively mapped the balance of an e-
`purse rather than the e-purse functionality, and from that it argues that an e-
`purse balance is just data, it's not software. Patent Owner is wrong.
`We turn to DX-9. As shown in DX-9, this excerpt from the
`Petition, page 29, shows that Petitioner's reliance on Laracey was far
`broader. It did not rely solely and exclusively on the account balance in
`isolation. This excerpt starts out by noting the e-purse construction that
`Petitioner applied in this proceeding, software that stores electronic value. It
`then goes on to state, Laracey teaches its mobile devices equipped with
`software that satisfies this construction and that it emphasizes a specific
`teaching in Laracey, namely, Laracey's mobile device can be used to initiate
`and conduct payment transactions involving stored value accounts. That is
`the software that satisfies the e-purse construction advanced in this
`11
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`proceeding. The Petition then highlighted the portion of that software that
`actually stores the electronic value, that performs the portion of the claim
`construction that requires storing electronic value. It stated that Laracey
`stored value account stores electronic financial information, including
`electronic value. In other words, the stored value account is just the portion
`of the overall software, the transaction software that Petitioner relied on
`from Laracey in its mapping.
`Now turning to DX-10, there's no legitimate dispute that Laracey
`conducts stored value transactions using software. Patent Owner's expert
`agreed on cross-examination that Laracey's transactions are in fact
`conducted via software, and as we see here from Petitioner's expert's original
`declaration, he explained that stored value accounts were well known in the
`prior art as the portion of financial transaction software that actually store
`value that is used to conduct financial transactions based on those stored
`value accounts. In sum, Petitioner's mapping here is far broader than Patent
`Owner alleges. It did map software and not just the account balance data in
`isolation.
`DX-11 through DX-18 address what is really the primary dispute
`between the parties in this proceeding, namely whether the proposed
`combination maintains an e-purse in the mobile device. On DX-11, I start
`with the Patent Owner Response. As I mentioned earlier, the theories
`advanced by a Patent Owner have shifted drastically in this proceeding. The
`Patent Owner Response at page 11 argued that an e-purse need not store
`electronic value, insisting as it did in the litigation that an e-purse need only
`store financial information. Consistent with that position, the Patent Owner
`response argument was that maintaining an e-purse requires storing financial
`12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`information on the mobile device between transactions. It further argued
`that Laracey's mobile device does not store financial information between
`transactions. Instead, Patent Owner argued that it receives a proxy
`representation of financial information and retains that only for the duration
`of a transaction, deleting it at the conclusion of a transaction. So that's the
`Patent Owner Response theory. You just need to store financial information.
`It need not include account balance, but that financial information needs to
`be stored between transactions.
`JUDGE SCANLON: Excuse me again, Mr. Hart. Would
`Petitioner agree with that, I guess, construction that storing financial
`information would mean maintaining a e-purse?
`MR. HART: We advance a narrower definition of e-purse that
`does require storing electronic value. Our proposed combination satisfies
`either. So, I'm sorry, Patent Owner advanced that broader construction in
`the litigation. It advanced that broader construction in the Patent Owner
`Response. Our proposed combination unquestionably satisfies that broader
`construction, but we have focused our mapping on a narrower construction,
`the same narrower construction we advanced in the application in the
`litigation.
`JUDGE SCANLON: Okay, yeah, thank you. I guess what I was
`really driving at, I don't think either party has really proposed the explicit
`construction for maintain, but would you agree that storing and maintaining
`in this case are equivalent?
`MR. HART: Yes, Your Honor, that is the meaning that both
`parties ascribe to maintaining, certainly up through the Patent Owner
`Response. As I'll get into in a few slides, the sur-reply shifts its theory and
`13
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`tries to back away from its theory that maintaining is storing, but both
`parties have advanced a theory that maintaining is simply storing, and that,
`you know, as I've already mentioned, whether the construction applied by
`the Board requires simply storing financial information under Patent
`Owner's broader construction, or storing electronic value under our narrower
`construction, the proposed combination satisfies both.
`JUDGE SCANLON: Great. Thank you.
`MR. HART: Thank you, Your Honor. On DX-12, we see that
`Patent Owner's expert confirmed on cross-examination that the Patent
`Owner Response theory was in fact based on this theory that at the
`conclusion of a transaction, Patent Owner interpreted Laracey's mobile
`device to delete account information or financial information. And the
`reason is, Patent Owner's expert explained that he viewed that as stale, no
`longer useful information. To reiterate, the POR, Patent Owner Response,
`says that maintaining an e-purse does not require storing value, simply
`requires storing financial information, but Patent Owner's theory is that that
`information is deleted at the conclusion of a transaction. In our reply, we
`demonstrated that Laracey says nothing about deleting information from the
`mobile device at any point, certainly not at the conclusion of a transaction.
`We established that Patent Owner's stale data theory is based on its
`interpretation of Laracey as a system that is fundamentally focused on
`allowing multiple devices to access a single account. And we also
`established in our reply that Laracey says absolutely nothing about allowing
`multiple devices to access the same account.
`Now in its sur-reply, as I've forecasted, Patent Owner appears to
`have abandoned this theory. Patent Owner's sur-reply completely changes
`14
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`course and no longer argues that Laracey deletes information after a
`transaction. That argument does not appear in the sur-reply.
`Turning to DX-13, the sur-reply advances a completely new
`theory. It says that even if Laracey's mobile device does store an account
`balance between transactions, the locally stored balance will be stale or
`outdated and is thus not maintained on the mobile device. So after arguing
`in the Patent Owner Response that maintaining an e-purse need not store
`balance at all, the sur-reply now insists that the mobile device not only --
`must not only store a balance, but it must be an accurate non store non stale
`balance. As we see on DX-13, the sur-reply cites the POR and Patent
`Owner's expert's declaration suggesting that such a theory was presented
`earlier. It was not. I have those pages from the POR in a quote from Patent
`Owner's expert at paragraph 71, the cited paragraph, on DX-13. And both,
`POR and the expert declaration are consistent. They both proffer a theory
`that financial information is deleted at the conclusion of a transaction.
`Neither one advances the theory that maintaining an e-purse is satisfied by
`storing an accurate, non-stale account balance.
`
`Turning to DX-14, this really summarizes the sur-reply at page 4,
`summarizes the new theory Patent Owner advances and its sur-reply,
`"maintaining financial information entails having the correct non-stale value
`of the information." So the mobile device under Patent Owner's new theory
`that the mobile device must always retain and maintain, store, an accurate
`non-stale version of the account balance. Because Patent Owner introduces
`an entirely new theory in its sur-reply, the Board should reject it as waived.
`But even if the Board were to credit this new theory, as I'll explain in the
`15
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`subsequent slides, the proposed grounds from Petitioner do satisfy even this
`new concept of maintaining, storing a non-stale account balance on the
`mobile device.
`Turning to DX-15, as an initial important point, Patent Owner's
`stale data theory is inextricably tied to its theory that a fundamental goal of
`Laracey is to allow multiple devices to access a single account. As we see in
`DX-15, Patent Owner, and its expert's theory for why Laracey's mobile
`device might not store accurate account balance is based entirely on this
`scenario in which multiple devices access the same account. For example, if
`two devices maintain the same account balance locally when one device uses
`that account by making a transaction, the other devices locally stored
`account will be out of date or stale. That is Patent Owner's theory of
`Laracey.
`
`Importantly, turning to DX-16, Patent Owner has admitted that the
`stale data issue does not apply to a scenario in which only one device uses an
`account. In describing Jogu, Patent Owner makes clear that the account
`balance maintained in a single mobile device, if that is the only device that
`accesses an account, will always be accurate and non-stale. It states, "Jogu
`is designed such that the payment account maintained at the phone company
`is associated with only one phone number, i.e., one device. Since there is
`only one device using the payment account, the data cannot be stale. All
`purchases are made through the device itself, and thus the balance in the
`device is always correct." In other words, if there's only one device
`accessing the account, the account balance maintained at the phone company
`on the server side will always match the account balance maintained in that
`device, the locally stored account balance.
`16
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`
`Turning to DX-17, the proposed combination assumes exactly this
`scenario. It assumes that only a single device has access to the e-purse
`account. Accordingly, under Patent Owner's own admission, the proposed
`combination would not experience the stale data issue that underlies its new
`sur-reply theory. In DX-7, Petitioner's expert in his supplemental
`declaration explained that the combination presented in the Petition assumes
`only a single device has access to the e-purse account. It relies on Jogu's
`teaching that the locally stored balance should be updated at the conclusion
`of a transaction to ensure that the mobile device and the server both have
`accurate matching account balances. Petitioner's expert also explained that a
`correct read of Laracey is not that Laracey allows multiple devices to access
`the same account, but is instead Laracey's native system gives only one
`device access to a given account. It's not critical for the Board to resolve
`whether Laracey does or does not conceive of a scenario in which multiple
`devices access one account. Even if the Board were to accept Patent
`Owner's interpretation that a Patent Owner might read Laracey to suggest
`the possibility of multiple devices accessing one account in some scenarios,
`Laracey unquestionably supports the scenario relied upon by Petitioner in
`which an account is accessed by one and only one device, avoiding that stale
`data theory.
`Turning to DX-18, we know Laracey supports the scenario relied
`upon by Petitioner because when it describes account balances, I'm sorry,
`accounts assigned to users, it does that only with respect to Figure 9. Figure
`9 represents the only specific example in Laracey of devices assigned to
`accounts. Figure 9 depicts two separate users. Each user has registered one
`device, and each device has access to multiple accounts. There is no
`17
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`suggestion in Figure 9 or in the corresponding description in Laracey that
`any other device has access to any of these accounts. Accordingly, Laracey
`expressly contemplates and teaches the precise arrangement that the
`proposed combination assumes, an e-purse account that is used by one and
`only one device. Per Patent Owner's own admission, the stale data theory
`that underlies its new arguments in the Patent Owner's sur-reply does not
`apply in this scenario. Accordingly, the Board should reject Patent Owner's
`arguments and find the proposed combination satisfies maintaining an e-
`purse on the mobile device under any of the proffered interpretations in this
`proceeding.
`DX-19 and DX-20 address the final criticisms advanced by Patent
`Owner in this proceeding, namely criticisms of the motivations to combine
`Laracey and Jogu. Now DX-19, I provide an excerpt from the Petition that
`summarizes some of those motivations to combine. As illustrated in this
`excerpt, the motivations to combine Laracey and Jogu are based on practical
`improvements to the user experience and to technically ensuring the system
`works as intended. On the user experience points, Jogu's teachings ensure
`that a user is informed when a selected account is insufficient for a
`transaction. It avoids the complications of payment being rejected, or of the
`user being forced to redo the transaction by selecting a different account, or
`canceling the transaction altogether. On the technical improvement side,
`Jogu's balance update process ensures that Laracey's mobile device always
`has a local balance at the conclusion of the transaction that matches the
`server balance, so that the next transaction, when the user interacts with a
`merchant and receives a dynamic checkout token that includes the
`transaction details, can proceed with an accurate locally stored balance.
`18
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`
`Turning to DX-20, each of Patent Owner's criticisms of these
`straightforward motivations to combine turn on Patent Owner's improperly
`narrow view of Laracey. Namely, it assumes that Laracey's system would
`always involve multiple devices accessing a single account. Based on that
`narrow interpretation of Laracey, Patent Owner insists that stale data issues
`would infect the combination and that Jo