Autoscribe Corp v. Stripe Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: Stripe, Inc. (Delaware)
  • Plaintiff's Counsel: AHMAD, ZAVITSANOS & MENSING, PLLC; CONNOLLY GALLAGHER LLP
• Case Identification: 1:25-cv-01498, D. Del., 04/22/2026
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is a Delaware corporation and its sole state of incorporation.
• Core Dispute: Plaintiff alleges that Defendant's online payment processing products infringe two patents related to methods for securely handling financial transactions and tokenizing sensitive payment information.
• Technical Context: The technology addresses the security and compliance challenges merchants face in e-commerce by offloading the collection and storage of sensitive payment data to a secure third-party system, thereby reducing the merchant's PCI DSS compliance burden.
• Key Procedural History: The complaint alleges that Plaintiff provided Defendant with written notice of the asserted patents and its infringement on December 12, 2025, which may form the basis for a subsequent willfulness claim.

Case Timeline

Date	Event
2012-06-05	Priority Date for '621 and '234 Patents
2023-04-04	U.S. Patent No. 11,620,621 Issued
2025-11-04	U.S. Patent No. 12,462,234 Issued
2025-12-12	Plaintiff Sends Notice Letter to Defendant
2026-04-22	Amended Complaint for Patent Infringement 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"

• Patent Identification: U.S. Patent No. 12,462,234 ("the '234 Patent"), titled "Processing a payment, by a secure computing system, from a payer to a payee operating a merchant computing system," issued on November 4, 2025.

The Invention Explained

• Problem Addressed: The patent's background describes the significant fraud risk and high compliance costs associated with handling sensitive credit card and bank account information, particularly the burden on merchants to meet the Payment Card Industry Data Security Standard (PCI DSS) '234 Patent, col. 1:24-49
• The Patented Solution: The invention proposes a system architecture separating a merchant's primary server from a "secure server." The merchant server uses an API to communicate with the secure server, which directly collects sensitive payment data from the payer (e.g., via an embedded form). The secure server then stores this data and provides a non-sensitive "token" back to the merchant. This allows the merchant to process payments via the token without ever storing, processing, or transmitting the sensitive financial data itself '234 Patent, col. 2:17-53 '234 Patent, Fig. 3
• Technical Importance: This tokenization method significantly reduces a merchant's PCI DSS compliance scope and associated costs by isolating their systems from sensitive cardholder data '234 Patent, col. 5:63-6:4

Key Claims at a Glance

• The complaint asserts independent claim 1 Compl. ¶22 Compl. ¶24
• The essential elements of method claim 1 include:
  • Providing, by a secure server to a merchant server, an application programming interface (API) with financial account registration and token retrieval functions.
  • Receiving, from the merchant server via the API, data associated with a payer and a payment amount.
  • Authenticating the payee.
  • Executing a financial account registration function, initiated by the merchant server, which involves generating a URL, establishing an encrypted connection with the payer's system, and outputting instructions to render a form and transmit the encrypted sensitive data to the secure server.
  • Receiving and storing the sensitive financial account information.
  • Executing a token retrieval function to provide a non-sensitive electronic data token to the merchant server.
  • Processing the payment transaction using the stored sensitive information without providing it to the merchant server.
• The complaint alleges infringement of "one or more claims," suggesting the right to assert other claims may be reserved Compl. ¶22

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 ("the '621 Patent"), titled "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 on April 4, 2023.

The Invention Explained

• Problem Addressed: The patent addresses the need for improved, conventional methods for securely obtaining and using account information to process financial payments while minimizing merchants' exposure to fraud and compliance burdens '621 Patent, col. 1:21-2:7
• The Patented Solution: Similar to the '234 Patent, the invention describes a method where a merchant server facilitates the enrollment of a payer's financial information. The merchant's webpage displays a "window or frame" (e.g., an iframe) that establishes a direct, secure connection between the payer's computer and a separate secure server. This secure server collects and stores the sensitive data, providing a non-sensitive token back to the merchant server for future payment processing '621 Patent, col. 17:15-24 '621 Patent, abstract
• Technical Importance: This method enables merchants to offer a seamless checkout experience while ensuring that sensitive payment data never passes through or is stored on their own servers, a key strategy for PCI compliance.

Key Claims at a Glance

• The complaint asserts independent claim 15 Compl. ¶41 Compl. ¶43
• The essential elements of method claim 15 include:
  • Providing a webpage to a payer and receiving enrollment data.
  • Providing data to a secure server via an API.
  • Displaying a window or frame within the webpage.
  • Providing authentication credentials to the API to establish an authenticated session.
  • Initiating an API's financial account registration function, which establishes a secure connection to the payer and renders a form for sensitive data entry.
  • Initiating an API's token retrieval function to output a non-sensitive token to the merchant server.
  • Receiving and storing the non-sensitive token.
  • Processing a payment by generating an instruction that uses a representation of the token.
• The complaint alleges infringement of "one or more claims," suggesting the right to assert other claims may be reserved Compl. ¶41

III. The Accused Instrumentality

