`571-272-7822
`
`Paper 33
`Entered: July 18, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`v.
`RFCYBER CORP.,
`Patent Owner.
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`
`
`
`
`
`
`
`Before KEVIN F. TURNER, PATRICK R. SCANLON, and
`KEVIN W. CHERRY, Administrative Patent Judges.
`CHERRY, Administrative Patent Judge.
`
`JUDGMENT
`Final Written Decision
`Determining All Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`INTRODUCTION
`I.
`This is a Final Written Decision in an inter partes review challenging
`the patentability of claims 1–17 (collectively, “the challenged claims”) of
`U.S. Patent No. 9,240,009 B2 (“the ’009 patent,” Ex. 1001). We have
`jurisdiction under 35 U.S.C. § 6. We issue this Final Written Decision under
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons that follow, we
`determine that Petitioner demonstrates, by a preponderance of the evidence,
`that claims 1–17 are unpatentable.
`Procedural History
`A.
`Apple Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting
`an inter partes review under 35 U.S.C. § 311. RFCyber Corp. (“Patent
`Owner”) filed a Preliminary Response (Paper 9, “Prelim. Resp.”). On July
`21, 2022, we instituted an inter partes review of the challenged claims.
`Paper 12 (“Institution Decision” or “Dec.”).
`Following institution, Patent Owner filed a Response (Paper 16, “PO
`Resp.”), Petitioner filed a Reply (Paper 23, “Reply”), and Patent Owner filed
`a Sur-reply (Paper 25, “Sur-reply”).
`We heard oral argument on April 21, 2023, and the record includes a
`transcript of the argument. Paper 32 (“Tr.”).
`Related Matters
`B.
`The parties identify the following district-court proceedings as related
`matters involving the ’009 patent: RFCyber Corp. v. Apple, Inc., Case No.
`6:21-cv-00916-ADA (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. 2–3; Paper 6, 1 (Patent Owner’s Mandatory Notices).
`
`2
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`The parties also identify the following Board proceedings involving
`petitioner Google LLC and related patents: IPR2021-00954 (U.S. Patent
`No. 8,448,855 B1); IPR2021-00955 (U.S. Patent No. 9,189,787 B1);
`IPR2021-00956 (U.S. Patent No. 9,240,009 B2); IPR2021-00957 (U.S.
`Patent No. 8,118,218 B2); IPR2021-00978 (Patent No. 8,448,855);
`IPR2021-00979 (Patent No. 8,118,218); IPR2021-00980 (Patent No.
`9,189,787); PGR2021-00028 (U.S. Patent No. 10,600,046 B2); and
`PGR2021-00029 (U.S. Patent No. 10,600,046 B2). Pet. 2–3; Paper 6, 1.
`Petitioner also identifies the following Board proceedings involving the ’009
`patent or related patents, filed by Samsung Electronics America, Inc. et al.:
`IPR2021-00978 (U.S. Patent No. 8,448,855 B1); IPR2021-00979 (U.S.
`Patent No. 8,118,218 B2); IPR2021-00980 (U.S. Patent No. 9,189,787 B1);
`and IPR2021-00981 (U.S. Patent No. 9,240,009 B2). Pet. 3–4; Paper 4, 2–3.
`Real Parties in Interest
`C.
`Petitioner identifies its real party in interest as Apple Inc. Paper 11
`(Petitioner’s Updated Mandatory Notice), 2.
`Patent Owner identifies RFCyber Corp. as its real party in interest.
`Paper 6, 1.
`
`The ’009 Patent (Ex. 1001)
`D.
`The ’009 patent relates to commerce over networks, and more
`specifically, techniques for personalizing a secure element and provisioning
`an application such as an electronic purse that can be used in portable
`devices configured for both electronic commerce (a.k.a., e-commerce) and
`mobile commerce (a.k.a., m-commerce). Ex. 1001, code (57), 1:18–24.
`The ’009 patent states that there is a “need to provide techniques to
`personalize a secure element in a contactless smart card or an NFC (Near
`
`3
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`Field Communication)-enabled mobile device so that such a device is so
`secured and personalized when it comes to financial applications or secure
`transactions.” Id. at 2:10–14. 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 any data can be accessed during a transaction.” Id. at
`1:33–40. According to the ’009 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/or wireless networks
`for m-commerce as the delivery of keys over a public domain network
`causes security concerns.” Id. at 1:40–44. The ’009 patent purports to
`overcome the limitations of the prior art by providing “techniques for
`personalizing secure elements in NFC devices to enable various secure
`transactions over a network (wired and/or wireless network).” Id. at 2:31–
`34.
`
`Figure 1A, reproduced below, provides a schematic view of one
`embodiment of the ’009 patent.
`
`4
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`
`FIG. 1A shows a simplified architecture diagram of computing
`device 100 according to one embodiment of the ’009 patent.
`Ex. 1001, 4:35–36.
`As shown in Figure 1A, mobile device 100 includes near field
`communication (NFC) controller 101 that enables device 100 to interact
`with another device wirelessly to exchange data with. Id. at 6:40–42. A
`user may use mobile device 100 as an e-purse or a wallet to pay for a
`purchase or an admission. Id. at 6:43–44. In operation, the e-purse is
`controlled by secure element (SE) 102. Id. at 6:44–46. SE 102 may take the
`form of a smart card, an integrated circuit (IC), or a software module,
`upgradable by overwriting some of all of the components. Id. at 6:59–61.
`“In one embodiment, the SE 102 is a tamper proof Smart Card chip capable
`to embed smart card-grade applications (e.g., payment, transport ...) with the
`required level of security and features.” Id. at 6:61–64.
`
`5
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`According to the ’009 patent, “SE 102 enables mobile device 100 to
`perform financial transaction, transport ticketing, loyalty, physical access
`control, and other exciting new services in a secured manner.” Id. at 6:46–
`49. To offer such services, the SE 102 is configured to support various
`applets, applications or modules (e.g., Applet 104 and E-Purse Application
`106). Id. at 6:49–51.
`When a mobile device is first purchased by or delivered to a customer,
`SE 102 in the mobile device is installed with a set of default keys (e.g., an
`Issuer Security Domain (ISD) key set by the SE manufacturer). Id. at 6:55–
`58. In one embodiment, SE 102 is or includes a software module loaded in
`secured memory space 107 in mobile device 100. Id. at 7:7–9. The software
`module may be updated by downloading updating components from a
`designated server using network interface 103 (e.g., a 3G network or an LTE
`network) in mobile device 100. Id. at 7:9–12.
`SE 102 needs to go through a personalization or provisioning process
`before it can be used. Id. at 7:13–18. According to one embodiment, the
`provisioning is performed over the air (“OTA”) to cause the SE to be
`personalized while installing an application or enabling a service (i.e.,
`application installation and personalization). Id. at 7:18–22. Applications
`are available for an NFC-enabled mobile device to download from a server
`or a TSM portal—a TSM, standing for Trusted Service Management, is a
`collection of services. Id. at 7:32–36.
`The provisioning process in the preferred embodiment proceeds as
`follows. First, the customer registers his/her mobile phone via a server
`(often TSM web portal). Id. at 7:61–62. The TSM server is configured to
`push a universal resource identifier (“URI”) of a provisioning manager to the
`
`6
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`registered mobile phone. Id. at 7:62–65. The customer can download the
`provisioning manager into the mobile device and start the personalization
`process. Id. at 7:65–66. The server uses information from the device, such
`as its serial number, to confirm that the device is genuine. Id. at 8:4–20.
`Once verified, the device then communicates and is registered with the
`server. Id. at 8:20–27. Once the device becomes part of the system, various
`services or data may be communicated to the device via the network. Id. at
`8:27–29. As part of the personalization process, the server requests device
`information of the SE, including the Issuer Security Domain information for
`this SE. Id. at 8:29–42.
`The device information is used to facilitate the generation of a set of
`keys. Id. at 8:63–65. The server is configured to establish a secured channel
`using the default ISD between its hardware security module (HSM) and the
`SE. Id. at 8:65–67. The server is also configured to compute a derived key
`set for the SE. Id. at 8:67–9:1. A master ISD key may be housed in a
`hardware security module (HSM) associated with the server or in a local
`HSM of the SE issuer. Id. at 9:2–9. If the master ISD key is housed in the
`HSM of the server, the server is configured to instruct the HSM to compute
`the derived key set. Id. at 9:9–11. If the master ISD key of the SE issuer is
`in a local HSM of the SE issuer, the server is configured to interact with the
`remote HSM to retrieve the keys. Id. at 9:13–16.
`The set of keys is securely delivered to the SE. Id. at 9:18. The set of
`keys is thus personalized to the SE and will be used for various secured
`subsequent operations or services with the device. Id. at 9:18–21.
`SE 102 of Figure 1A may be perceived as a preload operating system in a
`Smart card, providing a platform for PIN management and security channels
`
`7
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`(security domains) for card personalization. Id. at 9:62–65. According to
`the ’009 patent, “SE 102 combines the interests of smart card issuers,
`vendors, industry groups, public entities and technology companies to define
`requirements and technology standards for multiple applications running in
`the smart cards.” Id. at 9:65–10:2. As an example, the ’009 patent describes
`one module 104, referred to as an e-purse security, that defines a set of
`protocols that enable micro payment transactions to be carried out in both
`wired and wireless environments. Id. at 10:3–6. With an electronic purse
`(a.k.a., e-purse) stored on a smart card, a set of keys (either symmetric or
`asymmetric) is personalized into the e-purse after the e-purse is issued. Id.
`at 10:6–9. During a transaction, the e-purse uses a set of respective keys for
`encryption and MAC computation in order to secure the message channel
`between the e-purse and a SAM (Security Authentication Module) or
`backend servers. Id. at 10:9–13. During the personalization or provisioning
`process described above, the single functional card access keys (or its
`transformation) are personalized into the e-purse with the e-purse transaction
`keys. Id. at 10:13–18.
`
`Illustrative Claim
`E.
`Petitioner challenges claims 1–17 of the ’009 patent. Pet. 1. Of the
`challenged claims, claims 1 and 14 are independent. Claim 1, reproduced
`below, is illustrative of the subject matter recited in the challenged claims
`(bracketing added).
`[1.PREAMBLE] A mobile device for conducting a
`secured transaction over a network, the mobile
`device comprising:
`[1a] a network interface;
`[1b] an interface to receive a secure element;
`
`8
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`[1c] a memory space for storing at least a module and an
`application downloaded from the network;
`[1d] a processor coupled to the memory space and
`configured to execute the module to perform
`operations including:
`[1di] sending to a server via the network interface an
`identifier identifying the application together with
`device information of a secure element, [1dii]
`wherein the application is downloaded from the
`network in the mobile device;
`[1diii] establishing a secured channel between the secure
`element and the server using a key set installed on
`the secure element, [1div] wherein the server is
`configured to prepare data necessary for the
`application to function as designed on the mobile
`device; and
`[1dv] receiving the data from the server to associate the
`application with the secure element, [1dvi]
`wherein the application subsequently functions in
`conjunction with the secure element.
`
`Id. at 24:16–36.
`Testimonial and Prior Art Evidence
`F.
`Petitioner submits the following evidence:
`Evidence
`Declaration of Gerald W. Smith (“Smith Decl.”)
`Dua, US 2006/0165060 A1 (published July 27, 2006, filed
`Jan. 21, 2005) (“Dua”)
`GlobalPlatform Card Specification Version 2.1.1 (March
`2003) (“GlobalPlatform” or “GP”)
`Smart Card Handbook Third Edition, by Wolfgang Rankl
`and Wolfgang Effing (2003) (“Smart Card Handbook”)
`U.S. Patent Application Publication No. 2006/0174352 A1
`(published August 3, 2006, filed January 31, 2006)
`(“Thibadeau”)
`Miguel Gomez Deposition Transcript, dated
`
`Exhibit No.
`1003
`1004
`
`1006
`
`1008
`
`1041
`
`1045
`
`9
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`Exhibit No.
`
`1046
`
`Evidence
`February 7, 2023 (“Gomez Tr.”)
`Supplemental Declaration of Gerald W. Smith (“Smith
`Supp. Decl.”)
`
`Patent Owner submits the following testimonial evidence:
`Evidence
`Exhibit No.
`Declaration of Miguel Gomez (“Gomez Decl.”)
`2007
`Deposition Transcript of Gerald W. Smith, taken
`2009
`November 14, 2022 (“Smith Tr.”)
`
`
`
`Asserted Unpatentability Challenges
`G.
`We instituted an inter partes review of the challenged claims on the
`following grounds of unpatentability:
`Claims Challenged
`35 U.S.C. §1
`1–6, 13–17
`103(a)
`7–10
`103(a)
`
`11–12
`
`103(a)
`
`
`
`References/Basis
`Dua, GlobalPlatform
`Dua, GlobalPlatform, Smart
`Card Handbook
`Dua, GlobalPlatform, Smart
`Card Handbook, Thibadeau
`
`
`1 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. The ’009 patent claims benefit
`of a September 24, 2006, filing date, which is before the effective date of the
`applicable AIA amendments. Ex. 1001, (63). Petitioner states that the
`“Board may presume that the effective filing date” to “resolve Petitioner’s
`challenge.” Pet. 7. Thus, we refer to the pre-AIA version of 35 U.S.C.
`§ 103. Our decision would be the same were we to apply the AIA version of
`the statute.
`
`10
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`II. ANALYSIS
`Legal Standards
`A.
`To prevail in its challenge, Petitioner must demonstrate by a
`preponderance of the evidence that the claims are unpatentable. 35 U.S.C.
`§ 316(e); 37 C.F.R. § 42.1(d) (2020). A 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 of the invention to a person having ordinary skill in the
`art. 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 skill in
`the art; and (4) objective evidence of nonobviousness, i.e., secondary
`considerations. See Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966).
`Subsumed within the Graham factors is the requirement that the skilled
`artisan would have had a reasonable expectation of success in combining the
`prior art references to achieve the claimed invention. Pfizer, Inc. v. Apotex,
`Inc., 480 F.3d 1348, 1361 (Fed. Cir. 2007). “Obviousness does not require
`absolute predictability of success. . . . [A]ll that is required is a reasonable
`expectation of success.” In re O’Farrell, 853 F.2d 894, 903–04 (Fed. Cir.
`1988).
`Moreover, “[the] combination of familiar elements according to
`known methods is likely to be obvious when it does no more than yield
`predictable results.” KSR, 550 U.S. at 416. “If a person of ordinary skill can
`implement a predictable variation, . . . § 103 likely bars its patentability.”
`Id. at 417.
`
`11
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`Level of Ordinary Skill in the Art
`B.
`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 ’009 patent “would have
`been knowledgeable regarding mobile payment methods and systems
`pertinent to the ’009 patent.” Pet. 9. Petitioner also contends that an
`ordinarily skilled artisan “would have had at least a bachelor’s degree in
`computer science, computer engineering, electrical engineering or an
`equivalent, and about one year of professional experience relating to mobile
`payment technology, which would have exposed them to concepts like
`GlobalPlatform and smart cards” and that “[l]ack of professional experience
`[can] be remedied by additional education, and vice versa.” Id. (citing
`Ex. 1003 (Smith Decl.) ¶¶ 28–29).
`In its Patent Owner Response, Patent Owner asserts that “[a] person of
`ordinary skill in the art would have a Bachelor’s degree in Computer
`Science, Computer Engineering, or Applied Mathematics, with 2 or more
`years of academic or industry experience in computer security, network
`
`12
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`security or mobile payment technology.” PO Resp. 7 (citing Ex. 2007
`(Gomez Decl.) ¶¶ 32-33).
`In its Reply, Petitioner argues that Patent Owner removes the
`requirement that a person of ordinary skill in the art have mobile payment
`experience. Reply 2. Petitioner asserts that experience with mobile
`payments is required for a person of ordinary skill in the art. Id. at 3 (citing
`Ex. 1046 (Smith Supp. Decl.) ¶¶ 4–10).
`Patent Owner further argues that “Patent Owner’s proposal, which has
`a greater experience requirement than Petitioner’s, addresses that the
`claimed arrangement of security features, such as ‘device information of a
`secure element’ and ‘secured channel[s] between the secure element and the
`server using a key set installed on the secure element,’ among others.” Sur-
`reply 3.
`Here, the parties’ definitions differ in one significant way. Petitioner
`requires one year of more specific experience, i.e., mobile payment
`experience, while Patent Owner requires more experience, but that
`experience can be more general related to computer and network security.
`We agree with Petitioner that mobile payment technology is an important
`aspect of the claimed invention and should be included in the definition.
`However, we also find that Petitioner’s definition is flexible enough to
`address the concerns of Patent Owner because, as the definition explains
`“[l]ack of professional experience [can] be remedied by additional
`education, and vice versa.” Petitioner’s articulation of the level of ordinary
`skill in the art is consistent with the ’009 patent and the asserted prior art,
`
`13
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`and we apply it in our obviousness evaluations below. 2 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).
`C. Claim Construction
`In an inter partes review, we construe claims “in accordance with the
`ordinary and customary meaning of such claim as understood by one of
`ordinary skill in the art and the prosecution history pertaining to the patent.”
`37 C.F.R. § 42.100(b). Furthermore, we expressly construe the claims only
`to the extent necessary to resolve the issues presented in this case. See Nidec
`Motor Corp. v. Zhongshan Broad Ocean Motor Co. Ltd., 868 F.3d 1013,
`1017 (Fed. Cir. 2017) (“[W]e need only construe terms ‘that are in
`controversy, and only to the extent necessary to resolve the controversy.’”
`(quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803
`(Fed. Cir. 1999))). We find that no express constructions are necessary for
`this decision.
`
`
`2 As for Petitioner’s argument that we should disregard Mr. Gomez’s
`testimony entirely because he lacks sufficient experience in mobile payment
`technology, Reply 2–3, we decline to do so. Mr. Gomez testifies that he has
`extensive experience with online and mobile commerce based on his
`professional experience developing hardware, software, and protocols used
`in online and mobile commerce. See Ex. 1045, 14:1–24. Given the flexible
`definition of a person of ordinary skill in the art, we find Mr. Gomez’s
`lengthy experience sufficient for him to qualify to testify. However,
`although we will not dismiss his testimony out of hand, we will still consider
`each part of his testimony and the reasoning and support he provides before
`assigning weight to that testimony. See Xerox Corp. v. Bytemark, Inc.,
`IPR2022-00624, Paper 9, 15 (PTAB Aug. 24, 2022)
`(precedential).
`
`14
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`D. Overview of the Prior Art
`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, code (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.”
`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
`
`15
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`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 ¶¶ 51–63.
`GlobalPlatform describes sequences of commands for installing,
`personalizing, and deleting applications on multi-application smart cards.
`Ex. 1006, 65–67, 88–90.
`3. Smart Card Handbook (Ex. 1008)
`Smart Card Handbook is a textbook by Wolfgang Rankl and
`Wolfgang Effing published by John Wiley & Sons. Among the many things
`it explains about smart cards, it describes card management systems that
`employ databases for holding data related to unique smart cards and data on
`the cards themselves. Ex. 1008, 251, 301, 600. Smart Card Handbook also
`discusses managing security keys on smart cards. Ex. 1008, 202–208.
`Smart Card Handbook explains that one technique for generating keys
`during personalization includes the use of a “card number” or “chip number”
`to generate an encryption key by a security module to secure the
`personalization data transmitted to the card. Id. at 645.
`4. Thibadeau (Ex. 1041)
`Thibadeau is a published U.S. patent application entitled “Method and
`Apparatus for Providing Versatile Services on Storage Devices.” Ex. 1041,
`(54). Thibadeau describes a way of storing “virtual smart cards” managed
`by “Card Operating System,” software “needed to interface into”
`standardized card environments such as GlobalPlatform-based smart cards.
`
`16
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`
`E. Unpatentability Grounds
`1. Alleged Obviousness of Claims 1–6 and 13–17 over Dua and
`GlobalPlatform
`Petitioner contends that claims 1–6 and 13–17 of the ’009 patent are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in view of
`GlobalPlatform. Pet. 14–52. Patent Owner opposes. PO Resp. 8–24; Sur-
`reply 6–19. Having considered the arguments and evidence before us, we
`determine that Petitioner has shown by a preponderance of the evidence that
`claims 1–6 and 13–17 would have been obvious over Dua in view of
`GlobalPlatform.
`a) Claim 1
`
`(1) Petitioner’s Contentions
`Petitioner contends that Dua discloses “[a] mobile device for
`conducting a secured transaction over a network, the mobile device
`comprising” (the [Preamble]) and “a network interface” (limitation [1a]) of
`claim 1. See Pet. 16–17 (citing Ex. 1004 (Dua) ¶¶ 41, 2, 15, 107, 313, 405,
`Figs. 1, 3, 8 (wireless devices 200, 400, 800 and wireless device interfacing
`with communications tower); Ex. 1003 (Smith Decl.) ¶¶ 107–109, 111).
`Petitioner relies on the combination of Dua and GlobalPlatform to account
`for “an interface to receive a secure element” (limitation [1b]), “a memory
`space for storing at least a module and an application downloaded from the
`network” (limitation [1c]), and “a processor coupled to the memory space
`and configured to execute the module to perform operations” (limitation
`[1d]). Pet. 17–21 (citing Ex. 1004 ¶¶ 7, 8, 14, 215, 293, 295, 309; Ex. 1003
`¶¶ 113–115, 118–124, 128–130; Ex. 1006 (GlobalPlatform), 29 (§ 3.2), 31
`(§ 3.5), 39 (5.1.1.1), 62 (§ 6.4.1), 65 (§ 6.4.1.2); Ex. 1008 (Smart Card
`
`17
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`Handbook), 53, 55, 735–786, 963; Ex. 10123, 1–2, 9; Ex. 1042, 168–69
`(’009 patent File History)). Petitioner also relies on Dua and GlobalPlatform
`to account for the operations performed by the processor (limitations [1di]–
`[1dvi]). Id. at 21–30. In particular, Petitioner contends that Dua in view of
`GlobalPlatform accounts for the operations of “sending to a server via the
`network interface an identifier identifying the application together with
`device information of a secure element” ([1di]). Id. at 21–23 (citing
`Ex. 1004 ¶¶ 41, 160, 179, Fig. 3; Ex. 1006, 18 (§ 1.3), 20 (§ 1.4), 81, 92–93
`(§ 7.6.2), 98 (§ 7.7.4); Ex. 1003 ¶¶ 132–136; Ex. 1008, 237, 257, 600, 650;
`Ex. 1012, 6). Petitioner argues that Dua, either alone or in combination with
`GlobalPlatform, accounts for the operation of “wherein the application is
`downloaded from the network in the mobile device” (limitation [1dii]). Id.
`at 23–24 (citing Ex. 1004 ¶¶ 104, 215, 289, 293; Ex. 1003 ¶ 138; Ex. 1008,
`650; Ex. 1014, 11 (ETSI Technical Specification 102 226 v6.12.0 (Sept.
`2005))). Petitioner asserts that the combination of Dua and GlobalPlatform
`accounts for the operation of “establishing a secured channel between the
`secure element and the server using a key set installed on the secure
`element” (limitation [1diii]). Id. at 24–26 (citing Ex. 1004 ¶¶ 201–205, 247;
`Ex. 1003 ¶¶ 98–105, 141–145; Ex. 1006, 29, 40, 53, 54, 218). Petitioner
`contends that Dua, either alone or in combination with GlobalPlatform,
`accounts for the operation of “wherein the server is configured to prepare
`data necessary for the application to function as designed on the mobile
`device” (limitation [1div]). Id. at 26–27 (citing Ex. 1004 ¶¶ 26, 57, 58, 148,
`215, 297; Ex. 1003 ¶¶ 147, 148; Ex. 1006, 44, 65–66, 88, 102). Finally,
`
`3 SmartMX, P5CT072 Secure Dual Interface PKI Smart Card Controller,
`Short Form Specification (Rev. 1.3 – 4 October 2004) (Ex. 1012).
`
`18
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`Petitioner relies on the combination of Dua and GlobalPlatform to account
`for the last two operations, “receiving the data from the server to associate
`the application with the secure element” (limitation [1dv]) and “wherein the
`application subsequently functions in conjunction with the secure element”
`(limitation [1dvi]). Id. at 28–30 (citing Ex. 1004 ¶¶ 18, 22, 26, 180, 215,
`247, 290, 293, 295, 296, 309, 318, 378; Ex. 1003 ¶¶ 148, 150–152, 155;
`Ex. 1006, 30, 65, 88, 89, 102).
`Petitioner argues that a person of ordinary skill would have been
`motivated to combine Dua and GlobalPlatform because Dua does not
`provide conventional smart card implementation details, but does refer to
`standards being developed that a person of ordinary skill would recognize as
`including GlobalPlatform. Pet. 14–16. Petitioner submits that
`“GlobalPlatform discloses ‘a hardware-neutral, vendor-neutral, Application-
`independent [smart] card management specification’ that provides a security
`architecture that protects the ‘structure and function of cards within the
`GlobalPlatform system’ for the life of the card—thus providing a ‘secure
`element’ as claimed.” Id. at 15 (citing Ex. 1006, 16, 32). Petitioner further
`notes that “Dua’s ‘wallet application should meet standards defined by card
`organizations,’ and GlobalPlatform was specifically developed by such card
`organizations.” Id. (citing Ex. 1004 ¶ 525; Ex. 1006, 16; Ex. 1003 ¶¶ 99–
`101). Thus, Petitioner contends that a person of ordinary skill would have
`been motivated and “would find it obvious to employ the well-known
`GlobalPlatform system with Dua’s smart cards.” Id. Petitioner provides
`another rationale that, because Dua describes using “a Java platform and
`Java applets” for wireless devices, the ordinary artisan would look to the
`JavaCard implementation described in GlobalPlatform, because
`
`19
`
`
`
`IPR2022-00413
`Patent 9,240,009 B2
`
`“GlobalPlatform ‘has primarily become the de facto standard for loading and
`managing Java-based applications with the Java Card operating system.[’]”
`Pet. 15–16 (citing Ex. 1008, p. 290).
`Petitioner further notes that Dua discloses the use of a Java platform
`and Java applets with its wireless devices, which a person of ordinary skill in
`the art would have recognized as being a reference to Java Card. Id.
`(Ex. 1004 ¶¶ 195, 500; Ex. 1003 ¶ 102). Petitioner submits that
`GlobalPlatform is designed to be compatible with Java Card. Id. at 16
`(citing Ex. 1006, 24, 29). Petitioner argues that “GlobalPlatform ‘has
`primarily become the de facto standard for loading and managing Java-based
`applications with the Java Card operating system.’” Id. (citing Ex. 1008,
`290). Petitioner argues that this “further confirms a [person of ordinary skill
`in the art] would be motivated to and would find it obvious to use
`GlobalPlatform with Dua’s smart cards.” Id.
`(2) Patent Owner’s Arguments
`Patent Owner raises several arguments regarding Petitioner’s
`contentions. PO Resp. 8–24. First, Patent Owner argues that that person of
`ordinary skill would not have combined Dua with GlobalPlatform. Id. at 8–
`18. Second, Patent Owner asserts that combination fails to account for the
`claimed “secure element.” Id. at 18–20. Finally, Petitioner contends that
`Dua fails to account for the claim limitation “wherein the server is
`configured to prepare data necessary for the application to function as
`designed on the mobile device.” Id. at 20–24.
`(3) Analysis
`With respect to the undisputed limitations, we have reviewed
`Petitioner’s contentions and evidence and find them sufficient. Therefore,
`
`20
`
`
`
`IPR2022-00413
`Paten