Autoscribe Corp v. Nuvei Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: Nuvei Corporation (Canada), Nuvei Technologies Corporation (Canada), Nuvei Limited (Cyprus), and Nuvei International Group Limited (Guernsey)
  • Plaintiff's Counsel: Ahmad, Zavitsanos & Mensing, PLLC; Ward, Smith, & Hill, PLLC
• Case Identification: 2:24-cv-00325, E.D. Tex., 11/11/2024
• Venue Allegations: Venue is asserted under 28 U.S.C. § 1391(c), which permits suing alien corporations in any judicial district where personal jurisdiction is established.
• Core Dispute: Plaintiff alleges that Defendants' online payment processing products and services infringe a patent related to securely processing payments using tokenization.
• Technical Context: The technology at issue involves methods for processing online payments that replace a customer's sensitive financial data with a non-sensitive token, a technique used to reduce the scope and cost of merchants' compliance with Payment Card Industry (PCI) data security standards.
• Key Procedural History: This is an Amended Complaint. The complaint alleges that certain defendants gained actual knowledge of the asserted patent and infringement on October 14, 2024, through documents produced in response to venue discovery requests in this same action.

Case Timeline

Date	Event
2012-06-05	U.S. Patent No. 11,620,621 Priority Date
2023-04-04	U.S. Patent No. 11,620,621 Issue Date
2024-10-14	Alleged date of actual knowledge for Nuvei International Group Limited and Nuvei Limited
2024-11-11	Complaint Filing Date

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," issued April 4, 2023 ('621 Patent)

The Invention Explained

• Problem Addressed: The patent background describes the significant problem of fraud in online financial transactions and the substantial cost and complexity for merchants to comply with the Payment Card Industry Data Security Standard (PCI DSS) when handling sensitive cardholder data '621 Patent, col. 1:19-51
• The Patented Solution: The invention describes a system that separates the functions of a merchant's primary server and a separate "secure server" to minimize the merchant's contact with sensitive data '621 Patent, abstract A merchant server provides a webpage to a customer but uses an API to direct the customer's browser to a form (e.g., in a frame or window) hosted by the secure server for the entry of financial information '621 Patent, col. 2:16-50 The secure server receives and stores this sensitive data, and in return, provides a "non-sensitive electronic data token" to the merchant server '621 Patent, col. 2:51-col. 3:14 The merchant can then use this token to initiate payments without ever possessing or storing the customer's actual financial account information, thereby reducing its PCI compliance burden '621 Patent, col. 3:4-14
• Technical Importance: This tokenization architecture allows merchants to maintain control over the customer relationship and payment initiation while outsourcing the security and compliance risks associated with handling sensitive financial data.

Key Claims at a Glance

• The complaint asserts independent claim 23 Compl. ¶25 Compl. ¶27
• Essential Elements of Claim 23 (A merchant server):
  • Provide a webpage to a payer computing system.
  • Receive enrollment data identifying the payer.
  • Provide payer data and a payment amount to a secure server via an API.
  • Display a window or frame within the webpage.
  • Provide authentication credentials to the API to establish an authenticated session.
  • Initiate a financial account registration function of the API that establishes a secure socket layer (SSL) connection within the window/frame, renders a form for sensitive financial information, and instructs the payer's system to encrypt and transmit that information to the secure server.
  • Initiate a token retrieval function of the API that outputs a non-sensitive token to the merchant server.
  • Receive the non-sensitive token, with the limitation that the merchant server does not receive the underlying sensitive information.
  • Store the token in association with the payer's enrollment data.
  • Process a payment by using the token to instruct the secure server to execute the transaction.
• The complaint does not explicitly reserve the right to assert dependent claims but refers to infringement of "one or more claims" Compl. ¶25

III. The Accused Instrumentality

Product Identification

• The accused services are Defendants' "Payment Page," "Simply Connect," and "Web SDK" products Compl. ¶19

Functionality and Market Context

• The complaint alleges these are payment processing solutions that allow online merchants to accept payments Compl. ¶19 The "Payment Page" product is described as integrating into a merchant's site "using an IFrame or a full page redirect" Compl. p. 10 This allows merchants to "securely process cards" via the "Nuvei Gateway" Compl. p. 10 The system uses tokenization, where customer card details are stored by Nuvei and represented by a "userPaymentOptionId" token, which is used for subsequent or recurring transactions without the merchant needing to store the credit card information itself Compl. p. 24 Compl. p. 27 This functionality is alleged to reduce the PCI compliance burden for merchants Compl. p. 12 Compl. p. 23 The complaint includes a screenshot from Defendants' documentation showing an overview of online payment options offered by Nuvei. Compl. p. 9

IV. Analysis of Infringement Allegations

The complaint alleges that by providing their products, Defendants "contribute and/or actively induce the creation of a merchant server, operated by or for the benefit of a payee that meets every element of Claim 23" Compl. ¶28

'621 Patent Infringement Allegations

