Autoscribe Corp v. Payment Savvy LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: Payment Savvy, LLC (Texas)
  • Plaintiff’s Counsel: Ahmad, Zavitsanos & Mensing, PLLC; Ward, Smith, & Hill, PLLC
• Case Identification: 2:23-cv-00390, E.D. Tex., 08/29/2023
• Venue Allegations: Venue is based on Defendant being headquartered in the district, which constitutes a regular and established place of business, and on alleged acts of infringement occurring within the district.
• Core Dispute: Plaintiff alleges that Defendant’s online payment processing solutions infringe a patent related to securely obtaining and using financial account information via a dual-server architecture that separates sensitive data handling from merchant-facing systems.
• Technical Context: The technology addresses the challenges merchants face with Payment Card Industry (PCI) compliance by outsourcing the collection and storage of sensitive financial data to a secure third-party server, which returns a non-sensitive token for transaction processing.
• Key Procedural History: The asserted patent is part of a family tracing back to 2012. The complaint does not mention any prior litigation, licensing history, or post-grant proceedings involving the asserted patent or its family members.

Case Timeline

Date	Event
2012-06-05	Earliest Priority Date for U.S. Patent No. 11,620,621
2023-04-04	U.S. Patent No. 11,620,621 Issued
2023-08-29	Complaint Filed

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"

• 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 time, effort, and cost for merchants to achieve and maintain compliance with the Payment Card Industry Data Security Standard (PCI DSS), which governs the handling of cardholder data to reduce fraud (’621 Patent, col. 1:28-50).
• The Patented Solution: The invention proposes a system architecture that separates a merchant’s primary server from a "secure server" (’621 Patent, col. 2:35-45). The merchant server handles the general e-commerce experience, but when a payer needs to enter sensitive financial information (e.g., a credit card number), the system directs the payer to the secure server, often within a "widget" or frame embedded in the merchant's webpage, creating a seamless user experience (’621 Patent, col. 6:65-67). The secure server collects, encrypts, and stores the sensitive data, and in return, provides the merchant server with a "non-sensitive electronic data token" that represents the stored account information (’621 Patent, col. 3:1-15). This allows the merchant to process payments using the token without ever handling or storing the actual sensitive data, thereby reducing its PCI compliance burden.
• Technical Importance: This tokenization approach allows merchants to offload the highest-risk data security responsibilities to a specialized, compliant provider while retaining control over customer relationships and transaction initiation (’621 Patent, col. 3:6-15).

Key Claims at a Glance

• The complaint asserts independent claim 1.
• Essential elements of claim 1, a method claim, include:
  • A secure server providing an application programming interface (API) to a merchant server.
  • The API providing financial account registration and token retrieval functions.
  • The secure server receiving data from the merchant server via the API.
  • The secure server authenticating the payee (the merchant).
  • Executing a financial account registration function by generating a URL to establish a secure connection with the payer's system.
  • Establishing this secure connection "within a window or frame" displayed within the merchant's webpage.
  • The secure server outputting instructions to the payer’s system to render a payment form and to encrypt and transmit the sensitive information.
  • Receiving and storing the sensitive information.
  • Executing a token retrieval function by providing a "non-sensitive electronic data token" to the merchant server, but not to the payer.
  • Processing the payment using the stored sensitive information upon request from the merchant.
• The complaint does not explicitly reserve the right to assert dependent claims, but infringement is alleged for "one or more claims" (Compl. ¶20).

III. The Accused Instrumentality

Product Identification

• The accused instrumentalities are Defendant’s "online payment solution," "Infringing Methods," and related services (Compl. ¶¶16, 23).

Functionality and Market Context

• The complaint alleges that Defendant provides payment processing solutions that allow merchants to accept payments via credit cards and other methods (Compl. ¶15). The solution is described as featuring an "open API platform" that "seamlessly integrates" into a merchant's existing website or software (Compl. ¶¶26, 30).
• The accused solution is alleged to use "Tokenization and encryption" and to be compliant with security standards like PCI (Compl. ¶¶27, 32). This is supported by a screenshot from Defendant's website showing an infographic for its "ALL-IN-DONE ONLINE PAYMENT SOLUTIONS," which lists "TOKENIZATION AND ENCRYPTION OF CARDHOLDER DATA" as a key feature (Compl. ¶27, p. 8).
• The complaint alleges that Defendant's platform uses Secure Sockets Layer (SSL) encryption to create a secure connection for transmitting sensitive information (Compl. ¶31). This is supported by another screenshot from Defendant's website describing SSL encryption (Compl. ¶31, p. 11).
• The complaint asserts that Defendant is a direct competitor to the Plaintiff, causing lost profits (Compl. ¶17).

IV. Analysis of Infringement Allegations

