`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`
`
`GOOGLE LLC,
`
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`
`Patent Owner.
`
`
`Patent No. 9,189,787
`Filing Date: May 28, 2013
`Issue Date: November 17, 2015
`
`Inventors: Liang Seng Koh, Futong Cho, Hsin Pan, and Fuliang Cho
`Title: METHOD AND APPARATUS FOR CONDUCTING
`E-COMMENCE AND M-COMMENCE
`
`
`__________________________________________________________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`Case No. IPR2021-00955
`
`__________________________________________________________________
`
`
`
`
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`Page(s)
`
`
`INTRODUCTION ........................................................................................................................ 1
`I.
`II. THE ’787 PATENT ..................................................................................................................... 2
`III. THE ALLEGED PRIOR ART ................................................................................................ 7
`A. Staib (U.S. Patent Pub. No. 2005/0222961) ..................................................... 7
`B. Chan (U.S. Patent No. 6,005,942) .................................................................... 9
`IV. PROSECUTION HISTORY OF THE ’787 PATENT .................................................. 9
`V. CLAIM Construction ................................................................................................................ 10
`VI. LEVEL OF ORDINARY SKILL IN THE ART ............................................................ 10
`VII. PETITIONER HAS NOT SHOWN A REASONABLE LIKELIHOOD OF
`SUCCESS AS TO ANY CHALLENGED CLAIM ............................................................. 10
`A. Requirements for Showing Obviousness Under 35 U.S.C. § 103 .................10
`B. Google’s Combination Fails To Disclose Or Render Obvious
`“a purse manager midlet being executed in the portable device to
`act as an agent to facilitate communications between the e-purse
`applet and a payment server to conduct transactions therebetween”
`as required by Challenged Claims 1, 2, 4-10 ........................................................11
`C. Google’s Combination Fails To Disclose Or Render Obvious
`“wherein the application is executed in the portable device to act as
`an agent to facilitate communications between the e-purse applet and
`a payment server to conduct transactions therebetween” as Required by
`Challenged Claims 11-12 and 14-19 ....................................................................16
`VIII. 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
`
`i
`
`

`

`IPR2021-00955
`PATENT NO. 9,189,787
`
`
`
`C. Significant Investment By The Time Of Institution Favors Discretionary
`Denial ....................................................................................................................21
`D. The District Court Litigation Involves Each Of the Challenged Claims
`(and Other 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
`IX. CONCLUSION ............................................................................................................................ 25
`
`
`
`
`
`ii
`
`

`

`
`
`TABLE OF AUTHORITIES
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
` 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) ..................................passim
`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) ................................................................................................ 10
`KSR Intern. Co. v. Telefex Inc.,
`550 U.S. 398 (2007) ............................................................................................ 11
`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
`RFCyber Corp. v. Google LLC and Google Payment Corp.,
`Case No. 2:20-cv-00274-JRG (E.D. Tex.) ..................................................... 1, 17
`Samsung Elecs. Am., Inc. v. Uniloc 2017 LLC,
`IPR2019-01787, Paper 7 (P.T.A.B. Jan. 7, 2020) .............................................. 20
`Supercell Oy v. Gree, Inc.,
`IPR2020-00513, Paper 11 (P.T.A.B. June 24, 2020) ......................................... 22
`
`iii
`
`

`

`IPR2021-00955
`IPR2021-00955
`PATENT NO. 9,189,787
`PATENTNO. 9,189,787
`
`
`Statutes
`Statutes
`35 U.S.C. § 103 ........................................................................................................ 10
`35 U.S.C. § 103 wee eeseeseeeceseeecessescesecscesecseeseesaeeeesaecnesseeseeseesessaeessaseeseaeeaseeseneeae® 10
`35 U.S.C. § 103(a) ..................................................................................................... 1
`35 ULS.C. § 103(a) oo. eeeeeesseseeeceececesececeseeseescssaescssaeencaesaceseesessaeessaeensaeeeseaseeseasees 1
`35 U.S.C. § 314(a) ................................................................................... 2, 17, 19, 24
`35 U.S.C. § 314(a) oo. eeeeeescesccceeececeeeeeceeeesseeeceaececesecseesesseesaeeesesesaeeasees2, 17, 19, 24
`35 U.S.C. § 314(b) ................................................................................................... 21
`35 U.S.C. § 314(D)oo eee eeeeseesceseeecesesecesecseeseesaeeesaeeeesseeseeseeseesaesessaeeeseaeeaseeseaseue® 21
`35 U.S.C. § 316(a)(11) ............................................................................................. 20
`35 ULS.C. § 316(a)11). eee eeseeecsceeececeeesseeeeesaeeeeaeeeecseeseeseesessaeeecsaeeeseaeeeseeseneeee® 20
`
`iv
`iv
`
`

