DCT

7:24-cv-00278

CardWare Inc v. Google LLC

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 7:24-cv-00278, W.D. Tex., 11/04/2024
  • Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google maintains multiple regular and established places of business in the district, including in Austin and Midland, and has committed acts of infringement within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s mobile payment services, Google Pay and Google Wallet, as implemented on its electronic devices, infringe four patents related to secure, tokenized payment transactions.
  • Technical Context: The technology at issue involves methods for enhancing the security of electronic payments by replacing static credit card details with dynamically generated, limited-use information or tokens for each transaction.
  • Key Procedural History: The complaint alleges that Plaintiff put Defendant on notice of infringement on or around October 10, 2023, a fact which forms the basis for the allegations of willful infringement.

Case Timeline

Date Event
2013-03-15 Priority Date for ’520, ’579, ’538, and ’634 Patents
2019-07-02 U.S. Patent No. 10,339,520 Issues
2020-10-20 U.S. Patent No. 10,810,579 Issues
2021-11-16 U.S. Patent No. 11,176,538 Issues
2023-04-04 U.S. Patent No. 11,620,634 Issues
2023-10-10 Plaintiff alleges Defendant was put on notice of infringement
2024-11-04 Complaint Filed

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 10,339,520 - MULTI-FUNCTIONAL CREDIT CARD TYPE PORTABLE ELECTRONIC DEVICE

  • Issued: July 2, 2019 (Compl. ¶19).

The Invention Explained

  • Problem Addressed: The patent’s background section identifies the security vulnerabilities of conventional credit cards, including those with magnetic stripes, smart chips, and RFID, noting their susceptibility to theft and compromise (’520 Patent, col. 1:59-65).
  • The Patented Solution: The invention is a portable electronic device, shaped like a credit card, capable of securely storing multiple payment accounts and generating temporary, single-use, or otherwise limited-duration payment numbers for transactions. This dynamic data generation is intended to replace the transmission of static, vulnerable card details, with the device able to communicate via NFC or by emulating a magnetic stripe using a dynamic magnetic field generator (’520 Patent, Abstract; col. 10:3-19).
  • Technical Importance: This technology aims to reduce payment fraud by ensuring that any intercepted transaction data is ephemeral and cannot be reused for subsequent unauthorized purchases (Compl. ¶15).

Key Claims at a Glance

  • The complaint asserts at least independent claim 10 (’520 Patent, Compl. ¶33).
  • The essential elements of method claim 10 include:
    • Accepting a user input of issued payment information at a touch screen display of an electronic device.
    • Receiving wirelessly a static device account number for storage on the device.
    • Dynamically generating a one-time limited-use number based on a set of inputs (e.g., time, merchant, amount, device secrets).
    • Using the static device account number and the dynamically generated one-time limited-use number together in place of the issuer-provided payment information to make a payment transaction.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 10,810,579 - SMART TOKENIZING PAYMENT CARD AND DEVICE AND TRANSACTION PROCESSING THEREOF, SYSTEM AND METHOD

  • Issued: October 20, 2020 (Compl. ¶21).

The Invention Explained

  • Problem Addressed: The patent addresses the security risks inherent in conventional payment cards, where static account information is vulnerable to compromise during transactions (’579 Patent, col. 1:63-67).
  • The Patented Solution: The patent describes a method for a secure transaction flow on an electronic device. The process begins with a user "priming operation" that readies the device for payment, followed by the device receiving a payment request via NFC. The device then generates and transmits "limited-use payment information" to the payment terminal and visually confirms the transaction status to the user. The core of the solution is the on-demand creation of transactional data that replaces the permanent account number (’579 Patent, Abstract; col. 19:1-22).
  • Technical Importance: The invention provides a specific, secure protocol for conducting contactless mobile payments, enhancing security by ensuring that the actual payment card number is never exposed during the transaction (Compl. ¶1, 15).

