DCT
2:23-cv-00364
Autoscribe Corp v. Fortis Payment Systems LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Autoscribe Corporation (Maryland)
- Defendant: Fortis Payment Systems, LLC (Delaware)
- Plaintiff’s Counsel: Ahmad, Zavitsanos & Mensing, PLLC; Ward, Smith, & Hill, PLLC
- Case Identification: 2:23-cv-00364, E.D. Tex., 08/10/2023
- Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in Plano, Texas, within the Eastern District of Texas, where it employs staff and conducts business activities related to the accused services.
- Core Dispute: Plaintiff alleges that Defendant’s "Embedded Payment" solutions, which allow merchants to process online payments without directly handling sensitive financial data, infringe a patent related to a two-server system for securely managing such transactions.
- Technical Context: The technology addresses the need for merchants to reduce their compliance burden under the Payment Card Industry Data Security Standard (PCI DSS) by offloading the collection and storage of sensitive payment information to a secure third-party server.
- Key Procedural History: The complaint does not mention any prior litigation, inter partes review (IPR) proceedings, or licensing history related to the asserted patent.
Case Timeline
| Date | Event |
|---|---|
| 2012-06-05 | ’621 Patent - Earliest Priority Date |
| 2023-04-04 | ’621 Patent - Issue Date |
| 2023-08-10 | 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.
The Invention Explained
- Problem Addressed: The patent identifies the high cost and complexity for merchants to secure customer financial data and comply with the Payment Card Industry Data Security Standard (PCI DSS) as a major problem in online commerce ('621 Patent, col. 1:22-51). A single security breach can compromise millions of accounts, creating significant risk for merchants who handle such data directly ('621 Patent, col. 1:28-31).
- The Patented Solution: The invention proposes a system architecture that separates the merchant's primary server from a dedicated "secure server" ('621 Patent, col. 2:34-36, Fig. 2). The merchant's system can handle a transaction up to the point of payment. To enter financial details, the payer is connected directly to the secure server, often within a frame or window on the merchant's webpage, so the merchant's systems never receive or store the sensitive data ('621 Patent, col. 6:56-62). The secure server captures the data, stores it, and provides the merchant with a non-sensitive "token" that acts as a reference to the stored data for future transactions, thereby reducing the merchant's PCI compliance scope ('621 Patent, col. 2:51-67).
- Technical Importance: This tokenization approach allows merchants to facilitate recurring payments and manage customer accounts without bearing the full security and regulatory burden of handling raw credit card or bank account numbers ('621 Patent, col. 3:6-15).
Key Claims at a Glance
- The complaint asserts infringement of at least independent claim 1 (Compl. ¶23).
- The essential elements of independent claim 1 include:
- A method performed by one or more secure servers for processing a payment.
- Providing an API to a merchant server that offers financial account registration and token retrieval functions.
- Receiving data from the merchant server via the API, including a payer identifier and payment amount.
- Authenticating the payee.
- Executing the financial account registration by generating a URL to establish a secure connection with the payer's computing system.
- Establishing this secure connection within a window or frame displayed on the merchant's webpage.
- Rendering a financial account registration form within that window or frame.
- Receiving and storing the sensitive financial information provided by the payer via the secure connection.
- Executing a token retrieval function by providing a non-sensitive electronic data token to the merchant server, without providing the sensitive information to the merchant or the token to the payer.
- Processing the payment using the stored sensitive information.
- The complaint does not explicitly reserve the right to assert dependent claims, but alleges infringement of "one or more claims" (Compl. ¶23).
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are Defendant’s "Embedded Payment" solutions, which include the "Elements" product and the Fortis API (Compl. ¶¶ 17, 24, 26).
Functionality and Market Context
- The "Elements" product is described as a customizable payment interface that can be embedded into a merchant's website or back-office software to receive card, ACH, and mobile wallet payments (Compl. ¶26, p. 8).
- Technically, the system uses an "iframe" to create a payment form that "securely sends the payment information to Fortis over an HTTPS connection," thereby removing "the capturing and transmission of card holder details from the integrators infrastructure, thus reducing their PCI scope" (Compl. ¶¶ 32, 26; p. 8, p. 12).
- The system uses an API to manage the transaction flow, which involves the merchant's server requesting a "client_token" from Fortis's server, using that token to render the payment fields, and then processing the transaction via API calls (Compl. ¶¶ 29-30; p. 9). A diagram in the complaint shows a workflow where an "ISV Server" (merchant) communicates with "Fortis" servers to create tokens and process transactions, while the user's "Browser" submits card details directly to Fortis (Compl. p. 9).
IV. Analysis of Infringement Allegations
’621 Patent 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... and provides access to the financial account registration and token retrieval functions to the merchant server | Defendant's Fortis API provides functions for its "Elements" product, including tokenization for recurring billing, which are accessible to the merchant ("ISV Server") (Compl. p. 8). The complaint points to documentation for "Store multi use token," "ISV Obtains Client_Token," and "Process Transaction" functions. | ¶¶27-29 | col. 22:5-14 |
| receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount... | The Fortis API receives a "POST" request from the merchant server containing transaction details, such as amount and currency, to create a "TransactionIntention" or "TicketIntention". A flowchart illustrates this data transfer from the "ISV Server" to "Fortis" (Compl. p. 9). | ¶30 | col. 22:15-19 |
| authenticates the payee | The complaint alleges this is met by the use of a "unique ID" to create an empty DOM node on the payment page, which is then passed to Elements (Compl. p. 11). This ID is associated with the merchant's account. | ¶31 | col. 22:20-21 |
| executes the financial account registration function... by: generating a uniform resource locator (URL)... for establishing a secure socket layer connection... | The "Elements" documentation describes an "iframe" that "securely sends payment information to Fortis over an HTTPS connection" and requires the merchant's checkout page to also use "https://" (Compl. p. 12). | ¶32(a) | col. 22:24-34 |
| establishing the secure socket layer connection... between the secure server and the payer computing system within a window or frame that is displayed within the webpage provided by the merchant server | The accused "Elements" product is described as creating an "iframe" within the merchant's webpage to establish a secure HTTPS connection for transmitting payment information to Fortis (Compl. p. 12). | ¶32(b) | col. 22:35-42 |
| outputting instructions... to render a financial account registration request form, within the window or frame... that provides functionality for the payer to provide sensitive financial account information | The "Elements" product is a set of "pre-built UI components for collecting and validating card number, ZIP code, expiration date, and other fields" that are rendered inside the "iframe" (Compl. p. 13). | ¶32(c) | col. 22:43-52 |
| 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 and without providing the non-sensitive electronic data token to the payer | The complaint provides a flowchart where Fortis creates a "Client_token" and returns it to the "ISV Obtains Client_token" step on the merchant server (Compl. p. 9). Defendant’s documentation also shows fetching a "client_token" for use by the merchant's server-side logic (Compl. p. 16). | ¶35 | col. 22:59-col. 23:2 |
| processing the payment transaction using the sensitive financial account information... and forwarding at least a portion of the payment amount to the payee. | A screenshot of a "Transaction Receipt" from Defendant's documentation shows a successful transaction for a specific amount, which is alleged to demonstrate processing of the payment (Compl. p. 16). | ¶35 | col. 23:3-9 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether Defendant’s integrated "Elements" platform, which acts as a service for merchants, constitutes a "secure server" that is distinct from the "merchant server" in the manner contemplated by the patent. The patent describes two separate servers, while the accused product is a service that integrates into the merchant's website.
- Technical Questions: The analysis may focus on whether the "client_token" and "ticket_id" described in Defendant’s documentation (Compl. p. 9) function as the "non-sensitive electronic data token" of the claim. The claim requires the token to be provided to the merchant server but not to the payer. The court will need to determine if the accused workflow, which involves scripts running in the payer's browser, meets this negative limitation.
V. Key Claim Terms for Construction
The Term: "secure server"
Context and Importance: The invention is premised on a two-server architecture. The definition of "secure server" and its relationship to the "merchant server" is foundational to the infringement analysis. Practitioners may focus on whether Fortis's hosted platform, as a whole, can be considered the claimed "secure server" when it is providing a service that runs partially on a merchant's site via an iframe.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification suggests the separation can be logical rather than strictly physical, stating the servers "may be the same hardware using a separated volume or partition, or memory section" ('621 Patent, col. 2:47-49). This could support an argument that Fortis's logically distinct payment processing service meets the definition, even if tightly integrated with the merchant's site.
- Evidence for a Narrower Interpretation: The patent consistently depicts the "secure server 202" and "merchant server 204" as distinct blocks in diagrams (e.g., Fig. 2) and states that "particular advantages are realized through logical and/or physical separation" ('621 Patent, col. 2:49-50). This language could support a narrower definition requiring more distinct operational separation than what an embedded service provides.
The Term: "non-sensitive electronic data token"
Context and Importance: The purpose of the token is to allow the merchant to initiate payments without possessing sensitive data. Its specific characteristics and how it is handled are critical. The infringement case depends on mapping Fortis's "client_token" and/or "ticket_id" to this claim term, including satisfying the negative limitation that it is not provided to the payer.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent broadly defines the token as a "symbolic representation of a financial instrument" ('621 Patent, col. 2:53-55) and an "index to the stored financial account information" ('621 Patent, col. 2:65-66). This could encompass any identifier that allows the merchant to reference the payment data stored on the secure server.
- Evidence for a Narrower Interpretation: The claim requires the token to be provided "to the merchant server" without providing it "to the payer." The accused system's flowchart (Compl. p. 9) shows a "client_token" being set in a script in the "Browser" column. A defendant may argue that this constitutes providing the token to the payer's computing system, thus failing to meet the negative limitation.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement of infringement, asserting that Defendant provides its customers (merchants) with APIs, documentation, and promotional literature that instruct and encourage them to implement the infringing payment method (Compl. ¶¶ 38-41). The complaint identifies several of Defendant's customers as direct infringers (Compl. ¶37). It also alleges contributory infringement, stating the provided APIs and code are especially adapted for use in an infringing manner and are not a staple commodity (Compl. ¶¶ 43-45).
- Willful Infringement: The complaint alleges that Defendant had "actual knowledge of the Asserted Patent... no later than the date of this Complaint" (Compl. ¶36). This forms the basis for a claim of post-suit willfulness. No facts supporting pre-suit knowledge are alleged.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural mapping: does Fortis's "Elements" platform, an embedded service that uses an "iframe" on a merchant's website, embody the distinct "merchant server" and "secure server" architecture required by the claims, or does this high level of integration fall outside the patent's scope?
- A key evidentiary question will be one of functional compliance: does the accused system's workflow, which involves a "client_token" being handled by scripts in the payer's browser, satisfy the claim 1 limitation of "providing a non-sensitive electronic data token... to the merchant server without providing the non-sensitive electronic data token to the payer"?
- The case will also likely examine the knowledge and intent elements for indirect infringement, focusing on whether Fortis’s documentation and API instructions actively instruct users to perform all steps of the claimed method with the specific intent to cause infringement.