DCT

2:24-cv-00325

Autoscribe Corp v. Nuvei Corp

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:24-cv-00325, E.D. Tex., 05/03/2024
  • Venue Allegations: Venue is alleged to be proper for the Canadian defendants as alien corporations subject to personal jurisdiction. For the Delaware defendant, Nuvei Technologies, Inc., venue is alleged based on a regular and established place of business in Plano, Texas, within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s online payment processing solutions infringe a patent related to securely processing financial transactions by separating the merchant's system from a secure payment server that handles sensitive data.
  • Technical Context: The technology concerns methods for reducing the security and compliance burden (such as PCI DSS) for online merchants by using tokenization, where sensitive payment data is handled by a third-party secure server, which provides a non-sensitive token to the merchant for processing transactions.
  • Key Procedural History: No prior litigation, licensing history, or other significant procedural events are mentioned in the complaint.

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-05-03 Complaint Filing Date

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

  • Patent Identification: 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.

The Invention Explained

  • Problem Addressed: The patent describes the significant cost, complexity, and security risks for merchants who handle customer credit card data, particularly the burden of complying with the Payment Card Industry Data Security Standard (PCI DSS) (ʼ621 Patent, col. 1:22-51). A security breach at a merchant can compromise millions of accounts (ʼ621 Patent, col. 1:26-29).
  • The Patented Solution: The invention proposes a system architecture that separates a merchant’s primary server from a "secure server." The merchant server initiates an enrollment session, but the customer provides sensitive financial information (like a credit card number) directly to the secure server, for instance, through a frame embedded in the merchant’s webpage (ʼ621 Patent, col. 2:30-50). The secure server stores this sensitive data and gives the merchant’s server a non-sensitive "token" in return. The merchant can then use this token to process payments without ever possessing or storing the actual financial data, thereby reducing its PCI compliance scope (ʼ621 Patent, col. 2:51-col. 3:15).
  • Technical Importance: This tokenization method allows merchants to maintain a seamless, integrated checkout experience on their own websites while offloading the primary responsibility for securing cardholder data to a specialized, compliant third-party provider (ʼ621 Patent, col. 2:4-7).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1 (Compl. ¶25, ¶27).
  • Independent Claim 1 of the ’621 Patent recites a multi-step method performed by one or more "secure servers," with key elements including:
    • Providing an API to a "merchant server" that enables financial account registration and token retrieval.
    • Receiving payer data and a payment amount from the merchant server via the API.
    • Authenticating the payee.
    • Executing a financial account registration function, which involves generating a URL and establishing a secure connection with the payer's computer system inside a window or frame on the merchant's webpage.
    • Rendering a form for the payer to enter sensitive financial information directly to the secure server.
    • Receiving and storing the sensitive information.
    • Executing a token retrieval function that provides a "non-sensitive electronic data token" to the merchant server, without providing the sensitive information itself.
    • Processing the payment transaction using the stored sensitive information upon request from the merchant.
  • The complaint does not explicitly reserve the right to assert dependent claims but refers to infringement of "one or more claims" (Compl. ¶23).

III. The Accused Instrumentality

Product Identification

The accused instrumentalities are Defendants’ payment processing services, including their “Payment Page,” “Simply Connect,” “Web SDK,” and “Server-to-server” products, collectively referred to as the "Infringing Methods" (Compl. ¶19, ¶26).

Functionality and Market Context

  • The accused products are described as online payment solutions that enable merchants to accept payments from customers (Compl. ¶28, p.8). The "Payment Page" product is specifically highlighted as a way to integrate Nuvei's features into a merchant's site "using an IFrame or a full page redirect" (Compl. ¶28, p.9).
  • The complaint alleges that a merchant integrates the service by creating an HTTPS request to Nuvei's servers, which redirects the customer to Nuvei's page or IFrame to handle the payment (Compl. ¶29, p.10). This process is alleged to use an API that enables merchants to process payments through Nuvei's "digital payment Gateway" while reducing the merchant's "PCI burden" (Compl. ¶29, p.11). A screenshot from Defendant's documentation illustrates the payment form presented to an end-user within this framework (Compl. ¶33c, p.18).
  • The complaint alleges that Defendants are a major financial services company processing approximately $130 billion in payments annually and that they compete directly with Plaintiff Autoscribe (Compl. ¶¶18, 20).

IV. Analysis of Infringement Allegations

