Autoscribe Corp v. M&A Ventures LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: M&A Ventures, LLC (Georgia)
  • Plaintiff’s Counsel: Miller & Martin PLLC; Ahmad, Zavitsanos & Mensing, PLLC
• Case Identification: 1:26-cv-00688, N.D. Ga., 02/05/2026
• Venue Allegations: Plaintiff alleges venue is proper in the Northern District of Georgia because Defendant is organized under Georgia law and maintains its headquarters, a regular and established place of business, within the district.
• Core Dispute: Plaintiff alleges that Defendant’s payment processing services, including its "Payment API," infringe a patent related to securely processing financial transactions by isolating sensitive payment data from merchant systems.
• Technical Context: The technology addresses the need for merchants to reduce their data security risks and compliance burdens (such as under the Payment Card Industry Data Security Standard) by using a third-party system to handle and store sensitive customer financial information.
• Key Procedural History: The complaint notes that the parties were previously involved in litigation that was transferred to the Northern District of Georgia, suggesting a pre-existing familiarity between the parties and with the venue.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 12,462,234 - "Processing a payment, by a secure computing system, from a payer to a payee operating a merchant computing system"

• Patent Identification: U.S. Patent No. 12462234 ("Processing a payment, by a secure computing system, from a payer to a payee operating a merchant computing system"), issued November 4, 2025 (hereafter, the "’234 Patent").

The Invention Explained

• Problem Addressed: The patent’s background section describes the significant problem of credit card fraud and the substantial cost, time, and effort required for merchants to obtain and maintain Payment Card Industry (PCI) compliance to securely handle sensitive cardholder data ʼ234 Patent, col. 1:24-51
• The Patented Solution: The invention proposes a system architecture that separates the merchant's computing system from a "secure server" that handles sensitive financial information ʼ234 Patent, col. 2:34-36 The merchant's system receives a non-sensitive "token" that represents the customer's payment information, which is stored only on the secure server ʼ234 Patent, abstract The merchant can then initiate payments using this token without ever directly receiving, transmitting, or storing the underlying sensitive data, thereby reducing its security and compliance burden ʼ234 Patent, col. 2:50-63 This interaction is often facilitated through a "widget" or "frame" on the merchant's website that communicates directly with the secure server ʼ234 Patent, col. 6:64-68
• Technical Importance: This tokenization approach allows merchants to participate in e-commerce while outsourcing a significant portion of the data security risk and regulatory complexity associated with handling credit card and bank account numbers.

Key Claims at a Glance

• The complaint asserts at least independent claim 1 Compl. ¶25 Compl. ¶27
• Claim 1 (Method):
  • A method of processing a payment performed by one or more secure servers.
  • Providing an API to a merchant server that provides financial account registration and token retrieval functions.
  • Receiving, from the merchant server via the API, payer data and a payment amount.
  • Authenticating the payee.
  • Executing a financial account registration function by:
    • Generating a URL (dynamic, or static with a parameter) to establish an encrypted connection between the secure server and the payer's computer.
    • Establishing the encrypted connection.
    • Outputting instructions to the payer's computer to render a registration form.
    • Outputting instructions to the payer's computer to encrypt the sensitive financial information and transmit it to the secure server.
  • Receiving the sensitive information via the encrypted connection.
  • Storing the sensitive information in a secure location in compliance with security standards.
  • Executing a token retrieval function by:
    • Providing a non-sensitive electronic data token to the merchant server.
    • Processing the payment using the sensitive information without providing it to the merchant server or the token to the payer.

III. The Accused Instrumentality

Product Identification

• The accused instrumentalities are Defendant's services provided through its "Payment API" and "Payrazr" service Compl. ¶26

Functionality and Market Context

• The complaint alleges that the accused "Payment API" provides a collection of endpoints that allow merchants to process payments Compl. ¶29 This is allegedly done through a system of tokenization and hosted checkout forms, which allows the Defendant's system to "capture the payment details and lower the PCI scope of the connecting application" Compl. ¶36 The documentation referenced in the complaint suggests the API is designed to allow a merchant's application to send payment data either directly or by using "hosted checkout forms via iframe or other embedded solutions or redirects" Compl. ¶28 The Defendant is described as a financial technology company that processed approximately $25.7 billion in card payments in 2022 (Compl. ¶18). A screenshot from Defendant's documentation illustrates the "POST 2nd -- Get One-Time Use URL" functionality, which returns a URL for a user to enter payment information Compl. p. 12

