DCT
6:22-cv-00697
RFCyber Corp v. Visa USA Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: RFCyber Corp. (Texas)
- Defendant: Visa U.S.A. Inc. (Delaware)
- Plaintiff’s Counsel: The Mort Law Firm, PLLC; Fabricant LLP
- Case Identification: 6:22-cv-00697, W.D. Tex., 06/28/2022
- Venue Allegations: Venue is based on Defendant allegedly having a regular and established place of business in the district and committing acts of patent infringement within the district.
- Core Dispute: Plaintiff alleges that Defendant’s tokenization and contactless payment services infringe four patents related to methods and systems for securely provisioning and using portable devices as an "electronic purse."
- Technical Context: The technology concerns secure mobile commerce, specifically the architecture for enabling devices like NFC-enabled phones to function as digital wallets for transactions over open networks.
- Key Procedural History: The complaint alleges that Defendant has known of the patents-in-suit since at least December 20, 2021, when it was served with a subpoena in a separate litigation involving the same patents, RFCyber v. Samsung Elecs. Co. This allegation is central to the claims of willful infringement.
Case Timeline
| Date | Event |
|---|---|
| 2006-09-24 | Earliest Priority Date for all Asserted Patents |
| 2012-02-21 | U.S. Patent No. 8,118,218 Issues |
| 2013-05-28 | U.S. Patent No. 8,448,855 Issues |
| 2015-11-17 | U.S. Patent No. 9,189,787 Issues |
| 2016-01-19 | U.S. Patent No. 9,240,009 Issues |
| 2021-12-20 | Defendant Allegedly Notified of Patents-in-Suit via Subpoena |
| 2022-06-28 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,118,218 - Method and Apparatus for Providing Electronic Purse
- Issued: Feb. 21, 2012
The Invention Explained
- Problem Addressed: The patent describes the difficulty of expanding single-function contactless card systems (used in "enclosed environments" like transit) to open networks for e-commerce and m-commerce due to the security risks of delivering cryptographic keys over a public domain network (’218 Patent, col. 1:24-39).
- The Patented Solution: The invention proposes a system architecture for a portable device (e.g., a cellphone) that functions as a secure "e-purse." It uses a "purse manager midlet" to facilitate communication between an "e-purse applet" (residing on a smart card) and a remote payment server, enabling secure transactions over wireless or wired networks. This is underpinned by a "three-tier security model" that manages key personalization and establishes secure communication channels for transactions (’218 Patent, Abstract; col. 1:51-col. 2:8; Fig. 2).
- Technical Importance: The described method provided a framework for enabling a single portable device to securely manage value and conduct transactions in both closed-loop (e.g., via NFC) and open-network (e.g., via cellular) environments (’218 Patent, col. 1:8-11).
Key Claims at a Glance
- The complaint asserts independent claim 1 and alleges infringement of one or more claims (Compl. ¶19-20).
- Claim 1 is a method for providing an e-purse, with key elements including:
- Providing a portable device with a smart card pre-loaded with an "emulator".
- The device has a memory space with a "midlet" to facilitate communication between an "e-purse applet" and a payment server over a wireless network.
- The "e-purse applet" is downloaded and installed in the smart card when in communication with the payment server.
- The device has a contactless interface for communication between the "e-purse applet" and the payment server over a wired network.
- "Personalizing the e-purse applet" by reading data from the smart card to generate operation keys.
- This personalization includes establishing an "initial security channel" to install and personalize the applet, and "creating a security channel on top of the initial security channel" to protect subsequent operations.
U.S. Patent No. 8,448,855 - Method and Apparatus for Funding an Electronic Purse
- Issued: May 28, 2013
The Invention Explained
- Problem Addressed: As with the parent ’218 patent, the technology addresses the need to securely conduct e-purse transactions over an open network without compromising security (’855 Patent, col. 1:32-47).
- The Patented Solution: This patent focuses specifically on the method of funding the e-purse. A user authenticates with a PIN, causing a "midlet" on the device to send a request to the "e-purse applet". The applet then communicates over a network with a server, which verifies the request against a financial institution account and initiates a fund transfer. The process relies on the same tiered security model involving an external Security Authentication Module (SAM) to personalize the e-purse and secure the transaction (’855 Patent, Abstract; col. 7:21-col. 8:66).
- Technical Importance: The invention details a specific workflow for securely adding value to a mobile wallet from an external bank account, a critical function for open-loop payment systems.
Key Claims at a Glance
- The complaint asserts independent claim 1 and alleges infringement of one or more claims (Compl. ¶36-37).
- Claim 1 is a method for funding an e-purse, with key elements including:
- Receiving a PIN from a user of a portable NFC device that includes a "card module".
- Initiating a request from a "midlet" after PIN verification, which sends the request to an "e-purse applet".
- The "e-purse applet" composes a response and sends it over a wireless network to a server.
- The server verifies the response against a financial institution account and initiates a fund transfer.
- Receiving commands from the server for the fund transfer.
- Causing an "emulator" to update a transaction log.
- The e-purse has been "personalized" by establishing an "initial security channel" and "creating a security channel on top of the initial" one.
U.S. Patent No. 9,189,787 - Method and Apparatus for Conducting E-Commerce and M-Commerce
- Issued: Nov. 17, 2015
- Technology Synopsis: This patent claims a portable commerce device comprising an "emulator" and an "e-purse applet" that are personalized via a security channel. The device is configured with two distinct interfaces: a first (NFC) interface for e-commerce with a reader, and a second interface to perform mobile commerce with a payment server, with both transaction types drawing from a fund stored in the emulator (’787 Patent, Abstract, Claim 1).
- Asserted Claims: The complaint asserts independent claim 1 (Compl. ¶55).
- Accused Features: The complaint alleges that NFC-enabled phones using Visa Token Service have an emulator (the NFC module/secure element), an e-purse applet (the payment card applet), and distinct interfaces for NFC and mobile commerce transactions against a tokenized value (Compl. ¶56, ¶59-60).
U.S. Patent No. 9,240,009 - Mobile Devices for Commerce Over Unsecured Networks
- Issued: Jan. 19, 2016
- Technology Synopsis: This patent claims a mobile device and method for conducting a secured transaction by provisioning an application. The device sends an application identifier and secure element information to a server. The server then establishes a secure channel with the secure element using an installed key set and sends back the necessary data to associate the application with the secure element, allowing it to function (’009 Patent, Abstract, Claim 1).
- Asserted Claims: The complaint asserts independent claim 1 (Compl. ¶71).
- Accused Features: The complaint alleges that the Visa Token Service provisioning process mirrors these steps: an NFC-enabled phone sends identifiers to a Visa server, which establishes a secure channel to the phone's secure element to deliver a token and associate it with the payment application (Compl. ¶72-78).
III. The Accused Instrumentality
Product Identification
- The complaint identifies the accused instrumentalities as Visa's services, including but not limited to Visa Token Service (VTS), Visa Ready, Token ID, and Visa payWave (Compl. ¶12).
Functionality and Market Context
- The Accused Products provide a system for replacing a cardholder's sensitive account number (PAN) with a unique digital identifier, or "token" (Compl. p. 8). This token is provisioned to an NFC-enabled device, such as a smartphone containing a secure element, allowing the device to be used for contactless payments. The complaint alleges these services manage the entire lifecycle of tokenization, including personalization of payment "applets," card emulation, and transaction processing via NFC (Compl. ¶12). The "Provisioning Diagram" included in the complaint illustrates a six-step process for how a cardholder's account is loaded onto a device and a token is generated and delivered (Compl. p. 10). The complaint alleges these services improve the user shopping experience and enhance Visa's market position (Compl. ¶12).
IV. Analysis of Infringement Allegations
’218 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| providing a portable device including or communicating with a smart card pre-loaded with an emulator... | The Accused Products are used with NFC-enabled phones that include or communicate with a "smart card" (e.g., NFC module, secure element) which is pre-loaded with an emulator. | ¶21 | col. 2:13-15 |
| the portable device including a memory space loaded with a midlet that is configured to facilitate communication between the e-purse applet and a payment server over a wireless network... | Accused Products, like phones using VTS, include memory (RAM, ROM) and a "midlet" (e.g., contactless payment application, SDK) that facilitates communication between the payment card applet and a payment server. | ¶22 | col. 2:15-20 |
| wherein the e-purse applet is downloaded and installed in the smart card when the smart card is in communication with the payment server... | The Visa Token Service causes NFC-enabled phones to download and install a payment card applet while in communication with a payment server, such as a TSP server. The complaint's "How it works" diagram illustrates the role of a Token Service Provider. | ¶23; p. 9 | col. 2:21-24 |
| personalizing the e-purse applet by reading off data from the smart card to generate in the smart card one or more operation keys... | The Visa Token Service establishes operations keys for secure connections between a stored payment card and an authentication module at a card issuer's server when adding a card or during transactions. | ¶25 | col. 2:25-30 |
| establishing an initial security channel between the smart card and the e-purse SAM to install and personalize the e-purse applet... | The Visa Token Service establishes a security channel with a Visa TSP server after a user enters card details, which operates to install and personalize the applet in the secure element. The "How Visa Token Service Works" diagram illustrates this initial channel establishment. | ¶26; p. 12 | col. 2:38-42 |
| creating a security channel on top of the initial security channel to protect subsequent operations... | It is alleged that once a Visa payment card applet is installed, subsequent operations are conducted via a security channel using the security key installed during the personalization, which is built on top of the initial channel. | ¶27 | col. 2:42-45 |
’855 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving a PIN from a user of a portable device, wherein the portable device is a near field communication (NFC) enabled device that includes a card module; | NFC-enabled phones configured with the Visa Token Service include a card module (secure element or NFC Controller) and require a PIN to unlock the device or authorize a transaction. | ¶38 | col. 7:21-23 |
| initiating a request from a midlet embedded in the portable device after the PIN is verified, wherein the midlet sends the request to an e-purse applet; | After PIN/passcode verification, the Visa Token Service and/or its associated client-side SDK (the alleged "midlet") sends a request to a payment card applet (the alleged "e-purse applet"). The "Provisioning Diagram" shows a step requiring a one-time passcode. | ¶39; p. 17 | col. 7:26-28 |
| sending the response by the e-purse applet over a wireless network to a server administrating the e-purse, the server configured to verify the response against an account in a financial institution... | An NFC-enabled phone sends a response from a payment card applet to a Visa TSP server over a wireless network, which is configured to request funds to complete a transaction. | ¶41 | col. 7:31-37 |
| receiving commands from the server in responding to the fund transfer request; | NFC-enabled phones configured with VTS receive commands in response to a fund transfer request, such as to communicate transaction information. The complaint's "Purchase Transaction Flow" diagram shows the issuer returning an authorization response to Visa. | ¶42; p. 19 | col. 7:42-43 |
| wherein the e-purse in the portable device has been personalized by operations including: establishing an initial security channel... and creating a security channel on top of the initial security channel... | VTS personalizes payment card applets by establishing an initial security channel with a payment server (TSP server) to install and configure the card, and subsequent communications are protected by operating keys established during this process. | ¶44, ¶45 | col. 7:51-64 |
Identified Points of Contention
- Scope Questions: A primary question will be whether the terms "e-purse applet", "midlet", and "emulator", which are described in the patent in the context of a specific mid-2000s Java Card/J2ME mobile architecture, can be construed to read on the components of modern smartphone payment systems, such as tokenized credentials in a secure element, mobile wallet applications, and operating system-level software development kits (SDKs).
- Technical Questions: The complaint alleges the creation of a "security channel on top of the initial security channel" (Compl. ¶27, ¶45). A technical dispute may arise over whether the accused VTS system actually creates two distinct, layered security channels as claimed, or whether it establishes a single secure session for personalization and subsequent transactions.
V. Key Claim Terms for Construction
The Term: "e-purse applet"
- Context and Importance: This term is at the heart of all asserted patents. Its construction is critical to determining if a modern, tokenized payment credential managed by the Visa Token Service within a device's secure element constitutes an infringement. Practitioners may focus on this term because the patents' detailed descriptions appear to tie the concept to a specific type of software ("applet in SMX") from a particular technological era.
- Intrinsic Evidence for a Broader Interpretation: The claims define it functionally as causing a portable device to "function as an electronic purse" (’787 Patent, cl. 1), suggesting any software component performing that role could qualify.
- Intrinsic Evidence for a Narrower Interpretation: The specification repeatedly describes the invention in the context of Java-based smart cards, stating "an e-purse is built on top of the global platform and implemented as an applet in SMX" and referring to a "JavaCard that can run Java applets" (’218 Patent, col. 5:1-3, col. 4:65-67). This may support a narrower construction limited to that specific implementation.
The Term: "midlet"
- Context and Importance: This term, appearing in the independent claims of the ’218 and ’855 patents, refers to a specific type of Java application for mobile devices (J2ME). The case may turn on whether a modern mobile wallet application or a Visa-provided SDK can be considered a "midlet".
- Intrinsic Evidence for a Broader Interpretation: The patent describes its role functionally as an "agent to facilitate communications between an e-purse applet and ... payment network" (’218 Patent, col. 5:6-9). This functional description could be argued to encompass modern software performing the same role.
- Intrinsic Evidence for a Narrower Interpretation: The specification explicitly states the component is "implemented as a 'midlet' on a Java cellphone, or an 'executable application' on a PDA device" (’218 Patent, col. 5:10-13). This language could be used to argue the term is limited to its well-known technical meaning in the J2ME context.
VI. Other Allegations
- Indirect Infringement: The complaint alleges that Visa induces infringement by providing customers, end-users, and NFC-enabled phone providers with instructions, technical support, marketing materials, and other documentation that "suggest[] that they use the Accused Products in an infringing manner" (Compl. ¶29, ¶47). It is also alleged that Visa "directs and controls the actions of others" by conditioning the benefit of using Visa's network on satisfying the claimed elements (Compl. ¶28, ¶46).
- Willful Infringement: The willfulness claim is based on alleged pre-suit knowledge. The complaint alleges Visa has known of the patents-in-suit "at least since December 20, 2021," when it was served a subpoena in other litigation that identified the patents (Compl. ¶14).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope and technological evolution: Can claim terms like "e-purse applet" and "midlet", which are rooted in the specific Java-based mobile architecture of the mid-2000s, be construed broadly enough to cover the functionalities of modern, OS-integrated tokenization systems like the Visa Token Service? The outcome may depend on whether the court adopts a functional definition or one tied to the specific embodiments disclosed in the patents.
- A key evidentiary question will be one of architectural mapping: Does the accused Visa Token Service system, with its complex interactions between device software, a secure element, and multiple server entities, actually implement the specific, layered security model claimed in the patents, particularly the requirement of "creating a security channel on top of the initial security channel"? The plaintiff will need to demonstrate a precise technical correspondence between the accused system and this claimed architecture.
- A central question for damages and indirect infringement will be knowledge and intent: Given the complaint’s allegation of pre-suit notice via a subpoena in related litigation, the focus will be on what evidence demonstrates Visa's state of mind regarding the patents-in-suit and whether its subsequent actions rise to the level of willfulness or inducement.