’621 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A method of processing a payment transaction... performed by one or more secure servers... Defendants' servers perform the infringing methods, acting as the secure servers (Compl. ¶¶26, 28). ¶28 col. 17:1-3
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... Defendants' API is described as enabling merchants to process payments through Nuvei's gateway, providing tokenization functions (Compl. ¶¶29-30). ¶30 col. 17:4-12
receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount... The API receives parameters such as "total_amount," "user_token_id," and "merchant_id" from the merchant (Compl. ¶31). ¶31 col. 17:13-16
authenticates the payee; The API uses a "checksum" created with a secret key to authenticate the HTTPS request from the merchant, who is the payee (Compl. ¶32). ¶32 col. 17:17
generating a uniform resource locator (URL), for establishing a secure socket layer connection... The merchant server creates an "HTTPS query string" which serves as the URL to initiate the payment process on Nuvei's servers (Compl. ¶33a). ¶33 col. 17:21-29
establishing the secure socket layer connection... between the secure server and the payer computing system within a window or frame... Defendants' documentation states the service can be loaded "via an IFrame," establishing the connection within a frame on the merchant's site (Compl. ¶33b). A visual shows documentation mentioning the use of an IFrame (Compl. p.17). ¶33 col. 17:30-37
outputting instructions... to render a financial account registration request form... Nuvei's servers output instructions that render a payment form for the end-user to enter card details (Compl. ¶33c). A screenshot shows the payment information form (Compl. p.18). ¶33 col. 17:38-46
executing a token retrieval function... by: providing a non-sensitive electronic data token representing the sensitive financial account information to the merchant server... Nuvei's "tokenization technology" is alleged to replace credit card information with a token that is returned to the merchant (Compl. ¶36). A visual from Defendant's website describes this tokenization process (Compl. p.23). ¶36 col. 18:2-10
processing the payment transaction using the sensitive financial account information... Defendants' documentation describes how, after a customer is redirected to a "Success page," Nuvei processes the transaction and sends a response with the outcome (Compl. ¶36). A visual illustrates this "Handle the Response" process (Compl. p.24). ¶36 col. 18:11-18

Identified Points of Contention

  • Scope Questions: The case may center on whether the roles of Defendants' systems and their merchant-customers' systems align with the "secure server" and "merchant server" architecture described in the patent. The patent's description emphasizes a model for reducing a merchant's own PCI compliance scope (ʼ621 Patent, col. 2:4-7), raising the question of whether this specific purpose limits the claim's scope to architectures implemented in that context.
  • Technical Questions: A key technical question may be whether the "checksum" used to "authenticate the request" (Compl. ¶32, p.15) from the merchant server meets the claim limitation of "authenticates the payee." A court may need to determine if authenticating a single data transmission is legally and technically equivalent to authenticating the merchant entity itself, as the term "payee" implies.

V. Key Claim Terms for Construction

"secure server"

Context and Importance: This term is foundational to the patent's architecture. The infringement theory depends on casting Defendants' platform as the "secure server" and their clients' e-commerce sites as the "merchant server." Practitioners may focus on this term because its construction will determine if the accused third-party processor model falls within the scope of the claims.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The claims themselves do not explicitly define the term beyond its function, suggesting any server performing the recited secure functions could qualify. Claim 8 describes a "secure server" as comprising processors and memory to execute the claimed steps, a broad structural definition.
  • Evidence for a Narrower Interpretation: The specification repeatedly contrasts the "secure server" with the "merchant's regular server" for the purpose of removing the merchant's systems from PCI audit scope (ʼ621 Patent, col. 2:30-50). This context suggests the term may imply a server that is logically and/or physically separate from the primary merchant systems to achieve this specific security benefit.

"authenticates the payee"

Context and Importance: The complaint maps this limitation to the API's use of a "SHA-256 encrypted checksum" to "authenticate the request" (Compl. ¶32, p.15). The validity of this mapping is critical for proving infringement of this element.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The patent does not provide an explicit definition, potentially allowing for any technical method that verifies the identity of the party entitled to payment (the payee). An argument could be made that authenticating a request originating from the payee's server, using a secret key known only to the payee, effectively authenticates the payee for that transaction.
  • Evidence for a Narrower Interpretation: The specification discusses authenticating a "system user" through a "login request method" that involves a "validation engine" and "user key registry" (ʼ621 Patent, Fig. 4f; col. 14:57-65). This more robust process could be used to argue that a simple checksum for a single API call is insufficient to meet the "authenticates the payee" limitation, which implies authenticating the entity, not just the data packet.

VI. Other Allegations

Indirect Infringement

The complaint alleges that Defendants induce infringement by their customers (merchants). The alleged inducing acts include advertising the infringing methods and publishing specifications, promotional literature, and API documentation that instruct and encourage customers to implement and use the patented methods (Compl. ¶¶38, 41-42). It is also alleged that Defendants contribute to infringement by providing APIs and code that are a material part of the invention and not a staple article of commerce (Compl. ¶¶44-46).

Willful Infringement

Willfulness is alleged based on Defendants having knowledge of the patent "no later than the date of this Complaint" (Compl. ¶37). The complaint also alleges willful blindness, stating Defendants acted with the belief that there was a high probability of infringement while remaining willfully blind (Compl. ¶40).

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

  • A core issue will be one of architectural equivalence: Does the relationship between a third-party payment processor (Nuvei) and its merchant-customer's website fit the patent's "secure server" and "merchant server" model, particularly given the specification's focus on a merchant separating its own systems to reduce its PCI compliance burden?
  • A second central question will be one of functional scope: Does the use of an API checksum to "authenticate the request" from a merchant's server satisfy the claim requirement to "authenticate the payee," or does the patent's context require a more robust authentication of the merchant entity itself?
  • Finally, the case may present a question of infringement theory: While the complaint alleges direct infringement by Defendants performing the claimed method on their servers, it also heavily pleads indirect infringement. The court may need to clarify whether the direct infringer is Nuvei, its merchant customers, or both acting in concert, which will impact the viability of the inducement and contributory infringement claims.