Key Claims at a Glance

  • The complaint asserts at least independent claim 19 (’579 Patent, Compl. ¶41).
  • The essential elements of method claim 19 include:
    • Receiving an input at an electronic device corresponding to a "priming operation" by a user.
    • Receiving a request for a transaction payment via an NFC interface.
    • Displaying images of a selected card issuer payment method on a touch-screen display.
    • Generating and using limited-use payment information in place of the card issuer supplied information.
    • Transmitting the limited-use payment information to an NFC recipient.
    • Visually conveying the transaction status on the display.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 11,176,538 - MULTI-FUNCTION SMART TOKENIZING ELECTRONIC PAYMENT DEVICE

  • Issued: November 16, 2021 (Compl. ¶23).
  • Technology Synopsis: This patent discloses a method for executing secure payments on a multi-function electronic device, addressing the fraud risks of conventional payment systems (’538 Patent, col. 1:62-65). The method involves a user "priming" the device for an imminent transaction, generating device-specific limited-use payment information by combining static and dynamic data elements, and transmitting this tokenized information to a merchant via NFC (’538 Patent, Abstract).
  • Asserted Claims: At least claim 19 (Compl. ¶49).
  • Accused Features: The complaint accuses Google's implementation of Google Pay and Google Wallet on its devices, which facilitate secure electronic payments, of infringing this patent (Compl. ¶28, 49).

U.S. Patent No. 11,620,634 - MULTI-FUNCTION SMART TOKENIZING ELECTRONIC PAYMENT DEVICE

  • Issued: April 4, 2023 (Compl. ¶25).
  • Technology Synopsis: This patent describes a system for secure electronic payments that aims to mitigate the security risks of traditional payment methods (’634 Patent, col. 2:1-4). The claimed system involves an electronic device that receives a user "priming operation," displays payment account options, and then dynamically generates and transmits limited-use, tokenized payment information to a payment terminal via NFC (’634 Patent, Abstract).
  • Asserted Claims: At least claim 1 (Compl. ¶57).
  • Accused Features: The functionality of the Accused Products for making contactless payments via Google Pay and Google Wallet is alleged to infringe the claims of this patent (Compl. ¶28, 57).

III. The Accused Instrumentality

Product Identification

The complaint identifies the "Accused Products" as Google-branded electronic devices that support Google Pay and/or Google Wallet, specifically naming Google Pixel smartphones and Google Pixel Watch smartwatches (Compl. ¶29).

Functionality and Market Context

The Accused Products are described as being pre-loaded with software for Google Pay and Google Wallet, enabling users to perform secure online and in-store contactless transactions (Compl. ¶3, 30). The in-store "tap-to-pay" feature utilizes Near-Field Communication (NFC) technology to communicate with payment terminals (Compl. ¶3). The complaint alleges that these services are specifically designed to facilitate the storage and generation of payment information on an electronic device to complete transactions (Compl. ¶36). No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint references, but does not attach, exemplary claim charts (Exhibits E, F, G, H) detailing its infringement theories. The narrative allegations are summarized below.

'520 Patent Infringement Allegations

The complaint alleges that the Accused Products directly infringe at least claim 10 of the ’520 Patent (Compl. ¶33). The narrative theory suggests that when a user provisions a card in Google Wallet, the device accepts "issued payment information" and receives for storage a "static device account number" (a virtual card number or token) from the payment network. During a transaction, the device is alleged to "dynamically [generate] a one-time limited-use number" (such as a cryptogram) based on various factors and uses this dynamic number "together" with the static account number to complete the payment, thereby practicing the claimed method (Compl. ¶33-37).

'579 Patent Infringement Allegations

Infringement of at least claim 19 of the ’579 Patent is alleged based on the functionality of Google Pay (Compl. ¶41). The theory maps the steps of a contactless payment: a user's action of unlocking their device or opening the Wallet app is alleged to be the claimed "priming operation." When the device is placed near a terminal, it receives a "request for a transaction payment" via NFC. The device then displays the selected payment card, generates "limited-use payment information" (the token and cryptogram), transmits it to the terminal, and displays the transaction status, allegedly meeting all steps of the claim (Compl. ¶41-45).

