DCT
6:23-cv-00048
Cortex MCP Inc v. Visa Inc
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Cortex MCP, Inc. (Delaware)
- Defendant: Visa, Inc. (Delaware)
- Plaintiff’s Counsel: Susman Godfrey L.L.P.; Cherry Johnson Siegmund James; Davis Cedillo & Mendoza Inc.
- Case Identification: 6:23-cv-00048, W.D. Tex., 04/10/2023
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Visa is registered to do business in Texas, has committed alleged acts of infringement in the district, and maintains a regular and established place of business in Austin, Texas.
- Core Dispute: Plaintiff alleges that Defendant’s Visa Token Service infringes four U.S. patents related to the secure generation, storage, and verification of digital credentials for mobile payments.
- Technical Context: The technology at issue involves replacing sensitive payment card data with a unique digital identifier, or "token," to secure transactions made via mobile wallets and other digital platforms.
- Key Procedural History: The complaint alleges that Plaintiff disclosed its technology and patents to Defendant or its subsidiary during meetings and communications in July 2013 and April 2016, prior to the filing of the lawsuit.
Case Timeline
| Date | Event |
|---|---|
| 2012-12-21 | Patent Priority Date for all Asserted Patents |
| 2013-07-01 | Cortex meets with Visa's CyberSource subsidiary |
| 2016-02-02 | U.S. Patent No. 9,251,531 Issues |
| 2016-04-01 | Cortex provides technology overview to Visa |
| 2018-04-24 | U.S. Patent No. 9,954,854 Issues |
| 2020-08-18 | U.S. Patent No. 10,749,859 Issues |
| 2022-05-10 | U.S. Patent No. 11,329,973 Issues |
| 2023-04-10 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,251,531 - “File format and platform for storage and verification of credentials”
The Invention Explained
- Problem Addressed: The patent’s background section describes that early mobile wallet adoption was hampered by security concerns and the need for specialized hardware, such as "secure element chips," which were not widely available in consumer smartphones, leading to a poor user experience compared to traditional credit cards (Compl. ¶8; ’531 Patent, col. 1:35-51).
- The Patented Solution: The invention proposes a system centered on an "Officially Verifiable Electronic Representation" (OVER) file. This system involves a central engine that generates a secure digital file (a token or "OVER file") representing a user's credential. This file can be stored on a standard mobile device, presented for a transaction at a third-party verifier (e.g., a merchant), and then authenticated by the central engine, which confirms the token's validity without exposing the underlying sensitive credential data (’531 Patent, Abstract; col. 3:62-4:21).
- Technical Importance: This architecture aimed to enable secure mobile payments across a broad range of devices by centralizing the core verification function, thereby removing the dependency on specialized, local hardware on the user's device (’531 Patent, col. 1:45-51).
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶16).
- The essential elements of Claim 1 of the ’531 Patent include:
- Storing information associated with a user's credential in a central engine.
- Receiving a generation request from a user's client device.
- Generating an "OVER file" that is a virtual representation of the credential, verified by an issuing agency.
- Transmitting the OVER file back to the user's device.
- Receiving a verifying request from a third-party device based on a "scan" associated with the OVER file.
- Verifying that the scan corresponds to the stored credential information.
- Transmitting an authentication message back to the third-party device.
- The complaint reserves the right to assert other claims and infringement under the doctrine of equivalents (Compl. ¶16, ¶18).
U.S. Patent No. 9,954,854 - “File format and platform for storage and verification of credentials”
The Invention Explained
- Problem Addressed: The patent addresses the same underlying technical problem as the ’531 Patent: the need for a secure and convenient system for storing and displaying user credentials for digital transactions (’954 Patent, col. 1:31-49).
- The Patented Solution: This patent, a continuation of the family, claims a non-transitory computer-readable medium with instructions to perform a process that extends the initial tokenization concept. The claimed method explicitly addresses the lifecycle of credentials across multiple user devices by describing a process for a "first OVER file" on a "first ... client device" and a distinct "second OVER file" on a "second ... client device," where the second file is described as being "invalid for use in the first OVER file client device" (’954 Patent, col. 2:2-27). This suggests a mechanism for managing token validity as users acquire new devices.
- Technical Importance: The invention adds a claimed capability for managing the lifecycle of digital credentials, allowing for the secure provisioning of a new token to a new device while potentially invalidating the token on a previous device (’954 Patent, col. 7:25-44).
Key Claims at a Glance
The complaint asserts independent claim 15 (Compl. ¶37).
The essential elements of Claim 15 of the ’854 Patent include instructions for a processor to perform operations comprising:
- Accessing a "first OVER file" on a "first OVER file client device."
- Transmitting a first verifying request to an engine, receiving a first authentication message, and outputting a first status indicator.
- Accessing a "second OVER file" on a "second OVER file client device," where this second file represents the same original credential but is "invalid for use in the first OVER file client device."
- Transmitting a second verifying request, receiving a second authentication message, and outputting a second status indicator for the second file.
The complaint reserves the right to assert other claims and infringement under the doctrine of equivalents (Compl. ¶37, ¶38).
Multi-Patent Capsule: U.S. Patent No. 10,749,859
- Patent Identification: 10,749,859, “File format and platform for storage and verification of credentials,” issued August 18, 2020 (Compl. ¶57).
- Technology Synopsis: This patent claims a method for verifying digital credentials where both the user's device and the merchant's point-of-sale terminal are specifically recited as being Near Field Communication (NFC) enabled devices. The communication and verification steps are explicitly based on an "NFC protocol-based communication" (’859 Patent, col. 21:64-22:24).
- Asserted Claims: Independent claim 1 (Compl. ¶60).
- Accused Features: The complaint accuses Visa's implementation of VTS for in-store contactless payments, where a user initiates a transaction by tapping an NFC-enabled mobile device on an NFC-enabled merchant terminal (Compl. ¶63, ¶66).
Multi-Patent Capsule: U.S. Patent No. 11,329,973
- Patent Identification: 11,329,973, “File format and platform for storage and verification of credentials,” issued May 10, 2022 (Compl. ¶77).
- Technology Synopsis: Building on the NFC-focused claims of the ’859 patent, this patent adds steps wherein the central verification engine actively requests "an agency authentication" from the credential's "issuing agency" (e.g., a card-issuing bank) to validate the credential. The engine then receives and stores a "status indicator" based on the agency's response (’973 Patent, col. 22:31-41).
- Asserted Claims: Independent claim 1 (Compl. ¶80).
- Accused Features: The complaint accuses the VTS workflow where Visa's network communicates with the card-issuing bank to validate that a presented token corresponds to a valid user account, and subsequently receives and stores the authentication status (Compl. ¶89-91).
III. The Accused Instrumentality
- Product Identification: The Visa Token Service (VTS) (Compl. ¶16).
- Functionality and Market Context: VTS is a commercial technology service that replaces a cardholder’s primary account number (PAN) with a unique digital identifier, or token (Compl. ¶19). This token is then provisioned to a user's digital wallet (e.g., Apple Pay, Samsung Pay) and used to process transactions without exposing the sensitive PAN (Compl. ¶20-22). The complaint alleges that VTS performs the entire lifecycle of tokenization: receiving requests from wallets, generating tokens, coordinating approval with issuing banks, delivering tokens to devices, and processing verification requests from merchants for both online and in-store NFC transactions (Compl. ¶23). The complaint references an infographic depicting the tokenization process, which shows a user's PAN being sent from a mobile device to the Visa network, which then returns a secure token to the device for use in transactions (Compl. ¶20, n.9). VTS is based on the EMVCo payment tokenization standard, a global framework for secure payments (Compl. ¶16).
IV. Analysis of Infringement Allegations
- 9,251,531 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| storing, in a memory of an officially verifiable electronic representation (OVER) generation and verification engine, information associated with a credential of a user... | The Visa Network, implementing VTS, stores a user's Primary Account Number (PAN) and other cardholder information in its digital Token Vault. | ¶19 | col. 4:1-4 |
| receiving, from an OVER file storage client device of the user, an OVER file generation request... | A digital wallet on a user's phone, acting as a "Token Requestor," sends a request to VTS to generate a payment token. | ¶20 | col. 5:26-30 |
| generating, by a processor of the OVER engine, an OVER file comprising a virtual representation of the credential that has been verified by an issuing agency... | The Visa Network ("OVER engine") generates a token and shares it with the credit card issuer ("issuing agency") for approval and verification. | ¶21 | col. 6:35-41 |
| transmitting, to the OVER file storage client device of the user, the OVER file in response to the OVER file generation request | The approved token ("OVER file") is transmitted from VTS back to the digital wallet on the user's phone. | ¶22 | col. 7:25-29 |
| receiving, from an OVER file third-party client verifying device, a verifying request to verify that the OVER file... authenticates the user based on a scan... | A merchant's point-of-sale (POS) terminal receives payment data from the user's device (e.g., via NFC tap) and sends a "Token Payment Request" to the Visa Network for verification. | ¶23 | col. 8:4-15 |
| verifying that the scan associated with the OVER file corresponds with the information associated with the credential of the user that is stored in the OVER engine... | The Visa Network verifies that the payment token received from the POS terminal corresponds to the PAN stored in its Token Vault. | ¶24 | col. 8:40-52 |
| transmitting, to the OVER file third-party client verifying device, an authentication message... | A payment authorization message is sent from the Visa Network back to the merchant's POS terminal, indicating whether the transaction is approved. | ¶25 | col. 8:50-56 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether the patent-specific term "OVER file" can be construed to encompass the industry-standard "payment token" generated by VTS. Further, the construction of "scan" will be critical; the complaint alleges it reads on an NFC tap, which may be disputed if the patent's specification is found to primarily disclose optical scanning.
- Technical Questions: Does the accused VTS system require verification by an "issuing agency" for every token generation as recited in the claim, or are there instances where Visa's network may generate a token without immediate issuer verification?
- 9,954,854 Infringement Allegations
| Claim Element (from Independent Claim 15) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A non-transitory computer-readable medium comprising instructions that...cause the processor to perform operations comprising: accessing a first OVER file stored on a first OVER file client device... | The VTS system is executed via instructions on computer-readable media and involves accessing a payment token ("first OVER file") stored on a user's primary mobile device ("first... client device"). | ¶39 | col. 4:1-7 |
| transmitting to the OVER engine a first verifying request... receiving a first authentication message... and outputting a first status indicator... | During a transaction, the user's device sends the token to the Visa Network ("OVER engine") for verification, which results in an authentication message and a status indicator (approval/denial) being returned to the merchant. | ¶42-44 | col. 8:50-56 |
| accessing a second OVER file stored on a second OVER file client device... wherein the second OVER file... is invalid for use in the first OVER file client device for authenticating the user... | The VTS system supports provisioning a new token ("second OVER file") to a user's new device ("second... client device"), which corresponds to the original credential but is tied to the new device. | ¶45 | col. 7:29-44 |
| transmitting to the OVER engine a second verifying request... receiving a second authentication message... and outputting a second status indicator... | The transaction verification process for the token on the second device mirrors the process for the first device. | ¶46-48 | col. 8:50-56 |
- Identified Points of Contention:
- Technical Questions: The claim requires that the "second OVER file" be "invalid for use in the first OVER file client device." A key factual question will be whether Visa's system architecture automatically and necessarily invalidates a token on a first device upon provisioning a token for the same credential to a second device, or if multiple devices can have concurrently valid tokens.
V. Key Claim Terms for Construction
The Term: "OVER file"
Context and Importance: This term is the foundation of all asserted claims. Its construction will determine whether Visa's standards-based "payment token" falls within the scope of the claims. Practitioners may focus on this term because the patent uses a seemingly proprietary term, while the accused product uses an industry-standard one.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the term functionally as a "virtual representation of the credential" and a "secure file format and platform for the storage and verification of key user or consumer credentials," language which could support a broad definition covering any digital token serving that purpose (’531 Patent, col. 3:62-64; col. 4:62-65).
- Evidence for a Narrower Interpretation: Defendant may argue that "OVER file" refers to a specific file structure, pointing to detailed depictions of credential layouts in the specification (e.g., Figures 9 and 10) that may differ from the structure of an EMVCo token (’531 Patent, col. 12:62-13:54).
The Term: "scan associated with the OVER file" (from the ’531 Patent)
Context and Importance: This term defines how a transaction is initiated at a merchant. Whether it covers modern contactless payment methods like NFC is critical to the infringement analysis for the earliest patent in the family.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language "scan associated with the OVER file" could be argued to be broader than "scanning the OVER file" itself, potentially covering any action that electronically reads data linked to the file, such as an NFC tap.
- Evidence for a Narrower Interpretation: The specification of the ’531 patent predominantly provides examples of optical scanning, such as a user scanning a QR code on a credential or a third party scanning a QR code displayed on a user's device screen (’531 Patent, col. 5:26-41; Fig. 8). The fact that later patents in the same family explicitly added limitations reciting "NFC" could be used to argue that the scope of "scan" in the original patent was not intended to include it.
VI. Other Allegations
- Indirect Infringement: The complaint alleges active inducement, asserting that Visa provides extensive documentation, developer guides, Application Programming Interfaces (APIs), and technical frameworks (via EMVCo) that instruct and encourage banks, merchants, and developers to implement and use the VTS in an infringing manner (Compl. ¶27).
- Willful Infringement: The complaint alleges willful infringement of the ’531 Patent based on pre-suit knowledge. It alleges that Cortex disclosed its technology, patent applications, and the issued ’531 Patent to Visa and its subsidiary CyberSource in meetings and communications in July 2013 and April 2016 (Compl. ¶10-11, ¶101). For the other patents, knowledge is alleged from the date of service of the complaint (Compl. ¶49, ¶69, ¶92).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "OVER file," which appears to be a construct of the patentee, be construed broadly enough to read on the industry-standard "payment token" used by the Visa Token Service, or is it limited to the specific file structures disclosed in the patent specification?
- A key claim construction question will be one of technological breadth: does the term "scan" in the '531 Patent, which is primarily exemplified by optical scanning, encompass the Near-Field Communication (NFC) tap that underpins modern in-store contactless payments, especially in light of later family patents explicitly adding NFC limitations?
- An important evidentiary question for the '854 Patent will concern credential lifecycle management: does the VTS architecture inherently render a token on a user's first device "invalid for use" upon the provisioning of a token to a second device, as strictly required by the claim, or can multiple valid tokens for the same credential coexist across different devices?