`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`
`Patent Owner.
`
`
`Patent No. 9,189,787
`Filing Date: May 28, 2013
`Issue Date: November 17, 2015
`
`Inventors: Liang Seng Koh, Futong Cho, Hsin Pan, and Fuliang Cho
`Title: METHOD AND APPARATUS FOR CONDUCTING
`E-COMMENCE AND M-COMMENCE
`
`
`__________________________________________________________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`Case No. IPR2022-00412
`
`__________________________________________________________________
`
`
`
`
`
` 
`
`

`

` 
`
`TABLE OF CONTENTS
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`Page(s)
`
`
`I. 
`INTRODUCTION ........................................................................................... 1 
`THE ’787 PATENT ......................................................................................... 3 
`II. 
`III.  THE ALLEGED PRIOR ART ........................................................................ 7 
`A.  Dua (U.S. Patent App. Pub. No. 2006/0165060) .................................. 7 
`B. 
`Philips (P5CT072 Secure Dual Interface PKI Smart Card
`Controller Short Form Specification) .................................................... 9 
`GlobalPlatform ...................................................................................... 9 
`C. 
`IV.  CLAIM CONSTRUCTION ............................................................................ 9 
`V. 
`LEVEL OF ORDINARY SKILL IN THE ART ............................................. 9 
`VI.  THE BOARD HAS TERMINATED THE SAMSUNG IPR THUS
`THERE IS NO INSTITUTED PROCEEDING FOR APPLE TO
`JOIN ............................................................................................................... 10 
`VII.  PETITIONER HAS NOT SHOWN A REASONABLE
`LIKELIHOOD OF SUCCESS AS TO ANY CHALLENGED
`CLAIM........................................................................................................... 10 
`A. 
`Requirements for Showing Obviousness Under 35 U.S.C. § 103
` ............................................................................................................. 10 
`Apple Fails to Show That the Limitation “a second interface
`configured to perform mobile commerce with a payment server
`via an application against the fund stored in the emulator” as
`Required by Claims 1-10 Would Be Obvious..................................... 11 
`Apple Fails to Show That the Limitation “performing mobile
`commerce via a second interface with a payment server via an
`application against the fund stored in the emulator,” as
`Required by Claims 11-19 Would Be Obvious .................................. 13 
`
`B. 
`
`C. 
`
`i
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`D.  Apple Fails to Show That the Limitations “a personalization
`process built on a first security channel so that the emulator is
`set to store a set of keys for subsequent data access
`authentication and the e-purse applet is configured to conduct a
`transaction with a network server over a second security
`channel”/“personalizing the emulator and the e-purse applet via
`a personalization process built on a first security channel so that
`the emulator is set to store a set of keys for subsequent data
`access authentication and the e-purse applet is configured to
`conduct a transaction with a network server over a second
`security channel” as required by all Challenged Claims Would
`Be Obvious .......................................................................................... 14 
`1. 
`Dua in View of Philips Does Not Disclose or Render
`Obvious the Limitation ............................................................. 15 
`Dua in View of GlobalPlatform and Philips Does Not
`Render this Limitation Obvious Because a POSA
`Would Not Combine Dua with Global Platform ...................... 16 
`VIII.  THE PETITION SHOULD BE DENIED IN THE DISCRETION OF
`THE DIRECTOR UNDER 35 U.S.C. § 314(A) ........................................... 21 
`A.  No Stay of the Parallel District Court Litigation ................................ 22 
`B. 
`The Board’s Written Decision Deadline Will Come Long After
`the Trial Date ....................................................................................... 23 
`Significant Investment by the Time of Institution Favors
`Discretionary Denial............................................................................ 24 
`The District Court Litigation Involves the Same Claims and the
`Same Arguments ................................................................................. 25 
`The Parallel District Court Litigation and the Petition Involve
`the Same Parties .................................................................................. 26 
`Other Circumstances Favor Denial of Institution ............................... 26 
`F. 
`IX.  CONCLUSION .............................................................................................. 26 
`
`
`D. 
`
`2. 
`
`C. 
`
`E. 
`
`ii
`
`

