Autoscribe Corp v. PCI Booking Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Autoscribe Corporation (Maryland)
  • Defendant: PCI Booking Limited (Ireland)
  • Plaintiff’s Counsel: AHMAD, ZAVITSANOS & MENSING, PLLC
• Case Identification: 3:24-cv-00081, S.D. Tex., 03/22/2024
• Venue Allegations: Plaintiff alleges venue is proper because Defendant resides in the district through a "US Sales & Support" office and has committed acts of infringement there. Alternatively, as an alien corporation, Defendant may be sued in any district.
• Core Dispute: Plaintiff alleges that Defendant’s "PCI Shield" and "Orchestra" secure payment processing services infringe a patent related to isolating sensitive financial data from merchant systems during online transactions.
• Technical Context: The technology addresses the need for e-commerce merchants to comply with Payment Card Industry Data Security Standards (PCI-DSS) by using a third-party secure server and tokenization to process payments without handling sensitive cardholder data directly.
• Key Procedural History: The patent-in-suit is subject to a terminal disclaimer, which may limit its enforceable term to that of an earlier-expiring, related patent. No other significant procedural events are mentioned in the complaint.

Case Timeline

Date	Event
2012-06-05	'621 Patent Earliest Priority Date
2023-04-04	'621 Patent Issue Date
2024-03-22	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"

The Invention Explained

• Problem Addressed: The patent’s background describes the significant cost, complexity, and risk merchants face in handling sensitive credit card data and complying with the stringent Payment Card Industry Data Security Standard (PCI-DSS) (’621 Patent, col. 1:21-50).
• The Patented Solution: The invention describes a system where a merchant’s website displays a window or frame (e.g., an iFrame) that is controlled by a separate, "secure server." A customer ("payer") enters their financial information directly into this frame, so the sensitive data is transmitted to the secure server without passing through the merchant's systems. The secure server then stores the sensitive data, creates a non-sensitive "token," and provides this token to the merchant. The merchant can then initiate payments using the token, offloading the burden of securing the actual card data (’621 Patent, Abstract; col. 2:18-67).
• Technical Importance: This architecture is designed to reduce the scope of a merchant's PCI-DSS compliance obligations, thereby lowering costs and security risks associated with processing online payments (’621 Patent, col. 6:1-5).

Key Claims at a Glance

• The complaint asserts "one or more claims," with Independent Claim 1 identified as representative (Compl. ¶¶ 23, 25).
• The essential elements of Independent Claim 1, a method claim, include:
  • Providing, by a secure server to a merchant server, an API with financial account registration and token retrieval functions.
  • Receiving data from the merchant server and authenticating the payee.
  • Executing a financial account registration function, which involves generating a URL and establishing a secure connection within a window or frame on the merchant's webpage to receive sensitive financial data from the payer.
  • Receiving and storing the sensitive information in a secure, compliant manner.
  • Executing a token retrieval function by providing a non-sensitive token to the merchant server, without providing the sensitive data to the merchant or the token to the payer.
  • 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.

III. The Accused Instrumentality

Product Identification

• Defendant’s "PCI Shield" and "Orchestra" products and services (collectively, the "Infringing Methods") (Compl. ¶24).

Functionality and Market Context

• The complaint alleges the accused products provide payment processing solutions that allow customers to "Capture customer payment information without exposing your underlying application systems to PCI scope" (Compl. ¶28). This is allegedly accomplished using an API that provides tokenization services; a customer enters card data into a form, such as an iFrame, which is then tokenized by Defendant's system, and a "card token" is relayed to the merchant's e-commerce site (Compl. ¶¶ 27, 29). This functionality is supported by a diagram in the complaint depicting various input methods (e.g., "WEB IFRAME") sending data to "PCI BOOKING," which in turn provides a "TOKEN" to the merchant ("YOUR COMPANY") (Compl. p. 7, ¶ 26).
• The Defendant is described as a "financial technology company with a heavy presence in payments and compliance for the travel industry" that "processes millions of cards per month" and competes directly with the Plaintiff (Compl. ¶¶ 16, 18).

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... providing... an application programming interface (API) that: provides financial account registration and token retrieval functions...	Defendant provides the PCI Shield and Orchestra products via secure servers, offering a "Universal Payment Gateway API" that enables tokenization and payment processing. A screenshot from Defendant's marketing describes the ability to "Capture customer payment information" using tokens (Compl. p. 8, ¶ 28).	¶¶27-28	col. 17:1-12
receives, from the merchant server via the API, at least one data element associated with the payer and a payment amount... authenticates the payee;	The API allegedly receives data elements like "Access Token" or "Session Token" and payment "amount" parameters. The complaint alleges that the use of these tokens for API access serves to authenticate the payee (merchant) (Compl. ¶¶ 30-31).	¶¶30-31	col. 17:13-17
executes the financial account registration function... by: generating a uniform resource locator (URL)... establishing the secure socket layer connection... within a window or frame... outputting instructions... to render a financial account registration request form...	Defendant's documentation allegedly describes preparing a "card entry form URL" and setting this URL as the source for an iFrame element on the merchant's site. This is alleged to establish a secure connection and render a form for data entry within the merchant's webpage (Compl. ¶¶ 32a-c).	¶32	col. 17:18-33
receiving the sensitive financial account information provided by the payer via the secure socket layer connection; 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 system allegedly receives card data submitted via the "Card Capture form." The complaint provides a marketing screenshot stating "PCI Booking is Level 1 PCI Compliant" and that it "securely stores the captured data," which alleges compliance with security standards (Compl. p. 15, ¶ 34).	¶¶33-34	col. 17:37-43
executing a token retrieval function... by: providing a non-sensitive electronic data token representing the sensitive financial account information to the merchant server... and processing the payment transaction using the sensitive financial account information...	Defendant’s documentation allegedly describes that "PCI Booking will tokenize the card and relay the card token to the e-commerce site." The subsequent ability to "charge the card" is alleged to satisfy the payment processing element (Compl. p. 16, ¶ 35). A diagram shows this token flow (Compl. p. 14, ¶ 33).	¶35	col. 17:44-60

