Autoscribe Corp v. Repay Holdings Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: M&A Ventures, LLC (Georgia)
  • Plaintiff’s Counsel: Ahmad, Zavitsanos & Mensing, PLLC; Ward, Smith, & Hill, PLLC
• Case Identification: Autoscribe Corporation v. M&A Ventures, LLC, 2:23-cv-00349, E.D. Tex., 08/05/2024
• Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains a "regular and established place of business" in The Colony, Texas, within the district, which is described as its largest facility, and because Defendant has customers in the district.
• Core Dispute: Plaintiff alleges that Defendant’s Payment API infringes a patent related to methods for securely processing online financial transactions using tokenization.
• Technical Context: The technology at issue involves systems that allow online merchants to accept payments without directly handling, processing, or storing sensitive customer financial data, thereby reducing the merchants' data security burdens and compliance scope under standards like the Payment Card Industry Data Security Standard (PCI DSS).
• Key Procedural History: The operative pleading is the Plaintiff’s Second Amended Complaint. The patent-in-suit is a continuation of a series of applications, with the complaint asserting an effective priority dating back to 2012.

Case Timeline

Date	Event
2012-06-05	Earliest Priority Date for U.S. Patent No. 11,620,621
2023-04-04	U.S. Patent No. 11,620,621 Issues
2024-08-05	Plaintiff's Second Amended Complaint for Patent Infringement Filed

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"

The Invention Explained

• Problem Addressed: The patent’s background section describes the significant cost, complexity, and risk associated with online 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) to prevent fraud (Compl. ¶10; ’621 Patent, col. 1:23-47).
• The Patented Solution: The invention describes a two-server system to solve this problem. A "merchant server" handles general e-commerce functions but offloads the sensitive task of collecting financial data to a separate "secure server." The payer enters financial information directly into a component (e.g., a frame or widget) controlled by the secure server, so the merchant server never receives or stores the sensitive data. The secure server then provides a non-sensitive "token" to the merchant server, which acts as a reference to the stored data. The merchant can use this token to initiate subsequent payments via an API call to the secure server, which processes the transaction using the vaulted financial information (’621 Patent, Abstract; col. 2:51-col. 3:14).
• Technical Importance: This tokenization architecture allows merchants to facilitate payment transactions without bringing their own systems into the scope of stringent PCI DSS audits, significantly reducing compliance costs and security risks (’621 Patent, col. 2:1-3, col. 5:6-9).

Key Claims at a Glance

• The complaint asserts independent claim 1 and alleges infringement of "one or more claims" (Compl. ¶24).
• The essential elements of independent method claim 1 include:
  • Providing an Application Programming Interface (API) from one or more secure servers to a merchant server.
  • The API provides financial account registration and token retrieval functions, receives payer data and a payment amount, and authenticates the payee.
  • Executing the financial account registration function by generating a URL for a secure connection.
  • Establishing the secure connection within a "window or frame" displayed on the merchant's webpage.
  • Outputting instructions to the payer's system to render a registration form within that window or frame and to encrypt and transmit the sensitive information to the secure server.
  • Receiving and storing the sensitive financial information at a secure location.
  • Executing a token retrieval function that provides a "non-sensitive electronic data token" to the merchant server, without providing the sensitive data itself to the merchant server or the token to the payer.
  • Processing the payment transaction using the stored sensitive information.

III. The Accused Instrumentality

Product Identification

• The complaint identifies Defendant’s "Payment API" and related services as the accused instrumentality (collectively, the "Infringing Methods") (Compl. ¶25).

Functionality and Market Context

• The complaint alleges that Defendant’s Payment API provides payment processing solutions to merchants (Compl. ¶17). Its functionality is described through API documentation, which indicates that it allows a merchant to make payments "both via token and sending full card data" by using "hosted checkout forms via iframe or other embedded solutions or redirects" (Compl. ¶28; Compl. p. 8). This process is alleged to "lower the PCI scope of the connecting application" by having the Defendant ("REPAY") "capture the payment details" (Compl. ¶35; Compl. p. 17). A screenshot from the API documentation shows how a merchant can "make the next request to lookup tokens by account on demand" (Compl. ¶30; Compl. p. 10).
• The complaint alleges Defendant is a significant financial technology company that processed approximately $25.7 billion in card payments in 2022 and directly competes with the Plaintiff (Compl. ¶¶17, 19).

IV. Analysis of Infringement Allegations