`

` 
`
`TABLE OF AUTHORITIES
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
` Page(s)
`
`Cases
`Apple Inc. v. Fintiv, Inc.,
`IPR2020-00019, Paper 11 (P.T.A.B. Mar. 20, 2020) ............................... 2, 21, 25
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed. Cir. 2015) .......................................................................... 18
`Cisco Sys., Inc. v. Ramot at Tel Aviv Univ. Ltd.,
`IPR2020-00122, Paper 15 (P.T.A.B. May 15, 2020) ......................................... 23
`Gen. Plastic Indus. Co. v. Canon Kabushiki Kaisha,
`IPR2016-01357, Paper 19 (P.T.A.B. Sept. 6, 2017) ........................................... 22
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) ................................................................................................ 10
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ............................................................................................ 11
`LG Elecs., Inc. v. Bell N. Research, LLC,
`IPR2020-00108, Paper 14 (P.T.A.B. May 20, 2020) ......................................... 10
`Lyft, Inc. v. Quartz Auto Techs., LLC,
`IPR2020-01450, Paper 7 (P.T.A.B. Mar. 4, 2021) ............................................. 19
`Next Caller Inc. v. TrustID, Inc.,
`IPR2019-00961, -00962, Paper 10, at 8-16 (P.T.A.B. Oct. 16,
`2019) ................................................................................................................... 23
`NHK Spring Co. v. Intri-Plex Techs., Inc.,
`IPR2018-00752, Paper 8 (P.T.A.B. Sept. 12, 2018) ........................................... 22
`Personal Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) ............................................................................ 18
`Samsung Elecs. Am., Inc. v. Uniloc 2017 LLC,
`IPR2019-01218, Paper 7 (P.T.A.B. Jan. 7, 2020) .............................................. 23
`
`iii
`
`

`

`IPR2022-00412
`PATENT NO. 9,189,787
`
` 
`Samsung Elecs. Co. v. RFCyber Corp.,
`IPR2021-00980, Paper No. 18 (P.T.A.B. Apr. 11, 2022) .................................. 10
`Supercell Oy v. Gree, Inc.,
`IPR2020-00513, Paper 11 (P.T.A.B. June 24, 2020) ......................................... 24
`Statutes
`35 U.S.C. § 103 ........................................................................................................ 10
`35 U.S.C. § 103(a) ..................................................................................................... 1
`35 U.S.C. § 314(a) ................................................................................... 2, 21, 22, 26
`35 U.S.C. § 314(b) ................................................................................................... 24
`35 U.S.C. § 316(a)(11) ............................................................................................. 23
`
`iv
`
`

`

`IPR2022-00412
`PATENT NO. 9,189,787
`
`LIST OF EXHIBITS
`
`2002
`
`2003
`
`Exhibit No. Description
`2001
`RFCyber Corp. v. Google LLC, et al., No. 2:20-cv-00274-JRG-
`RSP, Dkt. 263 (E.D. Tex. Feb. 10, 2022)
`RFCyber Corp. v. Google LLC, et al., No. 2:20-cv-00274-JRG-
`RSP, Dkt. 264 (E.D. Tex. Feb. 11, 2022)
`EMVCo, LLC, “A Guide To EMV Chip Technology, Version
`2.0”
`RFCyber Corp. v. Apple Inc., No. 6:21-cv-00916-ADA, Dkt. 29
`(W.D. Tex. Jan. 28, 2022)
`Apple’s Preliminary Invalidity Contentions, RFCyber Corp. v.
`Apple Inc., No. 6:21-cv-00916-ADA, dated March 1, 2022
`Exhibit C-2 to Apple’s Preliminary Invalidity Contentions,
`RFCyber Corp. v. Apple Inc., No. 6:21-cv-00916-ADA, dated
`March 1, 2022
`
`2004
`
`2005
`
`2006
`
` 
`
`
`
`
`
`v
`
`

`

