BenedorTSE LLC v. Google LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: BenedorTSE, LLC (Delaware)
  • Defendant: Google LLC (Delaware)
  • Plaintiff's Counsel: Waddey Acheson LLC
• Case Identification: 3:26-cv-00563, M.D. Tenn., Filed 05/01/2026
• Venue Allegations: Venue is based on Defendant Google's ownership and operation of a permanent, physical, and staffed data center in Clarksville, Tennessee, which the complaint alleges constitutes a regular and established place of business within the district.
• Core Dispute: Plaintiff alleges that Defendant's Google Pay/Wallet mobile payment service, in conjunction with its hardware and infrastructure, infringes three patents related to methods for conducting secure electronic transactions.
• Technical Context: The technology concerns securing online and mobile payments by using device-specific and user-specific identifiers to generate a unique, single-use encrypted credential for each transaction, a foundational concept in modern payment tokenization.
• Key Procedural History: The complaint alleges that Google had pre-suit knowledge of the patents-in-suit. This is based on citations to the patents' underlying application in at least three Google-owned patents issued between 2018 and 2020. Additionally, the complaint alleges that in January 2010, Plaintiff's predecessor pitched the patented technology directly to Google's legal and executive teams, seeking a joint venture.

Case Timeline

Date	Event
2000-12-01	Earliest Priority Date for '713, '979, and '723 Patents
2010-01-19	Benedor allegedly pitches SecurePay system to Google executives
2012-09-04	U.S. Patent No. 8,260,723 Issues
2013-06-11	U.S. Patent No. 8,463,713 Issues
2016-07-26	U.S. Patent No. 9,400,979 Issues
2018-01-16	Google-owned U.S. Patent No. 9,870,556 issues, citing the '723 patent family
2018-02-01	Google breaks ground on Clarksville, TN data center (approximate date)
2018-12-04	Google-owned U.S. Patent No. 10,147,112 issues, citing the '723 patent family
2020-03-17	Google-owned U.S. Patent No. 10,592,884 issues, citing the '723 patent family
2022-01-01	Google Pay rebranded and consolidated as Google Wallet (approximate date)
2022-11-06	Google publicly opens Clarksville, TN data center
2026-05-01	Complaint Filed

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

U.S. Patent No. 8,463,713 - "Transactional Security Over a Network" (Issued Jun. 11, 2013)

The Invention Explained

• Problem Addressed: The patent family addresses the security risks of early e-commerce, where transmitting unencrypted financial data was common, and even when encrypted in transit (e.g., via SSL), the data was exposed to the merchant upon arrival, creating a security vulnerability Compl. ¶¶8-9 '723 Patent, col. 1:49-54 Existing secure protocols were often too cumbersome for widespread consumer adoption Compl. ¶10
• The Patented Solution: The invention proposes a method where a user's device generates an encrypted "customer code" containing user and hardware identifiers. This code is sent to a merchant, who forwards it to a "verification entity" (e.g., a financial institution) for decryption and authorization. This process avoids exposing the customer's raw financial data, like a credit card number, to the merchant, effectively using the customer's own device as part of a two-factor authentication system '723 Patent, abstract '723 Patent, col. 2:30-38
• Technical Importance: This method provided a framework for strong, "person-present" verification in a digital context, separating the roles of the merchant (transaction facilitator) and the financial institution (identity verifier) to enhance security Compl. ¶14

Key Claims at a Glance

• The complaint asserts at least independent Claim 13 Compl. ¶69
• Claim 13 of the '713 Patent recites a method comprising the following essential elements:
  • Receiving an entered password from a user via a graphical user interface.
  • Determining if the entered password is valid.
  • Based on a valid password, reading a hardware identifier from the user's device.
  • Determining if the hardware identifier is valid.
  • Based on a valid hardware identifier, retrieving a user agreement identifier.
  • Creating an encrypted user code by encrypting the user agreement identifier and the hardware identifier, with the code being valid only for a single request.
  • Transmitting the encrypted user code to a provider for an authorization decision.
• The complaint reserves the right to assert additional claims Compl. ¶68

