DCT
1:25-cv-01487
Autoscribe Corp v. Emerchantpay Corp
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Autoscribe Corporation (Maryland)
- Defendant: EmerchantPay Corporation (Delaware)
- Plaintiff’s Counsel: Connolly Gallagher LLP; Ahmad, Zavitsanos & Mensing, PLLC
- Case Identification: 1:25-cv-01487, D. Del., 12/10/2025
- Venue Allegations: Plaintiff alleges venue is proper in the District of Delaware because Defendant is a Delaware corporation and therefore resides in the state for purposes of patent venue.
- Core Dispute: Plaintiff alleges that Defendant’s online payment processing solutions infringe two patents related to securely handling financial account information and processing payments using tokenization.
- Technical Context: The patents address methods for reducing the security and compliance burdens (such as PCI DSS) for online merchants by using a separate, secure server to handle sensitive payment data, providing the merchant with a non-sensitive "token" for transaction processing.
- Key Procedural History: The complaint alleges that Plaintiff provided Defendant with notice of the asserted patents and its infringement via a letter delivered on December 10, 2025, the same day the complaint was filed.
Case Timeline
| Date | Event |
|---|---|
| 2012-06-05 | Earliest Priority Date for ’234 and ’621 Patents |
| 2023-04-04 | ’621 Patent Issued |
| 2025-11-04 | ’234 Patent Issued |
| 2025-12-10 | Notice Letter Delivered to Defendant |
| 2025-12-10 | Complaint Filed |
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,” issued November 4, 2025 (’234 Patent)
The Invention Explained
- Problem Addressed: The patent’s background section identifies the significant costs, complexity, and fraud risk for merchants who handle sensitive customer financial data, particularly the burdens associated with complying with the Payment Card Industry Data Security Standard (PCI DSS) (U.S. Patent No. 11,620,621, col. 1:22-52).
- The Patented Solution: The invention describes a system where a "merchant server" offloads the handling of sensitive payment information to a separate "secure server." The secure server provides an Application Programming Interface (API) to the merchant. When a payer needs to enter payment details, the secure server generates a URL that directs the payer's browser to a form hosted by the secure server, isolating the merchant's systems from the sensitive data. After the data is collected, the secure server creates a "non-sensitive electronic data token" and provides it to the merchant server, which can then use the token to initiate payments without ever possessing the underlying financial account details (U.S. Patent No. 11,620,621, col. 2:51-67; col. 6:5-15).
- Technical Importance: This tokenization architecture allows merchants to process online payments while minimizing their PCI DSS compliance scope, as their systems do not store, process, or transmit sensitive cardholder information (Compl. ¶6).
Key Claims at a Glance
- The complaint asserts infringement of one or more claims, including independent Claim 1 (Compl. ¶22).
- Essential elements of Claim 1 include:
- A method of processing a payment transaction performed by one or more secure servers.
- Providing an API from the secure servers to a merchant server.
- The API provides financial account registration and token retrieval functions.
- The API receives payer data and a payment amount from the merchant server.
- The payee is authenticated.
- The financial account registration function is executed by generating a URL (dynamic or static) for an encrypted connection between the secure server and the payer.
- The secure server establishes the connection and outputs instructions to the payer's system to render a payment form and encrypt the sensitive information for transmission back to the secure server.
- The secure server receives and stores the sensitive information.
- A token retrieval function is executed, providing a non-sensitive token to the merchant server (but not the payer).
- The payment is processed using the sensitive information, initiated via the token, without providing the sensitive information back to the merchant.
U.S. Patent No. 11,620,621 - “Enrolling A Payer By A Merchant Server Operated By Or For The Benefit Of A Payee And Processinga Payment From The Payer By A Secure Server,” issued April 4, 2023 (’621 Patent)
The Invention Explained
- Problem Addressed: As with the related ’234 Patent, this patent addresses the technical problem of reducing fraud risk and PCI compliance burdens for merchants processing online payments (’621 Patent, col. 1:22-52).
- The Patented Solution: The patent describes a method performed by a merchant server for enrolling a payer. The merchant server receives enrollment data and uses an API to communicate with a secure server. A key feature is the displaying of a "window or frame" within the merchant's webpage, inside which a secure connection is established between the payer's computer and the secure server. This allows the payer to enter sensitive financial information directly to the secure server without it passing through the merchant's systems. The merchant server then receives a non-sensitive token from the secure server, which it stores and uses to process payments (’621 Patent, Abstract; col. 20:65-21:1).
- Technical Importance: By embedding the secure payment form within the merchant's own site via a window or frame (e.g., an iFrame), this solution provides a more seamless user experience while still achieving the security and compliance benefits of isolating sensitive data (’621 Patent, col. 20:65-21:1).
Key Claims at a Glance
- The complaint asserts infringement of one or more claims, including independent Claim 15 (Compl. ¶40).
- Essential elements of Claim 15 include:
- A method of enrolling a payer performed by a merchant server.
- Providing a webpage to the payer and receiving enrollment data.
- Providing payer data and a payment amount to a secure server via an API.
- Displaying a window or frame within the merchant's webpage.
- Providing authentication credentials to the API.
- Initiating a financial account registration function of the API, which establishes a secure connection and renders a payment form within the window or frame.
- Initiating a token retrieval function that outputs a non-sensitive token to the merchant server.
- Receiving the token from the secure server.
- Storing the token in association with the enrollment data.
- Processing a payment by generating an instruction using the token.
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are Defendant EmerchantPay's "Web Payment Form" product and services that utilize its "WPF API" (Compl. ¶15).
Functionality and Market Context
- The complaint describes the Web Payment Form (WPF) as a "hosted payment page on emerchantpay's servers" designed to cover merchants' PCI DSS compliance requirements (Compl. ¶25, figure on p. 7). A merchant's server uses the WPF API to send an initial request with transaction details (Compl. ¶28). In response, the API provides a unique URL for the payment session, which the merchant can use to redirect the customer or display the payment form within an iFrame on the merchant's own checkout page (Compl. ¶30, ¶46). The complaint includes a screenshot of the accused WPF rendered inside a sample merchant's page, showing fields for cardholder data entry (Compl. p. 12). After the payer submits their information, EmerchantPay's system processes the transaction and returns a "consumer_id" and/or a "payment_transaction_token" to the merchant, which can be stored and used for future payments (Compl. ¶33, ¶49).
IV. Analysis of Infringement Allegations
’234 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 | Defendant provides the WPF API, which allows merchants to create a payment session (registration) and receive back tokens for subsequent payments (retrieval). | ¶26, ¶27 | col. 6:61-63 |
| receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount | The merchant server sends an initial "Create method request" via the API containing elements like "customer_email", "amount", and "currency". | ¶28 | col. 3:4-7 |
| authenticates the payee | The merchant authenticates to the API using "HTTP Basic Authentication" with API credentials. | ¶29 | col. 14:1-7 |
| executes the financial account registration function... by: generating a uniform resource locator (URL) | EmerchantPay's servers return a "redirect_url" in response to the Create request, described as a "unique URL address of the payment session." | ¶30 | col. 14:46-48 |
| establishing the encrypted connection... outputting instructions... to render a financial account registration request form | The payer's browser is redirected to the unique URL, establishing an HTTPS connection and rendering the WPF for data entry. | ¶30 | col. 12:62-67 |
| receiving the sensitive financial account information provided by the payer via the encrypted connection | The WPF page, which "uses 128-bit SSL encryption," receives the payer's financial data. | ¶31 | col. 8:31-35 |
| storing the sensitive financial account information in a secure storage location... maintain compliance with... information security standards | Defendant's gateway is alleged to be PCI DSS Level 1 compliant, which requires protecting stored cardholder data with encryption. | ¶32 | col. 8:36-38 |
| executing a token retrieval function... by: providing a non-sensitive electronic data token... to the merchant server | After transaction processing, the system returns a "consumer_id" and/or "payment_transaction_token" to the merchant. | ¶33 | col. 3:8-15 |
| processing the payment transaction using the sensitive financial account information, without providing the sensitive financial account information to the merchant server | The system processes the payment using the stored data and only returns a token to the merchant, not the underlying account information. | ¶33 | col. 3:4-8 |
Identified Points of Contention
- Scope Questions: A potential point of contention may be whether the accused system, operated by a single entity (EmerchantPay), can be neatly divided into the claimed "secure server" and "merchant server" roles, or if the architecture differs from that contemplated by the patent.
- Technical Questions: The analysis may turn on whether the accused "consumer_id" and "payment_transaction_token" function as the claimed "non-sensitive electronic data token representing the sensitive financial account information." The complaint alleges this function by showing an example HTTP response containing these tokens (Compl. p. 15).
’621 Patent Infringement Allegations
| Claim Element (from Independent Claim 15) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method of enrolling a payer by a merchant server... providing a webpage to a payer computing system used by a payer | The method is allegedly performed by Defendant's merchants on their sites where customers "finalise purchases." | ¶43, ¶44 | col. 20:58-60 |
| providing, to a secure server via an application programming interface (API)... at least one data element... and a payment amount | The merchant server provides "amount" and "customer_email" to the secure server via the initial Create request. | ¶45 | col. 3:4-7 |
| displaying a window or frame within the webpage | Defendant's documentation instructs merchants to display "the WPF redirect in an iFrame on your checkout page." | ¶46 | col. 20:65-21:1 |
| initiating a financial account registration function... establishing a secure socket layer connection... within the window or frame | The customer is redirected to the unique URL within the iFrame, establishing an SSL connection to EmerchantPay's servers to render the payment form. | ¶48 | col. 12:62-67 |
| initiating a token retrieval function... outputting a non-sensitive electronic data token... to the merchant server | EmerchantPay's system returns a "consumer_id" and/or "payment_transaction_token" after the transaction is processed. | ¶49 | col. 8:36-44 |
| storing the non-sensitive electronic data token in association with the enrollment data identifying the payer | Defendant's documentation allegedly instructs merchants to "be sure to store all tokens returned for a customer_id and customer_email combination." | ¶51 | col. 8:48-50 |
| processing a payment from the payer by generating a payment transaction instruction, using the token retrieval function of the API | Merchants allegedly use the returned "consumer_id" or token to process subsequent payments for returning customers. | ¶52 | col. 8:51-59 |
Identified Points of Contention
- Scope Questions: Claim 15 is a method claim directed to actions taken "by a merchant server." The infringement theory appears to rely on the actions of Defendant's merchant customers being attributed to the Defendant under theories of indirect infringement, raising questions about divided infringement and inducement.
- Technical Questions: What evidence does the complaint provide that the accused WPF, when displayed in an iFrame, performs the specific sequence of "establishing a secure socket layer connection... within the window or frame" and "outputting instructions... to render a financial account registration request form, within the window or frame" as required by the claim? The complaint points to documentation instructing merchants to display the WPF in an iFrame (Compl. ¶46).
V. Key Claim Terms for Construction
The Term: "secure server"
- Context and Importance: The claimed invention is architecturally defined by the interaction between a "merchant server" and a "secure server." The definition of "secure server" is fundamental to determining whether the accused EmerchantPay system, which acts as a third-party payment gateway, embodies this claimed architecture.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification functionally describes the secure server as the server that "stores the sensitive financial account information" (’621 Patent, col. 2:40-44). This could support a broad definition covering any system component that performs this data-handling role.
- Evidence for a Narrower Interpretation: The specification also notes that "particular advantages are realized through logical and/or physical separation of the merchant's server and the secure server" (’621 Patent, col. 2:49-51), and Figure 2 depicts them as distinct entities (202 and 204). This could support a narrower construction requiring a degree of separation beyond mere functional difference.
The Term: "non-sensitive electronic data token"
- Context and Importance: This term defines the object that enables the merchant to avoid handling sensitive data. The infringement case hinges on whether the accused "consumer_id" and "payment_transaction_token" meet this definition. Practitioners may focus on this term because it is the core of the tokenization concept.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification defines a token broadly as "a symbolic representation of a financial instrument," an "index to the stored financial account information," and a "pointer that allows the payee to reference the financial account information" (’621 Patent, col. 1:54-58; col. 8:40-44). This functional language may support reading the term on the accused tokens.
- Evidence for a Narrower Interpretation: The specification states the token is "only meaningful to participants in the processing cycle" (’621 Patent, col. 1:56-58). An argument could be made that if the accused "consumer_id" can be linked to other personally identifiable information by the merchant, it may not be truly "non-sensitive" in the manner required by the patent.
VI. Other Allegations
- Indirect Infringement: For the ’621 Patent, the complaint alleges both induced and contributory infringement (Compl. ¶53-62). The inducement allegations are based on claims that Defendant provides documentation and promotional literature encouraging merchants to use the WPF API to "Reduce PCI DSS compliance" and "Store card payment details to provide one-click payments," thereby instructing them on how to perform the infringing method (Compl. ¶57).
- Willful Infringement: Willfulness is alleged for both patents, based on knowledge acquired "at least as early as its receipt of this Complaint" (Compl. ¶36, ¶64). The complaint does not allege any facts supporting pre-suit knowledge of the patents.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural mapping: Does the relationship between a merchant's e-commerce platform and EmerchantPay's hosted Web Payment Form, a third-party service, align with the patent's two-party "merchant server" and "secure server" architecture, especially for method claims directed at actions "by a merchant server"?
- A key evidentiary question will be one of definitional equivalence: Do the "consumer_id" and "payment_transaction_token" generated by the accused system function as the "non-sensitive electronic data token" required by the claims, or do their specific properties or usage contexts create a technical mismatch with the patent's definition?
- A central legal question for the ’621 Patent will be one of divided infringement: Can Plaintiff establish that Defendant's merchants perform all steps of the claimed method and that Defendant's control over or direction of its merchants is sufficient to attribute their actions to Defendant for the purposes of direct or indirect infringement?