` 
`I.
`
`INTRODUCTION
`On January 14, 2022, Apple Inc. (“Apple” or “Petitioner”) filed a petition
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`requesting inter partes review (“IPR”) of U.S. Patent No. 9,189,787 (Ex. 1001, the
`
`“’787 Patent”), challenging claims 1-19 (the “challenged claims”) as unpatentable
`
`under (pre-AIA) 35 U.S.C. § 103(a). The Declaration of Gerald W. Smith, Ex. 1003,
`
`(“Smith Declaration”) accompanied the Petition. Apple simultaneously filed a
`
`Motion for Joinder with then-pending IPR2021-00980. Paper No. 3 (“Motion”). On
`
`January 26, 2022, the Board issued a Notice of Filing Date Accorded for the petition
`
`and set the time for filing patent owner’s preliminary response. Paper No. 4. On
`
`April 11, 2022, the Board terminated IPR2021-00980 (the “Samsung IPR”) pursuant
`
`to a joint motion between the parties to that proceeding. Apple is also a party to the
`
`district court case captioned as RFCyber Corp. v. Apple, Inc., Case No. 2:21-cv-
`
`00916-ADA (W.D. Tex.) (hereinafter, the “District Court Litigation” or “Texas
`
`Action”), filed on September 7, 2021.
`
`The Board should deny Apple’s Petition. At the outset, the Samsung IPR has
`
`been terminated; thus there is no proceeding that Apple can join. And, as shown
`
`below, Apple’s Petition cannot show a reasonable likelihood of success with respect
`
`to any claim.
`
`In particular, Apple fails to show that its proposed combination discloses or
`
`renders obvious the key limitations:
`
`1
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
` “a second interface configured to perform mobile commerce with a
`
`payment server via an application against the fund stored in the
`
`emulator”;
`
` “performing mobile commerce via a second interface with a payment
`
`server via an application against the fund stored in the emulator”; and
`
` “a personalization process built on a first security channel so that the
`
`emulator is set to store a set of keys for subsequent data access
`
`authentication and the e-purse applet is configured to conduct a
`
`transaction with a network server over a second security
`
`channel”/“personalizing the emulator and the e-purse applet via a
`
`personalization process built on a first security channel so that the
`
`emulator is set to store a set of keys for subsequent data access
`
`authentication and the e-purse applet is configured to conduct a
`
`transaction with a network server over a second security channel.”
`
`Moreover, Apple fails to show that a person of skill in the art would have
`
`combined its references to arrive at Apple’s proposed combination.
`
`Second, the Fintiv factors all favor denying this Petition in the discretion of
`
`the Director under 35 U.S.C. § 314(a). The District Court in the pending litigation
`
`between Petitioner and Patent Owner has set trial for June 2023, before this
`
`proceeding will reach the projected statutory deadline for a Final Written Decision.
`
`2
`
`

`

` 
`Moreover, the parties have begun the claim construction process, and they and the
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`District Court will have invested substantial resources in the overlapping issues
`
`before an institution decision. Indeed, the Court’s schedule will see claim
`
`construction completed before the institution decision.
`
`Accordingly, the Board should deny institution.
`
`II. THE ’787 PATENT
`The ’787 Patent claims mobile devices and methods of using mobile devices
`
`in electronic and mobile commerce. ’787 Patent at 1:17-21. The inventors of the
`
`’787 Patent realized that existing contactless cards were not effective for use in
`
`electronic or mobile commerce “because stored values and transaction information
`
`are stored in data storage of each tag that is protected by a set of keys.” Id. at 1:33-
`
`37. Those keys “need to be delivered to the card for authentication before data can
`
`be accessed during a transaction.” Id. at 1:37-39. “This constraint makes systems
`
`using such technology difficult to be expanded to an open environment such as the
`
`Internet for e-commerce and cellular networks for m-commerce as the key delivery
`
`over a public domain network causes security concerns.” Id. at 1:39-43.
`
`To solve these problems, the inventors of the ’787 Patent developed a system
`
`for personalizing a card stored in a portable device. The system makes use of a
`
`midlet that facilitates communication between the securely stored applets and
`
`payment servers over a wireless network:
`
`3
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`’787 Patent, Fig. 2 (showing midlet (in yellow), and applet (in green)).
`
`
`
`
`
`4
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`’787 Patent, Fig. 3B (annotations added).
`
`
`
`5
`
`

`

` 
`
`The midlet facilitates this communication, for example, while the card is
`
`being personalized. The entire process is protected by a three-tier security model:
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`’787 Patent, Fig. 1A
`
`
`
`“The three-tier security model 100 includes physical security 102, e-purse
`
`security 104 and card manager security 106.” ’787 Patent at 3:58-60. The physical
`
`security “refers to a security mechanism provided by a single functional card to
`
`protect data stored on the card. The card may be hardware implemented or software
`
`emulated running on a type of media.” Id. at 3:61-64. E-purse security “defines a
`
`set of protocols that enable micro payment transactions to be carried out in both
`
`6
`
`

`