U.S. Patent No. 11,620,621 Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
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...	Defendant provides an "open API platform" that enables financial account registration and offers "Tokenization" functions. A screenshot from Defendant's website highlights "TOKENIZATION AND ENCRYPTION OF CARDHOLDER DATA" (p. 8).	¶¶26-27	col. 6:55-62
authenticates the payee	Defendant provides merchants with "payment gateway credentials" which are used to authenticate the merchant (payee) and integrate the payment platform into the merchant's software.	¶29	col. 14:55-67
executes the financial account registration function... by: generating a uniform resource locator (URL), for establishing a secure socket layer connection... within a window or frame that is displayed within the webpage provided by the merchant server	Defendant’s solution "seamlessly integrates into your website," which the complaint alleges involves establishing a secure connection within the merchant's webpage to receive payment information.	¶30	col. 17:5-22
outputting instructions to the payer computing system... to render a financial account registration request form... that provides functionality for the payer to provide sensitive financial account information	Defendant's platform provides a "web payment platform" which includes an "online payment form" for customers to enter payment data.	¶¶28, 30	col. 17:23-29
receiving the sensitive financial account information provided by the payer via the secure socket layer connection	Defendant's platform uses "Secure Sockets Layer (SSL) encryption" to create a secure connection between a web server and a browser to receive sensitive information like credit card numbers.	¶31	col. 17:36-39
storing the sensitive financial account information in a secure storage location and performing each software process required to maintain compliance with one or more information security standards	Defendant's platform is described as a "compliant and secure system" that adheres to security standards such as PCI and NACHA. A screenshot cites Defendant's "Level 1 PCI Compliant" status (p. 13).	¶32	col. 17:40-44
executing a token retrieval function... by: providing a non-sensitive electronic data token representing the sensitive financial account information to the merchant server without providing the sensitive financial account information to the merchant server	Defendant's documentation describes "[t]okenization" as a standard feature, which the complaint alleges involves providing a non-sensitive token to the merchant in place of the actual cardholder data.	¶33	col. 17:45-52

• Identified Points of Contention:
  • Technical Question: The claim requires establishing a secure connection "within a window or frame that is displayed within the webpage provided by the merchant server." The complaint relies on marketing language like "seamlessly integrates" (Compl. ¶30) as evidence. A central factual question will be whether the accused system technically operates using an embedded element (such as an iframe, as contemplated by the patent's mention of a "widget or frame" at col. 6:66-67) or if it uses a different method, such as a redirect to a separate page, that may not meet this limitation.
  • Legal/Factual Question: Claim 1 is a method claim whose steps are performed by multiple parties (the secure server, the merchant server, the payer's computing system). The complaint alleges direct infringement by Defendant. This raises the question of whether Defendant directs or controls the other parties' actions to such a degree that all steps of the method can be attributed to it under the standard for divided infringement established in Akamai v. Limelight. The complaint does not provide specific facts to support a "direction or control" theory beyond offering an integrated solution.

V. Key Claim Terms for Construction

• The Term: "secure server" / "merchant server"

• Context and Importance: The patent's architecture is premised on a distinction between the "merchant server" and the "secure server," where the latter handles sensitive data to reduce the compliance burden on the former. The viability of the infringement case depends on mapping Defendant's system architecture to this two-server model. Practitioners may focus on this distinction to determine if the accused system, allegedly provided as a single "online payment solution" (Compl. ¶23), in fact embodies the separate roles and functions of both the claimed "secure server" and the "merchant server" (the latter being operated by Defendant's customer).

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent states that the servers "may operate in the same location or may be the same hardware using a separated volume or partition" (’621 Patent, col. 2:47-49), which could support an argument that the distinction is logical rather than strictly physical.
  • Evidence for a Narrower Interpretation: The specification repeatedly describes the servers as distinct entities performing different functions, with the merchant server not receiving or having security responsibility for the financial account information (’621 Patent, col. 2:51-57, col. 3:11-15). This suggests a functional, if not physical, separation is required.

• The Term: "within a window or frame that is displayed within the webpage provided by the merchant server"

• Context and Importance: This term is critical because it defines the specific technical implementation of the user interface. The infringement analysis will turn on whether Defendant's "seamless[] integrat[ion]" (Compl. ¶28) meets this structural requirement. If Defendant's system uses a full-page redirect to a separate, hosted payment page, it may not infringe this limitation.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: A party might argue that "window" could be interpreted broadly to include a new browser tab or window that is programmatically opened, as long as the user experience is part of a single, continuous transaction flow.
  • Evidence for a Narrower Interpretation: The patent specifically mentions implementing the function in a "widget" or "frame" (’621 Patent, col. 6:66-67). The phrase "within the webpage" strongly suggests an embedded element, like an HTML <iframe>, rather than a separate page, supporting a narrower construction that requires the secure form to be contained inside the merchant's original page.

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant advertises its services and provides promotional literature, documentation, instructions, and technical assistance that encourage its customers (merchants) to implement and use the infringing methods (Compl. ¶¶36-39). The complaint points to Defendant's marketing that its solution is "easy to integrate" and that "We'll plug your payment gateway credentials into the back end of your software" as evidence of affirmative acts to encourage infringement (Compl. ¶39).
• Willful Infringement: Willfulness is alleged based on Defendant having "actual knowledge of the Asserted Patent... no later than the date of this Complaint" (Compl. ¶34). This allegation appears to support only a claim for post-suit willfulness, as it does not plead facts showing Defendant had knowledge of the patent prior to the lawsuit being filed.

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

• A core issue will be one of technical implementation versus claim scope: Does the accused system’s "seamless integration" meet the specific architectural requirement of rendering the payment form "within a window or frame" on the merchant's webpage, or does it use a different technique (e.g., a redirect) that falls outside the scope of the claim language? The resolution will depend on evidence of how the accused system actually operates, rather than the marketing language cited in the complaint.
• A key legal question will be one of divided infringement: Can Plaintiff prove that Defendant, as the provider of the "secure server" component, directs or controls its customers (operating the "merchant servers") and the end-users (operating the "payer computing systems") in a manner sufficient to attribute all steps of the claimed method to Defendant for the purpose of establishing direct infringement?
• A central claim construction question will be the required degree of separation between the claimed "merchant server" and "secure server." The case may turn on whether the patent requires distinct physical or merely logical separation, and how that maps onto the architecture of Defendant’s integrated payment platform.