throbber
Trials@uspto.gov
`571-272-7822
`
`Paper 10
`Entered: December 15, 2021
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SAMSUNG ELECTRONICS AMERICA, INC. and
`SAMSUNG ELECTRONICS CO., LTD.,
`Petitioner,
`v.
`RFCYBER CORP.,
`Patent Owner.
`
`IPR2021-00981
`Patent 9,240,009 B2
`
`
`
`
`
`
`
`
`
`Before PATRICK R. SCANLON, KEVIN W. CHERRY, and
`KRISTI L. R. SAWERT, Administrative Patent Judges.
`CHERRY, Administrative Patent Judge.
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`INTRODUCTION
`I.
`Samsung Electronics America, Inc. and Samsung Electronics Co.,
`Ltd. (“Petitioner”) filed a petition to institute inter partes review of
`claims 1–17 of U.S. Patent No. 9,240,009 B2 (Ex. 1001, “the ’009 patent”).
`Paper 1 (“Pet.”). RFCyber Corp. (“Patent Owner”) filed a Preliminary
`Response. Paper 6 (“Prelim. Resp.”). On our authorization, Petitioner filed
`a Reply to Patent Owner’s Preliminary Response. Paper 8 (“Reply”). Patent
`Owner filed a Sur-Reply. Paper 9 (“Sur-Reply”).
`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”).
`Applying those standards, and upon considering the Petition, the
`Preliminary Response, the Reply, the Sur-Reply, and the evidence of record,
`we determine the information presented shows a reasonable likelihood that
`
`2
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`Petitioner would prevail in establishing the unpatentability of at least one of
`the challenged claims of the ’009 patent. Accordingly, we institute an inter
`partes review of all challenged claims (i.e., claims 1–17) of the ’009 patent,
`based 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 ’009 patent: 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; Paper 4, 1–2 (Patent Owner’s Mandatory Notices).
`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); 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
`4, 1. Petitioner also identifies the following Board proceedings involving
`the ’009 patent or related patents, filed by petitioner: 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.
`B. Real Parties in Interest
`Petitioner identifies its real parties in interest as Samsung Electronics
`America, Inc. and Samsung Electronics Co., Ltd. Pet. 2.
`
`3
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`Patent Owner identifies RFCyber Corp. as its real party in interest.
`Paper 4, 1.
`C. Overview of the ’009 patent
`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, (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
`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 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
`
`4
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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.
`
`
`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. According to the
`’009 patent, “SE 102 enables mobile device 100 to perform financial
`transaction, transport ticketing, loyalty, physical access control, and other
`
`5
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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
`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
`
`6
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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 (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
`
`7
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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 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 an SAM (Security Authentication Module) or
`backend servers. Id. at 10:9–13. During 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.
`D. The Challenged Claims
`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;
`[1c] a memory space for storing at least a module and an
`application downloaded from the network;
`
`8
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`[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.
`E. Evidence
`Petitioner submits the following evidence:
`Evidence
`Declaration of Gerald W. Smith
`Dua, US 2006/0160060 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”)
`
`Exhibit No.
`1003
`1004
`
`1006
`
`1008
`
`1041
`
`9
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`F. Asserted Ground of Unpatentability
`Petitioner asserts the following grounds of unpatentability:
`Claim(s) Challenged
`35 U.S.C. §
`Reference(s)
`1–6, 13–17
`1031
`Dua, GlobalPlatform
`Dua, GlobalPlatform, Smart
`7–10
`103
`Card Handbook
`Dua, GlobalPlatform, Smart
`Card Handbook, Thibadeau
`
`11–12
`
`103
`
`Pet. 6. Patent Owner disputes Petitioner’s asserted grounds of
`unpatentability. See generally Prelim. Resp.
`III. PATENTABILITY ANALYSIS
`Petitioner contends that claims 1–6 and 13–17 of the ’009 patent are
`unpatentable under 35 U.S.C. § 103 as obvious over Dua in view of
`GlobalPlatform, claims 7–10 are unpatentable under 35 U.S.C. § 103 as
`obvious over Dua in view of GlobalPlatform and Smart Card Handbook, and
`claims 11 and 12 are unpatentable under 35 U.S.C. § 103 as obvious over
`Dua in view of GlobalPlatform, Smart Card Handbook, and Thibadeau.
`Pet. 6.
`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
`
`
`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 effective filing date” to “resolve
`Petitioner’s challenge.” Pet. 6. 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
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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.2 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
`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).
`
`
`2 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.
`
`11
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`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 ’009 patent “would have
`been knowledgeable regarding mobile payment methods and systems
`pertinent to the ’009 patent. Pet. 10. 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. at 10–11
`(citing Ex. 1003 ¶¶ 28–29). Patent Owner states that it “utilizes Petitioner’s
`proposed level of skill in the art,” but only for its Preliminary Response.
`Prelim. Resp. 7.
`Based on this record, we adopt Petitioner’s articulation of the level of
`ordinary skill in the art, which is consistent with the ’009 patent and the
`asserted prior art, and we apply it in our obviousness evaluations below. See
`
`12
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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
`’009 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).”
`See 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 it applies “the plain and ordinary meaning to
`the claims as no specific constructions are required to resolve the grounds
`presented in this Petition.” Pet. 11. Patent Owner argues that “claim
`construction is not required to resolve any issues” at this point in the
`proceeding. Prelim. Resp. 7.
`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.
`
`13
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`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
`specifies the card architecture, security architecture, Life Cycle models for
`
`14
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`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.
`Ex. 1041 ¶¶ 91, 99; Ex. 1003 ¶¶ 94–96.
`D. Alleged Ground of Unpatentability 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
`
`15
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`GlobalPlatform. Pet. 18–54. Patent Owner opposes. Prelim. Resp. 7–15.
`Having considered the arguments and evidence before us, we determine that
`the record establishes a reasonable likelihood that Petitioner would prevail
`on this asserted ground of unpatentability.
`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. 18–19 (citing Ex. 1004 ¶¶ 41, 2, 15, 107, 313, 405, Figs. 1,
`3, 8 (wireless devices 200, 400, 800 and wireless device interfacing with
`communications tower); Ex. 1003 ¶¶ 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. 19–23
`(citing Ex. 1004 ¶¶ 7, 8, 14, 215, 293, 295, 309; Ex. 1003 ¶¶ 113–115, 118–
`124, 128–130; Ex. 1006, 29 (§ 3.2), 31 (§ 3.5), 39 (5.1.1.1), 62 (§ 6.4.1), 65
`(§ 6.4.1.2); Ex. 1008, 53, 55, 735–786, 963; Ex. 1012, 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 23–32. 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 23–25
`(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,
`
`16
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`650; Ex. 1012, 6 (SmartMX P5CT072 Secure Dual Interface PKI Smart
`Card Controller Specification (4 Oct. 2004)). Petitioner argues that Dua,
`either alone or combination with GlobalPlatform, account for the operation
`of “wherein the application is downloaded from the network in the mobile
`device” (limitation [1dii]). Id. at 25–26 (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
`26–27 (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 prepared data necessary for the application to
`function as designed on the mobile device” (limitation [1div]). Id. at 28–29
`(citing Ex. 1004 ¶¶ 26, 57, 58, 148, 215, 297; Ex. 1003 ¶¶ 147, 148;
`Ex. 1006, 44, 65–66, 88, 102). Finally, 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 29–32 (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
`
`17
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`standards being developed that a person of ordinary skill would recognize as
`including GlobalPlatform. Pet. 16–17. 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 17 (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 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. (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. at 17–18 (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. at 18.
`At this stage, Patent Owner disputes whether the combination
`accounts for limitation [1div]—“wherein the server is configured to prepare
`
`18
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`data necessary for the application to function as designed on the mobile
`device”—and whether Petitioner has shown an adequate motivation to
`combine Dua and GlobalPlatform. Prelim. Resp. 7–15.
`As to the undisputed limitations claim 1, we have reviewed
`Petitioner’s cited evidence and explanation, and find it sufficient at this
`stage. We will focus our analysis on the elements of Petitioner’s case that
`Patent Owner currently disputes.
`With respect to limitation [1div], Patent Owner argues that Petitioner
`identifies Dua’s Wireless Credential Manager (“WCM”) as the “server” of
`the claims, the Personalization File, which the WCM receives from the
`issuer’s card management system, as the “data,” and Dua’s extensions as the
`claimed “application” for claim 1 or the “module” for claim 14. Prelim.
`Resp. 8. Patent Owner argues, however, that the Personalization File cannot
`be the claimed data of limitation [1div] because “Dua explains that the
`Personalization File is for the wallet application itself, not for any
`extensions.” Id. at 9 (citing Ex. 1004 ¶¶ 57–63). Patent Owner also argues
`that Petitioner “does not identify any disclosure that the Personalization File
`is ‘prepared by’ the WCM; the WCM merely receives the file and forwards
`it to the user’s device.” Id.
`We disagree with Patent Owner on this record and determine that
`Petitioner has adequately shown that Dua accounts for limitation. As an
`initial matter, contrary to one of Patent Owner’s contentions, the
`Personalization File does contain data used by the extensions. The
`Personalization File contains credentials. Ex. 1004 ¶ 57. The credentials
`contains various data. Id. ¶¶ 297–307. Among those data is an
`
`19
`
`

`

`IPR2021-00981
`Patent 9,240,009 B2
`
`
`Identifier to extension to which the credential is associated
`(When a credential is selected by a user this identifier is used to
`launch an extension in the wallet application)[.]
`Id. ¶ 306; see also Ex. 1004 ¶ 293 (explaining extensions are “mini-
`programs that operate within the wallet application” and which “extend”
`“the capability of the wallet application in order to handle new features and
`capabilities that are specific to an issuer’s credential” (emphasis added));
`Ex. 1003 ¶¶ 120, 147. Thus, on this record, we do not agree that the
`Personali

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