` 
`wired and wireless environments.” Id. at 4:4-6. “During a transaction, the purse
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`uses a set of respective keys for encryption and MAC computation in order to secure
`
`the message channel between the purse and the SAM or backend servers.” Id. at
`
`4:9-13. “Card Manager Security 106, referring to 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.” Id. at 4:19-
`
`24.
`
`A device that has been personalized using the three-tier security as above can
`
`then perform e-commerce and m-commerce against a fund stored in the emulator,
`
`using an NFC interface for e-commerce and a second interface for m-commerce. Id.
`
`at 2:36-52, 5:1-15, Fig. 2.
`
`III. THE ALLEGED PRIOR ART
`A. Dua (U.S. Patent App. Pub. No. 2006/0165060)
`U.S. Patent App. Pub. No. 2006/0165060 (Ex. 1004, “Dua”) is directed to a
`
`system for “managing credentials through a wireless network.” Dua at Title,
`
`Abstract. Dua was filed on January 21, 2005 and published on July 27, 2006. Dua.
`
`Dua sought to solve difficulties with inputting credentials into a wireless device.
`
`Dua at [0019]. To overcome these difficulties, Dua describes a system “through
`
`7
`
`

`

` 
`which credential issuers can securely and rapidly target specific wireless devices for
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`the distribution of the appropriate credentials.” Id. at [0020], [0024].
`
`Dua achieves its goals by using the Session Initiation Protocol (SIP). Id. at
`
`[0042]. Using SIP, each device, such as a portable phone, contains a wallet
`
`application and is assigned an “E.164 phone number, Uniform Resource Identifier
`
`(URI), or other type of unique address that can be resolved over the Internet.” Id.
`
`Dua also describes a Wireless Credential Manager (WCM), that “maintains, controls
`
`and distributes credentials.” Id. at [0043]. To provide credentials to the wireless
`
`device, a card issuer sends a personalization file to the WCM, along with the device’s
`
`phone number. Id. at [0057]. The WCM uses the phone number (or other unique
`
`device identifier) to connect to the specific device using SIP. Id. at [0061]-[0062],
`
`[0128]-[0182]. The communication may be secured using SIPS/TLS or another
`
`method. Id. at [0131], [0180]. The WCM then provides the credentials to the
`
`wireless device. Id. at [0180]. This use of SIP to “establish direct communication”
`
`between the WCM and the device is “an important aspect of” Dua. Id. at [0178].
`
`“The direct connection between the end-points using SIP offers a secure method,
`
`without intermediary servers, by which to transmit confidential information.” Id.
`
`Dua also describes “extensions.” Id. at [0289]. Dua’s extensions “‘extend’
`
`the capability of the wallet platform by enabling a new set of features defined by the
`
`8
`
`

`

` 
`credential issuer.” Id. Extensions may be preloaded or using the secure SIP
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`provisioning process for credentials. Id. at [0295], [0296].
`
`B.
`
`Philips (P5CT072 Secure Dual Interface PKI Smart Card
`Controller Short Form Specification)
`Ex. 1012 (“Philips”) purports to be a datasheet describing the P5CT072 Smart
`
`Card Controller. Ex. 1012 at 1. Philips bears a revision date of October 4, 2004,
`
`and states that it was “Published in the Netherlands,” but does not specify when it
`
`was published or otherwise made available to the public. Id. at 12.
`
`C. GlobalPlatform
`The GlobalPlatform Card Specification Version 2.1.1
`
`(Ex. 1006,
`
`“GlobalPlatform”) describes the “specifications that shall be implemented on
`
`GlobalPlatform smart cards.” GlobalPlatform at 16. GlobalPlatform describes its
`
`own security architecture and commands for use in installing and personalizing
`
`applications on GlobalPlatform cards. GlobalPlatform at 65-67, 88-90.
`
`IV. CLAIM CONSTRUCTION
`For the purposes of this Preliminary Response only, Patent Owner believes
`
`that claim construction is not required to resolve any issues.
`
`V. LEVEL OF ORDINARY SKILL IN THE ART
`For the purposes of this Preliminary Response only, Patent Owner utilizes
`
`Petitioner’s proposed level of skill in the art— “a bachelor’s degree[] in computer
`
`9
`
`