`

`
`
`
`
`LIST OF EXHIBITS
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`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” or “Google”) submitted a
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`petition (Paper 2, “Petition” or “Pet.”) to institute inter partes review (“IPR”) of
`
`U.S. Patent No. 9,189,787 (Ex. 1001, the “’787 Patent”), challenging claims 1, 2,
`
`4-12, and 14-19 as unpatentable under (pre-AIA) 35 U.S.C. § 103(a) (the
`
`“Challenged Claims”). The Petition identifies real parties-in-interest as “Google
`
`LLC and Google Payment Corp.” Pet. at 8. 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. Google is a party to the
`
`district court case captioned as RFCyber Corp. v. Google LLC and Google
`
`Payment Corp., Case No. 2:20-cv-00274-JRG (Lead Case) (E.D. Tex.)
`
`(hereinafter, the “District Court Litigation” or “Texas Action”).
`
`The Board should deny Google’s Petition. First, Google fails to show that
`
`its proposed combination discloses or renders obvious the key limitations “a purse
`
`manager midlet being executed in the portable device to act as an agent to facilitate
`
`communications between the e-purse applet and a payment server to conduct
`
`transactions therebetween” and “wherein the application is executed in the portable
`
`device to act as an agent to facilitate communications between the e-purse applet
`
`and a payment server to conduct transactions therebetween.” These limitations
`
`1
`
`

`

`
`were added during prosecution and overcame a rejection against Staib (Ex. 1005),
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`Google’s primary reference. The “mobile application” of Staib, which Google
`
`attempts to map to the limitations, does not act as an agent to facilitate
`
`communication with any alleged “applet.” Instead, Staib is clear that the mobile
`
`application communicates only on its own part and does not have any relation to
`
`communications with anything stored in the security module on which Google
`
`relies.
`
`Second, the Fintiv factors all favor denying this Petition in the discretion of
`
`the Director under 35 U.S.C. § 314(a). The District Court in the pending litigation
`
`between Petitioner and Patent Owner has set trial for March 2022, long before this
`
`proceeding will reach the projected statutory deadline for a Final Written Decision.
`
`Moreover, the parties have begun discovery and the claim construction process,
`
`and they and the District Court will have invested substantial resources in the
`
`overlapping issues before an institution decision. Indeed, the Court’s schedule will
`
`see discovery closed and claim construction completed before the institution
`
`decision.
`
`Accordingly, the Board should deny institution.
`
`II. THE ’787 PATENT
`The ’787 Patent claims methods and systems for providing electronic purses
`
`(e-purses) for use in electronic and mobile commerce. ’787 Patent at 1:7-11. The
`
`2
`
`

`

`
`inventors of the ’787 Patent realized that existing contactless cards were not
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`effective for use in electronic or mobile commerce “because stored values and
`
`transaction information are stored in data storage of each tag that is protected by a
`
`set of keys.” Id. at 1:33-37. Those keys “need to be delivered to the card for
`
`authentication before data can be accessed during a transaction.” Id. at 1:37-39.
`
`“This constraint makes systems using such technology difficult to be expanded to
`
`an open environment such as the Internet for e-commerce and cellular networks for
`
`m-commerce as the key delivery over a public domain network causes security
`
`concerns.” Id. at 1:39-43.
`
`To solve these problems, the inventors of the ’787 patent developed a system
`
`for personalizing a card stored in a portable device. The system makes use of a
`
`midlet that facilitates communication between the securely stored applets and
`
`payment servers over a wireless network:
`
`3
`
`

`

`
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`’787 Patent, Fig. 2 (showing midlet (in yellow), and applet (in green)).
`
`
`
`
`
`4
`
`

