Nuvei Technologies Inc v. Autoscribe Corp

1. Case Identification

• Case #: IPR2025-00089
• Patent #: 11,620,621
• Filed: November 6, 2024
• Petitioner(s): Nuvei Technologies, Inc.
• Patent Owner(s): Autoscribe Corporation
• Challenged Claims: 1-27

2. Patent Overview

• Title: Systems and Methods for Obtaining and Using Account Information to Process Financial Payments
• Brief Description: The ’621 patent discloses methods for processing online payments where a merchant server uses an API to display a payment form from a separate, secure server within a window or frame (e.g., an iFrame) on the merchant's webpage. This architecture allows the secure server to handle sensitive financial data, reducing the merchant's security compliance burden, and uses tokenization to enable subsequent payments.

3. Grounds for Unpatentability

Ground 1: Claims 1-27 are obvious over Stringfellow in view of Kloster

• Prior Art Relied Upon: Stringfellow (Application # 2010/0174626) and Kloster (Application # 2010/0094755).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Stringfellow taught the core architecture of the ’621 patent. Specifically, Stringfellow disclosed a method where an "online merchant system" (the claimed "merchant server") serves a webpage to a "user" (the "payer computer system"). Within this page, a "sign-in page" from a "trusted intermediary system" (the "secure server") is implemented as an iFrame. This allows the user to enter sensitive financial information directly to the secure server, isolating the merchant from that data to reduce security risks. However, Stringfellow did not explicitly disclose a "token retrieval" function. Petitioner asserted that Kloster supplied this missing element. Kloster described a nearly identical architecture where a "payment system server" collected sensitive data via an iFrame on a "business entity's" website and then provided a non-sensitive "payment data token" back to the business entity. This token could be used for subsequent or recurring payments without re-exposing sensitive data.
  • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine the teachings of Stringfellow and Kloster because both references addressed the same problem—reducing a merchant's PCI compliance burden—using the same fundamental solution of an iFrame-based payment system. Kloster explicitly taught the benefits of adding tokenization to such a system, such as enabling "one-time payment processing, customer data profile management, and/or recurring payment options" without requiring the merchant to store sensitive information. A POSITA would have been motivated to incorporate Kloster's well-known tokenization functionality into Stringfellow's system to gain these recognized advantages.
  • Expectation of Success: A POSITA would have a reasonable expectation of success in combining these references. Both systems were based on common web technologies (APIs, iFrames, HTTP), and integrating a tokenization function as described by Kloster into the payment flow of Stringfellow was a straightforward implementation of known e-commerce principles.

Ground 2: Claims 1-27 are obvious over Stringfellow in view of Kloster and Carlson

• Prior Art Relied Upon: Stringfellow (Application # 2010/0174626), Kloster (Application # 2010/0094755), and Carlson (Application # 2008/0319869).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground built upon the combination of Stringfellow and Kloster from Ground 1, adding Carlson to further support the obviousness of specific claim limitations related to identifying the payer and payee. The challenged claims required generating a URL (either static with parameters or dynamic) to identify the transaction. Petitioner contended that Carlson explicitly taught using URL query string parameters to tie together different messages in a single transaction. Carlson disclosed passing a "merchant ID" and a "correlation ID" in a URL's query string to populate an iFrame, explaining this "ties together messages associated with the same transaction." This directly mapped to claim limitations requiring the URL to identify the payer and payee.
  • Motivation to Combine: While the Stringfellow/Kloster combination already rendered this limitation obvious, a POSITA would also look to Carlson for a known method of maintaining transaction context between a merchant server and a secure payment server. Carlson explicitly explained the rationale for including transaction identifiers in a URL sent to an iFrame. A POSITA implementing the Stringfellow/Kloster system would naturally use this common and well-documented technique to ensure that the payment information entered in the iFrame was correctly associated with the corresponding shopping session on the merchant's site.
  • Expectation of Success: Implementing context-passing via URL parameters as taught by Carlson was a routine and predictable task in web development at the time, ensuring a high expectation of success.

4. Arguments Regarding Discretionary Denial

• Petitioner argued against discretionary denial by asserting the grounds were not cumulative of art considered during prosecution or in a co-pending inter partes review (IPR).
  • Original Prosecution: The Examiner never considered Kloster or the specific combination of Stringfellow and Kloster. While the Examiner had considered references similar to Stringfellow in a parent application, claims were allowed based on a limitation not present in the challenged claims of the ’621 patent.
  • Co-pending IPR (IPR2024-01159): Petitioner argued that this petition was not cumulative of IPR2024-01159 because it relied on different prior art (that IPR did not rely on Stringfellow), challenged additional claims not at issue in the other IPR, and did not rely on the same proposed claim constructions.

5. Relief Requested

• Petitioner requested institution of an inter partes review and cancellation of claims 1-27 of the ’621 patent as unpatentable under 35 U.S.C. §103.