Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper # 32
`Entered: May 31, 2023
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`Patent Owner.
`____________
`
`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`____________
`
`Record of Oral Hearing
`Held: April 21, 2023
`____________
`
`
`
`Before KEVIN F. TURNER, PATRICK R. SCANLON, and
`KEVIN W. CHERRY, Administrative Patent Judges.
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`PAUL R. HART
`Erise IP, P.A.
`5299 DTC Blvd., Suite 1340
`Greenwood Village, Colorado 80111
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`RICHARD COWELL
`Fabricant, LLP
`411 Theodore Fremd Avenue,
`Suite 206 South
`Rye, New York, 10580
`21212)5797 
`The above-entitled matter came on for hearing on Friday,
`April 21, 2023, commencing at 1:00 p.m., Eastern Time, via video
`conference.
`
`
`
`
`
`2
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`
`PROCEEDINGS
`JUDGE SCANLON: Good afternoon or, I guess, good morning
`depending on your location. Welcome to the Patent Trial and Appeal Board.
`We are here today for a consolidated hearing in IPR2022-00412 and -00413
`between Petitioner, Apple Inc. and Patent Owner, RFCyber Corp. The ’412
`case involves patent number 9,189,787 and the ’413 case involves patent
`number 9,240,009. I’m Judge Scanlon and joining me today are Judge
`Cherry and Judge Turner. Let’s start with appearances. Who’s here are for
`Petitioner, please?
`MR. HART: Thank you, your Honor. Paul Hart with Erise IP for
`Petitioner Apple.
`JUDGE SCANLON: Okay, thank you. And for Patent Owner?
`MR. COWELL: Good afternoon, your Honor. This is Richard Cowell
`of Fabricant LLP for Patent Owner RFCyber.
`JUDGE SCANLON: Okay. Very good, thank you. If at any time
`during this hearing 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 connection information. Please make every effort to avoid speaking
`over others. That will assist our court reporter in making a clear record.
`Also, please try to mute your line when you’re not speaking.
`We do have the entire record including the demonstratives before us.
`When referring to materials from your demonstratives, it’s helpful if you
`could provide us with a page number for the slide to improve the clarity of
`the record or if you’re citing to other exhibits or papers in the record, please
`provide page number and/or line number.
`
`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
`
`
`
`3
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`
`Please be aware that there is a public access line open for the hearing.
`I don’t think there’s any confidential information in the record, but if there is
`something that’s confidential you’d like 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 rebuttal. We will keep time to the best of our ability
`and I will try to provide updates about the remaining time as the hearing
`progresses. With that, we’ll start with Petitioner. And please let us know
`how much, if any, time you would like to reserve for rebuttal.
`MR. HART: Thank you, your Honor. I’m going to try very hard not
`to use the full 90 minutes, but let’s reserve 25 minutes of the 90 for rebuttal.
`JUDGE SCANLON: Okay, thank you. Proceed when you are ready.
`MR. HART: Thanks very much, your Honor. The ’787 and the ’009
`patent are both directed to implementing smart cards on mobile devices.
`The detailed disclosures in both patents rely heavily on well-established
`smart card functionalities, such as those in the GlobalPlatform standard,
`including its card management and its security functionality. Indeed, both
`patents, the ’787 and the ’009, repeatedly reference the GlobalPlatform
`standard and many of its standardized features are respected in the challenge
`claims themselves. For the ’787 patent specifically, the Philips SmartMX
`controller also plays a prominent role in both the specification and the
`claims. Despite these patents’ heavy reliance on existing standards and
`
`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
`
`
`
`4
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`commercial products, neither GlobalPlatform nor any document discussing
`Philips SmartMX was provided to the office during prosecution.
`The proposed grounds in both proceedings seek to remedy Patent
`Owner’s failure to submit the standards and commercial products on which
`its alleged inventions are based. Those IPRs rely on base reference Dua.
`Dua describes a cell phone equipped with smart card functionalities and
`describes a network topology that supports mobile financial transactions.
`However, Dua’s device relies on smart card agnostic communication
`protocols, the dominant communication protocol relied on by Dua is SIP.
`SIP is most widely recognized as internet telephony, voice over IP based
`communication protocol. Dua also discloses security mechanisms such as
`TLS and S/MIME. Those are both more widely recognized as email security
`communication protocols. None of those protocols, SIP, TLS, or S/MIME,
`are specific to smart cards. None of them are associated with the smart card
`industry or smart card transaction. Both petitions establish that POSITA
`would have been motivated to implement Dua’s smart card functionalities
`pursuant to GlobalPlatform, the dominant smart card standard at the time.
`Four times now, twice when instituting Samsung’s petitions and twice
`when instituting Apple’s petitions, this Board has concluded that the
`proposed combination is supported by concrete motivation to combine.
`Namely, the improved interoperability realized by implementing Dua
`pursuant to GlobalPlatform provides that motivation. This is still the
`primary dispute between the parties. As the record has developed, Apple
`has supplemented its record, clarified the issues with the testimony of Gerry
`Smith, a true expert in the field, who actually served on the GlobalPlatform
`board on behalf of American Express. Patent Owner took a different tack.
`
`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
`
`
`
`5
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`It relies on the testimony of a Mr. Miguel Gomez, an engineer whose career
`has focused on general computer networking and who has no experience
`whatsoever with smart cards or with financial transactions of any sort.
`Turning to the slides, Petitioner’s DX-2 summarizes the sole proposed
`ground in the ’787 patent proceeding, the ’412 proceeding. There is a single
`ground here. It proposes that Claims 1 through 19 are rendered obvious over
`Dua in view of GlobalPlatform, the standard that I talked about, in a data
`sheet describing a Philips SmartMX controller.
`DX-3, Petitioner’s next slide, summarizes the remaining disputes
`between the parties in the ’787 patent proceeding. Those include proper
`definition of a person having ordinary skill in the art, whether Philips is prior
`art, motivation to combine, and then four substantive limitation specific
`disputes, three addressing the independent claims and one addressing Claims
`6 and 16.
`Turning to DX-4, this picks up the first substantive dispute between
`the parties, which is the proper definition of a person having ordinary skill.
`As I mentioned, these patents are directed to conducting mobile financial
`transactions with smart cards. The claims are built on standards like
`GlobalPlatform and commercial products like Philips SmartMX.
`Accordingly, a person of ordinary skill in the art needs experience with
`mobile payment technology to form an adequate foundation on which to
`opine on these issues. At institution, this Board correctly held the
`Petitioner’s proposed definition is, quote, “consistent with the ’787 patent
`and the asserted prior art.” It made the same finding preliminarily with
`respect to the ’009 proceeding.
`
`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
`
`
`
`6
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`
`Now, key with respect to the parties’ dispute about the definition of a
`POSITA is that Petitioner’s proposed definition requires professional
`experience relating to mobile payment technology. This makes sense.
`These patents are smart card patents. The entire purpose of these patents
`and focus of these patents is mobile payment technology. Although Patent
`Owner did not dispute this definition in its POPR, it now seeks to redefine a
`POSITA, removing any requirement for mobile payment experience
`whatsoever.
`In DX-5, I want to emphasize that the parties do not dispute the focus
`of these patents. As we see in DX-5, Patent Owner in its Patent Owner
`Response at page 1 characterizes the ’787 patent as a patent that claims
`methods and systems for providing e-purses for use in electronic and mobile
`commerce. Its expert characterizes the patent in the same way. It has
`similar characterizations of the ’009 patent. Again, the parties are in
`agreement that these are mobile commerce patents. That is the focus of both
`the ’787 and the ’009.
`If we turn to DX-6, Patent Owner without explanation, no rationale
`provided, introduced a new definition of a POSITA. As highlighted on
`DX-6, the Patent Owner inserted the word “or” to remove a requirement for
`mobile payment technology experience. The reason for the shift is
`transparent. Patent Owner’s expert, Mr. Gomez, has no relevant experience
`in the space. He has no experience with mobile payments, no experience
`with e-purses, no experience with smart card standards, and no educational
`experience to remedy his lack of professional experience.
`Now, turning to DX-7, in its sur-reply, after we pointed out in our
`reply that Mr. Gomez does not satisfy the correct standard and the Patent
`
`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
`
`
`
`7
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`Owner failed substantiate its new definition, Patent Owner takes the position
`that Mr. Gomez satisfies even Petitioner’s definition of a POSITA. It points
`to two specific bits of testimony under cross examination from Mr. Gomez’s
`deposition transcript. In the first, he merely testified that he had general
`networking experience. Quote, “I’ve worked on all the systems that the
`mobile commerce leans on in order to be able to communicate secure data
`across a network.” I followed up on this a number of times. He was simply
`saying that he worked on networks and that mobile commerce is connected
`over networks. Mr. Gomez never identified any specific financial
`transaction systems that he ever worked on as a professional engineer.
`The second bit of testimony that Patent Owner has pointed to is
`simply Mr. Gomez testifying that he has worked on secure memory. He
`never worked on smart cards. He never worked on any financial
`transactions of any sort. Again, Mr. Gomez’s background has no relevant
`experience, no mobile financial technology experience. Accordingly, his
`testimony should be accorded little to no weight, particularly where he
`weighs in on issues specific to financial transactions and smart cards as
`much as his testimony in these proceedings does.
`Turning to DX-8, the next dispute whether Philips is eligible as prior
`art. The petition advanced a long list of evidence demonstrating that Philips,
`a data sheet, was publicly available prior to September 24, 2006, the
`presumed priority date for the ’787 patent in this proceeding. In response,
`Patent Owner’s sole affirmative evidence is unsupported speculation that
`based on the type of document Philips is, it may have been subject to an
`NDA and may not have been public. Now, Mr. Gomez relies heavily on the
`fact he worked at Philips in the past and the fact that this data sheet is a
`
`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
`
`
`
`8
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`Philips data sheet, to speculate that this data sheet might not have been
`public.
`Turning to DX-9, when I cross examined Mr. Gomez on his opinion,
`he confirmed he was not at Philips in October 2004 when this data sheet was
`published. He also failed to identify any specific knowledge he possessed
`about this data sheet itself. Again, this is just general speculation based on
`the data type. Neither Patent Owner nor Mr. Gomez has presented any
`specific evidence that this data sheet was protected in any way or subject to
`an NDA.
`Turning to DX-10, I’ve summarized the categories of evidence that
`Petitioner has presented in this proceeding establishing that that Philips was,
`in fact, publicly available prior to the priority date here. The first set of
`bullet points are all the evidence presented in the petition. The second set of
`evidence, these are new bits of evidence that were presented in response to
`rebut Patent Owner’s allegation that Philips might have been subject to an
`NDA and not publicly available. Perhaps most compelling among this
`second set of bullet points is that Philips was listed in an IDS and submitted
`to the Patent Office on September 12, 2005. This is Exhibit 1053. That is
`more than one year prior to the priority date for the ’787 patent that we
`presume for purposes of this proceeding. Patent Owner has no substantive
`response to this evidence. Accordingly, the Board should conclude that
`Philips is prior art to the ’787 patent.
`Turning to DX-12, this picks up on the next substantive dispute. As I
`mentioned, possibly the largest dispute between the parties in this
`proceeding and that is motivation to combine. The overriding theme of
`Petitioner’s motivation to combine case here is that Dua describes smart
`
`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
`
`
`
`9
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`cards, but it fails to describe any of the conventional smart card
`implementation details. Instead, as I mentioned earlier, Dua relies on
`generic communication protocols and security protocols that were not used
`by others in the smart card industry. As this Board has now found four
`times at institution, there is a concrete interoperability benefit implementing
`Dua pursuant to GlobalPlatform. GlobalPlatform, again, was the dominant
`international standard that governed smart cards at the time.
`Turning to DX-13, I’ve summarized the primary arguments Patent
`Owner has advanced challenging the motivation to combine in this
`proceeding. First, Patent Owner argues that there is no benefit from
`GlobalPlatform and that it is redundant of Dua’s native security
`mechanisms, TLS and S/MIME. Second, Patent Owner has argued that the
`combination would destroy an allegedly important SIP based wireless device
`targeting feature that is described by Dua. And third, Patent Owner disputes
`that Dua expressly motivates the combination. I address each one of these
`three points in the next few slides. So turning to DX-14, the redundancy
`argument. GlobalPlatform is not redundant. It adds interoperability benefits
`that do not exist with Dua’s native security elements, TLS and S/MIME. In
`fact, on cross examination, Patent Owner’s expert agreed that neither TLS
`nor S/MIME were known in the smart card industry. I asked him, “Are you
`aware of any examples in the prior art of systems using TLS or S/MIME to
`secure smart card transaction?” In both cases, he said it was possible, but he
`was not aware of any such examples. Accordingly, GlobalPlatform’s
`international standardized security mechanisms do, in fact, add an
`interoperability benefit above and beyond the native security of Dua, which
`is not smart card specific.
`
`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
`
`
`
`10
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`
`Turning to DX-15, this picks up on the argument that the combination
`would destroy a SIP based wireless device targeting feature in Dua. Now,
`Patent Owner is just wrong that the proposed combination destroys Dua’s
`SIP-based device targeting. Patent Owner created from whole cloth an
`argument that the proposed combination discards SIP entirely.
`From that manufactured narrative, it argued that SIP is too important
`to be discarded from Dua, which it contends weighs against the combination.
`But Petitioner never argued that SIP would have to be discarded in the
`combination. In its reply in an expert supplemental declaration, Petitioner
`established that a POSITA would indeed have been motivated to use SIP to
`establish that initial channel to target end devices to set up what its expert
`refers to as a “pipe” between the mobile devices and the servers, and then on
`top of that channel or pipe, GlobalPlatform’s security mechanisms would be
`deployed. Accordingly, Patent Owner’s second argument that the
`combination destroys SIP should be rejected because it’s simply not relevant
`to the actual proposed combination in this proceeding.
`Finally, although the law does not demand express motivation from
`the references themselves, Dua does indeed expressly motivate complying
`with government standards including GlobalPlatform, which was the
`dominant smart card standard at the time.
`Turning to DX-16, I’ll highlight just two teachings from Dua that
`would expressly motivate complying with standards like GlobalPlatform.
`The first we see is in Dua paragraph 525. It states, the wallet application
`should meet standards defined by card organizations. Second, Dua
`paragraph 13, it notes that credit card organizations were working jointly to
`develop specifications that define requirements for security and
`
`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
`
`
`
`11
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`interoperability between cards and terminals. I’m going to take both of these
`separately in the subsequent slides.
`So turning to DX-17, this picks up on Dua’s paragraph 525 teaching
`that the wallet application should meet standards defined by card
`organizations. Patent Owner disputes that this would have motivated a
`POSITA to comply with a standard like GlobalPlatform. Instead, it argues
`that this statement, this teaching in Dua, should be read and limited to the
`EMV standard and only the EMV standard. At the outset, Patent Owner is
`just wrong about its interpretation.
`Petitioner’s expert, the only expert in this case with actual smart card
`standard experience and who served on the GlobalPlatform board, testified
`that this language would have been interpreted by a POSITA more broadly
`to encourage compliance with standards like GlobalPlatform, not just EMV.
`But even if we accept Patent Owner’s argument for argument’s sake that this
`is only talking about EMV, Patent Owner submitted an EMV document in
`this case, Exhibit 2003. And if we look at that EMV document, it is clear
`that EMV cannot be considered in isolation. In fact, that EMV document,
`Exhibit 2003, expressly recommends that any system complying with EMV
`also comply with the GlobalPlatform standard. Again, this is not surprising.
`GlobalPlatform was the dominant international smart card standard. All
`smart card systems were encouraged to comply with it.
`Turning to DX-18, the Dua teaching, paragraph 13 regarding created
`card organizations working on interoperability. Patent Owner’s critique of
`this statement is that it contends GlobalPlatform does not address the card-
`terminal relationship and it contends this statement in paragraph 13 should
`be limited to the card-terminal relationship. As Petitioner’s expert, Mr.
`
`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
`
`
`
`12
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`Smith, explained in a supplemental declaration, Exhibit 1042, and as we see
`on DX-18 in Figure 2-1 from the GlobalPlatform architecture,
`GlobalPlatform does indeed define the relationship between cards and card
`terminals, card readers. Again, in sum, although not required to establish
`obviousness, Dua does indeed expressly motivate implementing Dua
`pursuant to then governing standards like GlobalPlatform, the standard at
`issue in the proposed combination.
`DX-19 picks up on the next dispute between parties, which turns on
`the claim language that requires an emulator for storing updated transaction
`logs. As we see here in DX-19, I have an excerpt from pages 20 and 21
`from the petition. The petition pointed to functionality in the MIFARE
`emulator that is described in the Philips reference that forms part of the
`proposed combination. The line on Mr. Smith, the petition establishes that
`MIFARE transactions involve storing transaction logs. He cited numerous
`background documents in support in his opening declaration, Exhibit 1003.
`He testified with corroborating evidence from those background documents
`that transaction logs are not only required for MIFARE, but are also
`mandatory for e-purses in general. Indeed, I highlighted that language at the
`bottom of DX-19. Such basic functionality is mandatory of e-purses in
`general, not just MIFARE.
`In DX-20, I’ve summarized main arguments that Patent Owner raises
`directed to the transaction log mapping here. First, in its sur-reply, Patent
`Owner argues that Apple in its reply raises a new argument that the
`functionality is somehow mandatory of e-purses in general. As we just saw
`in DX-19, that argument in theory and supporting has been in the case since
`its petition. I just showed the Board an express statement with supporting
`
`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
`
`
`
`13
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`evidence that advanced the mandatory e-purses in general theory in the
`petition. Second, Patent Owner argues that the Smart Card Handbook, one
`of many background documents discussed and relied upon by Mr. Smith,
`should have been a component of our combination and Patent Owner
`suggests that we failed to demonstrate the Smart Card Handbook is actually
`prior art to the ’787 patent.
`I’ll get to the propriety of relying on corroborating evidence in an
`expert declaration separately, but on the evidentiary question, there is no
`question that the Smart Card Handbook is prior art to the challenged patents
`here. In fact, Smart Card Handbook is relied upon as a formal component in
`the proposed ground in the ’009 patent proceeding, which we are also
`talking about today. In that proceeding, Patent Owner has not challenged
`the prior art status or the authenticity of this Smart Card Handbook. Though
`again, this suggestion of evidentiary impropriety is simply a red herring.
`There is no question that the Smart Card Handbook is prior art.
`The last point the Patent Owner raises, it argues that an obviousness
`combination cannot rely on the background knowledge of a POSITA. That
`argument is contrary to well established precedent, which I will address in
`the next slide, DX-21. In DX-21, I have an excerpt from the reply on pages
`16 and 17 where we quote from a recent Federal Circuit case, Philips v.
`Google, 947 F.3d 1330, where the Federal Circuit held in the context of an
`IPR proceeding that it is not improper to rely in an expert’s background
`knowledge or an expert’s testimony as to what a person of ordinary skill
`would have known, so long as that testimony is corroborated by background
`evidence. That’s exactly what Petitioner has done here. Mr. Smith
`discussed numerous background documents to establish not only that
`
`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
`
`
`
`14
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`transaction logs are a necessary part of implementing an e-purse, but he also
`explained how those transaction logs are maintained and even where they
`are stored in the MIFARE emulator that forms a part of our proposed
`combination here. Again, this is entirely proper testimony from an expert
`establishing the background knowledge of a POSITA that is extensively
`corroborated by background evidence.
`Turning to DX-22, this is a one-sided record. Tellingly, Patent Owner
`does not dispute that transaction logs are mandatory in e-purses and
`MIFARE specifically. It has not introduced any evidence disputing that
`point. It has not introduced any exemplary e-purses that do not rely on
`transaction logs. I’ve summarized here on these lower bullet points on DX-
`22 the extensive evidence from Mr. Smith across two separate declarations
`citing a long list of background documents that corroborate his opinion that
`one of skill in the art would have understood transaction logs were
`mandatory and routine with e-purses and MIFARE emulator specifically.
`Accordingly, the Board should reject Patent Owner’s critiques of
`Petitioner’s evidence on this patent log issue.
`JUDGE SCANLON: Excuse me, Mr. Hart. Quick question. Does
`Mr. Smith in his testimony refer to the Handbook as background
`information?
`MR. HART: He does indeed, your Honor, and that is initially in his
`open declaration, which is Exhibit 1003. He walks through a number of
`background documents, including the Smart Card Handbook, which is
`Exhibit 1008, a textbook called RFID Handbook, which is Exhibit 1019, a
`patent, Exhibit 1038, and other documents, all of which he discusses
`extensively to establish that transaction logs are routine, how transaction
`
`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
`
`
`
`15
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`logs are maintained, and the important point here, that transaction logs are
`mandatory with e-purses including with MIFARE emulator e-purses.
`JUDGE SCANLON: Thank you.
`MR. HART: Thank you, your Honor. DX-23 picks up on the next
`dispute between the parties, which turns on personalizing the emulator. As I
`mentioned, these claims have concepts that are pulled directly from smart
`card industry including smart card standards like GlobalPlatform.
`Personalization is on its face a somewhat confusing and dense concept, so I
`think it’s helpful to briefly touch on what personalization is in this context
`and what the parties are actually disputing.
`So the personalization process at issue here involves receiving
`encryption keys that can be used to conduct secure financial transactions and
`communication. The parties are not disputing that personalization in these
`claims involves provisioning fees and they are not disputing the fact that
`personalization does, in fact, occur in the proposed combination. What the
`parties are disputing is whether Petitioner has adequately shown that keys
`are stored in the MIFARE emulator in the proposed combination rather than
`somewhere else. And as I’ll walk through in subsequent slides, we have, in
`fact, established that there are keys stored in the MIFARE emulator in the
`proposed combination.
`DX-24 provides an overview of the combination. It walks through
`three key points. First, the record establishes that GlobalPlatform uses triple
`DES keys for secure cryptographic communications. Second point, Philips’
`MIFARE emulator also uses triple DES keys for its cryptographic
`communications. And third, those keys are personalized into the MIFARE
`emulator to allow the emulator to operate. That’s the key point. And that’s
`
`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
`
`
`
`16
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`really that third point is where Patent Owner has taken issue with our
`proposed combination and the evidentiary record.
`Turning to DX-25 --
`JUDGE CHERRY: Sorry. I think one other place where we’re kind
`of held up is maybe a point too and maybe you could go over that a little bit
`about the DES co-processor, because it doesn’t seem, at least in the portion
`cited, at least the Philips reference doesn’t seem to expressly tie the triple
`key to the DES-3 co-processor. And maybe you could explain why point
`two is correct as well as what you’re going to address with point three.
`MR. HART: Sure. I do think the co-processor is somewhat of a side
`issue here. We’ve established in the reply that the DES co-processor does in
`fact have access to that MIFARE memory, but the really important piece
`here is the point that the MIFARE emulator has this key based secure
`memory that is inaccessible without these keys, and so the important point
`that we have tried to stress in our papers in response to Patent Owner’s
`criticisms is that our expert has laid out both in his original declaration,
`Exhibit 1003, and in his supplemental declaration that in order for the
`MIFARE emulator to operate, it must be able to access that 4 kilobytes of
`EEPROM. And that is key-based. That’s key secured. So without those
`keys, it can’t access that, and without accessing that, it cannot operate as a
`MIFARE emulator. And that’s where transaction log is stored, that’s where
`the commands are accessed.
`So it has to have these keys in order to access that memory. And now,
`the cryptographic processor is what actually performs encrypting and
`decrypting. And so the point there is just that it needs to rely on a
`cryptographic processor in order to implement encrypted and decrypted
`
`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
`
`
`
`17
`
`

`