Claim Element (from Independent Claim 23)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
A merchant server ... provide a webpage to a payer computing system used by a payer	Defendants' products are integrated into a merchant's site, which provides a webpage to customers. A screenshot shows Nuvei's "Payment Page" solution integrates via an "IFrame or a full page redirect... into your site." (Compl. p. 11).	¶29	col. 22:5-10
display a window or frame within the webpage provided to the payer computing system	The accused "Payment Page" is loaded "via an IFrame or a full page redirect" on the merchant's site, which functions as the claimed window or frame.	¶32	col. 27:3-5
initiate a financial account registration function of the API ... establishing a secure socket layer connection between the secure server and the payer computing system within the window or frame	The accused products use an HTTPS request to create a secure connection to Nuvei's page or IFrame, which the complaint alleges fulfills the SSL connection requirement. A screenshot illustrates creating an HTTPS query string to submit a request. (Compl. p. 20).	¶34	col. 26:7-19
outputting instructions to the payer computing system to render a financial account registration request form	The Nuvei IFrame or redirected page renders a payment form where a user can input card details. The complaint provides a screenshot of an E-commerce demo page showing a payment form with fields for Cardholder Name, Card Number, Expiry date, and Security Code. (Compl. p. 21).	¶34	col. 26:48-59
initiate a token retrieval function ... outputting a non-sensitive electronic data token representing the sensitive financial account information to the merchant server	Nuvei's system uses a tokenization technology that "replaces credit card information with a token." This token allows access to billing data without the merchant storing the credit card information. A screenshot describes this tokenization process. Compl. p. 24	¶35	col. 28:42-49
store the non-sensitive electronic data token in association with the enrollment data identifying the payer	Defendants' documentation describes using a "userPaymentOptionId" token for recurring transactions, which is stored and associated with the customer for future payments initiated by the merchant.	¶37	col. 28:53-56
process a payment from the payer by generating a payment transaction instruction, using the token retrieval function of the API	The complaint alleges merchants perform recurring payments or subscriptions using "stored card credentials" by sending the encrypted "userPaymentOptionId" token in a payment request. A screenshot describes using stored "UPOs" (User Payment Options) for merchant-initiated transactions. (Compl. p. 28).	¶37	col. 28:57-65

• Identified Points of Contention:
  • Scope Question: The infringement theory is centered on "inducement and contribution" Compl. ¶28 A central question will be whether Defendants' products, which are integrated into a merchant's e-commerce site, can be seen as causing the creation of the claimed "merchant server" system, or if there is a legally significant distinction between providing the tools (the accused API, SDK, and gateway) and operating the claimed server itself.
  • Technical Question: What evidence demonstrates that the accused system's "userPaymentOptionId" Compl. ¶36 is functionally and structurally equivalent to the "non-sensitive electronic data token" as defined by the patent? The analysis will likely focus on whether the token is truly non-sensitive and whether the merchant server is prevented from accessing the underlying financial data, as required by the claim.

V. Key Claim Terms for Construction

• The Term: "A merchant server, operated by or for the benefit of a payee"

• Context and Importance: This term, appearing in the preamble of claim 23, defines the apparatus being claimed. The infringement allegations focus on indirect infringement, suggesting Defendants do not directly operate the "merchant server" but instead provide tools for merchants to do so Compl. ¶28 The construction of this term will be critical to determining whether Defendants' activities fall within the scope of the claim.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The phrase "for the benefit of a payee" could be argued to encompass a third-party service provider like Nuvei, whose systems are provided for the benefit of their merchant clients (the payees). The specification notes that the functions can be provided by "processors serving merchants" '621 Patent, col. 6:17-18
  • Evidence for a Narrower Interpretation: The patent consistently distinguishes between the "merchant server" and the "secure server," often depicting them as separate entities operated by different parties '621 Patent, Fig. 2 '621 Patent, col. 6:1-8 This could support an argument that the "merchant server" is the one directly controlled by the merchant, not the third-party payment processor's gateway.

• The Term: "secure server"

• Context and Importance: The patent's architecture is founded on the functional separation between the "merchant server" and the "secure server," with the latter handling all sensitive data. The infringement analysis will depend on mapping Nuvei's payment gateway and backend systems to this claimed "secure server."

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the secure server as the system that receives and stores financial account information and provides a token in return '621 Patent, col. 2:16-50 Any system performing these core functions could potentially be considered a "secure server."
  • Evidence for a Narrower Interpretation: The specification suggests the secure server may have a "higher level of security than the merchant server" and is the component that must be PCI-compliant '621 Patent, col. 8:9-14 Embodiments describe the secure server generating a URL and hosting the payment form within a frame on the merchant's page '621 Patent, col. 26:1-35, providing specific technical characteristics that could limit the term's scope.

VI. Other Allegations

• Indirect Infringement: The complaint heavily relies on allegations of indirect infringement. It alleges inducement by stating Defendants provide documentation, APIs, and promotional literature that encourage and instruct users (merchants) to implement the accused products in a way that infringes claim 23 Compl. ¶¶42-44 It alleges contributory infringement by claiming Defendants provide APIs and code that are "especially made or especially adapted for use in an infringement" and are "not a staple article or commodity of commerce suitable for substantial noninfringing use" Compl. ¶¶45-47
• Willful Infringement: Willfulness is alleged based on Defendants' knowledge of the patent, purportedly gained no later than the date of the original complaint for two defendants, and no later than October 14, 2024, for two other defendants following venue-related discovery Compl. ¶38 Compl. ¶50

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

1. A central issue will be one of indirect liability: Given that the asserted claim is for a "merchant server" apparatus, and Plaintiff's theory is that Defendants induce and contribute to infringement, can Plaintiff prove that Defendants' customers (merchants) directly infringe the claim by combining their own websites with Defendants' payment products, and that Defendants knowingly and intentionally caused this infringement?

2. A key question of claim scope will be: Can the patent's two-part architecture of a "merchant server" and a "secure server" be read onto the accused system, where Defendants provide a payment gateway service (the alleged "secure server") that is integrated into a merchant's website (the alleged "merchant server") via an API and an IFrame? The case may turn on whether this real-world implementation matches the specific functional and structural limitations of the patent's claims.