IPR2021-00956
`PATENT NO. 9,240,009
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`
`
`GOOGLE LLC,
`
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`Patent Owner.
`
`
`Patent No. 9,240,009
`Filing Date: January 16, 2012
`Issue Date: January 19, 2016
`
`Inventors: Liang Seng Koh, Hsin Pan, and Xiangzhen Xie
`Title: MOBILE DEVICES FOR COMMERCE OVER UNSECURERD
`NETWORKS
`
`
`__________________________________________________________________
`
`RFCYBER CORP.’S
`PRELIMINARY RESPONSE
`
`Case No. IPR2021-00956
`
`__________________________________________________________________
`
`
`
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`Page(s)
`
`
`INTRODUCTION .............................................................................................. 1
`I.
`II. THE ‘009 PATENT ........................................................................................... 1
`III. THE ALLEGED PRIOR ART ........................................................................... 5
`A. Staib (U.S. Patent Pub. No. 2005/0222961) ..................................................... 5
`B. Holtmanns (U.S. Patent No. 7,628,322) ........................................................... 7
`C. Wentker (U.S. Patent No. 6,481,632) ............................................................... 7
`IV. CLAIM CONSTRUCTioN ................................................................................ 8
`V. LEVEL OF ORDINARY SKILL IN THE ART ............................................... 8
`VI. PETITIONER HAS NOT SHOWN A REASONABLE LIKELIHOOD OF
`SUCCESS AS TO ANY CHALLENGED CLAIM .......................................... 8
`A. Requirements for Showing Obviousness Under 35 U.S.C. § 103 .................... 8
`B. Google’s Combination Fails To Disclose Or Render Obvious a “secure
`element” as required by all Challenged Claims ................................................ 9
`C. Google’s Combination Fails To Disclose Or Render Obvious “a memory
`space for storing … an application downloaded from the network” as
`required by Challenged Claims 1-13. .............................................................12
`D. Google’s Combination Fails to Disclose or Render Obvious “a memory space
`for storing various modules downloaded from the network” .........................16
`VII. THE PETITION SHOULD BE DENIED IN THE DISCRETION OF THE
`DIRECTOR UNDER 35 U.S.C. § 314(A) .......................................................17
`A. No Stay of the Parallel District Court Litigation ............................................19
`B. The Board’s Written Decision Deadline Will Come Long After The Trial
`Date .................................................................................................................20
`C. Significant Investment By The Time Of Institution Favors Discretionary
`Denial ..............................................................................................................21
`
`i
`
`

`

`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`D. The District Court Litigation Involves the Same Claims and the Same
`Arguments .......................................................................................................23
`E. The Parallel District Court Litigation and the Petition Involve the Same
`Parties ..............................................................................................................24
`F. Other Circumstances Favor Denial Of Institution ..........................................24
`VIII. CONCLUSION ...............................................................................................25
`
`
`ii
`
`

`

`
`
`TABLE OF AUTHORITIES
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
` Page(s)
`
`Cases
`AGIS Software Dev. LLC v. Google LLC,
`No. 2:19-cv-00361-JRG, 2021 WL 465424 (E.D. Tex. Feb. 9,
`2021) ................................................................................................................... 19
`In re Apple Inc.,
`979 F.3d 1332 (Fed. Cir. 2020) .......................................................................... 21
`Apple Inc. v. Fintiv, Inc.,
`IPR2020-00019, Paper 11 (P.T.A.B. Mar. 20, 2020) ............................. 17, 18, 23
`Cisco Sys., Inc. v. Ramot at Tel Aviv Univ. Ltd.,
`IPR2020-00122, Paper 15 (P.T.A.B. May 15, 2020) ......................................... 20
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) .................................................................................................. 8
`KSR Intern. Co. v. Telefex Inc.,
`550 U.S. 398 (2007) .............................................................................................. 9
`Next Caller Inc. v. TrustID, Inc.,
`IPR2019-00961, -00962...................................................................................... 20
`NHK Spring Co. v. Intri-Plex Techs., Inc.,
`IPR2018-00752, Paper 8 (P.T.A.B. Sept. 12, 2018)........................................... 19
`Personalized Media Commc’ns, LLC v. Google LLC,
`2:19-cv-00090-JRG, Dkt. No. 291 (E.D. Tex. Jul. 30, 2020) ............................ 21
`RFCyber Corp. v. Google LLC, et al.,
`No. 2:20-cv-00274-JRG (E.D. Tex.) .................................................................. 17
`Samsung Elecs. Am., Inc. v. Uniloc 2017 LLC,
`IPR2019-01218, Paper 7 (P.T.A.B. Jan. 7, 2020) .............................................. 20
`In re Stepan Co.,
`868 F.3d 1342 (Fed. Cir. 2017) .......................................................................... 11
`
`iii
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`
`Supercell Oy v. Gree, Inc.,
`IPR2020-00513, Paper 11 (P.T.A.B. June 24, 2020) ......................................... 22
`Statutes
`35 U.S.C. § 103 ...................................................................................................... 8, 9
`35 U.S.C. § 314(A) ...................................................................................... 17, 18, 24
`35 U.S.C. § 314(b) ................................................................................................... 21
`35 U.S.C. § 316(a)(11) ............................................................................................. 20
`
`
`
`iv
`
`