`

`
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`’787 Patent, Fig. 3B (annotations added).
`
`
`
`5
`
`

`

`The midlet facilitates this communication, for example, while the card is
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`
`
`being personalized. The entire process is protected by a three-tier security model:
`
`’787 Patent, Fig. 1A
`
`
`
`
`
`“The three-tier security model 100 includes physical security 102, e-purse
`
`security 104 and card manager security 106.” ’787 Patent at 3:58-60. The
`
`physical security “refers to a security mechanism provided by a single functional
`
`card to protect data stored on the card. The card may be hardware implemented or
`
`software emulated running on a type of media.” Id. at 3:61-64. E-purse security
`
`“defines a set of protocols that enable micro payment transactions to be carried out
`
`6
`
`

`

`
`in both wired and wireless environments.” Id. at 4:4-6. “During a transaction, the
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`purse uses a set of respective keys for encryption and MAC computation in order
`
`to secure the message channel between the purse and the SAM or backend
`
`servers.” Id.at 4:9-13. “Card Manager Security 106, referring to a general security
`
`framework of a preload operating system in a Smart card, provides a platform for
`
`PIN management and security channels (security domains) for card
`
`personalization. This platform via a card manager can be used to personalize a
`
`purse in one embodiment.” Id. at 4:19-24.
`
`
`
`A device that has been personalized using the three-tier security as above
`
`can then perform e-commerce and m-commerce using an emulator, and NFC
`
`interface for e-commerce, and a second interface for m-commerce. Id. at 2:36-52,
`
`5:1-15, Fig. 2.
`
`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
`
`7
`
`

`

`
`payment systems.” Id., ¶ [0022]. A “service application running in a service
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`operator’s computer” settles the transactions. Id., [0023]. “The combination of the
`
`mobile application and the service application provide a complete solution to allow
`
`a common mobile device to pay for goods and services…as well as subsequent
`
`settlement of payments.” Id., [0024].
`
`
`
`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
`
`8
`
`

`

`
`be used to create a secure Internet connection to the service operator 48 and that
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`the data and/or application are transferred directly from the secure storage area to
`
`the service operator or vice versa as required.”).
`
`B. Chan (U.S. Patent No. 6,005,942)
`U.S. Patent No. 6,005,942 to Chan (Ex. GOOG-1008, “Chan”) describes a
`
`“system and method to allow card issuers to securely add applications during the
`
`lifetime of the card after the card has already been issued (post issuance).” Chan at
`
`Abstract. Chan uses “security domain applications on the card [that] provide
`
`security for loaded applications by managing keys; each application is associated
`
`with a security domain.” Id.
`
`IV. PROSECUTION HISTORY OF THE ’787 PATENT
`
`During prosecution of the application that led to the ’787 Patent, the
`
`Examiner rejected the then-pending claims as obvious over Staib in view of U.S.
`
`Patent No. 6,031,912 (“Moulart”). Ex. 1002 at 79-88. In response, the Applicants
`
`amended the claims to include, among other limitations, “a purse manager midlet”
`
`to claim 1, and the “application … to facilitate communications between the e-
`
`purse applet and a payment server” in claim 11. Id. at 66-70. The Examiner then
`
`allowed the claims. Id. at 6-11.
`
`
`
`
`
`9
`
`

`

`
`V. CLAIM CONSTRUCTION
`For the purposes of this Preliminary Response Only, Patent Owner believes
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`that claim construction is not required to resolve any issues.
`
`VI. 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 an equivalent, and one year of professional
`
`experience relating to mobile payments.” Pet. at 15.
`
`VII. PETITIONER HAS NOT SHOWN A REASONABLE
`LIKELIHOOD OF SUCCESS AS TO ANY CHALLENGED
`CLAIM
`Requirements for Showing Obviousness Under 35 U.S.C. §
`103
`The question of obviousness is resolved on the basis of underlying factual
`
`A.
`
`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) 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
`
`10
`
`

`

