DCT
1:24-cv-03547
AuthWallet LLC v. Total System Services LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: AuthWallet LLC (Texas)
- Defendant: Total System Services Inc (Georgia)
- Plaintiff’s Counsel: The Ducos Law Firm, LLC
- Case Identification: 1:24-cv-03547, N.D. Ga., 09/11/2024
- Venue Allegations: Plaintiff alleges venue is proper in the Northern District of Georgia because Defendant maintains 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 processing systems and services infringe a patent related to processing financial transactions using an intermediary server and out-of-band confirmation on a customer's mobile device.
- Technical Context: The technology concerns methods for enhancing the security of electronic payments by adding a mobile device confirmation step, a field of significant importance in the financial technology sector for fraud reduction.
- Key Procedural History: Plaintiff, a non-practicing entity, notes that it and its predecessors have entered into settlement licenses with other entities, but asserts that none of these licenses were for producing a patented article, which may be an attempt to preemptively address patent marking defenses. The patent was assigned to AuthWallet, LLC in March 2020.
Case Timeline
| Date | Event |
|---|---|
| 2008-11-08 | U.S. Patent No. 8,099,368 Priority Date |
| 2012-01-17 | U.S. Patent No. 8,099,368 Issued |
| 2017-05-30 | Global Payments (TSYS) enables tokenization for commercial issuers |
| 2020-03-06 | Patent assigned to AuthWallet, LLC |
| 2024-09-11 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,099,368 - Intermediary service and method for processing financial transaction data with mobile device confirmation
- Patent Identification: U.S. Patent No. 8,099,368, issued January 17, 2012.
The Invention Explained
- Problem Addressed: The patent addresses several competing concerns in electronic transaction systems, including the need for merchants to reduce processing fees, the challenge of detecting fraudulent transactions in real-time, and the inconvenience for consumers of managing multiple payment methods and verifying transactions only after the fact via statements (’368 Patent, col. 1:18-62).
- The Patented Solution: The invention describes an "intermediary service" that sits between the transaction acquirer and the card-issuing institution (’368 Patent, col. 2:36-42). When a transaction is initiated, this service receives the request and uses an "out-of-band" channel to send a notification to the customer's mobile device (’368 Patent, col. 2:42-46; Fig. 2B). This allows the customer to confirm or deny the transaction, and potentially select from multiple payment instruments, before the intermediary service provides the necessary account information to the acquirer to complete the transaction (’368 Patent, col. 3:35-55).
- Technical Importance: This approach introduced an active, real-time consumer verification step into the payment authorization flow, aiming to reduce fraud at the moment of transaction rather than through after-the-fact analysis.
Key Claims at a Glance
- The complaint asserts claims 1-29 of the ’368 Patent (Compl. ¶9). Independent claim 1 is detailed below.
- Claim 1 is a method for processing financial transaction data in a server, comprising the steps of:
- Receiving an authorization request from a requester for a transaction at a point of purchase.
- Authenticating the authorization request.
- Retrieving customer information from storage, including data on multiple payment instruments and a mobile device address.
- Generating a transaction indication message for the mobile device that allows selection from at least two payment instruments.
- Transmitting the message to the mobile device.
- Receiving a customer confirmation message from the mobile device that includes a selected payment instrument.
- Obtaining customer account information from an issuing institution, where the account information includes a first part encrypted by a first method and a second part encrypted by a second method, with the server being capable of decrypting the first part but not the second.
- Providing the customer account information to the requester if the transaction is authorized.
- The complaint reserves the right to assert other claims, including dependent claims (Compl. ¶9).
III. The Accused Instrumentality
Product Identification
The accused instrumentalities are Defendant’s "Payment Solutions," which include acquiring and issuing financial transaction data services, specifically referencing the "TransIT" platform and its associated APIs (Compl., Ex. B, pp. 41, 48).
Functionality and Market Context
- The complaint alleges that Defendant’s services, such as those detailed in its "TransIT API 3.0" documentation, provide an infrastructure for processing payment transactions (Compl., Ex. B, p. 48). This includes receiving authorization requests from merchants (requesters), authenticating transactions, enabling notifications and receipts, and facilitating payment using various methods, including tokenization (Compl., Ex. B, p. 38). The complaint provides a screenshot of a "TSYS Developer" portal listing services such as "Network Tokenization," "Notification and receipts," and "Account Funding Transaction" as part of the accused functionality (Compl., Ex. B, p. 38).
- The complaint alleges these services are central to Defendant’s business of processing electronic payments for merchants and financial institutions.
IV. Analysis of Infringement Allegations
’368 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method for processing financial transaction data in a server including a processor and an associated storage area... | Defendant's payment solutions allegedly operate on servers with processors and storage to handle mobile payments, authentication, and tokenized transaction information. A screenshot from Defendant's website describes its "cloud-native platform." (Compl., Ex. B, p. 41). | ¶9; Ex. B, p. 41 | col. 10:46-50 |
| receiving from a requester an authorization request generated as a result of a transaction at a point of purchase, wherein the authorization request includes a purchaser identifier, a transaction amount, and information identifying the point of purchase; | Defendant's systems allegedly receive authorization requests (e.g., ISO-8583 format) from requesters (acquirers/issuers) that include payment details, a purchaser identifier, transaction amount, and point-of-sale terminal ID. The complaint points to API documentation for an "Auth message." (Compl., Ex. B, p. 42). | ¶9; Ex. B, p. 42 | col. 5:8-14 |
| retrieving customer information associated with the purchaser identifier from the storage area, the customer information including data defining multiple payment instruments and an address associated with a mobile device of the customer; | Stored customer information (e.g., card owner name, address, payment methods, contact device details) is allegedly retrieved from Defendant's databases via an API request using a purchaser identifier. A screenshot shows API fields for "cardHolderName", "addressLine1", and "tokenRequired". (Compl., Ex. B, p. 47). | ¶9; Ex. B, p. 47 | col. 5:23-33 |
| generating a transaction indication message for transmittal to the mobile device of the customer, the transaction indication message including information about the transaction and specifying a response that allows a selection of a payment instrument from at least two of the multiple payment instruments... | Defendant's "TransIT API 3.0" allegedly enables the generation and customization of transaction messages to devices, which can specify different payment methods. A presented diagram shows a "Merchant Payment Form" with payment options. (Compl., Ex. B, p. 49). | ¶9; Ex. B, pp. 48-49 | col. 5:34-38 |
| receiving a customer confirmation message from the mobile device in response to the transaction indication message, wherein the customer confirmation message includes a selected payment instrument; | Defendant is alleged to receive customer confirmation, including the selected payment method, via its mobile payment applications. The complaint includes a screenshot from a TSYS demo video showing a "SUCCESSFUL" transaction on a mobile phone with a specific card selected. (Compl., Ex. B, p. 52). | ¶9; Ex. B, p. 52 | col. 6:51-56 |
| obtaining customer account information from an issuing institution... the customer account information including a first part encrypted according to a first encryption method and a second part encrypted according to a second encryption method... such that the server is capable of decrypting the first part and is not capable of decrypting the second part; | Plaintiff alleges Defendant's systems obtain account information from issuers and that PCI-DSS standards require two different types of encryption: strong encryption for the PAN data itself ("first part") and session-level encryption for the transmission protocol ("second part"). The complaint alleges the server can handle the session but not decrypt the underlying PAN. | ¶9; Ex. B, pp. 54-57 | col. 19:50-61 |
Identified Points of Contention
- Technical Question: The central dispute may concern the final limitation of claim 1 regarding two distinct encryption methods where the server can decrypt the "first part" but not the "second part." The complaint's theory appears to map the "first part" to encrypted PAN data and the "second part" to the encrypted transmission session (e.g., TLS). However, the complaint then argues that Defendant's servers are not capable of decrypting the PAN data itself (Compl., Ex. B, p. 57), which raises the question of whether this allegation contradicts the claim requirement that the server is "capable of decrypting the first part." The evidence and arguments regarding the architecture of Defendant's servers and the specific capabilities of each component will be critical.
- Scope Question: Does the functionality described in Defendant's high-level marketing materials and API documentation (e.g., Compl., Ex. B, pp. 38, 41) actually perform the specific, ordered steps of the claimed method? For example, what evidence demonstrates that Defendant's system generates a message that explicitly "allows a selection of a payment instrument from at least two of the multiple payment instruments" and transmits it to a mobile device for confirmation before obtaining account information from the issuer, as the claim requires?
V. Key Claim Terms for Construction
- The Term: "a first part encrypted according to a first encryption method and a second part encrypted according to a second encryption method... selected such that the server is capable of decrypting the first part and is not capable of decrypting the second part"
- Context and Importance: This complex limitation appears to be the core of the asserted novelty and will likely be the focal point of the infringement and validity analysis. The construction of what constitutes the "first part," "second part," and the server's specific decryption capabilities will determine whether Defendant’s PCI-DSS compliant architecture infringes.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent does not appear to explicitly define "first part" or "second part." A party might argue these terms should be given their plain and ordinary meaning in the context of routing encrypted data, where different data elements within a single transmission can be encrypted with different keys for different recipients.
- Evidence for a Narrower Interpretation: The specification, particularly Figure 9 and the accompanying text, provides a specific embodiment of multi-party encryption (’368 Patent, col. 18:35-65). It describes a system where an acquirer and an issuing institution can exchange messages encrypted with a key (Key D) that the intermediary service cannot decrypt, while the intermediary service communicates with those parties using different keys (Keys A' and C'). A party could argue that the claim terms must be limited to this specific "pass-through" encryption architecture, where the "second part" is the data encrypted with Key D, which the intermediary "is not capable of decrypting."
VI. Other Allegations
- Indirect Infringement: The complaint alleges both induced and contributory infringement. For inducement, it alleges Defendant "actively encouraged or instructed others (e.g., its customers...)" on how to use its products and services in an infringing manner (Compl. ¶11). For contributory infringement, it makes the same allegation and further states there are "no substantial noninfringing uses" for the accused products and services (Compl. ¶12).
- Willful Infringement: Willfulness is alleged based on Defendant’s knowledge of the ’368 patent "from at least the filing date of the lawsuit" (Compl. ¶¶11-12). The prayer for relief also seeks a finding of willfulness if pre-suit knowledge is revealed in discovery (Compl., Prayer for Relief ¶e).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of technical evidence and claim interpretation: Does the Plaintiff's infringement theory on the dual-encryption limitation—where the server is "capable of decrypting the first part" but "not capable of decrypting the second part"—align with both the patent's specification and the actual operation of the Defendant's systems? The complaint's own supporting arguments appear to create a potential contradiction on this point, which will likely be a central focus of litigation.
- A key evidentiary question will be one of process flow: Can Plaintiff demonstrate that Defendant's accused systems perform the specific sequence of steps mandated by claim 1? Specifically, does the accused system first generate and transmit a message allowing a user to select between multiple payment instruments on a mobile device, and only after receiving a confirmation, proceed to obtain account information from an issuing institution?