’621 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
providing, by the one or more secure servers to a merchant server... an application programming interface (API)	Defendant provides a "Payment API" to its merchants, described in its documentation as "a full collection of endpoints that supports everything from provisioning users to making payments." A screenshot shows documentation for the "REPAY API." (Compl. p. 8).	¶28	col. 16:56-59
that... authenticates the payee	The Payment API authenticates the merchant (payee) through an "Authorization" request header that includes an "apptoken." A screenshot shows this "Authorization" header in the API documentation. (Compl. p. 12).	¶32	col. 17:1-2
and executes the financial account registration function... by: generating a uniform resource locator (URL)	The API documentation describes a "Get One-Time Use URL" endpoint that returns a URL for the checkout process. A screenshot shows a sample JSON response containing a generated "url." (Compl. p. 13).	¶33(a)	col. 17:4-8
establishing the secure socket layer connection... between the secure server and the payer computing system within a window or frame that is displayed within the webpage provided by the merchant server	The documentation for the "one-time use URL" states it can be used to "embed in a host application," which the complaint alleges corresponds to a window or frame. The complaint points to documentation mentioning use of an "iFrame." (Compl. p. 8).	¶33(b)	col. 17:14-20
outputting instructions... to render a financial account registration request form... that provides functionality for the payer to provide sensitive financial account information	The API provides a "checkout form" for the user to enter payment data. Documentation describes this form as the means "to send a user to for entering full card data on our hosted page." A screenshot illustrates how to get the "proper checkout form." (Compl. p. 15).	¶33(c)	col. 17:21-29
executing a token retrieval function... by: providing a non-sensitive electronic data token representing the sensitive financial account information to the merchant server without providing the sensitive financial account information	Defendant's API documentation describes retrieving "vault tokens." A "Card Remit Webhook" provides a stored_payment_id which is described as a "token from Retrieve vault tokens." A screenshot shows the "GET OR Retrieve Vault Tokens" endpoint. (Compl. p. 18).	¶36	col. 17:46-52
and processing the payment transaction using the sensitive financial account information	The documentation for the "Card Payment" folder states that its functions are necessary to "make a payment." A screenshot shows this description. (Compl. p. 19).	¶36	col. 17:53-59

Identified Points of Contention

• Scope Question: The claim requires the API to "authenticate the payee". The complaint alleges this is met by an "apptoken" in an API request header (Compl. ¶32). This raises the question of whether an application-level token, which may only authenticate the software making the call, legally and technically satisfies the requirement to authenticate the "payee", which is the merchant entity itself.
• Technical Question: What evidence demonstrates that the stored_payment_id returned by Defendant’s API is a "non-sensitive electronic data token" as required by the claim? The infringement analysis may focus on whether this identifier has any meaning or value outside the specific payment ecosystem that would render it "sensitive" or if it fails to "represent" the financial information in the manner contemplated by the patent.

V. Key Claim Terms for Construction

The Term: "authenticates the payee"

• Context and Importance: This step is a predicate for executing the claimed registration function. The definition will be critical to determining if Defendant's use of an API "apptoken" meets this limitation. Practitioners may focus on this term because API keys can serve various purposes, and its alignment with "authenticating the payee" is a potential point of dispute.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent does not appear to provide a special definition, which may support using the term's plain and ordinary meaning. This could encompass any reliable method of verifying that the entity initiating the process is the authorized merchant customer.
  • Evidence for a Narrower Interpretation: The patent's flowcharts depict a login process involving an "organization, application, and user key registry" and a "validation engine" ('621 Patent, Fig. 4f, elements 580, 586). A party could argue this implies a more robust, user-centric login and validation process is required to "authenticate the payee," beyond simply presenting a static application token in a header.

The Term: "window or frame that is displayed within the webpage provided by the merchant server"

• Context and Importance: This limitation defines the specific user interface mechanism for securely collecting data while maintaining a seamless user experience. The complaint alleges infringement through the use of an "iframe" (Compl. p. 8).
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: A party might argue the term should be interpreted functionally to cover any modern web technology that embeds one document within another to achieve the same visual result and data isolation, not just the literal HTML <frame> or <iframe> tags.
  • Evidence for a Narrower Interpretation: The patent's priority date is 2012, a time when "frame" and "iframe" had specific technical meanings. A party could argue the claim is limited to these specific technologies and does not read on other methods of embedding content or on a simple redirect to a separately hosted page, which the accused product's documentation also mentions as a possibility (Compl. p. 8).

VI. Other Allegations

Indirect Infringement

• The complaint alleges inducement of infringement. The factual basis is Defendant's alleged creation and distribution of API documentation, specifications, user manuals, and technical support that instruct and encourage its customers (the merchants) to use the Payment API in an infringing manner (Compl. ¶¶ 40-42). The complaint also names several specific customers as alleged direct infringers (Compl. ¶38).

Willful Infringement

• The complaint alleges willful infringement based on Defendant having knowledge of the patent "at least as early as its receipt of this Complaint" (Compl. ¶49).

VII. Analyst’s Conclusion: Key Questions for the Case

• A core issue will be one of claim construction and scope: can the term "authenticates the payee" be satisfied by the "apptoken" presented in the accused API's request header, or does the intrinsic evidence require a more comprehensive user and organizational validation process as depicted in the patent's detailed figures?
• A central evidentiary question will be one of technical mapping: while the complaint provides extensive API documentation, the case will depend on evidence of how the accused Payment API operates in practice. Does the accused system’s actual implementation of its checkout form, tokenization, and payment processing align with every specific limitation of Claim 1, or are there operational differences that create a mismatch with the claim language?
• Another key question will concern the negative limitation that the secure server provides the token "without providing the sensitive financial account information to the merchant server." The outcome may turn on forensic evidence establishing whether the accused architecture maintains this strict data partitioning at all times, or if any sensitive data is directly or indirectly exposed to the merchant's system.