`
`skill in the art to which the subject matter pertains.” KSR Intern. Co. v. Telefex
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`Inc., 550 U.S. 398, 406 (2007) (quoting 35 U.S.C. § 103).
`
`B. Google’s Combination Fails To Disclose Or Render Obvious
`“a purse manager midlet being executed in the portable
`device to act as an agent to facilitate communications
`between the e-purse applet and a payment server to conduct
`transactions therebetween” as required by Challenged
`Claims 1, 2, 4-10
`Claim 1, and therefore its dependent claims, requires “a purse manager
`
`
`
`midlet being executed in the portable device to act as an agent to facilitate
`
`communications between the e-purse applet and a payment server to conduct
`
`transactions therebetween.” ’787 Patent at claim 1. Thus, the claims require that
`
`the midlet act as an agent to facilitate communications between an e-purse applet
`
`on one side and a payment server on the other. But there are no e-purse applets in
`
`Staib (as Google tacitly admits). And Google does not identify any midlet that
`
`would, even in Google’s proposed combination, facilitate any communications
`
`between Google’s proposed e-purse applet (Chan’s security domain application
`
`loaded into Staib’s secure module) and any other component. Indeed, the only
`
`midlet Google suggests, Staib’s mobile application, is explicitly described as
`
`completely separate from the secure module and its contents. See infra. Moreover,
`
`the secure module is described as setting up its own communications; if the secure
`
`module were to rely on the mobile application for communications, it would
`
`11
`
`

`

`
`sidestep the enhanced security of the secure module, thus defeating the purpose of
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`including an external “secure module.” Staib, ¶¶ [0043], [0038]. Accordingly,
`
`Google fails to identify any midlet that facilitates communication between an
`
`applet and any payment server (or anything else) in its proposed combination, nor
`
`to identify any modifications that would have been obvious at the time of the
`
`invention.
`
`
`
`Google asserts that Staib’s “mobile application” is the midlet of the claims.
`
`Pet. at 51. Staib’s mobile application communicates directly with merchant
`
`systems to perform transactions. Staib at [0022], [0024]. The mobile application
`
`further accesses the storage on the mobile device to create a payment token and
`
`directly provide the payment token to a merchant contactless communicatory. Id.
`
`at [0064], [0066]. Staib’s mobile application does not facilitate communication
`
`between any e-purse applet, because the mobile application itself both accesses the
`
`storage on the mobile device and communicates directly with service applications
`
`on merchant systems. Id. at [0024] (“The combination of the mobile application
`
`and the service application provide a complete solution to allow a common mobile
`
`device to pay for goods and services through merchants that are associated with
`
`different payment systems as well as subsequent settlement of payments among the
`
`different payment systems.”); [0023] (describing “a service application running in
`
`a service operator's computer”); see also id., ¶¶ [0091], [0131]. Indeed, the
`
`12
`
`

`

`
`Examiner considered Staib’s mobile application to be an applet, not the midlet.
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`Ex. 1002 at 83-84.
`
`
`
`Google tacitly admits that Staib’s mobile application does not facilitate
`
`communication between an e-purse applet and a payment server. Pet. at 51-53.
`
`Instead, Google argues that it would be obvious to add Chan’s security domain
`
`applications to Staib’s external security module, and that those security domain
`
`applications within the security module would be e-purse applets. Pet. at 52-53.
`
`However, even if true, the mobile application would still not act as a midlet that
`
`facilitates communication between Chan’s applications and a payment server,
`
`because Staib is clear that: i) the mobile application does not interface in any way
`
`with the security module or anything within it; and ii) the security module
`
`establishes its own communications by using the mobile phone or the mobile
`
`phone’s operating system. A Chan application, even if stored in the security
`
`module, would likewise communicate using the mobile phone or its operating
`
`system as Staib teaches. Therefore, the Staib/Chan combination does not disclose
`
`or render obvious this limitation. Google identifies no motivation for a POSA to
`
`further modify the Staib/Chan combination so that items stored in the security
`
`module would communicate via the mobile application.
`
`
`
`Staib explains that the external security module is completely separate from
`
`the mobile application and does not facilitate communication between anything on
`
`13
`
`

`