U.S. Patent No. 9,400,979 - "Transactional Security Over a Network" (Issued Jul. 26, 2016)

The Invention Explained

• Problem Addressed: As with its parent patents, the '979 Patent addresses the need for a secure and convenient online transaction system that protects customer financial data from being exposed to merchants Compl. ¶¶8-9 '723 Patent, col. 1:49-54
• The Patented Solution: The patent describes a multi-step method executed on a user's device that involves password validation, reading and validating a device-specific hardware identifier, retrieving a user identifier, creating a unique encrypted code from these elements, and transmitting it to a provider for authorization '979 Patent, abstract '723 Patent, col. 2:30-38 This secures the transaction without revealing underlying account details to the merchant.
• Technical Importance: The invention's approach of combining user credentials with device-specific hardware identifiers on the client side was a key step toward the tokenization standards that now underpin secure mobile payments (Compl. ¶¶14; Compl. ¶16).

Key Claims at a Glance

• The complaint asserts at least independent Claim 1 Compl. ¶61
• Claim 1 of the '979 Patent recites a method comprising the following essential elements:
  • Receiving a user-entered password via a graphical user interface.
  • Determining if the password is valid.
  • After validation, reading a device-specific hardware identifier from secure hardware.
  • Determining if the hardware identifier is valid.
  • Retrieving a user identifier corresponding to the user's payment account.
  • Creating an encrypted user code derived from the user identifier and the hardware identifier.
  • Transmitting the encrypted user code to a provider to request authorization and receiving the decision.
• The complaint reserves the right to assert additional claims Compl. ¶60

Multi-Patent Capsule: U.S. Patent No. 8,260,723

• Patent Identification: U.S. Patent No. 8,260,723, "Transactional Security Over a Network," issued September 4, 2012 Compl. ¶20
• Technology Synopsis: The patent addresses security flaws in early e-commerce by proposing a system that encrypts customer and device identifiers on the user's own computer to create a secure "customer code" '723 Patent, abstract This code is used for transaction authorization in place of exposing a real credit card number to a merchant, thus preventing the merchant from storing and potentially leaking sensitive financial data Compl. ¶16 '723 Patent, col. 2:39-42
• Asserted Claims: The complaint asserts at least independent Claim 1 and non-transitory computer-readable medium Claim 7 Compl. ¶¶82-83
• Accused Features: The complaint alleges that the Google Pay/Wallet system infringes by performing the claimed steps of: receiving a user password, reading and validating hardware identifiers (cryptographic keys from the Titan M security chip), retrieving a customer identifier (the DPAN), creating an encrypted code (the ARQC cryptogram), and transmitting it to a merchant for authorization Compl. ¶¶84-92

III. The Accused Instrumentality

• Product Identification: The "Accused Instrumentality" is a collection of Google's products and services, including the Google Pay / Google Wallet mobile payment service, Google Pixel smartphones (Pixel 3 and later models), the Pixel Watch, the Android operating system, and Google's back-end tokenization, attestation, and payment authorization infrastructure Compl. ¶25
• Functionality and Market Context: The complaint describes the accused functionality as a multi-step process for making a secure mobile payment Compl. ¶28 The process begins when a user authenticates to their device, which unlocks access to device-bound cryptographic keys stored in a hardware-backed secure element like the Titan M security chip Compl. ¶¶29-30 The Google Wallet application then retrieves a tokenized payment credential (a Device Primary Account Number, or DPAN) and combines it with the device key and a transaction counter to generate a one-time dynamic cryptogram, which is transmitted to the payment terminal via NFC Compl. ¶¶31-34 The complaint alleges these features are technically necessary for the service to function and are key selling points for Google's hardware, driving significant revenue and ecosystem lock-in Compl. ¶¶52-53

No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

'713 Patent Infringement Allegations