`

` 
`science, computer engineering, electrical engineering or an equivalent, and one year
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`of professional experience relating to mobile payment technology.” Pet. at 11.
`
`VI. THE BOARD HAS TERMINATED THE SAMSUNG IPR THUS
`THERE IS NO INSTITUTED PROCEEDING FOR APPLE TO
`JOIN
`On April 11, 2022, the Board terminated the Samsung IPR. Samsung Elecs.
`
`Co. v. RFCyber Corp., IPR2021-00980, Paper No. 18 (P.T.A.B. Apr. 11, 2022).
`
`With no active proceeding, Apple’s motion for joinder should be denied. See, e.g.,
`
`LG Elecs., Inc. v. Bell N. Research, LLC, Case No. IPR2020-00108, Paper 14
`
`(P.T.A.B. May 20, 2020) (denying motion for joinder after original proceeding was
`
`terminated).
`
`VII. PETITIONER HAS NOT SHOWN A REASONABLE
`LIKELIHOOD OF SUCCESS AS TO ANY CHALLENGED
`CLAIM
`A. Requirements for Showing Obviousness Under 35 U.S.C.
`§ 103
`The question of obviousness is resolved on the basis of underlying factual
`
`determinations, including: (1) the scope and content of the prior art, (2) any
`
`differences between the claimed subject matter and the prior art, (3) the level of skill
`
`in the art, and (4) where in evidence, so called secondary considerations. Graham
`
`v. John Deere Co. of Kansas City, 383 U.S. 1, 17–18 (1966). A claim is only
`
`unpatentable under 35 U.S.C. § 103 if “the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a whole
`
`10
`
`