`

`
`
`
`
`
`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`EXHIBIT LIST
`
`2002
`
`2003
`
`2004
`
`2005
`
`2006
`
`2007
`
`2008
`
`Exhibit No. Description
`2001
`RFCyber Corp. v. Google, No. 2:20-cv-00274-JRG, Dkt. 63 (E.D.
`Tex. June 10, 2021)
`Google Notice of Intent to Serve Subpoenas on Nokia Corp.,
`served June 25, 2021
`Google Notice of Intent to Serve Subpoenas on EMV Co., served
`June 28, 2021
`Google Notice of Intent to Serve Subpoenas on Global Platform
`Inc. served June 28, 2021
`Google Notice of Intent to Serve Subpoenas on NFC Forum, Inc.,
`served June 28, 2021
`Google Notice of Intent to Serve Subpoenas on Mastercard Inc.
`served July 8, 2021
`Google Notice of Intent to Serve Subpoenas on NXP USA, Inc.
`served July 8, 2021
`Google Notice of Intent to Serve Subpoenas on Secure
`Technology Alliance served July 8, 2021
`Google Notice of Intent to Serve Subpoenas on Visa Inc. served
`July 8, 2021
`Google Notice of Intent to Serve Subpoenas on Mastercard Inc.
`served July 27, 2021
`Google Notice of Intent to Serve Subpoenas on Sequent Software
`Inc. served August 9, 2021
`Google’s Invalidity and Subject Matter Eligibility Contentions,
`served July 14, 2021
`
`2009
`
`2010
`
`2011
`
`2012
`
`v
`
`

`

`
`I.
`
`INTRODUCTION
`On May 19, 2021, Google LLC (“Petitioner”) filed a petition requesting
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`inter partes review of claims 1-17 (“challenged claims”) of U.S. Patent No.
`
`9,240,009 (GOOG-1001, “‘009 Patent”). Paper 2. (“Petition” or “Pet.”). The
`
`Declaration of Stephen Gray GOOG-1003, (“Gray Declaration”) accompanied the
`
`Petition. On May 24, 2021, the Board issued a Notice of Filing Date Accorded for
`
`the petition and set the time for filing patent owner’s preliminary response. Paper
`
`3.
`
`II. THE ‘009 PATENT
`The invention of the ’009 Patent “is generally related to commerce over
`
`networks,” particularly “techniques for personalizing a secure element and
`
`provisioning an application such as an electronic purse that can advantageously be
`
`used in portable devices configured for both electronic commerce (a.k.a., e-
`
`commerce) and mobile commerce (a.k.a., m-commerce). ‘009 Patent at 1:18-24.
`
`The inventors of the ‘009 Patent realized that “[o]ne of the concerns in the NFC
`
`mobile ecosystem is its security in an open network. Thus, there is a need to
`
`provide techniques to personalize a secure element in a contactless smart card or an
`
`NFC-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:9-14.
`
`1
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`To solve these problems, the inventors of the ‘009 Patent developed
`
`
`
`“techniques for personalizing secure elements in NFC devices to enable various
`
`secure transactions over a network.” ‘009 Patent at 2:31-34. For example, “security
`
`keys (either symmetric or asymmetric) are personalized so as to personalize an e-
`
`purse and perform a secured transaction with a payment server.” Id. at 2:53-56.
`
`“According to one embodiment of the present invention, FIG.1D illustrates data
`
`flows among a user for an NFC device (e.g., an NFC mobile phone), the NFC
`
`device itself, a TSM server, a corresponding SE manufacturer and an SE issuer.”
`
`Id. at 9:58-61.
`
`
`
`2
`
`

`

`
`‘009 Patent, Fig. 1D.
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`For example, the system makes use of an e-purse manager midlet that
`
`facilitates communication between securely stored applets and payment servers
`
`over a wireless network:
`
`‘009 Patent, Fig. 2F (showing midlet (in yellow), and applet (in green)).
`
`
`
`3
`
`

`

`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`
`
`‘009 Patent, Fig. 3B (annotations added)
`
`For example, in a data flow among three entities (e.g., a SAM, an e-purse
`
`manager, and a single function tag), an e-purse manager may act as a gatekeeper
`
`“to ensure only secured and authorized data transactions could happen.” ‘009
`
`Patent, 10:28-29.”
`
`4
`
`

`

`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`
`
`‘009 Patent, Fig. 1E.
`
`III. THE ALLEGED PRIOR ART
`Staib (U.S. Patent Pub. No. 2005/0222961)
`A.
`U.S. Patent Pub. No. 2005/0222961 (Ex. GOOG-1005, “Staib”) is directed
`
`to a “system for facilitating contactless payment transactions” using a “mobile
`
`application.” Staib, [0021-22]. Staib’s “mobile application” is associated with
`
`only one contactless payment system but can “perform contactless payment
`
`transactions with merchants that are associated with . . . other payment systems by
`
`emulating the transmission standards and data exchange formats used by those
`
`payment systems.” Id., [0022]. A “service application running in a service
`
`operator’s computer” settles the transactions. Id., [0023]. “The combination of the
`
`mobile application and the service application provide a complete solution to allow
`
`5
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`a common mobile device to pay for goods and services . . . as well as subsequent
`
`settlement of payments.” Id., [0024]. Staib does not use the term “secure element.”
`
`Staib’s system makes use of an NFC module, “connected to its own antenna
`
`18 and the CPU 14 of the smart mobile device 10.” Id., [0039]. The NFC
`
`module “includes a communication chip and may also contain its own processor
`
`for handling data encryption and the like and secure memory area for storing the
`
`stored value.” Id., [0038]. “In an alternative embodiment, an external module may
`
`be connected to the NFC chip 16 which would comprise a secure storage area
`
`which in turn would contain its own processor and operating system.” Id. Or, in a
`
`third embodiment, the system may make use of “a USIM (Universal Subscriber
`
`Identity Module) (not shown) which is in communication with the NFC module
`
`16.” Id.
`
`Staib explains that in embodiments with the external module, that external
`
`module “utilize[s] the operating system of the mobile phone 10 to create secure
`
`internet connections for the purposes of transferring data directly from the secure
`
`storage to the service operator 48.” Id., [0043]; see also id., [0051] (“In a
`
`deployment where an external security module is used, the mobile phone 10 may
`
`be used to create a secure Internet connection to the service operator 48 and that
`
`the data and/or application are transferred directly from the secure storage area to
`
`the service operator or vice versa as required.”).
`
`6
`
`

`

`
`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`B. Holtmanns (U.S. Patent No. 7,628,322)
`U.S. Patent No. 7,628,322 is (Ex. GOOG-1006, “Holtmanns”) is directed to
`
`“[m]ethods of creating a secure channel over which credit card personalization data
`
`can be transmitted over the air.” Holtmanns, Abstract. Holtmann’s field “relates to
`
`enabling a mobile terminal for credit card personalization, and more particularly to
`
`enabling a mobile terminal for credit card personalization using a wireless
`
`network.” Id., 1:17-20. “In particular, in exemplary embodiments Generic
`
`Authentication Architecture (GAA) may be used to establish a shared secret that
`
`can be used to create a secure communication channel between the user equipment
`
`(UE) and a personalization application server or bureau acting as a network
`
`application function (NAF) server.” Id., 3:51-56. Holtmanns does not use the term
`
`“secure element.”
`
`C. Wentker (U.S. Patent No. 6,481,632)
`U.S. Patent No. 6,481,632 (Ex. GOOG-1007, “Wentker”) is directed to a
`
`smart card architecture including “a run-time environment, a card manager, one or
`
`more security domains, a provider application and an issuer application.” Wentker,
`
`Abstract. Wentker’s purported invention “relates to a technique for delegating the
`
`management of applications on a smart card such as loading, installation, and
`
`deletion.” Id. at 1:13-15. “This concept of delegated management allows the card
`
`7
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`issuer the option of empowering application providers to initiate changes to the
`
`issuer's Smart cards that are pre-approved by the card issuer.” Id. at 3:5-8. Wentker
`
`does not use the term “secure element.”
`
`
`IV. CLAIM CONSTRUCTION
`For the purposes of Preliminary Response only, Patent Owner believes that
`
`claim construction is not required to resolve any issues.
`
`V. LEVEL OF ORDINARY SKILL IN THE ART
`
`For the purposes of this Preliminary Response Only, Patent Owner utilizes
`
`Petitioner’s proposed level of skill in the art— “bachelor’s degree in computer
`
`science, computer engineering, or equivalent, and one year of professional
`
`experience relating to mobile payments.” Pet. at 13.
`
`VI. PETITIONER HAS NOT SHOWN A REASONABLE
`LIKELIHOOD OF SUCCESS AS TO ANY CHALLENGED
`CLAIM
`Google submits two supposed grounds of obviousness. Pet. at 15. Ground 2
`
`
`
`only challenges dependent claims. Id. As discussed below, none of Google’s
`
`combinations renders any claim obvious.
`
`A. Requirements for Showing Obviousness Under 35 U.S.C. §
`103
`The question of obviousness is resolved on the basis of underlying factual
`
`determinations, including: (1) the scope and content of the prior art, (2) any
`
`8
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`differences between the claimed subject matter and the prior art, (3) the level of
`
`skill in the art, and (4) where in evidence, so called secondary considerations.
`
`Graham v. John Deere Co. of Kansas City, 383 U.S. 1, 17–18 (1966). A claim is
`
`only unpatentable under 35 U.S.C. § 103 if the differences between the claimed
`
`subject matter and the prior art are such that the subject matter, as a whole, would
`
`have been obvious at the time the invention was made to a person having ordinary
`
`skill in the art to which the subject matter pertains. KSR Intern. Co. v. Telefex Inc.,
`
`550 U.S. 398, 406 (2007) (quoting 35 U.S.C. § 103).
`
`B. Google’s Combination Fails To Disclose Or Render
`Obvious a “secure element” as required by all Challenged
`Claims
`Every Challenged Claim requires a “secure element.” See ‘009 Patent at
`
`claims 1 and 14. Google fails to show that this limitation is disclosed or rendered
`
`obvious by any of its combinations.
`
`First, Google wrongly attributes features of other components and
`
`alternative embodiments to Staib’s USIM and fails to show that Staib’s USIM
`
`discloses a secure element.
`
`Google wrongly characterizes Staib’s USIM as including “its own processor
`
`for ‘data encryption and the like and secure memory area for storing the stored
`
`value.’” Pet. at 31. To the contrary, the cited disclosure pertains not to a USIM, but
`
`to “[a] communication module (NFC) 16 connected to the CPU.” Staib at [0038].
`
`9
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`Staib’s only disclosure of a USIM is that “in another alternative embodiment, the
`
`stored value can be stored in a separate hardware such as in a USIM”:
`
`A communication module (NFC) 16 connected to the
`CPU 14 includes a communication chip and may also
`contain its own processor for handling data encryption
`and the like and secure memory area for storing the
`stored value. In an alternative embodiment, an external
`module may be connected to the NFC chip 16 which
`would comprise a secure storage area which in turn would
`contain its own processor and operating system. This
`external module can be used to store the stored value in its
`secure memory area. Still
`in another alternative
`embodiment, the stored value can be stored in a separate
`hardware such as in a USIM (Universal Subscriber
`Identity Module (not shown) which is in communication
`with the NFC module 16.
`Staib, at [0038] (emphasis added). There is no disclosure in Staib that the USIM is
`
`capable of “securely hosting an application” as required under Google’s own
`
`construction.
`
`Google does not assert that Staib’s “communication module (NFC)” is a
`
`secure element, even under its own construction.
`
`Google also wrongly characterizes Staib’s USIM as the “external security
`
`module.” Pet. at 32. Staib’s “external security module” refers to yet another
`
`element which may be “attached to the NFC interface.” Staib at [0043], [0038]
`
`(explaining that the external security module and USIM are two different
`
`embodiments). Notably, there is no disclosure that Staib’s external security module
`
`even includes a storage, and Staib only describes it used in concert with a separate
`
`10
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`“storage area attached to the NFC interface.” Staib at [0043], [0051]. Google does
`
`not assert that Staib’s “external security module” is a secure element independent
`
`of a USIM card, even under Google’s own construction.
`
`Accordingly, Google’s arguments relying on disclosure that relates not to
`
`Staib’s USIM, but its “communication module NFC” or “external security module”
`
`are irrelevant. Google does not articulate how these elements constitute a secure
`
`element and does not explain how either element would be capable of “securely
`
`hosting an application.” Nor does Google articulate any motivation to combine
`
`these disparate elements and embodiments within Staib. See In re Stepan Co., 868
`
`F.3d 1342, 1346 n.1 (Fed. Cir. 2017) (“Whether a rejection is based on combining
`
`disclosures from multiple references, combining multiple embodiments from a
`
`single reference, or selecting from large lists of elements in a single reference,
`
`there must be a motivation to make the combination and a reasonable expectation
`
`that such a combination would be successful, otherwise a skilled artisan would not
`
`arrive at the claimed combination.”) Accordingly, Google’s attempt to identify a
`
`“secure element” also fails on this basis.
`
`Second, Google compounds its error with the unsupported conclusion that
`
`any disclosure pertaining to a “smart card” in other references of its asserted
`
`obviousness combinations (Wentker, Holtmanns, and Pesonen) automatically
`
`pertains to a secure element. See e.g. Pet. at 24-25 (“When considering Staib’s
`
`11
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`description of using a security module (smart card) with security domains . . . a
`
`POSITA would have considered other literature more fully describing known
`
`smart card technologies . . . .); see also 35-36, and 64. Again, this is not the case.
`
`Google’s arguments rely on the incorrect assumption that every smart card is
`
`automatically a secure element. Id.; see also Pet. at 23-24. But even under
`
`Google’s own construction, while some smart cards may be secure elements, it
`
`does not follow that all smart cards are necessarily secure elements. Thus, in
`
`addition to Staib’s failure to disclose this limitation, this misapprehension is fatal
`
`to Google’s asserted motivations to combine.
`
`Because Google fails to show that Staib, alone or in combination, discloses a
`
`“secure element,” the Petition must be denied.
`
`C. Google’s Combination Fails To Disclose Or Render
`Obvious “a memory space for storing … an application
`downloaded from the network” as required by Challenged
`Claims 1-13.
`Challenged Claims 1-13 require “a memory space for storing at least a
`
`module and an application downloaded from the network.” ‘009 Patent at claim
`
`1 (emphasis added). Claims 1 recites additional limitations on the “application”:
`
`a processor coupled to the memory space and configured
`to execute the module to perform operations including:
`sending to a server via the network interface an identifier
`identifying the application . . . establishing a secured
`channel between the secure element and the server using a
`key set installed on the secure element, wherein the server
`
`12
`
`

`

