`
`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-00412
`U.S. Patent No. 9,189,787
`
`_________________
`
`
`SUPPLEMENTAL DECLARATION OF GERALD W. SMITH
`
`
`
`
`
`
`
`IPR2022-00412
`Apple EX1042 Page 1
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`
`TABLE OF CONTENTS
`
`INTRODUCTION ............................................................................................. 3
`I.
`II. OPINIONS REGARDING RFCYBER’S PATENT OWNER RESPONSE .... 4
`A. Person of Ordinary Skill in the Art ................................................................. 4
`B. Patent Owner and its Expert Identify No New Criticisms of Petitioner’s
`Motivation to Combine That Would Compel a Different Result From Institution9
`1. The Combination Does Not “Discard” SIP ................................................. 9
`2. A POSITA Would Have Been Expressly Motivated to Combine Dua and
`GlobalPlatform ................................................................................................. 16
`C. The Combination Discloses an Emulator that Stores Updated Transaction
`Logs ..................................................................................................................... 22
`D. The Combination Discloses Personalizing the Emulator ............................. 27
`E. The Combination Discloses Two-Channel Personalization ......................... 32
`III. CONCLUSION ............................................................................................ 36
`
`
`
`
`
`
`
`
`IPR2022-00412
`Apple EX1042 Page 2
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`
`I, Gerald Smith, hereby declare the following:
`
`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. 9,189,787 (the “’787 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 November 18, 2022 and the accompanying expert
`
`declaration of Mr. Miguel Gomez (Ex. 2007). 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;
`• Patent Owner’s Response (“POR”) (Paper 15)
`• Declaration of Miguel Gomez (Ex. 2007)
`• Transcript of Deposition of Miguel Gomez (Ex. 1041)
`• U.S. Patent No. 7,694,128 to Judge et. al (“Judge”) (Ex. 1046)
`• U.S. Patent No. 7,003,480 to Fox et al. (“Fox”) (Ex. 1047)
`
`
`
`IPR2022-00412
`Apple EX1042 Page 3
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`• EMV Card Personalization Specification, Version 1.0, June 2003 (Ex.
`1048)
`• GlobalPlatform CPSdemonstrator Specification, Version 2.0 May 2006
`(Ex. 1049)
`• Zhiqun Chen. Java Card™ Technology for Smart Cards. Sun
`Microsystems. 2000. (“Chen”) (Ex. 1051)
`• U.S. Patent App. Pub. No. 2006/0174352 to Thibadeau (“Thibadeau”)
`(Ex. 1052)
`
`II. OPINIONS REGARDING RFCYBER’S
`RESPONSE
`A.
`Person of Ordinary Skill in the Art
`4.
`I understand that the Board adopted at institution, the level of skill in
`
`PATENT OWNER
`
`the art outlined in my previous declaration. I note that Patent Owner and its expert,
`
`Mr. Gomez, now propose rewriting the required level of skill of a POSITA to not
`
`require experience with mobile payment technology. (Patent Owner Response) POR
`
`at 10 (“2 or more years of academic or industry experience in computer security,
`
`network security or mobile payment technology”) (emphasis added). As stated in
`
`my prior opinions, a POSITA at the time of the ’787 Patent would have “been
`
`knowledgeable regarding mobile payment methods and systems including smart
`
`cards, smart card applications, smart card operating systems, and standards
`
`concerning smart cards” and would have had at least “one year of professional
`
`experience relating to mobile payment technology” for numerous reasons. I discuss
`
`several reasons why mobile payment technology experience is required below.
`
`
`
`IPR2022-00412
`Apple EX1042 Page 4
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`I understand that the definition of a POSITA can be informed by the
`
`5.
`
`technology at issue (e.g., the teachings as a whole and the patent’s purpose), my
`
`general knowledge as a POSITA, all of my prior educational and industry
`
`experience, and several pertinent factors including, for example, the types of
`
`problems encountered in the art, the prior art solutions to those problems, and the
`
`sophistication of the technology.
`
`6.
`
`First, when considering the ’787 Patent’s teachings as a whole, the ’787
`
`Patent’s purpose is related to mobile payment technology. Indeed, the ’787 Patent
`
`itself describes its “Technical Field” as “[p]articularly, the present invention is
`
`related to electronic purses that can be advantageously used in portable devices
`
`configured for both electronic commerce (a.k.a., e-commerce) and mobile
`
`commerce (a.k.a., m-commerce).” ’787 Patent at 1:17-21. I note that Patent Owner,
`
`Patent Owner’s expert Mr. Gomez, and the Board have all agreed that the ’787 Patent
`
`relates to mobile payment technology, including systems and methods for
`
`performing e-commerce and m-commerce. POR (Paper 15) at 1-6 (“The ’787 Patent
`
`claims methods and systems for providing electronic purses (e-purses) for use in
`
`electronic and mobile commerce. ’787 Patent, 1:17-21. The inventors of the ’787
`
`Patent realized that existing contactless cards were not effective for use in electronic
`
`or mobile commerce[.]”), id. (“To solve these problems, the inventors of the ’787
`
`Patent developed a system for personalizing a card stored in a portable device.”), id.
`
`
`
`IPR2022-00412
`Apple EX1042 Page 5
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`(“A device that has been personalized using the three-tier security as above can then
`
`perform e-commerce and m-commerce using an emulator, and NFC interface for e-
`
`commerce, and a second interface for m-commerce.”); Ex. 2007 (Gomez
`
`Declaration) at ¶¶34-38; Institution Decision (Paper 11) at 4-7, 10-11.
`
`7.
`
`Second, considering the factors listed above, in my prior opinions I
`
`outlined the types of problems encountered in the art, prior art solutions to those
`
`problems, and the sophisticated aspects of mobile payment technology, including
`
`the technology at the heart of the ’787 Patent and the prior art. Ex. 1003 at ¶¶29-41
`
`(overviewing ’787 Patent and problems related to securely funding an e-purse along
`
`with known solutions for security, such as GlobalPlatform), 58-78 (overviewing
`
`GlobalPlatform and the relevant functionalities), 83-101 (overviewing other related
`
`mobile payment technology concepts in the art), 102-112 (overviewing Dua and
`
`Philips).
`
`8.
`
`For instance, the ’787 Patent itself describes problems, solutions, and
`
`articulates the sophisticated nature of mobile payment technology. In order to
`
`understand these problems, solutions, and sophisticated topics, a POSITA would
`
`have needed professional mobile payment technology experience. For example, the
`
`’787 Patent generally describes concepts related to mobile payment technology, such
`
`as e-purses, security including cryptographic keys, card manager security including
`
`“a Global Platform (GP),” emulators, and smart card communications involving
`
`
`
`IPR2022-00412
`Apple EX1042 Page 6
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`application protocol data units (APDUs). Some problems noted in the ’787 Patent
`
`include providing security for e-purse funding techniques. The ’787 Patent describes
`
`e-purse security involving a set of protocols enabling micro payment transactions
`
`and involving a set of cryptographic keys (“either symmetric or asymmetric”) stored
`
`on a smart card and wherein a set of keys is personalized into the purse. ’787 Patent
`
`at 4:4-10. The ’787 Patent provides known solutions to this “security problem”—
`
`such as “Card Manager Security 106” which is “a general security framework of a
`
`preload operating system in a smart card, provides a platform for PIN management
`
`and security channels (security domains) for card personalization. This platform via
`
`a card manager can be used to personalize a purse in one embodiment. One example
`
`of the card manager security 106 is what is referred to as a Global Platform (GP)
`
`that is a cross-industry membership organization created to advance standards for
`
`smart card growth.” ’787 Patent at 4:19-27.
`
`9.
`
`The ’787 Patent further describes other sophisticated mobile payment
`
`technology concepts. For example, the ’787 patent describes a “Smart MX (SMX)
`
`module. The SMX is pre-loaded with a Mifare emulator 208 (which is a single
`
`functional card) for storing values.” ’787 Patent at 5:1-8. Additionally, “the SMX is
`
`a JavaCard that can run Java applets. According to one embodiment, an e-purse is
`
`built on top of the global platform and implemented as an applet in SMX.” ’787
`
`Patent at 5:10-13. Further, the ’787 Patent describes APDU commands, which were
`
`
`
`IPR2022-00412
`Apple EX1042 Page 7
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`well known to be a standard messaging protocol for smart cards according to
`
`GlobalPlatform. ’787 Patent at 7:57-67 (“The midlet strips and extracts the APDU
`
`commands from the response and forwards the commands the e-purse at 418. The e-
`
`purse verifies the commands at 420 and, provided they are authorized, send the
`
`commands to the emulator at 420 and, meanwhile updating a transaction log.”),
`
`8:13-18 (“The e-purse verifies the authenticity (e.g., in APDU format) and sends
`
`commands to the emulator 438 and updates the transaction logs. By now, the e-purse
`
`finishes the necessary steps and returns a response to the midlet 434 that forwards
`
`an (APDU) response in a network request[.]”); GlobalPlatform at 18 (describing
`
`APDU as “Standard communication messaging protocol between a card accepting
`
`device and a smart card.”).
`
`10. Thus, for the reasons I discussed above and in my prior declaration (Ex.
`
`1003, ¶¶27-28) including the ’787 Patent’s Technical Field and purpose and factors
`
`such as the type of problems encountered in the art, the prior art solutions to those
`
`problems, and the sophistication of the technology, the level of skill of a POSITA
`
`would have required at least “one year of professional experience relating to mobile
`
`payment technology” (where “[l]ack of professional experience could be remedied
`
`by additional education, and vice versa”) to understand these unique mobile payment
`
`technology concepts. Further, because the Challenged Claims are not directed to
`
`merely generic communication protocols, the level of skill of a POSITA would have
`
`
`
`IPR2022-00412
`Apple EX1042 Page 8
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`required at least one year of experience with mobile payment technologies to
`
`understand the Challenged Claims and the prior art.
`
`B.
`Patent Owner and its Expert Identify No New Criticisms of
`Petitioner’s Motivation to Combine That Would Compel a Different
`Result From Institution
`11.
`In my original declaration, I discussed in detail the reasons a POSITA
`
`would be motivated to combine Dua, GlobalPlatform, and Philips. See, e.g., Ex.
`
`1003 at 114-128.1 Based on my review of the POR, Mr. Gomez’s declaration, and
`
`Mr. Gomez’s deposition testimony, I understand Patent Owner and Mr. Gomez raise
`
`certain issues related to these motivations.
`
`1.
`The Combination Does Not “Discard” SIP
`Initially, I note that Patent Owner and Mr. Gomez have interpreted the
`
`12.
`
`proposed combination of Dua, GlobalPlatform, and Philips as entirely replacing
`
`Dua’s use of the SIP protocol (such as the ability to construct an endpoint-to-
`
`endpoint connection) with GlobalPlatform’s personalization techniques. POR at 13-
`
`22. This position is inconsistent with Petitioner’s proposed combination and my
`
`opinions supporting this combination. Previously, in my opinions regarding
`
`combining Dua and GlobalPlatform, I did not address the specific mechanisms
`
`involved in connecting one endpoint to another (e.g., a smart card to a server or host)
`
`because details on such endpoint-to-endpoint connections are not required by the
`
`
`1 All citations to Ex. 1003 and Ex. 2007 are to paragraph numbers.
`
`
`
`IPR2022-00412
`Apple EX1042 Page 9
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`claims. See Ex. 1003. For instance, independent claims 1 and 11 focus on the specific
`
`smart card communications that occur over an already established network
`
`connection, but not the means by which that initial network connection is
`
`established. E.g., the claims do not recite any specific mechanism for establishing
`
`the initial network connection, such as SIP, TCP/IP, HTTP, etc.
`
`13. While my previous opinions did not address this (because the claims do
`
`not require it), I address this position now in response to Patent Owner’s critiques.
`
`Patent Owner is incorrect that the proposed combination “replaces” SIP’s endpoint
`
`connections with GlobalPlatform. In the combination, Dua’s SIP protocol constructs
`
`the connection between endpoints, and GlobalPlatform establishes the secure
`
`channels within that connection for smart card specific communications. In other
`
`words, the combination utilizes Dua’s SIP protocol to connect one endpoint to
`
`another and to utilize GlobalPlatform’s security on top of said SIP protocol to
`
`construct secure channels.
`
`14.
`
`In more detail, in the proposed combination, Dua teaches utilizing the
`
`SIP protocol to connect endpoints. Dua at [0093] (“SIP (Session Initiation Protocol,
`
`RFC 3261) is a text-based application protocol that allows two endpoints in the
`
`Internet to discover one another to exchange context information about a session
`
`they would like to share.”), [0095]-[0096] (“SIP supports five facets of establishing
`
`and terminating multimedia communications: 1. User Location: Determination of
`
`
`
`IPR2022-00412
`Apple EX1042 Page 10
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`the end system to be used for communication[.]”). In my opinion, Dua’s SIP
`
`networking protocol for connecting endpoints functions like a “pipe” to connect the
`
`two endpoints (e.g., smart card and server or host such as Dua’s WCM) together
`
`over a network.
`
`15. For the reasons I discuss below, it is my opinion that Dua and
`
`GlobalPlatform operate concomitantly to establish endpoint connections and secure
`
`communications within that SIP connection. As also outlined below, a POSITA
`
`would have understood that in the combination, GlobalPlatform’s processes relying
`
`on the exchange of APDU messages would be sent over Dua’s SIP endpoint-to-
`
`endpoint connection (“pipe”) because, (1) SIP is derived from HTTP, (2) APDUs
`
`are the standard messaging protocol for smart cards, and (3) it was known to transmit
`
`APDUs over HTTP.
`
`a)
`SIP is Derived from HTTP
`16. A POSITA would have understood from Dua that the SIP protocol is
`
`derived from HTTP. Dua teaches “SIP is based on an HTTP-like request/response
`
`transaction model.” Dua at [0102], id. (“SIP uses most of the header fields, encoding
`
`rules, and status codes of HTTP.”), [0132] (teaching the same), [201] (“The
`
`following discussion covers security mechanisms and procedures which may be used
`
`in a preferred embodiment of the system of the present invention. Since the SIP
`
`message structure is a straight derivation from the HTTP request/response model,
`
`
`
`IPR2022-00412
`Apple EX1042 Page 11
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`all security mechanisms available for HTTP (RFC 2617) can also be applied to SIP
`
`sessions.”), [0494] (“The connection between the wallet application and the storage
`
`service could utilize an application protocol such as HTTP, SIP, or others.”).
`
`b) APDU’s are the Standard Messaging Protocols for
`Smart Cards
`17. GlobalPlatform teaches transmitting APDUs as one of the common
`
`formats for smart-card-based messaging. For example, GlobalPlatform teaches
`
`APDUs are the “[s]tandard communication messaging protocol between a card
`
`accepting device and a smart card[.]” GlobalPlatform at 18. Namely, GlobalPlatform
`
`teaches transmitting APDUs over Secure Channels via Secure Channel Protocols.
`
`GlobalPlatform at 30 (teaching the Security Domain “has a well-defined external
`
`APDU interface to ensure that all Security Domain implementations behave
`
`consistently and can be managed identically by the same off-card management
`
`systems. As the majority of these services and APDU commands are related to Card
`
`Content management, the Security Domain is closely interacting with the OPEN.”),
`
`39 (“The state OP_READY indicates that the runtime environment shall be available
`
`and the Issuer Security Domain, acting as the selected Application, shall be ready to
`
`receive, execute and respond
`
`to APDU commands.”), 101-103 (teaching
`
`transmitting APDUs to initiate secure channels and perform secure messaging); see
`
`generally id., 213-234 (teaching Secure Channel Protocol functions including
`
`transmitting APDUs).
`
`
`
`IPR2022-00412
`Apple EX1042 Page 12
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`18. Other known works in the mobile payment technologies field support
`
`that APDUs are a standard messaging protocol for smart cards. For example, Java
`
`Card Technology for Smart Cards, Architecture and Programmer’s Guide, by
`
`Zhiqun Chen (“Chen”) teaches “smart cards speak to other computers by using their
`
`own data packets – called APDUs (application protocol data units). An APDU
`
`contains either a command or a response message.” Chen (Ex. 1051) at 26. Chen
`
`discloses a smart card communication model where APDUs are transmitted between
`
`a host (e.g., computer, server) and a smart card:
`
`
`
`Chen at 27.
`
`c)
`It was Known to Transmit APDUs Over HTTP
`19. At the outset, a POSITA would have understood that APDUs, which
`
`are the standard messaging protocol for smart card communications as explained
`
`above, would have been transmitted over a network for performing various smart
`
`card functions including security and transactions. See, e.g., GlobalPlatform at 101-
`
`
`
`IPR2022-00412
`Apple EX1042 Page 13
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`103, 213-234. For example, APDU commands are utilized for performing functions
`
`such as DELETE, INSTALL, and PUT KEY. GlobalPlatform at 105. Additionally,
`
`GlobalPlatform teaches APDUs are involved in setting up a Secure Channel, as
`
`depicted in Figure E-1 below:
`
`GlobalPlatform at 215 (“Figure E-1” annotated), 214-216 (teaching Secure Channel
`
`Protocol SCP02 utilizes APDUs for Secure Channel initiation and message
`
`
`
`integrity).
`
`20. One common type of network protocol over which APDU’s are
`
`transmitted for smart card communications was HTTP. One example is taught by
`
`Thibadeau (Ex. 1052). Thibadeau teaches an “Issuance Server 170, located in a
`
`computer server 172 provides APDUs over HTTP to a local computer 174. The local
`
`computer includes an Issuance Client 176 that transmits the APDUs over ATA to
`
`
`
`IPR2022-00412
`Apple EX1042 Page 14
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`the trusted drive 178.” Thibadeau at [0123], [0126] (“The APDU exchange between
`
`the Issuance server and the Issuance Client occurs over the hypertext transfer
`
`protocol (http), using a lightweight wrapper protocol.”). Below I have provided an
`
`annotated version of Fig. 10 of Thibadeau illustrating APDUs transmitted over
`
`HTTP:
`
`
`
`Thibadeau at Fig. 10 (annotated). A POSITA would have understood that HTTP is
`
`thus one network protocol for transmitting APDUs over a network between
`
`endpoints. As I opined above, Dua expressly teaches SIP is derived from HTTP and
`
`uses HTTP security. See ¶16 above. A POSITA would have understood that
`
`transmitting APDUs between endpoints using a network protocol such as SIP would
`
`have functioned the same way as transmitting APDUs between endpoints over a
`
`network protocol such as HTTP, as taught by Thibadeau. Thus, in the proposed
`
`combination, Dua’s SIP protocol would have been used
`
`to
`
`transport
`
`GlobalPlatform’s APDUs over a network between said endpoints.
`
`
`
`IPR2022-00412
`Apple EX1042 Page 15
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`A POSITA Would Have Been Expressly Motivated to
`Combine Dua and GlobalPlatform
`21. First, Patent Owner argues that Dua’s express interoperability goal that
`
`2.
`
`its “wallet application should meet standards defined by card organizations” does
`
`not motivate a POSITA to combine Dua and GlobalPlatform. POR at 20-21. In
`
`support of this position, Patent Owner suggests that a “POSITA would understand
`
`that GlobalPlatform is not related to interoperability between chip cards and
`
`terminals; it purports to provide a ‘card management architecture.’” POR at 19-20;
`
`Ex. 2007 at 61-64. In my opinion, Patent Owner is mistaken. A POSITA would have
`
`understood that GlobalPlatform is related to interoperability between chip cards and
`
`terminals as well as other components. Indeed, GlobalPlatform itself teaches its
`
`architecture includes numerous components such as cards, card acceptance devices,
`
`terminal management systems, card management systems, and other components, as
`
`illustrated in the figure below:
`
`
`
`IPR2022-00412
`Apple EX1042 Page 16
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`
`
`
`Ex. 1006 at 27, 16; Ex. 1003 at 61, 148. Specifically, GlobalPlatform teaches that
`
`“GlobalPlatform cards are intended to be functional in the widest range of
`
`environments (i.e., Card Acceptance Devices).” GlobalPlatform at 161. A POSITA
`
`would therefore have understood that GlobalPlatform is related to interoperability
`
`between chip cards and terminals. Further on the issue of interoperability,
`
`GlobalPlatform also teaches that Application Protocol Data Units (APDUs) are
`
`“[s]tandard communication messaging protocol between a card accepting device and
`
`
`
`IPR2022-00412
`Apple EX1042 Page 17
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`a smart card[,]” further supporting interoperability with payment terminals (e.g.,
`
`card acceptance devices). Ex. 1006 at 18; Ex. 1003 at 64, 72, 76.
`
`22. Second, Patent Owner argues that “unlike EMV, GlobalPlatform is not
`
`a card organization” and is “not payment-related[.]” POR at 20-21; Ex. 2007 at 65.
`
`In my opinion, Patent Owner is mistaken. Initially, Patent Owner appears to
`
`narrowly interpret Dua’s disclosures at [0525], limiting Dua’s compatibility to
`
`“payment-related” standards while ignoring all other card organization standards.
`
`But nothing in Dua requires a “payment-related” standard. However, even if Dua
`
`only suggested compatibility with payment-related standards, a POSITA would have
`
`understood that GlobalPlatform is “payment-related.” GlobalPlatform, which “has
`
`been established by leading companies from the payments and communications
`
`industries” is a standard defined by a card organization (GlobalPlatform Inc.) and
`
`is related to the use of smart cards for performing transactions. “[T]he cards can be
`
`used with mobile phones to make purchases over the Internet as well as to securely
`
`access a PC.” Ex. 1006 at 16. Additionally, GlobalPlatform teaches card acceptance
`
`devices and servers as part of its architecture. Ex. 1006 at 27; Ex. 1003 at 39, 148.
`
`As I opined above, GlobalPlatform is related to security for performing transactions
`
`and interoperability between smart cards and off-card entities including card
`
`terminal devices and remote servers. Thus, a POSITA would have understood that
`
`
`
`IPR2022-00412
`Apple EX1042 Page 18
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`GlobalPlatform is “payment-related” and is thus a standard defined by a card
`
`organization even under Patent Owner’s overly narrow interpretation of Dua.
`
`23. Third, Patent Owner also interprets Dua’s disclosures at [0014] and
`
`[0525] narrowly to suggest only that its “wallet application should meet the EMV
`
`standard,” not other known standards. POR at 18-21. In support, Patent Owner relies
`
`on Ex. 2003, which is an EMVCo Guide to EMV chip technology. However, Patent
`
`Owner’s Exhibit 2003 teaches that EMVCo collaborates with other standards
`
`organizations and industry bodies, including GlobalPlatform. Specifically, I note
`
`that Patent Owner’s Exhibit 2003 states the “EMV Chip Specifications cannot be
`
`considered in isolation, and to this end, EMVCo collaborates with other industry
`
`bodies and standards organisations. Examples of this collaboration are given below”
`
`and include Global Platform. Ex. 2003 at 16:
`
`GlobalPlatform – Part of EMVCo’s activities is to review the
`functionality and security of platforms on which an EMV chip
`payment application will reside. Alignment with standards bodies
`such as GlobalPlatform are important as EMV chip payment
`applications are increasingly implemented on shared chip platforms
`that support multiple applications, each from a different application
`owner.
`Therefore, in my opinion, a POSITA would have understood that Dua’s teaching of
`
`card organizations and an EMV-Compliant wallet application would have motivated
`
`a POSITA to look to a card organization such as GlobalPlatform (Inc.) for assisting
`
`with management of applications on Dua’s smart card because the GlobalPlatform
`
`
`
`IPR2022-00412
`Apple EX1042 Page 19
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`specification provides well-known security and implementation details for those
`
`very purposes. Ex. 1003 at ¶¶115-121.
`
`24.
`
`Indeed, it was well-known that the smart card industry encouraged
`
`interoperability in many respects and across many complementary standards. For
`
`example, EMV technologies incorporated many details from GlobalPlatform and
`
`vice versa. For example, the EMV Card Personalization Specification incorporated
`
`aspects of GlobalPlatform. Ex. 1048. The EMV Card Personalization specification
`
`teaches “[t]he data preparation system must protect the completed personalization
`
`data file for integrity and authenticity (e.g., MAC or signed hash). For examples of
`
`implementation,
`
`see GlobalPlatform Load and Personalization
`
`Interface
`
`Specification.” Ex. 1048 at 17. In another example, several data elements such as
`
`CRN (Card and Application Management System (CAMS) Reference Number),
`
`STATUSCOLL, NUMBERPID, and IDVC1 also refer to GlobalPlatform specifications.
`
`Ex. 1048 at 34, 10. In yet another example, the EMV Card Personalization
`
`Specification teaches an “example of the complete structure of the log file including
`
`a header record is specified in GlobalPlatform Load and Personalization Interface
`
`Specification.” Ex. 1048 at 53. Thus, a POSITA would have understood that EMV
`
`technologies and standards both suggested compatibility with GlobalPlatform and
`
`incorporated GlobalPlatform functionalities.
`
`
`
`IPR2022-00412
`Apple EX1042 Page 20
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`25. Additionally, I provide a research example below detailing an EMV
`
`compliant device that uses GlobalPlatform personalization techniques. Namely, the
`
`GlobalPlatform CPSdemonstrator Specification teaches a “Sample Applet to
`
`exercise EMV CPS.” Ex. 1049 at 1. Ex. 1049 teaches that the document “provides
`
`the specifications for the CPSdemonstrator application. The application’s design is
`
`based on the EMV Card Personalization Specification, a common approach to
`
`personalization for all IC card applications.” Ex. 1049 at 6. Indeed, Ex. 1049
`
`references the EMV Card Personalization Specification v1.0 and GlobalPlatform
`
`Card Specification v2.2 as well as EMV Integrated Circuit Card Specifications for
`
`Payment Systems v4.1. Ex. 1049 at 8.
`
`26. Finally, in my opinion, Patent Owner is also incorrect in suggesting
`
`that Dua does not reference Java Card. POR at 21-22. I note that Dua expressly
`
`teaches “Java applets running in a mobile phone,” which a POSITA would have
`
`understood is a reference to Java Card, which was a well-known smart card for
`
`running Java applets in mobile devices. Dua at [0216]; Ex. 1003 at 118, 125. Further,
`
`a POSITA would have been motivated to combine Dua with GlobalPlatform because
`
`GlobalPlatform was the “de facto standard for loading and managing Java-based
`
`applications with the Java Card operating system.” Ex. 1003 at 118 (including citing
`
`Ex. 1008 at 290 “GlobalPlatform ‘has primarily become the de facto standard for
`
`loading and managing Java-based applications with the Java Card operating
`
`
`
`IPR2022-00412
`Apple EX1042 Page 21
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`system.’”). Indeed, a POSITA would have known that Java Card was one of the most
`
`important and dominant smart card options at that time. GlobalPlatform at 16
`
`(“Beginning in the mid-1990s, a number of very significant breakthroughs occurred
`
`in the chip card industry with the introduction of open systems specifications for
`
`Application development. The three leading technologies in this area are Java
`
`Card™ … These technology specifications provide an important contribution to the
`
`solution towards the multi-Application chip card vision[.]”), Therefore, a POSITA
`
`would also have been “separately motivate[d]”
`
`to combine Dua with
`
`GlobalPlatform.
`
`C. The Combination Discloses an Emulator that Stores Updated
`Transaction Logs
`27. Patent Owner argues that a POSITA would “not understand Philips or
`
`Dua to include a transaction log as claimed.” POR at 25-27. I disagree. As I opined
`
`previously, a standard (classic) Mifare transaction involved the use of encryption
`
`keys to update the stored balance in the card (storing security values) as well as
`
`updating a transaction log, and that it was mandatory in e-purses in general and also
`
`specifically in Mifare to store purse balances in transaction logs. Ex. 1003 at 134-
`
`136 (noting it was mandatory in e-purses in general and Mifare specifically to store
`
`purse balances in transaction logs). In a Mifare transaction, specifically, value-
`
`blocks are stored in memory and use various keys for reading, writing, and access.
`
`Id. at 135 (citing Ex-1019 at 199 and 201). Similar to these “classic” Mifare
`
`
`
`IPR2022-00412
`Apple EX1042 Page 22
`
`
`
`Inter Partes Review No. IPR2022-00412
`U.S. Patent No. 9,189,787
`transactions, Philips emulates these transactions. Ex. 1003 at 112, 134. In emulated
`
`Mifare, as the ’787 Patent admits and as I previously opined, the “SMX [Smart MX
`
`module] is pre-loaded with a Mifare emulator 208 (which is a single functional card)
`
`for storing values.” Ex-1001 at 5:6-8. Ex. 1003 at 135. Namely, the emulator stores
`
`the values above, which in classic Mifare are value-blocks stored in memory. Ex.
`
`1003 at 134-136. And as I opined, emulated Mifare functions like classic Mifare (Ex.
`
`1003 at 112) such that the emulator would store these value-blocks, consistent with
`
`the teachings in the ’787 Patent. Ex. 1003 at 134-136 (discussing Ex-1019 and other
`
`evidence).
`
`28. More specifically, when using emulated Mifare, such as taught by
`
`Philips, the Mifare emulator would emulate real Mifare functions which included
`
`updating value blocks stored in memory. Ex. 1003 at 134-136 (citing Philips at 3
`
`which notes that the Mifare command set, including read, write, and access, is
`
`emulated); se
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
