DCT
6:23-cv-00708
RFCyber Corp. v. Visa U.S.A. Inc.
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: RFCyber Corp. (Texas)
- Defendant: Visa USA. 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: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district and has committed alleged acts of infringement there.
- Core Dispute: Plaintiff alleges that Defendant’s payment tokenization services, including Visa Token Service and related platforms, infringe four patents related to secure mobile and contactless payment technologies.
- Technical Context: The patents address methods for enabling secure financial transactions on portable devices like mobile phones over open networks by creating secure channels between the device and back-end servers.
- Key Procedural History: The complaint alleges that Defendant has been aware of the patents-in-suit since at least December 20, 2021, when it was served with a subpoena in a separate litigation, RFCyber v. Samsung. This allegation forms the primary basis for the claim of willful infringement.
Case Timeline
| Date | Event |
|---|---|
| 2006-09-24 | Earliest Priority Date for all Patents-in-Suit |
| 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 | Alleged date of Visa's knowledge of the Patents-in-Suit |
| 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 February 21, 2012
The Invention Explained
- Problem Addressed: The patent describes the difficulty of extending closed-loop contactless payment systems (like those for transit) to open environments like the internet ("e-commerce") or cellular networks ("m-commerce") due to the security risks of delivering cryptographic keys over public networks (ʼ218 Patent, col. 1:22-38).
- The Patented Solution: The invention proposes a system where a portable device, such as a cellphone, is equipped with a smart card module containing an "e-purse applet" and an emulator. A software component called a "midlet" on the device facilitates communication between the e-purse applet and a remote payment server. Security is managed by personalizing the e-purse applet with operation keys that establish a secured channel to an external Security Authentication Module (SAM), which can be a backend server (ʼ218 Patent, Abstract; col. 2:1-8). The architecture contemplates distinct communication paths for mobile commerce (wireless) and e-commerce (wired, via a PC agent) (ʼ218 Patent, Fig. 2).
- Technical Importance: The invention describes a layered security architecture intended to allow a single portable device to function as a secure "e-purse" for transactions in both physically-proximate (contactless) and remote (online) commerce environments (ʼ218 Patent, col. 1:40-49).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶20).
- Claim 1 is a method claim with the following essential elements:
- Providing a portable device with a smart card pre-loaded with an emulator and a memory space loaded with a "midlet."
- The midlet facilitates 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 it communicates 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, which are used to establish a secured channel with an external "e-purse security authentication module (SAM)."
- This personalization involves establishing an initial security channel to install and personalize the applet, and then 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 a continuation of the '218 patent, the '855 patent addresses the same fundamental problem of enabling secure e-purse transactions, with a specific focus on the process of funding the e-purse (ʼ855 Patent, col. 1:33-47).
- The Patented Solution: The invention is a method for funding an e-purse on a portable device. After a user enters a PIN, a "midlet" on the device sends a request to an "e-purse applet." The applet composes a response and sends it to a server, which verifies the response against an account at a financial institution and initiates a fund transfer. The server then sends commands back to the device, and an emulator updates a transaction log. This entire process is secured by the same two-layer security channel personalization described in the parent '218 patent (ʼ855 Patent, Abstract; col. 8:1-25).
- Technical Importance: The technology details a specific workflow for securely adding value to a mobile wallet from a remote financial source, a critical function for the viability of e-purse systems (ʼ855 Patent, col. 1:8-14).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶37).
- Claim 1 is a method claim with the following essential elements:
- Receiving a PIN from a user of a portable NFC device containing a card module.
- Initiating a request from a "midlet" to an "e-purse applet" after PIN verification.
- Causing the e-purse applet to compose a response and send it over a wireless network to a server.
- The server verifies the response and initiates a fund transfer request to a financial institution.
- Receiving commands from the server in response to the fund transfer.
- Causing an emulator to update a transaction log after the e-purse applet verifies the commands' authenticity.
- The method relies on the e-purse having been personalized by establishing an initial security channel with an external SAM and creating a second security channel on top of the first.
Multi-Patent Capsule
U.S. Patent No. 9,189,787 - "Method and Apparatus for Conducting E-Commerce and M-Commerce," Issued November 17, 2015
- Technology Synopsis: This patent describes a portable commerce device comprising an emulator, an e-purse applet, and a "purse manager midlet." The device has two distinct interfaces: a first (NFC) interface for local e-commerce and a second interface for mobile commerce with a remote payment server. The system is secured through a personalization process that establishes security channels and sets keys for authentication (Compl. ¶55).
- Asserted Claims: At least independent claim 1 (Compl. ¶55).
- Accused Features: The complaint alleges that Visa's services, which enable both NFC payments and mobile commerce, infringe by providing a portable device (a phone) with an emulator (in an NFC Module), an e-purse applet (payment card applet), and a purse manager midlet (mobile wallet application) that operate in a manner corresponding to the claim (Compl. ¶56-61).
U.S. Patent No. 9,240,009 - "Mobile Devices for Commerce Over Unsecured Networks," Issued January 19, 2016
- Technology Synopsis: This patent focuses on the provisioning of a secure application on a mobile device. The method involves the device sending identifiers for the application and a secure element to a server. The server uses this information to prepare necessary data and establish a secured channel with the secure element using a pre-installed key set. The server then sends the data to the device, associating the application with the secure element so it can function securely (Compl. ¶71).
- Asserted Claims: At least independent claim 1 (Compl. ¶71).
- Accused Features: The complaint alleges Visa's Token Service infringes by comprising a process where a mobile device communicates with a Visa server to provision a payment application (Visa card applet) onto a secure element, establishing a secure channel to download keys and other data necessary for the applet to function (Compl. ¶72-78).
III. The Accused Instrumentality
Product Identification
- The complaint identifies the accused instrumentalities as a suite of services including, but not limited to, Visa Token Service (VTS), Visa Ready, Token ID, Visa payWave, and other Token Service Provider and/or Trusted Service Manager solutions (the "Accused Products") (Compl. ¶12).
Functionality and Market Context
- The Accused Products provide a system for replacing a cardholder's sensitive 16-digit Primary Account Number (PAN) with a unique digital identifier called a "token" (Compl. p. 8). As described in a diagram from Visa's materials included in the complaint, this tokenization process is initiated when a consumer enrolls a card in a digital wallet. A token requestor asks Visa's Token Service for a token, which, with issuer approval, replaces the PAN. This token is then used for online and NFC payments, protecting the underlying PAN from exposure (Compl. p. 12, "How Visa Token Service Works" diagram). The complaint alleges these services enable functionality to "personalize a payment card applet, emulate a payment card, and process a transaction via NFC" (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 configured to execute a request from an e-purse applet... 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... | NFC-enabled phones configured with Visa Token Service include a smart card (e.g., NFC module, secure element) pre-loaded with an emulator. These phones also have memory and a "midlet," described as client-side software (e.g., an SDK) that facilitates communication with a payment server over a wireless network (Compl. p. 9, diagram). | ¶21, ¶22 | col. 2:11-18 |
| 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 (Compl. p. 10, "Provisioning Diagram"). | ¶23 | col. 7:45-53 |
| personalizing the e-purse applet by reading off data from the smart card to generate in the smart card one or more operation keys that are subsequently used to establish a secured channel between the e-purse applet and an e-purse security authentication module (SAM) external to the smart card... | The Visa Token Service establishes operations keys for secure connections between a stored payment card and an authentication module at a server of the card issuer and/or merchant when adding a card or during transactions. | ¶25 | col. 2:20-29 |
| wherein said personalizing the e-purse applet comprises: establishing an initial security channel between the smart card and the e-purse SAM to install and personalize the e-purse applet in the smart card... | 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 smart card's secure element (Compl. p. 12, diagram). | ¶26 | col. 8:58-62 |
| and creating a security channel on top of the initial security channel to protect subsequent operations of the smart card with the e-purse SAM, wherein any subsequent operation of the emulator is conducted over the security channel via the e-purse applet. | Once a Visa payment card applet is installed, subsequent operations are conducted via the e-purse applet using the security key installed during personalization. | ¶27 | col. 8:62-68 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether Visa's distributed, server-based architecture (e.g., "Visa Token Service," "Visa TSP server") constitutes the "e-purse security authentication module (SAM) external to the smart card" as claimed. The patent's use of "SAM" and its depiction as a discrete "SAM Module" (ʼ218 Patent, Fig. 2) could suggest a requirement for a specific hardware security module, raising the question of whether a collection of servers meets this limitation.
- Technical Questions: Claim 1 requires "creating a security channel on top of the initial security channel." The complaint alleges this is met by conducting subsequent operations "using the security key installed during the personalization process" (Compl. ¶27). This raises the evidentiary question of whether simply using a previously-installed key is functionally equivalent to the claim's specific requirement of creating a distinct, layered security channel.
'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 Visa Token Service include a card module (e.g., secure element or NFC Controller) and require a PIN to unlock the device and to carry out transactions via NFC. | ¶38 | col. 7:48-52 |
| 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 verification, the Visa Token Service (and/or associated client-side SDK, the alleged "midlet") sends a request to a payment card applet (the alleged "e-purse applet"). This is depicted in the "Provisioning Diagram" where the device sends a load request after user input (Compl. p. 17). | ¶39 | col. 7:52-54 |
| 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 across a network... | The Visa card applet sends a response to a payment/gateway server (e.g., a Visa TSP server) over a wireless network. The server is configured to verify the response and request funds to complete the transaction. | ¶41 | col. 7:59-65 |
| causing an emulator in the portable device to update a transaction log after an authenticity of the commands is verified by the e-purse applet... | An emulator within NFC-enabled phones updates a transaction log once commands have been authenticated by the installed and configured Visa card applet. | ¶43 | col. 8:10-13 |
| wherein the e-purse in the portable device has been personalized by operations including: establishing an initial security channel between the card module and an e-purse security authentication module (SAM) external to the card module... | The Accused Products personalize payment card applets by establishing an initial security channel with a security authentication module (e.g., a Visa TSP server) to install and configure the payment cards. The "How Visa Token Service Works" diagram shows this flow from consumer enrollment to token issuance (Compl. p. 20). | ¶44 | col. 8:16-22 |
- Identified Points of Contention:
- Scope Questions: As with the '218 patent, a primary dispute may concern whether the modern "client-side service and/or SDK" (Compl. ¶39) falls within the scope of the term "midlet," a term strongly associated with Java ME technology from the patent's era.
- Technical Questions: The claim requires the server to initiate a "fund transfer request... to the financial institution." The complaint's allegations and supporting diagrams describe a token authorization flow where Visa sends the token to the card issuer for authorization (Compl. p. 19, "Purchase Transaction Flow" diagram, step 4). A court may need to determine if this authorization process is the same as the claimed "fund transfer request."
V. Key Claim Terms for Construction
Term: "midlet" ('218 Patent, cl. 1; '855 Patent, cl. 1)
- Context and Importance: This term appears in the asserted independent claims of both lead patents. Its construction is critical because the patents were filed when "MIDlet" had a specific technical meaning (a Java ME application for mobile devices), while the Accused Products use modern software development kits (SDKs) and client-side applications. Practitioners may focus on this term to dispute whether the patent's scope is limited to the specific technology of its time or reads on modern equivalents.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification provides a general definition, describing a midlet as "a software component suitable for being executed on a portable device" ('218 Patent, col. 5:9-11).
- Evidence for a Narrower Interpretation: The specification immediately follows the broader definition with a specific example: "implemented as a 'midlet' on a Java cellphone" ('218 Patent, col. 5:11-12). This explicit tie to Java technology of the era could be used to argue for a narrower construction limited to that context.
Term: "e-purse security authentication module (SAM) external to the smart card" ('218 Patent, cl. 1; '855 Patent, cl. 1)
- Context and Importance: The definition of this term will determine whether Visa's distributed, server-based tokenization infrastructure can meet this claim limitation. The infringement allegations map this term to components like "an authentication module at a server of the card issuer" (Compl. ¶25) and a "Visa TSP server" (Compl. ¶26).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification suggests flexibility, stating that during a transaction, security keys are used to establish a channel between the e-purse and a "SAM (Security Authentication Module) or backend server" ('218 Patent, col. 2:6-8), which may support construing the term to cover a server system.
- Evidence for a Narrower Interpretation: The figures depict a discrete "SAM Module" (e.g., '218 Patent, Fig. 2, element 212). In the smart card industry, a "SAM" often refers to a specific, physical secure hardware module. An argument could be made that the claims require such a discrete component, not a distributed server architecture.
VI. Other Allegations
- Indirect Infringement: The complaint alleges both induced and contributory infringement. Inducement is alleged based on Visa providing the Accused Products with "instructions, documentation, and other information to customers and end-users suggesting that they use the Accused Products in an infringing manner" (Compl. ¶29, ¶47, ¶63, ¶80). Contributory infringement is alleged on the basis that components like the Visa Token Service are material to the invention, not staple articles of commerce, and are known by Visa to be especially adapted for infringement (Compl. ¶30, ¶48, ¶64, ¶81).
- Willful Infringement: Willfulness is alleged based on Visa's purported knowledge of the Patents-in-Suit "at least since December 20, 2021, when it received service of a subpoena issued by RFCyber in the action of RFCyber v. Samsung Elecs. Co." (Compl. ¶14). The complaint further alleges that Visa received correspondence from Samsung that also identified the patents, reinforcing the notice allegation.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of technological translation: Can claim terms rooted in the mobile technology of the mid-2000s, such as "midlet" and "SAM," be construed to cover the distributed, server-based software architecture of Visa's modern tokenization platform? The outcome will likely depend on whether these terms are interpreted by their general function or by their specific technical meaning at the time of invention.
- A key evidentiary question will be one of functional specificity: Do the security protocols of the Accused Products perform the specific, two-step process of "establishing an initial security channel" and then "creating a security channel on top of the initial security channel" as required by the claims, or does Visa's system use a more generalized security key management scheme that is functionally different?
- A central dispute will likely focus on architectural equivalence: Can RFCyber prove that Visa's complex, multi-component system, including the Visa Token Service, backend servers, and issuer networks, collectively functions as the relatively discrete "e-purse security authentication module (SAM)" envisioned in the patents, or is there a fundamental architectural mismatch?