DCT
1:25-cv-01498
Autoscribe Corp v. Stripe Inc
Key Events
Complaint
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., 12/12/2025
- Venue Allegations: Venue is based on Defendant’s state of incorporation, Delaware.
- Core Dispute: Plaintiff alleges that Defendant’s payment processing products and APIs infringe two patents related to methods for securely processing online payments using tokenization to isolate sensitive financial data from merchant servers.
- Technical Context: The technology addresses the security and compliance challenges of e-commerce by enabling merchants to accept payments without directly handling, transmitting, or storing sensitive customer financial data, thereby reducing their data breach risk and PCI compliance scope.
- Key Procedural History: The complaint alleges that a notice letter regarding the asserted patents and infringement was delivered to the defendant on the same day the lawsuit was filed.
Case Timeline
| Date | Event |
|---|---|
| 2012-06-05 | Priority Date for U.S. Patent Nos. 11,620,621 and 12,462,234 |
| 2023-04-04 | U.S. Patent No. 11,620,621 Issues |
| 2025-11-04 | U.S. Patent No. 12,462,234 Issues |
| 2025-12-12 | Notice Letter Delivered to Defendant |
| 2025-12-12 | Complaint Filing Date |
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 Nov. 4, 2025)
The Invention Explained
- Problem Addressed: The patent's specification describes the significant problem of credit card fraud and the substantial costs and complexities merchants face to comply with the Payment Card Industry Data Security Standard (PCI DSS) when handling sensitive cardholder data (U.S. Patent No. 11,620,621, col. 1:23-52).
- The Patented Solution: The invention discloses a payment processing method centered on architectural separation. A "merchant server" interacts with a customer but offloads the collection of sensitive financial information to a separate "secure server." This is achieved via an Application Programming Interface (API) that allows the merchant's webpage to generate a form for the user to enter payment details, which are then encrypted and transmitted directly to the secure server. In return, the merchant server receives a "non-sensitive electronic data token" that represents the sensitive information. The merchant can then use this token to initiate payment transactions without ever possessing or storing the underlying financial data ('234 Patent, Abstract; '621 Patent, col. 2:51-col. 3:15).
- Technical Importance: This tokenization method allows online merchants to reduce their security risk and the scope of their PCI DSS compliance obligations by ensuring sensitive financial data bypasses their systems entirely ('621 Patent, col. 2:4-7).
Key Claims at a Glance
- The complaint asserts independent claim 1 ('234 Patent, col. 17:1-col. 18:2; Compl. ¶24).
- Essential elements of claim 1 include:
- A method performed by one or more secure servers for processing a payment.
- Providing an API to a merchant server that offers financial account registration and token retrieval functions.
- Receiving payer data and a payment amount from the merchant server via the API.
- Authenticating the payee.
- Executing a financial account registration function by generating a URL, establishing an encrypted connection, and outputting instructions to render a form and transmit encrypted financial information from the payer's system to the secure server.
- Receiving and storing the sensitive financial information.
- Executing a token retrieval function by providing a non-sensitive data token to the merchant server.
- Processing the payment using the stored sensitive information, without providing that information to the merchant server.
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
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 Apr. 4, 2023)
The Invention Explained
- Problem Addressed: The patent addresses the same technical problem as the ’234 Patent: the burdens placed on merchants to securely handle customer payment data and maintain PCI compliance ('621 Patent, col. 1:23-52).
- The Patented Solution: The invention describes a method for "enrolling a payer" where a merchant server displays a webpage containing a "window or frame" that connects directly to a secure server over a secure (e.g., SSL) connection. The payer enters their financial details into this frame, and the data is sent only to the secure server. The merchant server is then provided with a non-sensitive token via an API. This token is stored in association with the payer's enrollment data and used to process subsequent payments, again ensuring the merchant server never handles the sensitive information ('621 Patent, Abstract; col. 17:1-col. 18:25).
- Technical Importance: This architecture provides a technical mechanism for merchants to integrate a secure payment data collection module directly into their own checkout webpages, creating a seamless user experience while maintaining the critical separation of sensitive data ('621 Patent, col. 10:55-65).
Key Claims at a Glance
- The complaint asserts independent claim 15 ('621 Patent, col. 19:60-col. 20:42; Compl. ¶42).
- Essential elements of claim 15 include:
- A method of enrolling a payer, performed by a merchant server.
- Providing a webpage, receiving enrollment data, and providing data to a secure server via an API.
- Displaying a window or frame within the webpage.
- Providing authentication credentials to the API for an authenticated session.
- Initiating a financial account registration function within the session that establishes a secure connection and renders a form for the payer to provide sensitive financial information directly to the secure server.
- Initiating a token retrieval function that outputs a non-sensitive token to the merchant server.
- Receiving and storing the token in association with the payer's enrollment data.
- Processing a payment by generating an instruction that uses the token.
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
III. The Accused Instrumentality
Product Identification
- Defendant’s “Elements,” “Checkout,” and “Payment Links” products, as well as other products utilizing the Stripe “Checkout Sessions” or “PaymentIntents” APIs (collectively, the "Infringing Methods") (Compl. ¶15).
Functionality and Market Context
- The complaint describes the accused products as payment processing solutions for online merchants (Compl. ¶14). The Stripe "Elements" product is specifically identified as a set of "prebuilt UI components for building your web checkout flow" (Compl. ¶25). A screenshot from Defendant's documentation provided in the complaint states, "Stripe.js tokenizes sensitive payment details within an Element without ever having them touch your server" (Compl. p. 7).
- The accused functionality involves merchants integrating Stripe's API into their websites. This integration allegedly allows a payer's sensitive financial data to be collected within a UI component, such as an iframe hosted by Stripe, and transmitted directly to Stripe's secure servers. Stripe then allegedly provides a token-like identifier back to the merchant, who can use it to process payments without handling the sensitive data (Compl. ¶¶26-33, 44-52). A visual from the complaint shows documentation describing how the "Payment Element contains an iframe that securely sends payment information to Stripe over an HTTPS connection" (Compl. p. 11).
- The complaint alleges Defendant processes approximately $1.4 trillion in payments annually, representing a significant market presence (Compl. ¶14).
IV. Analysis of Infringement Allegations
12,462,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 Stripe API, which merchants use to build payment flows. | ¶26 | col. 6:53-64 |
| receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount | The API receives customer data (e.g., "name," "email") to create a "Customer object" and an "amount" to create a "PaymentIntent." | ¶28 | col. 8:52-59 |
| authenticates the payee | Merchants must register for a Stripe account and use an "API key" or "secret key" to access the API, thereby authenticating themselves as the payee. | ¶29 | col. 17:1-2 |
| executes the financial account registration function... by: generating a uniform resource locator (URL)... to render a financial account registration request form | The Stripe "Payment Element" is a prebuilt UI component, an iframe, which collects payment details. An iframe is rendered via a source URL. A screenshot describes this as the method to "Collect payment details" (Compl. p. 11). | ¶30 | col. 17:5-13 |
| receiving the sensitive financial account information provided by the payer via the encrypted connection | The Payment Element "securely send[s] payment information to Stripe over an HTTPS connection." | ¶31 | col. 17:36-39 |
| storing the sensitive financial account information in a secure storage location... | Defendant is a PCI Service Provider Level 1 certified entity and uses a "Card Data Vault" for secure storage. The complaint includes a screenshot titled "Security at Stripe" describing these features (Compl. p. 14). | ¶32 | col. 17:40-44 |
| executing a token retrieval function... by: providing a non-sensitive electronic data token... to the merchant server | Defendant's system saves "PaymentMethods" to a "Customer object" and provides identifiers for these objects to the merchant server. | ¶33 | col. 17:45-52 |
11,620,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 operated by or for the benefit of a payee, the method comprising: providing a webpage to a payer computing system... | Merchant servers use Defendant's products to create a "web checkout flow" for payers. | ¶44 | col. 17:1-2 |
| providing, to a secure server via an... (API)... at least one data element associated with the payer and a payment amount... | The merchant server uses the API to create a "Customer" with data like "name" or "email" and a "PaymentIntent" with an "amount." | ¶45 | col. 17:5-9 |
| displaying a window or frame within the webpage provided to the payer computing system | Defendant's documentation states that the "Payment Element contains an iframe." | ¶46 | col. 17:10-13 |
| providing authentication credentials to the API to establish an authenticated session... | The merchant server provides its "API key" or "secret key" to authenticate with the Stripe API. | ¶47 | col. 17:14-17 |
| initiating a financial account registration function... establishing a secure socket layer connection... to render a financial account registration request form... | The iframe component establishes an HTTPS connection to Stripe's secure server and presents a "prebuilt UI" for collecting payment details. | ¶48 | col. 17:18-28 |
| initiating a token retrieval function of the API... outputting a non-sensitive electronic data token... to the merchant server | Defendant's system saves "PaymentMethods" and provides object identifiers for them to the merchant server. | ¶49 | col. 18:1-5 |
| 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 IDs of the Customer and PaymentMethod objects with their "own internal representation of a customer." | ¶51 | col. 18:13-15 |
| processing a payment from the payer by generating a payment transaction instruction, using the token retrieval function of the API | The merchant server creates a "payment_intent" using parameters including the "customer" and "payment_method" identifiers. | ¶52 | col. 18:16-25 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether the defendant's system of providing object identifiers (e.g., "CUSTOMER_ID," "PAYMENT_METHOD_ID") for API calls meets the definitional scope of a "non-sensitive electronic data token" as contemplated by the patents.
- Technical Questions: The analysis may focus on the precise flow of data. What evidence does the complaint provide that the merchant server itself performs the step of "providing... data... to a secure server" versus this action being performed by the payer's browser under the direction of code served by the merchant? The complaint also raises joint enterprise liability, suggesting this distribution of actions is a point of focus (Compl. ¶34).
V. Key Claim Terms for Construction
The Term: "non-sensitive electronic data token" (asserted in claims of both the '234 and '621 Patents)
- Context and Importance: This term is central to the invention's value proposition of separating sensitive and non-sensitive data. The infringement case hinges on whether Defendant's system of "Customer" and "PaymentMethod" identifiers falls within the scope of this term. Practitioners may focus on this term because the patents' claims require providing this specific construct to the merchant server.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the token as a "symbolic representation of a financial instrument" and an "index to the stored financial account information," language which could support a broad definition covering various forms of reference identifiers ('621 Patent, col. 2:54-56, col. 2:65-66).
- Evidence for a Narrower Interpretation: The specification also characterizes the token as a "pointer that allows the payee to reference the financial account information" ('621 Patent, col. 8:40-42). A party could argue this implies a specific technical structure that is narrower than any generic identifier.
The Term: "secure server"
- Context and Importance: The claimed invention is predicated on the architectural division between a "merchant server" and a "secure server." The definition of "secure server" is critical for establishing where the claimed functions occur and whether the accused system maintains the required separation.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification 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," suggesting the separation can be logical rather than strictly physical ('621 Patent, col. 2:45-50).
- Evidence for a Narrower Interpretation: The description repeatedly emphasizes that the secure server is the entity that "stores the sensitive financial account information" and is distinct from the merchant's systems to reduce the merchant's PCI compliance scope ('621 Patent, Abstract; col. 2:4-7). Any evidence that the accused "merchant server" receives or processes sensitive data could be used to argue it does not meet the claimed architecture.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement and contributory infringement of the ’621 Patent. The inducement allegation is based on Defendant providing APIs, documentation, and promotional materials that allegedly instruct and encourage its merchant customers to implement the infringing methods (Compl. ¶¶56-57). The contributory infringement allegation is based on Defendant providing APIs and code that are a "material part of the invention" and not a "staple article or commodity of commerce suitable for substantial noninfringing use" (Compl. ¶¶59-61).
- Willful Infringement: The complaint alleges willful infringement of both patents, based on Defendant having knowledge "at least as early as its receipt of this Complaint" and the associated notice letter delivered the same day (Compl. ¶18, ¶36, ¶64). The Plaintiff reserves the right to seek discovery on pre-suit willfulness.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the term "non-sensitive electronic data token," which is central to both asserted patents, be construed to read on the system of customer and payment method object identifiers allegedly used in Defendant’s API?
- A key question will be one of architectural alignment: Does the division of responsibilities between Defendant's servers and its customers' servers in the accused products map onto the claimed functional separation between a "secure server" and a "merchant server," especially given the patents' focus on isolating the merchant from sensitive data?
- An evidentiary question will center on distributed action: Given that the claimed methods involve actions by a merchant server, a secure server, and a payer's computing system, the case may turn on whether the Plaintiff can successfully prove its theories of direct infringement, including potentially joint enterprise, by demonstrating who performs or controls each claimed step in the accused system.