`

` 
`would have been obvious at the time the invention was made to a person having
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`ordinary skill in the art to which said subject matter pertains.” KSR Int’l Co. v.
`
`Teleflex Inc., 550 U.S. 398, 406 (2007) (quoting 35 U.S.C. § 103). 
`
`B. Apple Fails to Show That the Limitation “a second interface
`configured to perform mobile commerce with a payment
`server via an application against the fund stored in the
`emulator” as Required by Claims 1-10 Would Be Obvious
`Claim 1 of the ’787 Patent (and therefore its dependent claims 2-10) requires
`
`“a second interface configured to perform mobile commerce with a payment server
`
`via an application against the fund stored in the emulator.” ’787 Patent at cl. 1. While
`
`Apple states that “Dua in view of Phillips” discloses and renders obvious this
`
`limitation (Pet. at 35), it fails to show that this limitation is disclosed or rendered
`
`obvious by either or both references.
`
`Apple spends little time on this limitation. It first states that “Dua’s devices
`
`also include hardware for m-commerce, including hardware to facilitate SIP
`
`communications with a remote server over a wireless network.” Pet. at 36 (citing
`
`Dua at [0041]-[0042], [0323]. But neither Apple’s conclusory statement nor the
`
`three cited paragraphs show that “facilitat[ing] SIP communications with a remote
`
`server” is the same as performing mobile commerce as required. Paragraphs [0041]
`
`and [0042] merely describe using wireless communications. Dua, [0041]-[0042].
`
`Paragraph [0323] discusses “online purchases and banking” but does not describe
`
`11
`
`

`

` 
`“mobile commerce via an application against the fund stored in the emulator” as
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`required by the claims.
`
`Apple next argues that the limitation is met by a “MIFARE over-the-air
`
`reload.” Pet. at 38. Dua is silent as to MIFARE; indeed, it does not mention
`
`MIFARE at all. See generally Dua. Dua briefly mentions that an extension may be
`
`needed for “an over-the-air reload tool” (Dua at [0293]), but it does not specify
`
`whether the reload would be an “over-the-air reload via RF swipe,” which would
`
`utilize the RFID interface (see Pet. at 38) or via some method using the cellular
`
`interface. However, even if it were obvious to use MIFARE with Dua, an over-the-
`
`air reload transaction would not be “against the fund stored in the emulator.” A
`
`transaction “against” a fund (as opposed to “relating” to a fund) requires using that
`
`fund to pay for the transaction. See, e.g., ’787 Patent, 4:4-6 (discussing “micro
`
`payment transactions to be carried out in both wired and wireless environments”).
`
`Neither Dua nor Phillips disclose using a stored MIFARE value to pay for an m-
`
`commerce transaction. Neither Apple nor Mr. Smith attempt to show otherwise or
`
`even substantively discuss that the transaction must be “against the fund stored in
`
`the emulator.” See Pet. at 38-39; Ex. 1003, ¶¶ 169-73.
`
`Since Apple has not shown that the limitation “a second interface configured
`
`to perform mobile commerce with a payment server via an application against the
`
`12
`
`

`

` 
`fund stored in the emulator” is disclosed or rendered obvious, it cannot show a
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`reasonable likelihood of prevailing with respect to claims 1-10.
`
`C. Apple Fails to Show That the Limitation “performing mobile
`commerce via a second interface with a payment server via
`an application against the fund stored in the emulator,” as
`Required by Claims 11-19 Would Be Obvious
`Claim 11 and its dependent claims recite “performing mobile commerce via a
`
`second interface with a payment server via an application against the fund stored in
`
`the emulator.” Apple relies on the same evidence and argument for this limitation
`
`as it does for “a second interface configured to perform mobile commerce with a
`
`payment server via an application against the fund stored in the emulator” discussed
`
`above. Pet. at 46. For the same reasons, Apple’s combination does not disclose
`
`“performing mobile commerce . . . against the fund stored in the emulator” and
`
`therefore does not render this limitation obvious.
`
`Accordingly, Apple has not and cannot show a reasonable likelihood of
`
`prevailing with respect to claims 11-19.
`
`13
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`D. Apple Fails to Show That the Limitations “a personalization
`process built on a first security channel so that the emulator
`is set to store a set of keys for subsequent data access
`authentication and the e-purse applet is configured to
`conduct a transaction with a network server over a second
`security channel”/“personalizing the emulator and the e-
`purse applet via a personalization process built on a first
`security channel so that the emulator is set to store a set of
`keys for subsequent data access authentication and the e-
`purse applet is configured to conduct a transaction with a
`network server over a second security channel” as required
`by all Challenged Claims Would Be Obvious
`All of the challenged claims require the limitation “wherein . . . [the] e-purse
`
`applet [is] are already personalized via a personalization process built on a first
`
`security channel . . . and the e-purse applet is configured to conduct a transaction
`
`with a network server over a second security channel” (’787 Patent at claim 1) or
`
`“personalizing . . . the e-purse applet via a personalization process built on a first
`
`security channel so that . . . the e-purse applet is configured to conduct a transaction
`
`with a network server over a second security channel” (’787 Patent at claim 11).
`
`Apple argues that this limitation is disclosed in two ways: i) via Dua in view of
`
`GlobalPlatform and Philips (Pet. at 25-32); and ii) via Dua in view of Philips (Pet.
`
`at 32-35). As discussed below, Dua in view of Philips does not disclose the
`
`limitation and a POSA would not combine Dua with GlobalPlatform.
`
`14
`
`

`

` 
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`1.
`
`Dua in View of Philips Does Not Disclose or Render
`Obvious the Limitation
`Apple does not show that Dua in view of Philips discloses the limitation,
`
`because Apple cannot show that the personalization process is “built on a first
`
`security channel” and that the “e-purse applet is configured to conduct a transaction
`
`with a network server over a second security channel.” According to Apple, Dua’s
`
`extensions are the e-purse applets of the claims. Pet. at 32. Dua explains that
`
`extensions are downloaded and personalized using Dua’s SIP-based provisioning
`
`system. Dua, ¶¶ [0295] (“Extensions may reside . . . on a remote server, securely
`
`accessible through the wallet application protocols”), [0296] (“The provisioning of
`
`such an extension to a wireless device using a valid E.164 number of URI is also
`
`possible.”).
`
`Apple argues that the SIP provisioning system, if it uses TLS, is the first
`
`security channel. Pet. at 33. Apple then argues that the SIP system can make use of
`
`a “security channel ‘built on’ the TLS security channel using S/MIME.” Id. at 32.
`
`But Apple, while quoting some sections of Dua explaining S/MIME, makes no effort
`
`to show that, after the personalization process is complete, the extension would
`
`conduct transactions with network servers via S/MIME. See id. Indeed, Apple
`
`devotes its entire section to arguing that the credentials which are used, at most, to
`
`personalize the extension would be transferred via S/MIME. See id. at 33-35. Thus,
`
`15
`
`

`

` 
`even under Apple’s characterization of Dua and Philips, the S/MIME channel is used
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`to personalize the extension, and thus cannot be the second security channel over
`
`which the extension should be configured to conduct a transaction with a network
`
`server. Indeed, Apple does not even attempt to describe a network server with which
`
`the extension would conduct a transaction. Apple does not argue that Philips
`
`remedies these deficiencies.
`
`Accordingly, Dua in view of Philips does not disclose or render obvious the
`
`limitation.
`
`2.
`
`Dua in View of GlobalPlatform and Philips Does Not Render
`this Limitation Obvious Because a POSA Would Not
`Combine Dua with Global Platform
`Apple’s remaining arguments rely on replacing Dua’s SIP-based secure
`
`provisioning process with GlobalPlatform’s process. A POSA would not make such
`
`a replacement because Dua already provides security through SIPS/TLS and other
`
`encryption methods. See supra III.A. Apple identifies no lack or flaw within Dua
`
`that would necessitate replacing Dua’s security with GlobalPlatform’s security.
`
`To manufacture a motivation to combine GlobalPlatform with Dua, Apple
`
`relies on statements in Dua relating to compliance with payment standards, not card
`
`management systems like GlobalPlatform. For example, Apple cites general
`
`statements in Dua that “MasterCard and Visa have also been working jointly over
`
`the last few years to develop specifications that define a set of requirements for
`
`16
`
`

`

` 
`security and interoperability between chip cards and terminals on a global basis,
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`regardless of the manufacturer, the financial institution, or where the card is used.”
`
`Pet. at 16 (quoting Dua at [0013]) (emphasis added).1 The specifications referred to
`
`are the EMV Chip Specifications.2 As EMVCo. explains, “The EMV Chip
`
`Specifications . . . are global payment industry specifications that describe the
`
`requirements for interoperability between chip-based payment applications and
`
`acceptance terminals to enable payment.” Ex. 2003 at 5. GlobalPlatform is not
`
`related to interoperability between chip cards and terminals; it purports to provide a
`
`“card management architecture.” Pet. at 13 (quoting Ex. 1006, p. 16). Accordingly,
`
`a POSA would look to EMV, not GlobalPlatform, when considering the
`
`specifications to which Dua refers.
`
`Apple further argues that a POSA would combine GlobalPlatform with Dua
`
`based on an out-of-context quote: “[The] wallet application should meet standards
`
`defined by card organizations.” Pet. at 17 (quoting Dua, [0525]). But the relevant
`
`sentence reads, in full, “EMV-Compliant—The wallet application should meet
`
`standards defined by card organizations.” As explained above, Dua specifically
`
` 
`1 The Petition cites to Dua, [0014], but that paragraph relates to smart cards
`becoming the “dominant technology for conducting financial transactions. Dua,
`[0014]. It does not discuss “credit card organizations ‘working jointly.’”
`2 EMV stands for Europay, Mastercard and Visa (Ex. 2003 at 5.)
`
`17
`
`

`

` 
`explains that the wallet application should be compliant with EMV specifications to
`
`IPR2022-00412
`PATENT NO. 9,189,787
`
`process payments. See also Dua, [0398] (noting “EMV ‘chip & PIN’” transactions.
`
`Apple finally argues that Dua’s reference to JAVA would lead a POSA to
`
`combine Dua with GlobalPlatform. First, Apple states, with no supporting evidence,
`
`that references to Java means that Dua is discussing JavaCard. Pet. at 17. Dua
`
`never mentions “JavaCard.” Apple’s expert also does not support the notion that a
`
`POSA would look to a JavaCard upon reviewing Dua; instead, Mr. Smith avers that
`
`Dua uses the “Java 2 Platform, Mobile Edition (J2ME)” as the operating system for
`
`the “mobile phone.” Ex. 1003, ¶ 118. But Dua never states that the smart card would
`
`have a J2ME operating system, or any operating system at all. See generally Dua.
`
`Instead, Dua states that J2ME may be used to create the wallet application—it says
`
`nothing about any smart card operating system. Dua, [0500]. Indeed, Dua mentions
`
`another alternate operating system and API. Dua, [0501] (discussing the use of
`
`Symbia OS v7.0s). In sum, Apple does not provide a motivation to combine Dua
`
`with GlobalPlatform. The mere existence of GlobalPlatform is not enough to
`
`provide a motivation; Apple needs to show a reason for a POSA to actually choose
`
`to use GlobalPlatform. Personal Web Techs., LLC v. Apple, Inc., 848 F.3d 987, 993-
`
`94 (Fed. Cir. 2017) (holding that testimony that references could be combined was
`
`“not enough: it does not imply a motivation to pick out those two references and
`
`combine them to arrive at the claimed invention”); Belden Inc. v. Berk-Tek