`
`
`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`the
`to prepare data necessary for
`is configured
`application to function as designed on the mobile device;
`and receiving the data from the server to associate the
`application with the secure element, wherein the
`application subsequently functions in conjunction with
`the secure element."
`Google fails to identify any “application” that meets these limitations in its
`
`proposed combination, nor does Google identify any modifications that would
`
`have been obvious at the time of the invention.
`
`Google asserts that Staib’s “cross border application” is the application of
`
`the claims. Pet. at 33. But Staib only describes a cross border application as
`
`“capable of reading the currency stored in the mobile device 22, converting it into
`
`the appropriate foreign currency and writing the new converted value into the
`
`mobile device. The cross border application 41 is also capable of emulating the RF
`
`standard and data exchange standards of the payment system in use in that foreign
`
`country.” Staib at [0051]; see also id. at [0057] and [0083]. Moreover, deployment
`
`of the cross border application occurs only in limited circumstances: “[s]tep 32 is
`
`an optional step that is executed only when the user is traveling to a foreign
`
`country and needs to convert the currency of the stored value into the respective
`
`foreign currency.” Id. at [0051] (emphasis added). Staib’s cross border application
`
`is not the “application” of the claims, and Google does not articulate any
`
`modifications that would have been obvious at the time of the invention.
`
`13
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`First, Google does not identify any “identifier identifying the application” of
`
`
`
`Staib’s cross border application. Pet. at 35-36. Instead, Google relies on Wentker’s
`
`“data authentication pattern,” and alleges it would have been obvious to use
`
`“Wentker’s smart card architecture including its card manager in combination
`
`with Staib’s mobile device to securely manage the loading and installation of
`
`multiple downloadable applications from different application providers on the
`
`same device.” Id. (emphasis added). Google fails to articulate any reason to apply
`
`Wentker’s disclosure regarding “smart card applications” to Staib’s specialized
`
`“cross border application” for currency conversions. See id. See also Wentker at
`
`6:22-24. Google also fails to identify any basis for the assumption that Staib’s
`
`“cross border application” includes “multiple downloadable applications from
`
`different application providers.” Pet. at 36-37. Accordingly, the Petition should be
`
`denied because Google failed to articulate any legitimate rationale to combine
`
`Staib’s cross-border application with any disclosure of Wentker.
`
`Second, Google does not identify any step wherein “the server is configured
`
`to prepare data necessary for the application to function as designed on the mobile
`
`device.” Google relies on Holtmann’s discussion of “a secure tunnel [] established
`
`between the secure core and the NAF server” for this limitation and argues that it
`
`would be obvious to utilize with Staib’s mobile device. Pet. at 38. Google’s
`
`rationale fails because it does not identify any support for the assertion that Staib’s
`
`14
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`“cross border application” conducts any transactions. Rather, Staib states that its
`
`“cross border application” converts between foreign currencies “based on a set of
`
`pre-arranged rules” between wallet operators, and that “settlement claims” are
`
`handled between wallet operators, not through the cross border application. Staib at
`
`[0083]-[0084]. Google instead appears to conflate Staib’s specialized “cross border
`
`application” with the higher level “mobile application” on which Google relies for
`
`the “module” limitation. Pet. at 32. Accordingly, the Petition should be denied
`
`because Google failed to articulate any legitimate rationale to combine Staib’s
`
`cross-border application with any “server” of Wentker.
`
`Third, Google relies on Holtmanns’ purported discussion of a
`
`“personalization process” for the assertion that “Staib’s mobile device would
`
`‘associate the application with the secure element,’ so that ‘the application
`
`subsequently functions with the secure element.’” Pet. at 40-41. Here, Google
`
`either attempts to articulate a motivation to combine with the wrong element of
`
`Staib (the “mobile application”), or improperly conflates Staib’s “mobile
`
`application” with its “cross border application.” Google fails to articulate any
`
`motivation to combine Holtmann’s disclosure with Staib’s “cross border
`
`application” to arrive at the challenged claims.
`
`Google’s only purported motivation to combine is directed to “enabling a
`
`user to use the mobile device to purchase goods or services or to pay for public
`
`15
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`transport tickets in a comparable manner to a credit or debit card.” Pet. at 40. This
`
`purported motivation to combine is germane only to Staib’s “mobile application”
`
`for allowing “a common mobile device to pay for goods and services,” not to
`
`Staib’s “cross border application” for currency conversion. Compare Staib at
`
`[0024] with id. at [0051]. Google relies on Staib’s “mobile application” for
`
`purported disclosure of the claimed “module,” not an “application,” and its
`
`motivation to combine is not directed to Staib’s "cross border application” for
`
`currency conversion at all. Google therefore fails to meet its threshold for
`
`articulating a motivation to combine because its only rationale is not germane to
`
`the “cross border application.” Google cannot conflate these elements in its attempt
`
`to articulate a motivation to combine.
`
`Because Google failed to show that Staib, alone or in combination, discloses
`
`the claimed “application,” the Petition should be denied.
`
`D. Google’s Combination Fails to Disclose or Render Obvious
`“a memory space for storing various modules downloaded
`from the network”
`Claims 14-17 require “a memory space for storing various modules” where
`
`
`
`the modules are provisioned similarly to the “applications” discussed above.
`
`Google relies solely on the same flawed arguments discussed above in Section
`
`V.C. Google’s combination thus fails to disclose or render obvious the “modules”
`
`at least because there is no “identifier identifying the each of the modules,” and
`
`16
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`there is no disclosure of “receiving the data from the server to associate the each of
`
`the modules with the secure element.”
`
`E. Google’s Ground 2 Fails to Remedy the Deficiencies in
`Ground 1
`In Ground 2, Google asserts that dependent claims 7-12 are obvious over a
`
`proposed combination of Staib, Wentker, Holtmanns, and Pesonen. Ground 2 is
`
`exclusively directed to claims depending on independent claim 1, and relies on the
`
`arguments in Ground 1 against claims 1-6 challenged in Ground 1. Accordingly,
`
`Ground 2 shares the same deficiencies identified above for ground 1.
`
`
`
`Accordingly, Google has failed to show that any Challenged Claim is
`
`obvious, and its Petition should be denied.
`
`VII. THE PETITION SHOULD BE DENIED IN THE DISCRETION
`OF THE DIRECTOR UNDER 35 U.S.C. § 314(A)
`The circumstances of the parallel District Court proceedings in Texas
`
`(RFCyber Corp. v. Google LLC, et al., No. 2:20-cv-00274-JRG (E.D. Tex.)) (“the
`
`Texas Action”) necessitate denial of the Petition under the Board’s precedent, as
`
`every factor considered in relation to efficiency, fairness, and the merits supports
`
`denial. See Apple Inc. v. Fintiv, Inc., IPR2020-00019, Paper 11, at 6 (P.T.A.B.
`
`Mar. 20, 2020) (precedential) (considering (a) “whether the court granted a stay or
`
`evidence exists that one may be granted if a proceeding is instituted;” (b)
`
`“proximity of the court’s trial date to the Board’s projected statutory deadline for a
`
`17
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`final written decision;” (c) “investment in the parallel proceeding by the court and
`
`the parties;” (d) “overlap between issues raised in the petition and in the parallel
`
`proceeding;” (e) “whether the petitioner and the defendant in the parallel
`
`proceeding are the same party;” and (f) “other circumstances that impact the
`
`Board’s exercise of discretion, including the merits.”).
`
`As set forth below, every Fintiv factor demonstrates that efficiency and
`
`integrity of the AIA are best served by denying review. First, the Court has not
`
`granted a stay and will not grant one under the “consistent and long established”
`
`practice of the Eastern District of Texas. Id. the Petitioner is the Defendant in the
`
`Texas Action. See infra Section VII.A. Second, trial (set for March 2022) will be
`
`long complete before the projected statutory deadline for a Final Written Decision
`
`in November 2022. See infra Section VII.B. Third, the parties have already
`
`invested massive resources developing legal and factual issues of validity and
`
`infringement, and the claim construction process will have completed before the
`
`institution decision on this petition. See infra Section VII.C. Fourth, there is
`
`complete overlap between the challenged claims and prior art and those at issue in
`
`the parallel proceedings. See infra Section VII.D. Fifth, Petitioner and Patent
`
`Owner will have completed claim construction before the Board issues an
`
`institution decision and will complete trial, and receive a judgment on the merits,
`
`before the projected statutory deadline for a final written decision. See infra
`
`18
`
`

`

`IPR2021-00956
`PATENT NO. 9,240,009
`
`
`Section VII.E. Finally, as shown above, Google’s obviousness combination, even
`
`taken at face value, lacks the key limitations of the claims and cannot render any
`
`claim obvious.
`
`Accordingly, the Board should exercise its discretion under § 314(a) and
`
`deny the Petition because institution of this proceeding would not be consistent
`
`with the objective of the AIA to “provide an effective and efficient alternative to
`
`district court litigation.” NHK Spring Co. v. Intri-Plex Techs., Inc., IPR2018-
`
`00752, Paper 8, at 20 (P.T.A.B. Sept. 12, 2018) (quoting Gen. Plastic Indus. Co.,
`
`Ltd. v. Canon Kabushiki Kaisha, IPR2016-01357, Paper 19, at 16–17 (P.T.A.B.
`
`Sept.