• Product Identification: The accused instrumentalities are Defendant's "Elements," "Checkout," and "Payment Links" products, as well as services that use the Stripe "Checkout Sessions" or "PaymentIntents" APIs Compl. ¶15 Compl. ¶23
• Functionality and Market Context:
  • The complaint alleges that the accused products provide payment processing services for online merchants Compl. ¶14 Functionally, they are described as a set of "prebuilt UI components" that create a checkout flow for merchants Compl. ¶25
  • A key accused feature is the "Payment Element," which the complaint alleges is an iframe that "securely sends payment information to Stripe over an HTTPS connection," thereby isolating the merchant's server from sensitive data Compl. ¶30.a.(i) Compl. ¶30.b.(ii) A screenshot from Defendant's documentation describes this feature as a "prebuilt UI component that simplifies collecting payment details" Compl. ¶30.a.(i)
  • The complaint alleges these products use tokenization, where sensitive data is collected and a non-sensitive token or object identifier (e.g., "Customer object," "PaymentMethod" ID) is returned to the merchant for processing payments Compl. ¶¶33-34
  • The complaint asserts that Defendant is a major market participant, processing approximately $1.4 trillion in payments annually Compl. ¶14

IV. Analysis of Infringement Allegations

'234 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) that: provides financial account registration and token retrieval functions...	Defendant's secure servers provide the Stripe API, which includes functionality for creating customers, payment intents, and saving payment methods.	¶26; ¶27	col. 25:54-62
...receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount...	The Stripe API receives customer details (e.g., name, email) and an "amount" to create a "PaymentIntent" for the transaction. A screenshot shows API calls with these parameters. Compl. ¶28	¶28	col. 25:63-26:2
...authenticates the payee...	The merchant (payee) is authenticated through a required registration process and the use of secret API keys to access the Stripe API.	¶29	col. 26:3-4
...executing the financial account registration function... by: generating a uniform resource locator (URL)...	An API call to a Stripe endpoint (e.g., "checkout/sessions") returns a URL that initiates the payment collection process via the "Payment Element."	¶30.a.(i)	col. 26:9-21
...establishing the encrypted connection... between the secure server and the payer computing system...	An HTTPS connection is established between the payer's browser and Stripe's servers when the Payment Element iframe is loaded.	¶30.b.(ii)	col. 26:22-37
...outputting instructions to the payer computing system... to render a financial account registration request form...	The Payment Element is described as a "prebuilt UI" that renders a form to "collect[] payment details for a variety of payment methods."	¶30.c.(iii)	col. 26:38-48
...storing the sensitive financial account information in a secure storage location... and performing each software process required to maintain compliance with... information security standards...	Defendant is alleged to be a PCI Service Provider Level 1 and to use a "Card Data Vault" to securely store sensitive data. A screenshot from Defendant's "Security at Stripe" page is provided as evidence. Compl. ¶32	¶32	col. 26:52-57
...executing a token retrieval function... by: providing a non-sensitive electronic data token... to the merchant server...	Stripe's API returns non-sensitive identifiers for "Customer" and "PaymentMethod" objects to the merchant, which can be used to initiate future payments.	¶33	col. 26:58-27:7

• Identified Points of Contention:
  • Scope Questions: Claim 1 is a method performed by "one or more secure servers." The complaint alleges infringement by Defendant "either itself, or by directing or controlling others to perform, or as part of a joint enterprise" Compl. ¶25 A central question for the court will be whether Stripe's actions meet the "direction or control" standard for joint infringement, as steps like data entry are performed by the payer and hosting the webpage is performed by the merchant.
  • Technical Questions: The claim requires generating a URL and then establishing a connection "in response to an HTTP request for the generated URL." The infringement theory relies on Stripe's API returning a URL or session ID that is then used to initialize a client-side JavaScript library ("Stripe.js"). The court may need to determine if this multi-step, API-and-client-side-script process is equivalent to the more linear sequence described in the claim.

'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... comprising: providing a webpage to a payer computing system used by a payer...	Merchant servers using Stripe's products create a "web checkout flow" for customers to complete a payment.	¶45	col. 27:60-63
...displaying a window or frame within the webpage provided to the payer computing system...	Defendant's documentation allegedly describes the "Payment Element" as containing an "iframe" that is placed on the merchant's payment page.	¶47	col. 28:4-5
...initiating a financial account registration function of the API during the authenticated session, the financial account registration function: establishing a secure socket layer connection...	The "Payment Element" iframe is alleged to "securely send[] payment information to Stripe over an HTTPS connection," establishing the secure link between the payer and Stripe's secure server.	¶49	col. 28:8-13
...initiating a token retrieval function of the API... outputting a non-sensitive electronic data token... to the merchant server...	Stripe's system allows saving "PaymentMethods" to a "Customer object" and provides object identifiers (the alleged token) back to the merchant server.	¶50	col. 28:28-33
...storing the non-sensitive electronic data token in association with the enrollment data identifying the payer...	Defendant's documentation allegedly instructs merchants to "associate the ID of the Customer object with your own internal representation of a customer."	¶52	col. 28:41-43
...processing a payment from the payer by generating a payment transaction instruction, using the token retrieval function of the API...	Merchants allegedly use the stored Customer and PaymentMethod IDs (the token) to create a "payment_intent" to charge the customer. A screenshot showing an API call for this purpose is included. Compl. ¶53	¶53	col. 28:45-56

