throbber
Trials@uspto.gov
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket