`571-272-7822
`
`Paper 11
`Date: July 21, 2022
`
`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
`
`
`
`
`
`
`
`
`
`Before KEVIN F. TURNER, PATRICK R. SCANLON, and
`KEVIN W. CHERRY, Administrative Patent Judges.
`SCANLON, Administrative Patent Judge.
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`Dismissing Petitioner’s Motion for Joinder as Moot
`37 C.F.R. §§ 42.22, 42.122(b)
`
`
`
`
`
`
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`INTRODUCTION
`I.
`Apple Inc. (“Petitioner”) filed a Petition to institute inter partes
`review of claims 1–19 of U.S. Patent No. 9,189,787 B1 (Ex. 1001, “the ’787
`patent”). Paper 1 (“Pet.”).1 RFCyber Corp. (“Patent Owner”) filed a
`Preliminary Response. Paper 9 (“Prelim. Resp.”).
`We have authority under 35 U.S.C. § 314 to determine whether to
`institute an inter partes review. The standard for instituting an inter partes
`review is set forth in 35 U.S.C. § 314(a), which provides that an inter partes
`review may not be instituted unless “there is a reasonable likelihood that the
`petitioner would prevail with respect to at least 1 of the claims challenged in
`the petition.” The Supreme Court has held that the Board, in a decision to
`institute under 35 U.S.C. § 314(b), may not institute review on less than all
`claims challenged in the petition. SAS Inst. Inc. v. Iancu, 138 S. Ct. 1348,
`1355–56 (2018). Moreover, in accordance with our rules, “[w]hen
`instituting inter partes review, the Board will authorize the review to
`proceed on all of the challenged claims and on all grounds of unpatentability
`asserted for each claim.” 37 C.F.R. § 42.108(a) (2020); see also PGS
`Geophysical AS v. Iancu, 891 F.3d 1354, 1360 (Fed. Cir. 2018) (interpreting
`the statute to require “a simple yes-or-no institution choice respecting a
`petition, embracing all challenges included in the petition”).
`
`
`1 Petitioner also filed a Motion for Joinder to IPR2021-00980 (Paper 3).
`Petitioner indicated that its Petition is substantially identical to the petition in
`IPR2021-00980. Pet. 5. (Although the Petition actually refers to the petition
`in IPR2021-00981, this appears to be a typographical error.) However,
`IPR2021-00980 has since settled and was terminated. Because IPR2021-
`00980 has been terminated, we dismiss Petitioner’s motion to join that
`proceeding as moot.
`
`2
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`Applying those standards, and upon considering the Petition, the
`Preliminary Response, and the evidence of record, we determine the
`information presented shows a reasonable likelihood that Petitioner would
`prevail in establishing the unpatentability of at least one of the challenged
`claims of the ’787 patent. Accordingly, we institute an inter partes review
`of all challenged claims (i.e., claims 1–19) of the ’787 patent on the grounds
`asserted in the Petition.
`
`II. BACKGROUND
`
`A. Related Matters
`The parties identify the following district-court proceedings as related
`matters involving the ’787 patent: RFCyber Corp. v. Apple, Inc., No. 6:21-
`cv-00916 (W.D. Tex.); RFCyber Corp. v. Google LLC, No. 2:20-cv-00274
`(EDTX); RFCyber Corp. v. LG Electronics, Inc., No. 2:20-cv-00336
`(EDTX); and RFCyber Corp. v. Samsung Electronics Co., 2:20-cv-00335
`(EDTX). Pet. 3; Paper 6, 1 (Patent Owner’s Mandatory Notices).
`Petitioner also identifies the following Board proceeding involving the
`same parties and a related patent: PGR2021-00028 (U.S. Patent No.
`10,600,046 B2 (“the ’046 patent”). Pet. 4. The parties also identify the
`following Board proceedings involving the ’787 patent or related patents,
`filed by Samsung Electronics America, Inc. et al.: IPR2021-00978 (U.S.
`Patent No. 8,448,855 B1 (“the ’855 patent”)); IPR2021-00979 (U.S. Patent
`No. 8,118,218 B2 (“the ’218 patent”)); IPR2021-00980 (the ’787 patent);
`and IPR2021-00981 (U.S. Patent No. 9,240,009 B2 (“the ’009 patent”)).
`Pet. 4; Paper 6, 1. Petitioner also identifies the following Board proceedings
`involving the ’787 patent or related patents, filed by Google LLC: IPR2021-
`00954 (the ’855 patent); IPR2021-00955 (the ’787 patent); IPR2021-00956
`
`3
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`(the ’009 patent); IPR2021-00957 (the ’218 patent); PGR2021-00028 (the
`’046 patent); and PGR2021-00029 (the ’046 patent). Pet. 3–4.
`B. Real Parties in Interest
`Petitioner identifies its real party in interest as Apple Inc. Pet. 2.
`Patent Owner identifies RFCyber Corp. as its real party in interest. Paper 6,
`1.
`
`C. Overview of the ’787 patent
`The ’787 patent relates to commerce over networks, and more
`specifically, to a method and apparatus for funding an electronic purse (“e-
`purse”) for use in portable devices configured for both electronic commerce
`(“e-commerce”) and mobile commerce (“m-commerce”). Ex. 1001, code
`(57), 1:15–19.
`The ’787 patent states that there is a “need for a mechanism in
`devices, especially portable devices, functioning as an electronic purse (e-
`purse) to be able to conduct transactions over an open network with a
`payment server without compromising security.” Id. at 1:44–48. Although
`closed systems—such as smart card technology—existed, they were
`“difficult to be expanded into other areas such as e-commerce and
`m-commerce” because “stored values and transaction information are stored
`in data storage of each tag that is protected by a set of keys,” which keys
`must be “delivered to the card for authentication before data can be accessed
`during a transaction.” Id. at 1:33–39. According to the ’787 patent, this
`required delivery of keys “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. The ’787 patent
`
`4
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`purports to overcome the limitations of the prior art by providing a system
`for funding an e-purse stored on a portable device. The e-purse allows for
`transactions “over an open network with a payment server without
`compromising security.” Id. at 1:60–64.
`Figure 2, reproduced below, provides a schematic view of one
`embodiment of the ’787 patent.
`
`
`
`FIG. 2 shows an exemplary architecture diagram 200 according
`to one embodiment of the ’787 patent. Ex. 1001, 3:6–7.
`As shown in Figure 2, a portable device is pre-loaded with smart card
`module 202 comprising emulator 208, e-purse applet 206, and purse
`manager midlet 204. Id. at 5:1–48. The portable device may be a cellphone
`that is “near field communication (NFC) enabled” and includes an RFID
`interface “that allows the cellphone to act as a tag.” Id. at 5:4–10.
`
`5
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`Purse management midlet 204 “is a software component” that “acts as
`an agent to facilitate communications between an e-purse applet 206 and one
`or more payment network and servers 210 to conduct transactions.” Id. at
`5:16–20. E-purse applet 206 is built on a global platform and “acts as a
`gatekeeper to regulate or control the data exchange.” Id. at 4:55–57, 5:11–
`13. Emulator 208 is “a hardware device or a program that pretends to be
`another particular device or program that other components expect to
`interact with.” Id. at 4:47–50.
`In one embodiment of the ’787 patent, a user may fund the e-purse
`from a bank account by a process conducted via the m-commerce path
`shown in Figure 2. Id. at 7:22–30. Figure 4C, reproduced below, “shows an
`exemplary block diagram 450 of related blocks interacting with each other to
`achieve the process” of funding the e-purse. Id. at 7:26–28.
`
`
`
`FIG. 4C “shows an exemplary block diagram of related blocks
`interacting with each other to achieve the process” of financing
`an e-purse according to one embodiment of the ’787 patent.
`Ex. 1001, 3:21–23.
`End user 432 enters a personal identification number (PIN), which, if
`valid, activates purse manager midlet 434. Id. at 7:34–37. The purse
`manager midlet “communicates with the e-purse applet 436 for a response
`
`6
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`that is then sent to the payment network and server 440.” Id. at 7:44–47.
`Payment network and server 440 “verifies that the response is from an
`authorized e-purse originally issued therefrom with a SAM module 444.”
`Id. at 8:1–4. “After the response is verified, the payment network and server
`440 sends a request to the [user’s] financing bank 442.” Id. at 8:4–7. Upon
`receiving authorization from the financing bank, “the server 440 will either
`reject the request or form a network response to be sent to the midlet 434.”
`Id. at 8:9–12. “The e-purse verifies the authenticity (e.g., in APDU format)
`and sends commands to the emulator 438 and updates the transaction logs.”
`Id. at 8:13–15. According to the ’787 patent, “[b]y 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 to the payment server 440.” Id. at
`8:15–18.
`D. The Challenged Claims
`Petitioner challenges claims 1–19 of the ’787 patent. Pet. 6–7. Of the
`challenged claims, claims 1 and 11 are independent. Ex. 1001, 8:49–9:4,
`9:49–10:14. Claim 1, reproduced below, is illustrative of the subject matter
`recited in the challenged claims (bracketing added).
`1. [PREAMBLE] A portable device for commerce, the
`portable device comprising:
`[1a] an emulator loaded in a smart card module for storing
`security values and updated transaction logs, and [1b] an
`e-purse applet to cause the portable device to function as
`an electronic purse (e-purse), [1c] wherein both of the
`emulator and e-purse applet are already personalized 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;
`
`7
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`Exhibit No.
`1003
`1004
`
`[1d] a first interface configured to perform field communication
`(NFC) with a reader to perform electronic commerce
`with the e-purse applet against a fund stored in the
`emulator;
`[1e] a second interface configured to perform mobile commerce
`with a payment server via an application against the fund
`stored in the emulator, and
`[1f] a purse manager midlet being executed in the portable
`device to act as an agent to facilitate communications
`between the e-purse applet and a payment server to
`conduct transactions therebetween.
`Id. at 8:49–9:4.
`E. Evidence
`Petitioner submits the following evidence:
`Evidence
`Declaration of Gerald W. Smith
`Dua, US 2006/0165060 A1 (published July 27, 2006)
`(“Dua”)
`GlobalPlatform, Card Specification, Version 2.1.1 (March
`2003) (“GlobalPlatform”)
`Philips Semiconductors SmartMX, P5CT072, Secure Dual
`Interface PKI Smart Card Controller, Rev. 1.3 (Oct. 4,
`2004) (“Philips”)
`
`1006
`
`1012
`
`F. Asserted Ground of Unpatentability
`Petitioner asserts the following ground of unpatentability:
`Claim(s) Challenged
`35 U.S.C. §
`Reference(s)
`1–19
`1032
`Dua, GlobalPlatform, Philips
`
`
`2 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. The ’787 patent claims benefit
`of a September 24, 2006, filing date, which is before the effective date of the
`applicable AIA amendments. Ex. 1001, code (63). Petitioner does not
`contest the ’787 patent’s priority date. Pet. 7. Thus, we refer to the pre-AIA
`
`8
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`Pet. 6–7. Patent Owner disputes Petitioner’s asserted ground of
`unpatentability. See generally Prelim. Resp.
`III. PATENTABILITY ANALYSIS
`Petitioner contends that claims 1–19 of the ’787 patent are
`unpatentable under 35 U.S.C. § 103 as obvious over of Dua, GlobalPlatform,
`and Philips. Pet. 6–7. A patent claim is unpatentable under 35 U.S.C.
`§ 103(a) if the differences between the claimed subject matter and the prior
`art are such that the subject matter, as a whole, would have been obvious at
`the time the invention was made to a person having ordinary skill in the art
`to which said subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550
`U.S. 398, 406 (2007). 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 ordinary skill in the art; and (4) when in evidence,
`objective evidence of nonobviousness.3 Graham v. John Deere Co., 383
`U.S. 1, 17–18 (1966).
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion never
`
`
`version of 35 U.S.C. § 103. Our decision would be the same were we to
`apply the AIA version of the statute.
`3 Patent Owner does not present arguments or evidence of secondary
`considerations in its Preliminary Response. Therefore, secondary
`considerations do not constitute part of our analysis herein.
`
`9
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`shifts to Patent Owner. See Dynamic Drinkware, LLC v. Nat’l Graphics,
`Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden of proof in
`inter partes review).
`We organize our patentability analysis into four sections. First, we
`address the level of ordinary skill in the art. Second, we address claim
`construction. Third, we provide an overview of the asserted references.
`And fourth, taking account of the information presented, we consider
`whether the Petition satisfies the threshold requirement for instituting an
`inter partes review under 35 U.S.C. § 314(a).
`A. Level of Ordinary Skill in the Art
`We consider the asserted grounds of unpatentability in view of the
`understanding of a person of ordinary skill in the art. In assessing the level
`of ordinary skill in the art, various factors may be considered, including the
`“type of problems encountered in the art; prior art solutions to those
`problems; rapidity with which innovations are made; sophistication of the
`technology; and educational level of active workers in the field.” In re
`GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995) (quoting Custom
`Accessories, Inc. v. Jeffrey-Allan Indus., Inc., 807 F.2d 955, 962 (Fed. Cir.
`1986)). “[O]ne or more factors may predominate.” Id.
`Relying on the declaration testimony of Mr. Smith, Petitioner
`contends that an ordinarily skilled artisan for the ’787 patent “would have
`been knowledgeable regarding mobile payment methods and systems
`pertinent to the ’787 patent.” Pet. 11 (citing Ex. 1003 ¶¶ 27–28). Petitioner
`also contends that an ordinarily skilled artisan “would have had at least a
`bachelor’s degrees [sic] in computer science, computer engineering,
`electrical engineering or an equivalent, and one year of professional
`
`10
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`experience relating to mobile payment technology,” and that “[l]ack of
`professional experience could be remedied by additional education, and vice
`versa.” Id. (citing Ex. 1003 ¶¶ 27–28). Patent Owner states that it “utilizes
`Petitioner’s proposed level of skill in the art,” but only for its Preliminary
`Response. Prelim. Resp. 9–10.
`Based on this record, we adopt Petitioner’s articulation of the level of
`ordinarily skill in the art, which is consistent with the ’787 patent and the
`asserted prior art, and we apply it in our obviousness evaluations below. See
`Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001) (the prior art,
`itself, can reflect appropriate level of ordinary skill in art).
`B. Claim Construction
`Next, we turn to claim construction. In interpreting the claims of the
`’787 patent, we “us[e] the same claim construction standard that would be
`used to construe the claim[s] in a civil action under 35 U.S.C. [§] 282(b).”
`37 C.F.R. § 42.100(b) (2020). The claim construction standard includes
`construing claims in accordance with the ordinary and customary meaning
`of such claims as would have been understood by one of ordinary skill in
`the art and the prosecution history pertaining to the patent. See id.; Phillips
`v. AWH Corp., 415 F.3d 1303, 1312–14 (Fed. Cir. 2005) (en banc).
`Petitioner contends that all claim terms, except “emulator” and
`“midlet,” should have their plain and ordinary meaning. Pet. 12. As to the
`claim terms “emulator” and “midlet,” Petitioner contends that the ’787
`patent expressly defines those terms “so those definitions are controlling.”
`Id. (citing Ex. 1001, 4:47–50, 5:20–22). Patent Owner argues that “claim
`construction is not required to resolve any issues” at this point in the
`proceeding. Prelim. Resp. 9.
`
`11
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`Having considered the record, we determine that no express claim
`construction is necessary for any claim terms. See Nidec Motor Corp. v.
`Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017)
`(holding that only claim terms in controversy need to be construed, and only
`to the extent necessary to resolve the controversy (citing Vivid Techs., Inc. v.
`Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))).
`C. The Prior Art
`Before turning to Petitioner’s asserted grounds of unpatentability, we
`provide brief summaries of the asserted references.
`1. Dua (Ex. 1004)
`Dua is a published U.S. patent application entitled “Method and
`Apparatus for Managing Credentials Through a Wireless Network.”
`Ex. 1004, (54). Dua discloses a “system and methodology for conducting
`financial and other transactions using a wireless device.” Id. at Abstract.
`Dua’s wireless device includes a “wallet application” that receives, stores,
`manages, and transmits multiple payment, identification, and other
`confidential information electronically. Id. ¶ 41. Card issuers like banks or
`merchants can develop custom “extensions” which are installed in the wallet
`application and stored in an embedded smart card. Id. ¶¶ 289, 295. One
`example of an extension is a stored-value card extension for paying subway
`fare. Id. ¶¶ 290, 293. The stored value card extension “need[s] to be
`programmed” to support “over-the-air reload,” i.e., wireless funding of the
`e-purse. Id. ¶ 293.
`2. GlobalPlatform (Ex. 1006)
`GlobalPlatform Card Specification version 2.1.1 describes the
`“[s]pecifications that shall be implemented on GlobalPlatform smart cards.”
`
`12
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`Ex. 1006, 16. GlobalPlatform describes its own security architecture and
`commands for use in installing and personalizing applications on
`GlobalPlatform cards. Ex. 1006, 65–67, 88–90. GlobalPlatform is a
`“hardware-neutral,” “vendor-neutral,” and “Application independent” “chip
`card standard,” which “provides a common security and card management
`architecture.” Ex. 1006, 16; Ex. 1008, 290. “GlobalPlatform is intended to
`run on top of any secure, multi-application card runtime environment”
`including Java Card. Ex. 1006, 16 (§1), 29 (§3.1). GlobalPlatform specifies
`the card architecture, security architecture, Life Cycle models for smart
`cards and their Applications, the Card Manager, Security Domains for key
`management, and establishing Secure Channels. Ex. 1003 ¶¶ 66–78.
`GlobalPlatform describes sequences of commands for installing,
`personalizing, and deleting applications on multi-application smart cards.
`Ex. 1006, 65–67, 88–90.
`3. Philips (Ex. 1012)
`Philips is a short form specification describing a Secure PKI Smart
`Card Controller for the SmartMX (Memory eXtension) multiple interface
`option platform. Ex. 1012, 1. The Smart Card Controller can be used as
`data memory and program memory. Id. The interface technology is well
`established in all products of the MIFARE interface platform. Id. at 2.
`“Compatibility with existing MIFARE® reader infrastructure and the
`optional free of charge emulation modes of MIFARE® 1K and MIFARE®
`4K enable fast system integration and backward compatibility of standard
`MIFARE® and ProX family based cards.” Id.
`
`13
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`D. Alleged Ground of Unpatentability Over Dua in View of
`GlobalPlatform and Philips
`Petitioner contends that claims 1–19 of the ’787 patent are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in view of
`GlobalPlatform and Philips. Pet. 15–57. In particular, Petitioner contends
`that the combination of Dua, GlobalPlatform, and Philips teaches or suggests
`each and every limitation of the challenged claims, id. at 19–57, and that an
`ordinarily skilled artisan would have had a reason to combine the disclosures
`of the prior art, id. at 15–19. Patent Owner opposes. Prelim. Resp. 10–17.
`In particular, Patent Owner argues that Petitioner has failed to show that an
`ordinarily skilled artisan would have combined the teachings of Dua and
`GlobalPlatform, id. at 11–14, and that Petitioner has failed to show that the
`prior art teaches or suggests the claimed e-purse applet personalization
`process, as required by all the challenged claims, id. at 14–20.
`1. Claim 1
`Petitioner contends that Dua discloses a system and method for
`conducting financial transactions in which a wireless device includes a
`wallet application “capable of receiving, storing, managing and transmitting
`multiple payment, identification, and other confidential information
`electronically.” Pet. 15–16 (citing Ex. 1004 ¶¶ 26, 41, 309). Petitioner also
`contends that Dua’s device has an embedded smart card, but that Dua does
`not describe conventional smart card details. Id. at 16 (citing Ex. 1004 ¶¶ 7,
`215, 295). According to Petitioner, however,
`Dua does refer to credit card organizations “working jointly over
`the last few years to develop specifications that define a set of
`requirements for security and interoperability between chip cards
`and terminals on a global basis, regardless of the manufacturer,
`financial institution, or where the card was used,” which [an
`
`14
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`including
`
`ordinarily skilled artisan] would recognize as
`GlobalPlatform.
`Id. (citing Ex. 1004 ¶ 14; Ex. 1006, 16; Ex. 1003 ¶¶ 115–116; Ex. 1008,
`290).
`In addition, Petitioner contends that GlobalPlatform discloses a smart
`card management specification or standard useable with Dua’s wallet
`application. Id. at 16–17 (citing Ex. 1004 ¶ 525; Ex. 1006, 16; Ex. 1003
`¶ 117). Petitioner also asserts that both Dua and GlobalPlatform use the
`Java Card operating system, and GlobalPlatform facilitates loading and
`installing issuer specific applications, such as Dua’s extensions. Id. at 17
`(citing Ex. 1004 ¶¶ 195, 216, 498–500; Ex. 1006, 24, 27, 29; Ex. 1003
`¶¶ 118–120; Ex. 1008, 290). Thus, in Petitioner’s view, an ordinarily skilled
`artisan would have been motivated to and would have found it obvious to
`have used GlobalPlatform with Dua’s smart cards, wallet application, and
`extensions. Id. (citing Ex. 1003 ¶ 121).
`Furthermore, Petitioner contends that Philips Semiconductor
`SmartMX smart cards were well-known dual interface cards designed to
`work with Java Card. Id. 17–18 (citing Exs. 1010–1013; Ex. 1028 ¶¶ 10, 23;
`Ex. 1029 ¶ 20; Ex. 1030, 43–44; Ex. 1031, 32:23–36; Ex. 1032 ¶ 11). Thus,
`Petitioner contends, an ordinarily skilled artisan would have been motivated
`to and would have found it obvious to have used a Philips smart card in
`Dua’s wireless device. Id. at 18–19 (citing Ex. 1003 ¶¶ 108–112, 122–125).
`Petitioner next provides analysis purporting to show where each
`limitation recited in independent claim 1 is disclosed by the combination of
`Dua, GlobalPlatform, and Philips. Id. at 19–43. At a high level, Petitioner
`maps Dua’s wireless devices to the portable device of claim 1, Dua’s “wallet
`application” to the midlet, Dua’s secure value card extension (“SVCE”) to
`
`15
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`the e-purse applet, Dua’s Wireless Credential Manager (“WCM”) to the e-
`purse SAM, and Philips’s MIFARE emulator to the claimed emulator. Id. at
`19. Petitioner also contends that Dua and GlobalPlatform “disclose types of
`two-level security.” Id.
`Specifically, as to the preamble of claim 1, Petitioner contends that
`Dua discloses “wireless devices (portable devices)” including “a wallet
`application capable of transmitting multiple payment, identification and
`other information electronically for commerce.” Id. (citing Ex. 1004 ¶¶ 2,
`15, 41, 107, 313, 405, Figs. 1, 3, 8 (wireless devices 200, 400, 800)
`(quotation omitted)). Petitioner also relies on Dua for teaching “an e-purse
`applet to cause the portable device to function as an electronic purse (e-
`purse)” (limitation [1b]), id. at 21–22 (citing Ex. 1004 ¶¶ 216, 288–296, 345,
`363, 368, 543; Ex. 1003 ¶¶ 138–142 (citing Ex. 1015, 1; Ex. 1017; Ex. 1018,
`14:6–18; Ex. 1027, 24)), and “a purse manager midlet being executed in the
`portable device to act as an agent to facilitate communications between the
`e-purse applet and a payment server to conduct transactions therebetween”
`(limitation [1f]), id. at 39–43 (citing Ex. 1004 ¶¶ 40–41, 43–44, 50–51, 57,
`93–110, 216, 253, 255–256, 290, 293–294, 309, 311, 323–335, 398, 422,
`498–502, 508, Figs. 1, 3, 4, 8, claim 50; Ex. 1003 ¶¶ 83–87, 175, 178–184,
`185; Ex. 1001, 5:11–13, 20–22; Ex. 1008, 650–652, 681–683, 694–697).
`Next, Petitioner relies on the combination of Dua and Philips for “an
`emulator loaded in a smart card module for storing security values and
`updated transaction logs” (limitation [1a]), and for the interfaces to perform
`electronic commerce (limitation [1d]) and mobile commerce (limitation
`[1e]). Id. at 20–21, 34–39. Specifically, as to limitation [1a], Petitioner
`contends that “it was obvious to employ a Philips’s SmartMX card as Dua’s
`
`16
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`smart card,” id. at 20 (citing Pet. at 15–19), and that an ordinarily skilled
`artisan “knew that a standard (classic) MIFARE® transaction involved the
`use of encryption keys to update the stored purse balance in the card (storing
`security values) as well as updating a transaction log,” id. (citing Ex. 1003
`¶¶ 134–135 (citing Ex. 1019, 199, 201; Ex. 1008, 487–488), ¶ 136 (citing
`Ex. 1008, 692–693, 706–707)).
`As to limitation [1d]—“a first interface configured to perform field
`communication (NFC) with a reader to perform electronic commerce with
`the e-purse applet against a fund stored in the emulator”—Petitioner
`contends that “Dua’s wireless devices have RFID contactless interfaces for
`completing transactions using Near Field Communication (NFC) technology
`to transfer information to a reader device.” Id. at 35 (citing Ex. 1004 ¶¶ 16,
`41, 296, 315, 336 (quotation omitted)). Petitioner contends that Dua’s
`SVCEs are e-purse applets that may be used for subway fare, that Philips’s
`“MIFARE® hardware and emulator are specifically designed for the same
`purpose,” and that Dua teaches integrating existing technology, such as
`Philips’s MIFARE hardware and emulator, into Dua’s portable device to
`extend the capability of the wallet application. Id. at 36–37 (citing Ex. 1004
`¶¶ 288–289, 293–295, 368; Ex. 1012, 2; Ex. 1030, 43–44; Ex. 1031, 32:23–
`38; Ex. 1003 ¶¶ 168–170)). Petitioner contends that an ordinarily skilled
`artisan “would want Dua’s SVCE to communicate with the Philips
`MIFARE® emulator to ‘extend’ the capability of the wallet application to
`MIFARE® ‘in order to handle new features and capabilities that are specific
`to an issuer’s credential,’ e.g., communication with a MIFARE® reader.”
`Id. at 37 (citing Ex. 1003 ¶¶ 168–170). And, because Dua teaches that
`certain payment methods, such as subway stored value cards, may be
`
`17
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`organization specific and the only method of payment accepted, Petitioner
`contends that an ordinarily skilled artisan would understand that Dua’s
`SVCE would perform e-commerce against a fund stored in the emulator via
`RFID. Id. at 37–38 (citing Ex. 1004 ¶¶ 11, 290, 293, 296, 315, 336;
`Ex. 1012, 3; Ex. 1003 ¶¶ 171–172).
`As to limitation [1e]—“a second interface configured to perform
`mobile commerce with a payment server via an application against the fund
`stored in the emulator”—Petitioner contends that “Dua’s devices also
`include hardware for m-commerce, including hardware to facilitate SIP
`communications with a remote server over a wireless network.”4 Id. at 36
`(citing Ex. 1004 ¶¶ 41–42, 323, Figs. 1, 3, 8). And Petitioner contends that
`“one obvious type of m-commerce would be a MIFARE® over-the-air
`reload, which involves contacting a ‘remote server,’ i.e., a payment server
`‘over a wireless network’ using appropriate software applications.” Id. at 38
`(citing Ex. 1003 ¶ 169–173; Ex. 1008, 694–697).
`Next, Petitioner relies on the combination of Dua, GlobalPlatform,
`and Philips to account for the claimed personalization process (limitation
`[1c]). Id. at 23–34. At the outset, Petitioner contends that “well before the
`’787 patent, ‘personalizing’ smart card applications was ubiquitous and
`well-known to” an ordinarily skilled artisan, id. at 23 (citing Ex. 1006, 88–
`89; Ex. 1008, 598, Fig. 10.1; Ex. 1001, 4:22–32, 4:52–57, 5:61–63), and that
`an ordinarily skilled artisan would have known that the personalization
`process “involves, inter alia, creating cryptographic keys to ensure secure
`communication,” id. (citing Pet. 1–2). Petitioner also contends that, in any
`
`
`4 “SIP” refers to a “Session Initiation Protocol.” Ex. 1004 ¶ 42.
`
`18
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`event, “Dua in view of GlobalPlatform and Philips disclose and render
`obvious this limitation in two different ways.” Id.
`As to the “first way,” Petitioner contends that “[i]t is obvious to use
`GlobalPlatform with Dua’s smart cards and extensions (e.g., SVCEs),” and
`“[t]o install and use Dua’s SVCE in a smart card, the extension must be
`paired with a GlobalPlatform Security Domain.” Id. at 23–24 (citing Pet.
`15–19; Ex. 1006, 30, 44; Ex. 1003 ¶¶ 144–147). Petitioner contends that an
`ordinarily skilled artisan would have utilized GlobalPlatform’s Application
`Provider Security Domain (“APSD”) as the security domain for Dua’s
`SVCE (e-purse applet), “because [APSD] allows ‘the use of keys that are
`completely isolated’ from other entities.” Id. at 25 (citing Ex. 1006, 30, 86
`(quotation omitted)).
`Petitioner contends that, after the APSD is downloaded and installed,
`“a personalization process built on a first security channel is conducted to
`provide sets of keys for subsequent data access authentication.” Id. at 26
`(citing Ex. 1006, 47–48, 87–88). Petitioner contends that both
`GlobalPlatform and Philips describe the use of triple DES keys for
`cryptographic communications, and that an ordinarily skilled artisan would
`have known that these keys must be personalized in order for Philips’s
`MIFARE emulator to operate over a GlobalPlatform Secure Channel and for
`protection against unauthorized access. Id. (citing Ex. 1006, 88, 185, 195–
`196, 203, 219; Ex. 1012, 1, 5, 7; Ex. 1003 ¶¶ 149–150; Ex. 1019, 199, 201).
`Thus, Petitioner contends, the prior art teaches an emulator “already
`personalized 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,” as claimed in limitation [1c]. Id. (citing Ex. 1003 ¶ 150).
`
`19
`
`
`
`IPR2022-00412
`Patent 9,189,787 B1
`
`
`As to the claimed personalization of the e-purse, Petitioner also
`contends that Dua’s SVCE would “need to obtain its personalization data,
`including its own keys and Cardholder-specific data.” Id. at 27 (quoting
`Ex. 1006, 88). Petitioner contends that, “[a]fter the APSD is loaded,
`installed, and personalized,