`IPR2022-00412 (Patent 9,189,787 B1)
`IPR2022-00413 (Patent 9,240,009 B2)
`
`communications, but the real keys at focus of the parties’ dispute here is
`whether those keys are in fact stored in the emulator, and as I established in
`the subsequent slides pointing to both the original declaration and the
`supplemental declaration, we have established conclusively that those keys
`are in fact stored in the emulator.
`So if I scroll down to --
`JUDGE SCANLON: If I could just follow up on that, so I think as far
`as the petition -- and correct me if I’m wrong -- I think the petition really
`just pointed to page 1 of the Philips reference, which mentions a triple key
`DES co-processor. So I’m not sure how that co-processor is connected to
`the emulator. Maybe what you were just discussing somehow makes that
`connection, but --
`MR. HART: I think -- I’m sorry. I didn’t mean to cut you off.
`JUDGE SCANLON: Yeah, if you could elaborate on that, I would
`appreciate it.
`MR. HART: Absolutely. I think DX-25 is a good place to point the
`Board to on this point. So DX-25 is an excerpt from the petition on page 26
`and this is where the petition establishes that those keys need to be
`provisioned in the emulator in order for the emulator to operate. Quote,
`“These keys must be personalized for the emulator to operate over a
`GlobalPlatform secure channel as it was well known to a POSITA that
`MIFARE memory structures are protected against unauthorized access by
`different keys.” And this is where we point to the fact that the SmartMX
`utilizes triple key DES co-processor with two or three keys loadable.
`So this ties together the concept of the co-processor with the keys,
`citing Exhibit 112, which is the Philips reference. It kind of brings those
`
`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