Identified Points of Contention

• Scope Questions: A central question may be whether the API authentication methods cited in the complaint, such as passing an "Access Token" or "Session Token," satisfy the claim limitation "authenticates the payee" (Compl. ¶31). A court may need to determine if authenticating a specific API request from a merchant's system is legally equivalent to authenticating the "payee" (the merchant entity) as contemplated by the patent.
• Technical Questions: The complaint alleges that the ability to "charge the card" after tokenization meets the "processing the payment transaction" limitation (Compl. ¶35). This limitation includes sub-steps of generating a request, obtaining the payment amount, and forwarding it to the payee. A factual dispute may arise over whether the accused system performs all of these sub-steps itself, or if it merely acts as a pass-through to a separate payment gateway that performs the actual funds transfer, which could create a gap in the infringement theory.

V. Key Claim Terms for Construction

"authenticates the payee"

• Context and Importance: This term is critical because the method of authentication will determine whether a key step of the claimed method is met. Practitioners may focus on this term because the complaint's theory relies on API access credentials (an "Access Token" or "Session Token") satisfying the requirement, which a defendant might argue is merely authenticating a single transaction or session, not the "payee" entity itself.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification discusses authenticating a "system user" and lists "Authentication using Session Token" and "Authentication using Access Token" as available methods, which could support the plaintiff's view that these common API security measures meet the claim requirement (’621 Patent, col. 11:57-67, Fig. 4f).
  • Evidence for a Narrower Interpretation: The claim uses the specific word "payee," which refers to the entity receiving payment. A defendant could argue this implies a more formal, persistent authentication of the merchant's identity, rather than the transient, per-request authentication of an API call.

"secure server"

• Context and Importance: The claims are performed by one or more "secure servers," distinct from the "merchant server." The definition of this term and its required relationship to the merchant server is foundational to the infringement case.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent states that "the merchant's server and secure server may operate in the same location or may be the same hardware using a separated volume or partition," suggesting that strict physical separation is not required (’621 Patent, col. 2:45-49).
  • Evidence for a Narrower Interpretation: The patent's core purpose is to remove the merchant from the scope of PCI compliance by isolating data. The specification emphasizes that "particular advantages are realized through logical and/or physical separation of the merchant's server and the secure server" (’621 Patent, col. 2:49-50). A defendant could argue that a system must exhibit this intended level of functional and logical separation to qualify.

VI. Other Allegations

Indirect Infringement

• The complaint alleges inducement, asserting that Defendant provides documentation, specifications, and promotional literature that instruct and encourage its customers (e-g., "e-commerce sites") to use the accused services in an infringing manner (Compl. ¶¶ 37, 40-41). A screenshot from Defendant's documentation states that "PCI Booking users (e-commerce sites)... should use this service," which the complaint offers as evidence of such instruction (Compl. p. 17, ¶ 37).

Willful Infringement

• The complaint alleges knowledge of the patent as of the filing of the complaint, supporting a claim for post-suit willfulness (Compl. ¶36). It also pleads pre-suit willfulness based on a theory of willful blindness, alleging Defendant acted with the belief of a high probability of infringement (Compl. ¶39).

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

• A core issue will be one of definitional scope: can the claim term "authenticates the payee", which suggests verifying a legal entity, be construed to cover the alleged practice of authenticating a transient API request with a session or access token? The resolution of this question may significantly impact whether a key step of the claimed method is met.
• A key evidentiary question will be one of functional performance: does the accused system’s "charge the card" capability (Compl. ¶35) perform the complete, multi-step "processing the payment transaction" function as claimed, or does it merely trigger a separate, third-party payment gateway that performs the critical actions of obtaining and forwarding funds? Proving that Defendant’s system, and not another entity’s, performs every part of this claimed step will be crucial for the Plaintiff.
• The case may also turn on a question of architectural mapping: does the accused system, where a single entity (PCI Booking) provides the entire tokenization service to a merchant, align with the patent’s description of a "merchant server" initiating functions on a separate "secure server"? While the servers may be logically distinct, the court will have to decide if this single-provider model is equivalent to the distributed architecture described in the patent.