Identified Points of Contention

  • Scope Questions: A potential point of dispute may be whether the "static device account number" as used in Google's tokenization architecture is functionally the same as the element recited in claim 10 of the ’520 Patent. Further, a question arises as to whether a general user action like unlocking a phone constitutes a "priming operation" as described in the ’579 Patent, which suggests an action taken to signal an "imminent" transaction (’579 Patent, col. 13:24-26).
  • Technical Questions: The analysis may focus on whether Google's system uses the static token and dynamic cryptogram "together in the place of issuer provided payment information" as required by claim 10 of the ’520 Patent, or if the cryptogram's function is purely to authenticate the token in a manner distinct from the claimed method.

V. Key Claim Terms for Construction

  • The Term: "limited-use number" (asserted in claim 10 of the ’520 Patent)

    • Context and Importance: This term is fundamental to the patent's security claims. Its construction will determine whether the single-use cryptograms generated by the Accused Products fall within the claim's scope.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification states that the number can be "limited to only one transaction, a finite number of transactions, or may be limited to a specified period of time" (’520 Patent, col. 10:19-22), suggesting the term is not confined to a single type of limitation.
      • Evidence for a Narrower Interpretation: Claim 10 recites that the number is generated based on a list of contextual inputs including "merchant; facility location; ... amount; and transaction information" (’520 Patent, col. 18:27-30). A party could argue that for a number to be a "limited-use number" under the claim, its generation must depend on such specific transaction context, rather than being solely time or counter-based.

  • The Term: "priming operation" (asserted in claim 19 of the ’579 Patent)

    • Context and Importance: The plaintiff’s infringement theory for the ’579 Patent relies on mapping common user interactions with the Accused Products to this term. Its definition is therefore critical to the dispute.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification provides examples of a "priming action" that include "a tap of the credit card device... or a gesture, swipe, or a key input" (’579 Patent, col. 11:39-42), which could support construing the term broadly to cover various user inputs.
      • Evidence for a Narrower Interpretation: The patent describes the operation as providing "an indication for a credit card device that a transaction is imminent" (’579 Patent, col. 13:24-26). This language may support a narrower construction requiring an action that specifically signals intent to pay immediately, as opposed to a general action like unlocking a device for other purposes.

VI. Other Allegations

Indirect Infringement

The complaint alleges both induced and contributory infringement for all asserted patents. Inducement is based on allegations that Google provides "promotional materials, product manuals, brochures, videos, demonstrations, and website materials" that instruct and encourage customers to use the Accused Products in an infringing manner (Compl. ¶35, 43, 51, 59). Contributory infringement is based on the allegation that Google Pay is a material component of the claimed invention, is not a staple article of commerce, and has no substantial non-infringing uses (Compl. ¶36, 44, 52, 60).

Willful Infringement

Willfulness is alleged for all four patents based on Google’s alleged continued infringement after receiving notice from CardWare on or around October 10, 2023 (Compl. ¶4, 38, 46, 54, 62).

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

  • A core issue will be one of definitional scope: can common user interactions with a smartphone, such as unlocking the device or opening an application, be construed to meet the patent term "priming operation," which the specification links to an "imminent" transaction?
  • A central question of claim construction will be whether the term "limited-use number" as claimed in the ’520 Patent requires generation based on specific transactional context (e.g., merchant, location), or if it broadly covers the type of dynamic cryptograms used in Google's existing payment architecture.
  • A key evidentiary question will be one of technical operation: does the tokenization architecture used by Google, which pairs a semi-static device account number with a dynamic authentication code, practice the claimed method of using two components "together in the place of" the original card number, or does it represent a fundamentally different and non-infringing technical implementation?