DCT
1:24-cv-04282
Autoscribe Corp v. M&A Ventures LLC
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Autoscribe Corporation (Maryland)
- Defendant: Repay Holdings Corporation, Repay Holdings, LLC, and M&A Ventures, LLC (Delaware / Georgia)
- Plaintiff’s Counsel: Ahmad, Zavitsanos & Mensing, PLLC
- Case Identification: 2:23-cv-00349, E.D. Tex., 01/08/2024
- Venue Allegations: Venue is based on Defendant allegedly maintaining a "regular and established place of business" in The Colony, Texas, within the district, and having committed acts of infringement in the district.
- Core Dispute: Plaintiff alleges that Defendant’s Payment API infringes a patent related to methods for securely processing online payment transactions by isolating a merchant's systems from sensitive financial data.
- Technical Context: The technology addresses the challenge of reducing Payment Card Industry (PCI) compliance burdens for online merchants through tokenization and the use of hosted payment fields.
- Key Procedural History: The operative complaint is a First Amended Complaint. The patent-in-suit was issued with a terminal disclaimer, which may limit its enforceable term to that of an earlier patent.
Case Timeline
| Date | Event |
|---|---|
| 2012-06-05 | '621 Patent Priority Date |
| 2023-04-04 | '621 Patent Issue Date |
| 2024-01-08 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
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"
- 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’s background section describes the significant cost, complexity, and security risks for merchants handling sensitive cardholder data, as well as the organizational and technical burdens of complying with the Payment Card Industry Data Security Standard (PCI DSS) ('621 Patent, col. 1:23-52).
- The Patented Solution: The invention describes a system architecture that separates the merchant’s primary server from a "secure server." A payer visiting a merchant’s website enters their financial information not into the merchant's site directly, but into a "window or frame" that establishes a secure, direct connection to the secure server ('621 Patent, col. 6:65-col. 7:2). The secure server captures and stores the sensitive data, returning only a non-sensitive "token" to the merchant server. The merchant can then initiate future payments using this token, without ever possessing or processing the underlying financial account information, thereby reducing its PCI compliance scope ('621 Patent, col. 2:51-65).
- Technical Importance: This method of offloading payment data collection and storage allows merchants to accept online payments while minimizing their exposure to sensitive data, which was a critical development for reducing security risks and compliance costs ('621 Patent, col. 1:53-col. 2:2).
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶26).
- Essential elements of independent claim 1, a method performed by one or more secure servers, include:
- Providing an API to a merchant server that offers financial account registration and token retrieval functions.
- Receiving payer and payment data from the merchant server via the API.
- Authenticating the payee.
- Executing a financial account registration function, which involves generating a URL (dynamic or static) for establishing a secure connection with the payer's system inside a "window or frame" on the merchant's webpage.
- Outputting instructions to the payer's system to render a registration form and to encrypt and transmit sensitive financial information to the secure server.
- Receiving and storing the sensitive information.
- Executing a token retrieval function, which provides a non-sensitive token to the merchant server without exposing the sensitive data to the merchant or the payer.
- Processing the payment transaction using the stored sensitive information.
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are the services Defendant provides through its “Payment API,” and other similar methods, collectively referred to as the “Infringing Methods” (Compl. ¶27).
Functionality and Market Context
- The complaint alleges that Defendant’s Payment API is a collection of endpoints that allows merchants to process payments. This functionality is allegedly provided in two ways: by directly sending full card data via the API, or "by using our hosted checkout forms via iframe or other embedded solutions or redirects" (Compl. ¶30). The complaint focuses on the latter functionality, where merchants can integrate a hosted payment form to offload the handling of sensitive card data, allegedly for the purpose of lowering "the PCI scope of the connecting application" (Compl. ¶37). This screenshot describing the purpose of the Payment API provides an overview of its function. (Compl. ¶29, p. 8).
IV. Analysis of Infringement Allegations
'621 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| providing... an application programming interface (API) that: provides financial account registration and token retrieval functions... and provides access... to the merchant server | Defendant provides a "Payment API" with "a full collection of endpoints that supports everything from provisioning users to making payments," including functions for making payments via token and using hosted checkout forms. | ¶30-32 | col. 6:56-62 |
| receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount from the payer to the payee | The API allegedly receives data fields such as "amount" and "customer_id" from the merchant. A screenshot from Defendant's documentation shows these required fields. | ¶33 | col. 17:10-12 |
| authenticates the payee | The API documentation allegedly shows an "Authorization" request header is used to authenticate the call to the system. | ¶34 | col. 17:17 |
| executes the financial account registration function... by: generating a uniform resource locator (URL)... | The API allegedly generates a "one-time use URL" in response to a request from the merchant server. A screenshot shows a JSON response containing a generated "url" field. | ¶35(a) | col. 17:5-12 |
| establishing the secure socket layer connection... between the secure server and the payer computing system within a window or frame... | The API documentation allegedly states the generated URL can be used to "embed in a host application," which the complaint equates to displaying within a window or frame. | ¶35(b) | col. 17:18-24 |
| outputting instructions... to render a financial account registration request form... | The API documentation allegedly describes getting the "proper checkout form" to send a user to for entering full card data on a hosted page. | ¶35(c) | col. 17:25-29 |
| storing the sensitive financial account information in a secure storage location and performing each software process required to maintain compliance with... security standards | The API documentation allegedly states that using its hosted payments "allows REPAY to capture the payment details and lower the PCI scope of the connecting application." | ¶37 | col. 17:40-44 |
| executing a token retrieval function... by: providing a non-sensitive electronic data token... to the merchant server | The documentation allegedly describes retrieving "vault tokens," where a "stored_payment_id" is described as a "token from Retrieve vault tokens." A screenshot shows a "Card Remit Webhook" for this purpose. | ¶38 | col. 17:45-52 |
- Identified Points of Contention:
- Scope Questions: The method of claim 1 involves actions by a "secure server", a "merchant server", and a "payer computing system". A question for the court will be whether the facts alleged are sufficient to hold Defendant, the operator of the secure server, liable for direct infringement of the entire method, which may require a "direction or control" analysis.
- Technical Questions: What evidence does the complaint provide that Defendant’s system "authenticates the payee," as required by the claim, versus merely authenticating the merchant’s software application via an "apptoken" as shown in the documentation (Compl. ¶34)? Further, what evidence demonstrates that Defendant's server performs the specific step of "outputting instructions to the payer computing system... to encrypt" the data, a step distinct from merely establishing a secure (SSL) connection?
V. Key Claim Terms for Construction
The Term: "secure server"
- Context and Importance: The claim architecture relies on a distinction between the "merchant server" and the "secure server". The definition of "secure server" is critical for determining if Defendant's platform, which may be a unified service, embodies the separate server structure required by the claims.
- Evidence for a Broader Interpretation: The specification states that the "merchant server" and "secure server" "may operate in the same location or may be the same hardware using a separated volume or partition" ('621 Patent, col. 2:45-50), which could support an argument that they need only be logically, not physically, separate.
- Evidence for a Narrower Interpretation: The patent's summary and background repeatedly emphasize the advantages of realizing a "logical and/or physical separation" to isolate the merchant from sensitive data, suggesting that a meaningful, functional separation is a core aspect of the invention ('621 Patent, col. 2:40-50).
The Term: "window or frame"
- Context and Importance: This term defines the mechanism by which the secure server's functionality is presented on the merchant's webpage. Infringement depends on whether the accused "iframe or other embedded solutions" (Compl. ¶30) fall within this scope.
- Evidence for a Broader Interpretation: The specification refers to implementing the functions "in a 'widget' or frame" ('621 Patent, col. 6:65-col. 7:2), suggesting these are examples and not an exhaustive list. Plaintiff may argue that an "iframe" is a type of frame and "embedded solutions" are equivalents.
- Evidence for a Narrower Interpretation: Defendant may argue that the term should be limited to the specific browser technologies understood as a "window or frame" at the time of the invention (priority date 2012) and that modern embedded components are technically distinct.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement, asserting that Defendant provides its customers (merchants) with its Payment API, along with documentation, specifications, and instructions that "encourage infringing use" (Compl. ¶¶ 43-44). The complaint identifies specific customers who are alleged to be direct infringers (Compl. ¶40).
- Willful Infringement: The complaint alleges that Defendant had knowledge of the patent "no later than the date of this Complaint" (Compl. ¶39), forming a basis for post-suit willfulness only. No allegations of pre-suit knowledge are made.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the distinct "merchant server" and "secure server" entities required by the claims be found within the Defendant's allegedly integrated Payment API platform? The interpretation of these terms will be central to the infringement analysis.
- A key evidentiary question will be one of divided infringement: As the asserted claim is a method involving multiple actors, the case may turn on whether the Plaintiff can prove that the Defendant directs or controls its merchant customers and their end-users to perform the claimed steps, thereby satisfying the requirements for single-entity liability for direct infringement.
- A third central question will be one of factual proof: Does the evidence from Defendant's API documentation, as presented in the complaint, sufficiently demonstrate every limitation of the asserted claim? Specifically, practitioners may focus on whether authenticating an "application" meets the "authenticates the payee" limitation and whether establishing an SSL connection inherently satisfies the requirement of "outputting instructions... to encrypt."