DCT
4:24-cv-03104
Autoscribe Corp v. Tsevo LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Autoscribe Corporation (Maryland)
- Defendant: Tsevo, LLC (Texas) and GambleID, LLC (Nevada)
- Plaintiff’s Counsel: AHMAD, ZAVITSANOS & MENSING, PLLC
- Case Identification: 4:24-cv-03104, TXSD, 03/18/2024
- Venue Allegations: Plaintiff alleges venue is proper in the Southern District of Texas because Defendant Tsevo is a Texas LLC, both Defendants share a principal place of business in Houston within the district, and both have customers in the district.
- Core Dispute: Plaintiff alleges that Defendants’ "Smart Cashier" and "Token Vault" payment processing products infringe a patent related to methods for securely processing online payments by isolating sensitive financial data from a merchant's primary servers.
- Technical Context: The technology concerns secure online payment systems, specifically architectural designs that use tokenization to reduce a merchant's Payment Card Industry (PCI) compliance burden by offloading the handling of sensitive financial information to a separate, secure system.
- Key Procedural History: The asserted patent is subject to a terminal disclaimer, which may limit its enforceable term to that of an earlier-expiring, related patent. The complaint does not mention any other prior litigation, licensing history, or administrative proceedings.
Case Timeline
| Date | Event |
|---|---|
| 2012-06-05 | '621' Patent - Earliest Priority Date Claimed |
| 2023-04-04 | '621 Patent - Issue Date |
| 2024-03-18 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
- Patent Identification: U.S. Patent No. 11,620,621 - "Enrolling a payer by a merchant server operated by or for the benefit of a payee and processing a payment from the payer by a secure server", issued April 4, 2023.
The Invention Explained
- Problem Addressed: The patent background describes the substantial cost, complexity, and security risks for merchants handling sensitive credit card and bank account information, particularly the burden of complying with the Payment Card Industry Data Security Standard (PCI DSS) ('621 Patent, col. 1:22-50). A single data breach can compromise millions of accounts and expose merchants to significant liability ('621 Patent, col. 1:28-31).
- The Patented Solution: The invention proposes a system architecture that separates the merchant's primary server from a "secure server" ('621 Patent, Fig. 2). The merchant server initiates an enrollment process, but the payer provides sensitive financial data directly to the secure server, often through a dedicated frame or window within the merchant's webpage ('621 Patent, col. 6:50-65). The secure server stores this sensitive data and provides a non-sensitive "token" back to the merchant server ('621 Patent, col. 2:51-68). The merchant can then use this token to initiate future payments without ever possessing, processing, or storing the actual financial account information, thereby reducing its PCI compliance scope ('621 Patent, col. 3:9-15).
- Technical Importance: This tokenization method allows merchants to maintain control over customer relationships and payment initiation while offloading the high-risk, high-cost function of securing sensitive payment data to a specialized, compliant system ('621 Patent, col. 2:51-57).
Key Claims at a Glance
- The complaint’s allegations focus on independent claim 1 ('621 Patent, Compl. ¶25, ¶27).
- The essential elements of method claim 1 include:
- A method performed by one or more secure servers for processing a payment.
- Providing an API to a merchant server that offers financial account registration and token retrieval functions.
- Receiving payer data and a payment amount from the merchant server via the API.
- Authenticating the payee.
- Executing the registration function by:
- Generating a URL (dynamic, or static with a parameter) to establish a secure connection with the payer's computer.
- Establishing the secure connection within a window or frame on the merchant's webpage.
- Outputting a form for the payer to enter sensitive financial information.
- Outputting instructions to encrypt and transmit that sensitive information to the secure server.
- Receiving and storing the sensitive information.
- Executing a token retrieval function that provides a non-sensitive token to the merchant server (but not to the payer).
- Processing the payment using the stored sensitive information.
- The complaint alleges infringement of "one or more claims," preserving the right to assert additional claims (Compl. ¶25).
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are Defendants’ "Smart Cashier" and "Token Vault" products, which collectively are alleged to perform the "Infringing Methods" (Compl. ¶26).
Functionality and Market Context
- The complaint alleges these products provide an end-to-end payment management gateway for various industries (Compl. ¶17-19). The "Smart Cashier" product is marketed as offering a flexible API for PCI-DSS compliant payments, while the "Token Vault" service is described as a system that "encrypts and replaces sensitive payment data with a unique identifier (token)" (Compl. ¶29, ¶36). The complaint includes a marketing visual for the "TOKEN VAULT" product, which states it provides "secure PCI compliant registration, tokenization, and encryption of payment methods" (Compl. p. 10). The system is alleged to be implemented via Defendants' "GIDX Platform" (Compl. ¶31).
IV. Analysis of Infringement Allegations
'621 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method of processing a payment transaction from a payer to a payee, the method being performed by one or more secure servers... | Defendants' "Smart Cashier" and "Token Vault" products are alleged to be performed by one or more secure servers to process payments. | ¶28 | col. 2:34-36 |
| providing...to a merchant server...an application programming interface (API) that: provides financial account registration and token retrieval functions... | Defendants' "GIDX Platform" allegedly provides a flexible API for "Smart Cashier" that enables PCI-compliant registration and tokenization via its "Token Vault" and "WebSession" services. A visual from Defendants' marketing describes a "flexible API" for the service (Compl. p. 9). | ¶29-30 | col. 6:53-61 |
| receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount... | The complaint points to API documentation for a "CreateSession" method, which allegedly receives parameters such as MerchantCustomerID, CustomerIpAddress, and CashierPaymentAmount from the merchant. A provided screenshot shows these required parameters in the API documentation (Compl. p. 12). |
¶32 | col. 2:27-33 |
| authenticates the payee... | The API allegedly authenticates the payee (merchant) using ApiKey and MerchantID parameters provided by the GIDX team to the merchant. |
¶33 | col. 2:19-22 |
| generating a uniform resource locator (URL)...the URL comprising either: a dynamic URL...or a static URL and a hypertext transport protocol (HTTP) parameter... | The API's CreateSession method allegedly returns a SessionURL described in documentation as an "encrypted, one time use, script-tag." The complaint alleges this meets the "generating a URL" limitation. A visual excerpt of the documentation describes the SessionURL (Compl. p. 14). |
¶34(a) | col. 12:59-65 |
| establishing the secure socket layer connection...within a window or frame that is displayed within the webpage provided by the merchant server... | The SessionURL (script-tag) allegedly connects to the "GIDX Service" directly from the customer's device, and an "HTML interface...is rendered and embedded by the script-tag into the merchants page." |
¶34(b) | col. 6:50-55 |
| providing a non-sensitive electronic data token representing the sensitive financial account information to the merchant server without providing the sensitive financial account information to the merchant server... | The "Token Vault" service is alleged to replace sensitive data with a "unique identifier (token)" and provide it to the merchant's processor, while the actual sensitive data is stored within the Token Vault solution. An example API response shows a "Token" field being returned (Compl. p. 18). | ¶37 | col. 2:51-68 |
Identified Points of Contention
- Technical Questions: The complaint alleges that a
SessionURL, described in Defendants' documentation as an "encrypted, one time use, script-tag," meets the claim limitation of generating a "uniform resource locator (URL)" (Compl. p. 14). A technical question for the court will be whether a "script-tag" is functionally and structurally equivalent to a "URL" as that term is used in the patent. - Scope Questions: The patent describes a system architecture with a "merchant server" and a "secure server." The complaint alleges Defendants' "GIDX Platform" performs the infringing method. This raises the question of how the accused platform's architecture maps to the claimed two-server structure. The dispute may focus on whether the GIDX Platform itself embodies the distinct functions and data-flow separation between a "merchant server" and a "secure server" as required by the claims.
V. Key Claim Terms for Construction
The Term: "secure server"
- Context and Importance: The definition of "secure server" is foundational to the claimed invention, as its separation from the "merchant server" is what enables the reduction in PCI compliance scope. The infringement analysis will depend on whether Defendants' "GIDX Platform" can be considered to contain both a "merchant server" and a "secure server" as distinct claimed entities.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification suggests the separation can be logical, not necessarily physical. It states that the "merchant's server and secure server may operate in the same location or may be the same hardware using a separated volume or partition, or memory section" ('621 Patent, col. 2:45-50). This could support an argument that logically distinct software modules on a single platform meet the claim.
- Evidence for a Narrower Interpretation: The patent consistently describes the servers as two different systems (a "first computing system" and a "second computing system") and repeatedly highlights the advantages of "logical and/or physical separation" ('621 Patent, col. 2:49-51). Figures and the general description often depict them as separate hardware boxes (e.g., Fig. 2), which could support an argument that distinct hardware or virtual machines are required.
The Term: "uniform resource locator (URL)"
- Context and Importance: Practitioners may focus on this term because the infringement allegation hinges on equating a "SessionURL" described as a "script-tag" with the claimed "URL." If a "script-tag" is found to be outside the scope of "URL," a key step of the infringement theory may fail.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent does not appear to provide a special definition for "URL." A party might argue that its plain and ordinary meaning at the time of the invention encompassed any web-based instruction that directs a client browser to a resource to establish a connection.
- Evidence for a Narrower Interpretation: The claim recites two specific types of URLs: a dynamic URL or a static URL with an HTTP parameter. A party could argue this context limits the term to conventional URL structures (e.g.,
protocol://domain/path?parameter=value) and excludes other web technologies like JavaScript tags, which operate differently. The embodiment in which a URL is used to "launch[] a browser window" may suggest a traditional, address-bar-visible URL ('621 Patent, col. 12:59-61).
VI. Other Allegations
Indirect Infringement
- The complaint alleges induced infringement, stating that Defendants provide API documentation, promotional materials, and technical support that instruct and encourage their customers (the merchants) to implement the "Infringing Methods" (Compl. ¶42-43). The complaint quotes from Defendants' documentation, which it characterizes as an "integration guide for implementing services of the GIDX Platform API" (Compl. ¶43). It also alleges contributory infringement, arguing that Defendants' APIs and code are especially adapted for infringement and are not staple articles of commerce (Compl. ¶45-47).
Willful Infringement
- Willfulness is alleged based on knowledge acquired "no later than the date of this Complaint" (Compl. ¶38). The complaint also makes an alternative allegation of willful blindness (Compl. ¶41). These allegations are based on post-suit knowledge.
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of definitional scope: can the term "uniform resource locator (URL)," as used in the patent, be construed to cover the "encrypted, one time use, script-tag" that the complaint alleges is generated by the accused system? The outcome of this construction could be dispositive for a key step in the infringement analysis.
- A key evidentiary question will be one of architectural mapping: does Defendants' integrated "GIDX Platform" operate as the distinct "merchant server" and "secure server" architecture required by the claims? The case may turn on what evidence is required to prove the functional and data-flow separation between software components within a single branded platform.
- A third question will relate to intent: for the indirect infringement claims, what evidence will demonstrate that Defendants, by providing their API and documentation, possessed the specific intent to encourage their customers to perform a method that would be found to infringe the '621 patent's specific architectural and functional limitations?