• Identified Points of Contention:
  • Scope Questions: Claim 15 is a "method of enrolling a payer by a merchant server." This framing raises a significant question of whether the direct infringer is the merchant, not Stripe. The complaint appears to anticipate this by pleading indirect infringement (inducement and contribution) for this patent, alleging Stripe provides the tools and instructions for its customers to perform the infringing method Compl. ¶¶55-65
  • Technical Questions: A potential point of dispute is whether a modern, JavaScript-based component like Stripe's "Payment Element" qualifies as a "window or frame" as understood by the patent. While it uses an iframe, its dynamic nature may differ from the simpler implementation potentially contemplated by the patent, which could be a focus during claim construction.

V. Key Claim Terms for Construction

• The Term: "secure server" (from '234 Patent, Claim 1; '621 Patent, Claim 15)

• Context and Importance: The patents' core concept rests on the architectural separation between a merchant's system and a "secure server" that handles sensitive data. The definition of this term is critical for determining which parts of Defendant's infrastructure fall within the claim scope and whether the alleged isolation of data is achieved in the manner claimed.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification suggests the separation can be logical, not just physical, stating the merchant and secure servers "may be the same hardware using a separated volume or partition, or memory section" '621 Patent, col. 2:45-49 This may support an argument that any logically distinct and secured processing environment qualifies.
  • Evidence for a Narrower Interpretation: The specification repeatedly emphasizes that the invention's purpose is to offload compliance burdens from the merchant, which suggests the "secure server" is operated by a different entity or is at least a system for which the merchant does not have security responsibility '621 Patent, col. 1:41-50 '621 Patent, col. 2:17-23 This could support a narrower definition requiring operational and/or legal separation.

• The Term: "window or frame" (from '621 Patent, Claim 15)

• Context and Importance: The complaint's infringement theory for the '621 Patent hinges on equating Stripe's "Payment Element" with the claimed "window or frame" '621 Patent, col. 18:4-5 The construction of this term will determine whether Stripe's use of a modern, dynamic iframe component falls within the scope of the claim.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification uses the term in a general sense to describe an embedded element for data collection within a webpage, a function directly served by an iframe '621 Patent, col. 17:19-24 The term itself is common in web technology and can be argued to have a plain and ordinary meaning that encompasses iframes.
  • Evidence for a Narrower Interpretation: A party might argue that the patent, with a 2012 priority date, envisioned a simpler, more static HTML element than the complex, JavaScript-driven "prebuilt UI component" that constitutes Stripe's "Payment Element" Compl. ¶25 Practitioners may focus on whether the dynamic generation and behavior of the accused element create a technical distinction from the claimed "window or frame."

VI. Other Allegations

• Indirect Infringement: The complaint alleges direct infringement for the '234 Patent, relying on a joint enterprise theory Compl. ¶35 For the '621 Patent, the complaint explicitly pleads theories of induced and contributory infringement Compl. ¶¶55-65 The inducement allegation is based on Defendant providing documentation, APIs, and promotional literature that allegedly instruct and encourage its customers (merchants) to implement the patented method Compl. ¶59 The contributory infringement allegation is based on the claim that Defendant's APIs and code are a material part of the invention, especially made for infringement, and not a staple article of commerce Compl. ¶¶63-64
• Willful Infringement: The complaint alleges willful infringement for both the '234 and '621 Patents Compl. ¶37 Compl. ¶67 The allegation is based on Defendant's alleged continued infringement after receiving a notice letter from Plaintiff on December 12, 2025, which allegedly provided knowledge of the patents and the infringing conduct.

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

1. Infringement Liability for a Divided System: The case will likely hinge on whether Plaintiff can prove infringement in a system where the claimed steps are performed by multiple distinct actors (Stripe, its merchant customers, and the end-user payers). For direct infringement, the key will be satisfying the "direction or control" standard for joint infringement under Akamai. For indirect infringement of the '621 Patent, the focus will be on whether Stripe's provision of tools and instructions is sufficient to establish the requisite intent for inducement.

2. Definitional Scope of Claim Terms: A core issue will be one of claim construction: can terms like "secure server" and "window or frame", rooted in a 2012-era specification, be construed to cover Defendant's modern, dynamic, and API-driven payment infrastructure? The outcome will depend on whether the court adopts a broad, functional definition or a narrower one tied to the specific embodiments disclosed.

3. Evidentiary Mapping to Claim Language: A key evidentiary question will be one of functional performance: does the accused system's operational sequence-involving API calls, client-side JavaScript, and the generation of objects like "PaymentIntents"-perform the specific, ordered steps required by the claims? For example, the court will have to determine if returning an API key that unlocks a client-side library is equivalent to "generating a uniform resource locator (URL)", as recited in Claim 1 of the '234 Patent.