Nuvei Technologies Inc v. Autoscribe Corp

Prosecution History analysis

Examiner Search analysis

Invalidity Framework analysis

Petition

Petition Analysis

## 1. Case Identification
- Case Number: [IPR2025-00089](https://ai-lab.exparte.com/case/ptab/IPR2025-00089)
- Patent #: [11,620,621](https://ai-lab.exparte.com/patent/11620621)
- Filed: November 6, 2024
- Petitioner(s): [Nuvei Technologies, Inc.](https://ai-lab.exparte.com/party/nuvei-technologies-corp)
- Patent Owner(s): [Autoscribe Corporation](https://ai-lab.exparte.com/party/autoscribe-corp)
- 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](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1001) discloses methods for processing online payments where a secure server, separate from a merchant's server, handles the collection of sensitive financial information. This is achieved by displaying a financial account registration form from the secure server within a window or frame (e.g., an iFrame) on the merchant's webpage, thereby reducing the merchant's PCI compliance burden.

## 3. Grounds for Unpatentability

#### Ground 1: Claims 1-27 are obvious over Stringfellow in view of Kloster.
  - **Prior Art Relied Upon:** U.S. Publication No. 2010/0174626 (“[Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007)”); U.S. Publication No. 2010/0094755 (“[Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008)”).
  - **Core Argument for this Ground:**
    - **Prior Art Mapping:** Petitioner argued that [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) taught the core architecture of the [’621 patent](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1001). [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007)’s “trusted intermediary system” (the claimed “secure server”) provides a sign-in page within an iFrame on an “online merchant system’s” webpage. This allows a user (the claimed “payer”) to enter sensitive financial data directly to the secure system, bypassing the merchant and achieving the patent’s stated goal of reducing merchant compliance costs. However, [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) did not explicitly teach tokenization. [Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008) was argued to supply this missing element, disclosing a “payment system server” that collects sensitive data and provides a non-sensitive “payment data token” to a “business entity” (the merchant). The merchant can then use this token to initiate payments without ever possessing the underlying sensitive financial information.
    - **Motivation to Combine:** Petitioner asserted a person of ordinary skill in the art (POSITA) would combine these references because they address the same problem (offloading merchant security burdens) using the same fundamental architecture (an iFrame-based payment system). A POSITA would have been motivated to incorporate [Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008)'s well-known tokenization functionality into [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007)'s system to gain the explicit benefits [Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008) described, such as enabling one-time and recurring payment options, while maintaining the core security advantage of isolating the merchant from sensitive data.
    - **Expectation of Success:** A POSITA would have had a high expectation of success because the combination involved integrating a known, compatible feature (tokenization) into a known system architecture to achieve predictable results.

#### Ground 2: Claims 1-27 are obvious over Stringfellow in view of Kloster and Carlson.
  - **Prior Art Relied Upon:** [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) (’626 application), [Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008) (’755 application), and U.S. Publication No. 2008/0319869A1 (“[Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018)”).
  - **Core Argument for this Ground:**
    - **Prior Art Mapping:** This ground builds on Ground 1, adding [Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018) to explicitly teach generating a URL with parameters to link a payment session to a specific transaction. The challenged claims require generating a URL that is either dynamic or a static URL with an HTTP parameter to identify the payer and payee. Petitioner contended that while [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) rendered this obvious, [Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018) explicitly disclosed it. [Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018) taught linking messages in a transaction by sending transaction information, including a "merchant ID" and a "correlation ID," within the query string of a URL used to populate an iFrame (e.g., `?Merchid=2000Scorrid=123`). This directly maps to the claimed method of using URL parameters to identify the parties to the transaction.
    - **Motivation to Combine:** A POSITA implementing the [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007)/[Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008) system would need to solve the fundamental problem of how to associate a payment session initiated in an iFrame with the specific transaction started on the merchant's site. Petitioner argued that [Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018) provided an explicit and well-known solution to this exact problem. Therefore, a POSITA would be motivated to use [Carlson](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1018)’s technique of embedding transaction identifiers in the URL query string to ensure the secure server could correctly process the payment for the right merchant and order.
    - **Expectation of Success:** Success would be expected, as using URL parameters to pass state information for web transactions was a conventional and reliable technique at the time.

## 4. Key Claim Construction Positions
- Petitioner argued that no special claim construction is necessary and that the challenged claim terms should be given their plain and ordinary meaning.
- The petition noted that a related case (IPR2024-01159) proposed constructions for three terms. Petitioner contended that its invalidity arguments are robust and do not rely on those constructions, which it suggested are inconsistent with the plain claim language. Specifically, Petitioner argued that [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) discloses the secure server generating a URL, so a construction that allows the merchant server to assemble the URL is not required.

## 5. Arguments Regarding Discretionary Denial
- **Not Cumulative Over Prosecution:** Petitioner argued that the grounds are not cumulative of the original prosecution because the Examiner never considered the combination of [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007) and [Kloster](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1008). The Examiner allowed ancestral claims over a similar reference based on a limitation not present in the currently challenged claims.
- **Not Cumulative Over Pending IPR (IPR2024-01159):** Petitioner argued against discretionary denial in view of a pending IPR on the same patent because this petition presents different arguments and evidence. Key distinctions asserted were: (1) Petitioner is not the same party or a co-defendant with the petitioners in the other IPR; (2) this petition relies on different prior art, primarily [Stringfellow](https://ai-lab.exparte.com/case/ptab/IPR2025-00089/doc/1007), which is not used in the other IPR; (3) this petition challenges additional claims not included in the other IPR; and (4) this petition does not rely on the claim constructions proposed in the other IPR.

## 6. Relief Requested
- Petitioner requested institution of an inter partes review and cancellation of claims 1-27 of Patent [11,620,621](https://ai-lab.exparte.com/patent/11620621) as unpatentable under 35 U.S.C. §103.

Online payment patent on PCI compliance tech challenged: Stringfellow & Kloster cited for obviousness of all 27 claims over iFrame & tokenization.