`
`the security module and a payment server. Indeed, the security module establishes
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`its own connections. For example, Staib explicitly teaches that “there may be an
`
`external security module and storage area attached to the NFC interface. This
`
`secure module may have the ability to utilize 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.” Staib at [0043]
`
`(emphasis added). The operating system is not the mobile application. Moreover,
`
`the operating system is not a midlet, even under Google’s interpretation of the
`
`patent as it is not a software component suitable for being executed on a portable
`
`device; Google does not argue otherwise. See Pet. at 12, 51-53.
`
`
`
`Similarly, Staib states, in a section on an optional cross-border application,
`
`“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.” Id. at [0051] (emphasis
`
`added). The mobile phone is not a midlet either.
`
`
`
`Google falsely states that “Staib teaches that the mobile application may
`
`‘create a secure Internet connection’ for the transfer of data between the external
`
`security module (smart card) and the service operator or vice versa,” and cites
`
`paragraph 51 of Staib. Pet. at 51 (citing Staib, ¶ [0051]). But as shown above, it is
`
`14
`
`

`

`
`the mobile phone or device, and not the mobile application that creates the secure
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`internet connection between the security module and the service operator described
`
`in paragraph 51. See Staib, [0051].
`
`
`
`The mobile application thus is neither used nor required to act as an agent to
`
`facilitate communication with anything stored in the security module; Staib instead
`
`teaches that the security module uses the mobile phone’s operating system to
`
`directly communicate with service operators. Indeed, by contrast, Staib is explicit
`
`about when the mobile application is used in conjunction with the mobile phone
`
`operating system (see id., [0052]).
`
`
`
`The only possible “facilitation” Google identifies is a parenthetical where it
`
`states that the mobile application “facilitates secure communication between the
`
`external security module and a server via the Internet.” Pet. at 52. But Staib is
`
`clear that the security module works outside the mobile application to set up its
`
`own Internet connection. E.g., Staib at [0043] (“This secure module may have the
`
`ability to utilize the operating system of the mobile phone 10 to create secure
`
`internet connections . . . .”); [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 . . . .”). Petitioner identifies no portion of
`
`Staib suggesting that the mobile application is involved in any way with
`
`communications between the secure module and any server. Indeed, Petitioner
`
`15
`
`

`

`
`explicitly admits in a later section that applications and data are “downloaded
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`directly to the external security module via a secure Internet connection between
`
`the mobile device and a network server.” Pet. at 41 (emphasis added). Because
`
`the applications are downloaded “directly” to the external security module, in
`
`accordance with Staib’s teachings, they do not use Staib’s mobile application as an
`
`agent to facilitate communication.
`
`
`
`Finally, Petitioner does not argue that a POSA would have modified Staib’s
`
`architecture so that the mobile application was involved in communications
`
`between the security module and a payment server. Pet. at 52-54. Further,
`
`Petitioner does not argue that Chan provides the midlet in any way.
`
`
`
`Accordingly, Petitioner has failed to show that Staib in view of Chan renders
`
`this limitation obvious, and therefore has failed to show that any of claims 1, 2, and
`
`4-10 are obvious.
`
`C. Google’s Combination Fails To Disclose Or Render Obvious
`“wherein the application is executed in the portable device
`to act as an agent to facilitate communications between the
`e-purse applet and a payment server to conduct
`transactions therebetween” as Required by Challenged
`Claims 11-12 and 14-19
`Claim 11 (and all of its dependent claims) requires an application “wherein
`
`
`
`the application is executed in the portable device to act as an agent to facilitate
`
`communications between the e-purse applet and a payment server to conduct
`
`16
`
`

`

`
`transactions therebetween.” Google simply references its flawed analysis
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`regarding claim 1’s “purse manager midlet.” Pet. at 70. Presuming that Google
`
`intends to identify Staib’s “mobile application” as claim 11’s “application,” its
`
`obviousness arguments fail. As stated above, Staib’s mobile application does not
`
`act as an agent to facilitate communications between the supposed e-purse applet
`
`stored in the security module and a server; rather the security module is disclosed
`
`as using the mobile phone or its operating system to establish communications.
`
`
`
`Accordingly, Google has not shown that any of the Challenged Claims are
`
`rendered obvious by Staib in view of Chan, and the Board should deny institution.
`
`
`
`VIII. 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
`
`

`

`
`final written decision;” (c) “investment in the parallel proceeding by the court and
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`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
`
`

`

`
`Section VII.E. Finally, as shown above, Google’s obviousness combination, even
`
`IPR2021-00955
`PATENT NO. 9,189,787
`
`taken at face value, lacks the “midlet” 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 l