Google LLC v. RFCyber Corp

1. Case Identification

• Case #: IPR2021-00957
• Patent #: 8,118,218
• Filed: May 19, 2021
• Petitioner(s): Google LLC.
• Patent Owner(s): RFCyber Corp.
• Challenged Claims: 1-18

2. Patent Overview

• Title: Mobile Device and Method for Providing e-Purse
• Brief Description: The ’218 patent describes a system and method for using a portable device, such as a cell phone, as a secure electronic purse (e-purse). The technology involves a smart card module within the device that is pre-loaded with an emulator, allowing it to securely download, personalize, and run an e-purse software application (applet) to conduct transactions over a network.

3. Grounds for Unpatentability

Ground 1: Obviousness of Claims 1-18 over Staib and Chan

• Prior Art Relied Upon: Staib (Application # 2005/0222961) and Chan (Patent 6,005,942).

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued that Staib disclosed the foundational method for providing an e-purse using a portable device. Staib taught a "smart mobile device" with a communication module (NFC) connected to an external security module (e.g., a USIM smart card) that acts as a stored-value device for contactless payments. This combination met the limitations of a portable device communicating with a smart card for e-purse functionality. However, Staib lacked specific details on the smart card's internal software architecture for securely managing applications post-issuance.

  Petitioner asserted that Chan filled this gap by teaching a well-known open platform security architecture for smart cards, specifically a Java Card environment. Chan's architecture included a virtual machine and a "Card Domain," which collectively functioned as the claimed "emulator" pre-loaded onto the smart card. This emulator was designed to securely download, manage, and run multiple applications, or "applets," such as a stored-value application corresponding to the claimed "e-purse applet." Chan further taught using security domains and cryptographic keys to securely personalize applets and establish secure communication channels with external servers, fulfilling limitations related to personalizing the applet and creating secure channels with a Security Authentication Module (SAM).

  • Motivation to Combine: Petitioner contended that a person of ordinary skill in the art (POSITA) would have been motivated to combine the teachings of Staib and Chan to improve Staib’s system. Staib presented a functional mobile payment system but was silent on the specific software architecture needed to securely add and manage payment applications on its smart card module. Chan provided a known, standardized solution (Java Card open platform) for this exact problem. A POSITA would have logically looked to established smart card software architectures like Chan’s to implement the security module in Staib’s device, thereby enabling the enhanced functionality of securely downloading and managing multiple payment applications from different providers.

  • Expectation of Success: The combination would have yielded predictable results. Chan’s architecture was designed to be platform-agnostic and work with any electronic device capable of interfacing with a smart card. Applying Chan's known software security architecture to Staib's mobile device with its external smart card module was a straightforward integration of a known software solution into a known hardware environment. This would predictably result in a mobile device capable of securely managing downloadable e-purse applications as claimed in the ’218 patent.

4. Key Claim Construction Positions

• "emulator": Petitioner argued that this term should be construed according to the explicit definition provided in the ’218 patent specification: "a hardware device or a program that pretends to be another particular device or program that other components expect to interact with." Petitioner contended that Chan's Java Card virtual machine and its associated architecture met this definition, as it is a program that simulates a Java processor to run Java applets on the smart card's native hardware.

5. Arguments Regarding Discretionary Denial

• Petitioner argued that discretionary denial under §314(a) and the Fintiv factors would be inappropriate and that the Board should institute review.
  • Fintiv Factors 1 & 2 (Stay and Trial Proximity): Petitioner argued these factors were neutral. No motion to stay had been filed in the parallel district court litigation, and the scheduled trial date was approximately nine months after the final written decision (FWD) due date and was subject to change.
  • Fintiv Factor 3 (Investment in Parallel Proceeding): This factor strongly favored institution because, at the time of filing the petition, investment in the merits of the invalidity positions in the district court was minimal. Infringement contentions had only recently been served, and no dispositive motions on validity had been filed.
  • Fintiv Factor 4 (Overlap of Issues): This factor favored institution, as Petitioner expressed willingness to stipulate against pursuing the same invalidity grounds in the district court, thereby mitigating concerns of overlap and conflicting decisions.
  • Fintiv Factor 5 (Overlap of Parties): This factor was neutral.
  • Fintiv Factor 6 (Other Circumstances): This factor favored institution due to the asserted strength of the unpatentability grounds presented in the petition.

6. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 1-18 of the ’218 patent as unpatentable under 35 U.S.C. §103.