Claim Element (from Independent Claim 13)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
receiving an entered password from a user via a graphical user interface	Google Wallet requires users to authenticate via the Android lock-screen GUI by entering a PIN or password before a purchase.	¶70	col. 29:60-63
determining if the entered password is valid	The Android OS (Gatekeeper/BiometricPrompt) validates the entered credential against a credential stored on the device.	¶71	col. 30:65-31:1
based on a valid password, reading a hardware identifier from the user's device	Upon user authentication, the Google Wallet applet accesses a device-specific cryptographic key ("Limited Use Key") from the hardware-backed Keystore (e.g., Titan M chip). This key is alleged to be a hardware identifier.	¶72	col. 31:2-5
determining if the hardware identifier is valid	The validity of the device key is checked internally (e.g., Keystore checks) and externally via Android Key Attestation and verification by the payment network.	¶73	col. 31:6-9
based on a valid hardware identifier, retrieving a user agreement identifier	After device validation, Google Wallet retrieves the Device Primary Account Number (DPAN) from on-device storage. The DPAN is alleged to be a tokenized representation of the user's payment card provisioned under an agreement, comprising the user agreement identifier.	¶74	col. 31:10-15
creating an encrypted user code by encrypting the user agreement identifier and the hardware identifier, each said encrypted code being valid only for a single request for an authorization decision	The Google Wallet HCE applet generates a dynamic, transaction-specific cryptogram (ARQC) using the DPAN (alleged user agreement identifier) and the device-bound key (alleged hardware identifier) as inputs.	¶75	col. 31:18-24
transmitting the encrypted user code to a provider in a request for an authorization decision	The device transmits the DPAN and the dynamic cryptogram to the merchant terminal via NFC or API payload, which is then routed through the payment network to the issuing bank for an authorization decision.	¶76	col. 32:3-9

'979 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
receiving, a user-entered password via a graphical user interface	The system receives a user's PIN or password via the Android lock-screen GUI to initiate a transaction.	¶61(a)	col. 15:27-31
determining if the entered credential is valid by checking it against a credential stored on the device	The Android Gatekeeper framework checks the entered credential against one stored on the device.	¶61(b)	col. 15:32-34
after validation, reading a device-specific hardware identifier from the device's secure hardware	The system reads a unique cryptographic key (Limited Use Key) from the hardware-backed Keystore (e.g., Titan M/M2 StrongBox Secure Element).	¶61(c)	col. 27:4-9
determining if the hardware identifier is valid	Validity is checked internally via Keystore and externally via Android Key Attestation against Google's infrastructure.	¶61(d)	col. 27:40-42
retrieving a user identifier corresponding to the user's payment account from the device's tokenized credential storage	The system retrieves the Device Primary Account Number (DPAN) from the device's tokenized storage.	¶61(e)	col. 11:22-25
creating an encrypted user code that is derived from both the user identifier and the hardware identifier	A dynamic EMVCo cryptogram is created, derived from the DPAN (alleged user identifier) and the device-bound Limited Use Key (alleged hardware identifier).	¶61(f)	col. 11:50-54
transmitting the encrypted user code to a provider...to request transaction authorization, and receiving the authorization decision from the provider	The cryptogram and DPAN are transmitted to the merchant and payment network for authorization, and the device receives the authorization decision back.	¶61(g)	col. 12:10-17

• Identified Points of Contention:
  • Scope Questions: A primary issue for the court may be whether claim terms from a patent family with a 2000 priority date can be construed to read on modern mobile payment architecture. For instance, the '723 Patent's claim 1 requires reading "a plurality of hardware identifiers comprising at least a portion of a serial number." The complaint alleges that unique cryptographic keys stored in a secure chip meet this limitation Compl. ¶86 The dispute may center on whether a cryptographic key, which is data, can be considered a "serial number of...a hardware component."
  • Technical Questions: The infringement theory relies on equating specific elements of the Google Pay system with claim limitations. For example, the complaint alleges the "Device Primary Account Number" (DPAN) is the claimed "user identifier" or "user agreement identifier" Compl. ¶¶61(e) Compl. ¶74 A court will have to determine whether a tokenized payment credential functions as an identifier of the user's agreement with the verification entity, as the patent language suggests, or merely as a substitute for a payment account number.

V. Key Claim Terms for Construction