IV. Analysis of Infringement Allegations

’234 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: A central question may be whether the actors performing each step of the claimed method align with the claim's structure. Claim 1 is a method performed "by one or more secure servers." The defense may argue that certain steps, such as encrypting the financial data, are performed by the payer's web browser ("client-side"), not by the "secure server" as the claim may require, raising a question of divided infringement. The complaint attempts to address this by alleging Defendant "directs or controls" the performance of all steps Compl. ¶28 Compl. ¶38
• Technical Questions: The analysis will likely focus on the specific sequence of operations. For example, does the accused API "outputting instructions... to encrypt" the data as required by the claim, or does it merely provide a form within a secure context (e.g., HTTPS) where the browser performs encryption according to its own protocols? The evidence provided in the complaint does not detail the specific instructions sent from Defendant's server to the payer's browser.

V. Key Claim Terms for Construction

The Term: "secure server"

• Context and Importance: The patent's architecture is predicated on the distinction between the "merchant server" (col. 6:9) and the "secure server" (col. 6:5). The infringement analysis depends on whether Defendant's "Payment API" servers qualify as the claimed "secure server" performing the claimed actions, distinct from its customers' "merchant servers." Practitioners may focus on this term to determine the required level of technical and operational separation between the two entities.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent 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" ʼ234 Patent, col. 2:45-49, which could support a construction where logical separation is sufficient.
  • Evidence for a Narrower Interpretation: The patent emphasizes that a key advantage is realized through "logical and/or physical separation" ʼ234 Patent, col. 2:49-50 and that the invention "avoids placing their customer tracking and payment processing systems (such as merchant server 204) within the scope" of PCI-DSS ʼ234 Patent, col. 6:1-3 This suggests a construction requiring a degree of separation sufficient to achieve this regulatory goal.

The Term: "outputting instructions to the payer computing system... to encrypt the sensitive financial account information"

• Context and Importance: This active "outputting instructions" language is a specific step in the claimed method. Infringement will depend on whether Defendant's servers are found to perform this step. The defense may argue that providing a secure (HTTPS) form field, which relies on standard browser and web server protocols for security, does not constitute "outputting instructions... to encrypt" in the specific manner claimed.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The detailed description of the process flow shows the "Financial Account Registration Application" (on the secure server) interacting with the user's web browser to receive encrypted data ʼ234 Patent, FIG. 4c, steps 532, 534 This interaction could be broadly interpreted as the server inherently "instructing" the browser to perform the encryption as part of the secure session.
  • Evidence for a Narrower Interpretation: The claim language recites two separate "outputting instructions" steps: one to "render a financial account registration request form," and a second to "encrypt the sensitive financial account information." A narrower reading would require evidence of a specific instruction for encryption that is separate from the instruction to render the form itself, such as a specific script or command sent from the server to the client browser.

VI. Other Allegations

Indirect Infringement

• The complaint makes conclusory allegations that Defendant acts by "directing or controlling others to perform, or as part of a joint enterprise" Compl. ¶28 It also includes a section on divided infringement, attributing the performance of third parties (like payment gateways or banks) to Defendant through direction, control, or joint enterprise Compl. ¶38 However, the complaint does not plead specific facts to support the knowledge and intent elements required for induced infringement.

Willful Infringement

• The complaint alleges that Defendant's infringement is willful based on knowledge of the patent acquired "at least as early as its receipt of this Complaint" Compl. ¶41 This constitutes an allegation of post-suit willfulness.

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

• A core issue will be one of technical specificity: does the Defendant's "Payment API" and hosted checkout system perform the precise, multi-step sequence recited in Claim 1? The case will likely require a detailed technical comparison between the accused system's operation—particularly the server-browser communication protocol—and the claim's requirements for "outputting instructions" to render a form and separately to encrypt data.
• A second key question will be one of divided infringement: can the Plaintiff prove that the Defendant's "secure servers" perform every step of the claimed method, or are some steps performed by other actors (such as the end-user's browser or third-party banks)? If so, the outcome may depend on whether the Plaintiff can establish that the Defendant "directs or controls" those other actors' performance under the standards set by patent law.
• Finally, the case may turn on a question of definitional scope during claim construction, centered on what level of logical or physical separation is required for a system to be considered a "secure server" distinct from a "merchant server" as contemplated by the patent.