The Term: "hardware identifier"

• Context and Importance: This term is central to all three patents. Its definition is critical because the patents require reading and validating this identifier from the user's device to create the secure code. The complaint alleges that a cryptographic key (the "Limited Use Key") stored in a secure hardware chip (e.g., Titan M) is the claimed "hardware identifier" (Compl. ¶72, Compl. ¶86). The case may turn on whether this data-based key falls within the scope of a term that the specification also describes using physical examples.
• Intrinsic Evidence for a Broader Interpretation: The claims use the general term "hardware identifier" without further limitation, which may support a broader construction not limited to just physical serial numbers '713 Patent, cl. 13 The specification's goal is to uniquely link the transaction to the device, a function a unique cryptographic key performs.
• Intrinsic Evidence for a Narrower Interpretation: The specification provides concrete examples, stating the system "reads and registers the unique hardware identifiers (such as serial numbers from the motherboard, the hard drives, the processor, etc.)" '723 Patent, col. 8:13-16 A defendant may argue these examples limit the term's scope to physical, permanent serial numbers rather than provisioned software keys, even if stored in hardware.

The Term: "user agreement identifier"

• Context and Importance: This term appears in asserted independent Claim 13 of the '713 Patent. The complaint alleges that the "Device Primary Account Number" (DPAN), a tokenized version of a credit card number, constitutes the "user agreement identifier" Compl. ¶74 Practitioners may focus on this term because the infringement allegation hinges on whether a payment token is an identifier of an agreement, not just an identifier used under an agreement.
• Intrinsic Evidence for a Broader Interpretation: The specification states this identifier "contains or identifies the contractual agreement between the customer and a verification entity" '713 Patent, col. 5:21-25 Plaintiff may argue that because the DPAN is created and provisioned pursuant to such an agreement, it serves to "identify" that agreement in the context of a transaction.
• Intrinsic Evidence for a Narrower Interpretation: A defendant may argue that the plain meaning of the term requires an identifier for the agreement itself (e.g., a contract number or unique account ID for the security service), not a tokenized payment instrument used for a transaction. The patent discusses the agreement as a distinct legal instrument, which may suggest its identifier should also be distinct from a payment credential '713 Patent, col. 19:35-42

VI. Other Allegations

• Indirect Infringement: The complaint alleges Google induces infringement by actively encouraging and instructing customers on how to use the Accused Instrumentality in an infringing manner, for example, through its public help documents Compl. ¶63 Compl. ¶78 It further alleges contributory infringement, stating Google supplies material components of the invention (the Google Wallet application and associated hardware/software) that are not staple articles of commerce and are known to be specially made for infringing use Compl. ¶64 Compl. ¶78
• Willful Infringement: The complaint alleges willful infringement based on Google's alleged pre-suit knowledge of the patent family. The allegations are twofold: (1) Google's own issued patents (e.g., U.S. Patent No. 9,870,556) cite the application that led to the '723 Patent as prior art, placing Google on notice no later than January 2018 Compl. ¶¶38-43; and (2) Benedor's predecessor allegedly conducted a "coordinated, multi-channel outreach to Google" in January 2010 to pitch the patented technology to Google's senior legal and engineering leadership, including its then-General Counsel Compl. ¶¶46-51

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

• A core issue will be one of definitional scope: can claim terms from a patent family with a 2000 priority date, such as "hardware identifier" (which the specification exemplifies with physical serial numbers), be construed to cover modern security concepts like unique cryptographic keys provisioned into a secure hardware enclave like Google's Titan M chip?
• A key evidentiary question will be one of functional equivalence: does Google's "Device Primary Account Number" (DPAN), a tokenized payment credential, perform the specific role of the claimed "user agreement identifier", or is there a fundamental mismatch between a payment instrument and an identifier of a legal agreement?
• A central question for damages will be willfulness: given the specific allegations of both prior art citations in Google's own patent portfolio and a direct 2010 business development pitch to Google's leadership, the court will need to evaluate the evidence regarding Google's state of mind and whether any infringement was willful, wanton, and deliberate.