DCT

3:25-cv-01473

Benedortse LLC v. Apple Inc

Key Events
Complaint
complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 3:25-cv-01473, M.D. Tenn., 12/19/2025
  • Venue Allegations: Venue is alleged to be proper in the Middle District of Tennessee because Apple has committed acts of infringement in the district and maintains a regular and established place of business, specifically an Apple Store, within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s Apple Pay mobile payment service, when used with supporting hardware like the iPhone and Apple Watch, infringes three patents related to methods for securely authorizing electronic transactions.
  • Technical Context: The technology at issue addresses security in electronic commerce by using a combination of user credentials and unique device identifiers to create an encrypted, single-use token for payment authorization, thereby avoiding the transmission of sensitive financial data to merchants.
  • Key Procedural History: The complaint alleges that Apple was aware of the technology prior to the suit, citing the fact that Apple filed an Information Disclosure Statement (IDS) in November 2018 that included the application leading to the ’723 Patent during the prosecution of its own patent related to Apple Pay. The complaint further notes that a USPTO Examiner in that prosecution described the inventor’s disclosure as "pertinent" to Apple’s own application.

Case Timeline

Date Event
2000-12-01 Earliest Priority Date for ’979, ’713, and ’723 Patents
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-11-01 Apple allegedly gains knowledge of '723 Patent via IDS filing
2021-08-13 USPTO Examiner issues Final Rejection in Apple patent prosecution
2025-12-19 Complaint Filed

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

U.S. Patent No. 9,400,979 - "Transactional Security Over a Network," issued July 26, 2016

The Invention Explained

  • Problem Addressed: Prior to the invention, electronic commerce was hampered by payment systems that required customers to transmit sensitive financial data (e.g., credit card numbers) to merchants, exposing that data to theft and fraud (Compl. ¶¶8-9). Existing security protocols like SSL only protected data in transit, leaving it vulnerable on merchant servers (Compl. ¶9).
  • The Patented Solution: The invention proposes a method where a user’s device generates a secure, encrypted code for each transaction without revealing sensitive financial information to the merchant (Compl. ¶16). The system combines a user-provided credential (like a password) with a device-specific hardware identifier to create a unique authorization code, which is then sent to a trusted provider (e.g., a financial institution) for verification ('723 Patent, col. 2:27-39; Fig. 11). This process links the transaction to both the authorized user and their specific device (Compl. ¶14).
  • Technical Importance: This approach provided a framework for multi-factor authentication in e-commerce that protected consumer data from merchants, a significant step in building trust and security for online transactions (Compl. ¶¶14, 16).

Key Claims at a Glance

  • The complaint asserts at least independent Claim 1 (Compl. ¶37).
  • The essential elements of Claim 1, as described in the complaint, are:
    • Receiving a user-entered password via a graphical interface.
    • Determining if the entered credential is valid.
    • Reading a device-specific hardware identifier from the device’s 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 both the user identifier and the hardware identifier.
    • Transmitting the encrypted user code to a provider to request transaction authorization.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 8,463,713 - "Transactional Security Over a Network," issued June 11, 2013

The Invention Explained

  • Problem Addressed: The ’713 Patent is part of the same family as the ’979 Patent and addresses the same technical problem of insecure online transactions where sensitive customer data is exposed to merchants (Compl. ¶20; ’713 Patent, col. 1:49-53).
  • The Patented Solution: The solution is materially the same as that described for the ’979 Patent, focusing on generating a transaction-specific encrypted code on a user’s device by combining user authentication with device-specific identifiers ('713 Patent, col. 2:27-39).
  • Technical Importance: As with the ’979 Patent, this technology aimed to enhance the security and convenience of e-commerce by minimizing the exposure of confidential user information during a transaction (Compl. ¶14).

Key Claims at a Glance

  • The complaint asserts at least independent Claim 13 (Compl. ¶45).
  • The essential elements of Claim 13, as described in the complaint, are:
    • 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.
    • Transmitting the encrypted user code to a provider in a request for an authorization decision.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 8,260,723 - "Transactional Security Over a Network," issued September 4, 2012

  • Patent Identification: U.S. Patent No. 8,260,723, “Transactional Security Over a Network,” issued September 4, 2012 (Compl. ¶20).
  • Technology Synopsis: This patent, from the same family as the others, discloses a method for securing transactions by validating a user password and then reading a "plurality of hardware identifiers" from the device. These identifiers are combined with a "customer identifier string" and a "count value" from a "sequencer" to create an encrypted customer code that is transmitted to the merchant instead of the customer's credit card information ('723 Patent, Claim 1).
  • Asserted Claims: The complaint asserts at least independent Claim 1 (Compl. ¶52).
  • Accused Features: The complaint alleges that Apple Pay infringes by using a device passcode, invoking cryptographic keys from the Secure Element ("plurality of hardware identifiers"), retrieving the Device Account Number ("customer identifier string"), and incrementing a transaction counter ("sequencer") to generate a unique cryptogram for each transaction (Compl. ¶52).

III. The Accused Instrumentality

Product Identification

The accused instrumentality is Apple’s mobile payment service, Apple Pay, as integrated with Apple’s hardware products (iPhone, iPad, Apple Watch, Mac computers) and supporting computer systems (the "Accused Instrumentality") (Compl. ¶¶1, 24).

Functionality and Market Context

  • The complaint alleges that when a user initiates a transaction, Apple Pay requires authentication (e.g., a device passcode) (Compl. ¶¶37a, 45a). Upon validation, the system accesses device-specific hardware, such as the Secure Element, to read a unique cryptographic key which functions as a hardware identifier (Compl. ¶¶37c, 45c). The system also retrieves a tokenized Device Account Number (DAN) that represents the user's payment account (Compl. ¶¶37e, 45e). A dynamic, single-use cryptogram is generated using these identifiers and transmitted to the merchant's terminal, which then routes it through the payment network for authorization (Compl. ¶¶37f-g, 45f-g). This process avoids transmitting the user’s actual credit card number to the merchant (Compl. ¶52h).
  • The complaint alleges that Apple Pay generates substantial revenue for Apple through fees charged to issuing banks and serves as a key feature that drives sales of Apple's hardware and increases customer "lock-in" to its ecosystem (Compl. ¶28). No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

’979 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
receives a user-entered password... via a graphical interface The Apple Pay system receives a device passcode entered by the user via the device's graphical interface. ¶37a '723 Patent, col. 30:57-61
determines if the entered credential is valid The device checks the entered passcode against a credential stored on the device. ¶37b '723 Patent, col. 30:61-64
...reads a device-specific hardware identifier from the device's secure hardware After validation, the system reads a unique cryptographic key from the device's Secure Element. ¶37c '723 Patent, col. 31:1-4
determines if the hardware identifier is valid The complaint alleges this step is performed. ¶37d '723 Patent, col. 31:5-9
retrieves a user identifier corresponding to the user's payment account The system retrieves the Device Account Number (DAN). ¶37e '723 Patent, col. 31:11-15
creates an encrypted user code... derived from both the user identifier and the hardware identifier The system creates a dynamic cryptogram derived from the DAN and the hardware identifier. ¶37f '723 Patent, col. 31:21-25
transmits the encrypted user code to a provider... to request transaction authorization The cryptogram is transmitted to a payment network and issuing bank to authorize the transaction. ¶37g '723 Patent, col. 32:6-9

’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 Apple Pay requires a user to authenticate by entering a passcode via the device's graphical user interface. ¶45a '713 Patent, col. 11:19-21
Determining if the entered password is valid The device's Secure Enclave validates the entered passcode against the credential stored on the device. ¶45b '713 Patent, col. 11:22-26
Based on a valid password, reading a hardware identifier from the user's device Upon successful authentication, Apple Pay accesses a unique, device-specific cryptographic key from the Secure Element. ¶45c '713 Patent, col. 11:27-33
Determining if the hardware identifier is valid Apple Pay allegedly validates the hardware identifier internally and externally. ¶45d '713 Patent, col. 11:34-40
Based on a valid hardware identifier, retrieving a user agreement identifier The Secure Element retrieves the Device Account Number (DAN), a tokenized representation of the user's payment card. ¶45e '713 Patent, col. 11:41-44
Creating an encrypted user code by encrypting the user agreement identifier and the hardware identifier The Secure Element generates a dynamic cryptogram using data that includes the DAN and the device's unique secret key. ¶45f '713 Patent, col. 11:45-49
Transmitting the encrypted user code to a provider in a request for an authorization decision The encrypted user code is transmitted via NFC and routed through the payment network to the bank for an authorization decision. ¶45g '713 Patent, col. 11:50-54

Identified Points of Contention

  • Scope Questions: A potential issue is whether terms from a patent family with a 2000 priority date, drafted in the context of desktop e-commerce, can be construed to cover the architecture of a modern, tokenized mobile payment system. For example, does the term "user agreement identifier" (’713 Patent) read on a "Device Account Number" (DAN), which is a payment token rather than a direct identifier of a user agreement?
  • Technical Questions: The infringement analysis may raise the question of whether Apple’s system performs the specific step of "determining if the hardware identifier is valid" (Compl. ¶¶37d, 45d). The complaint’s allegation is conclusory, and the question for the court may be what technical evidence supports that the system performs a separate validation step, as opposed to simply using the identifier as an input for generating the cryptogram. For the ’723 Patent, it may be disputed whether a single "unique cryptographic key" (Compl. ¶52c) satisfies the claim limitation "a plurality of hardware identifiers comprising at least a portion of a serial number."

V. Key Claim Terms for Construction

The Term: "hardware identifier" (asserted in claims of the ’713 and ’979 Patents)

Context and Importance

This term is foundational to the invention, as it provides the link between a transaction and a specific physical device. The complaint equates this term with a "unique cryptographic key" from Apple's Secure Element (Compl. ¶¶37c, 45c). Practitioners may focus on this term because its scope will determine whether a non-human-readable, cryptographically generated key falls within the meaning of an "identifier" as contemplated by the patent.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The specification provides examples of identifiers, stating "unique hardware identifiers (such as serial numbers from the motherboard, the hard drives, the processor, etc.)" ('723 Patent, col. 8:14-16). The phrase "such as" suggests this list is illustrative, not exhaustive, which may support a construction broad enough to include other unique, hardware-bound data like a cryptographic key.
  • Evidence for a Narrower Interpretation: The specification repeatedly uses "serial number" as the primary example of a hardware identifier ('723 Patent, col. 31:2; col. 35:2). This could support an argument that the invention contemplated a persistent, factory-set, and directly readable number, rather than an abstract cryptographic key stored within a secure microprocessor.

The Term: "sequencer" (asserted in Claim 1 of the ’723 Patent)

Context and Importance

This term provides for transaction-specific uniqueness, preventing replay attacks. The complaint alleges that a "transaction counter" in Apple’s Secure Element is an example of the claimed "sequencer" (Compl. ¶52f). The dispute will likely center on whether a simple counter that is incremented meets the definition of a "sequencer" as used in the patent.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The claim requires "updating a count value by incrementing a sequencer" ('723 Patent, col. 35:12-14). This language may support a view that any component that maintains and increments a count for each transaction performs the function of the claimed "sequencer." The patent diagrams also show a "Sequencer" element (418) on the customer computer ('723 Patent, Fig. 12).
  • Evidence for a Narrower Interpretation: The term "sequencer" could be construed to require more than a simple counter, perhaps implying a specific type of hardware or software module that generates a sequence of numbers. However, the specification provides little language to support a narrower definition beyond the claim language itself, which refers to "incrementing" it to "update a count value" ('723 Patent, col. 31:16-18), an action consistent with a counter.

VI. Other Allegations

Indirect Infringement

The complaint alleges inducement of infringement, stating that Apple "actively and knowingly encouraged and instructed its customers" to use the accused features of Apple Pay (Compl. ¶39). It also alleges contributory infringement on the basis that Apple provides the Apple Pay service and integrated hardware, which are "material components" of the invention that are "specially made and adapted for use in an infringing manner" and are not staple articles of commerce (Compl. ¶40).

Willful Infringement

Willfulness is alleged based on Apple’s pre-suit knowledge of the patents-in-suit (Compl. ¶¶41, 48, 56). The complaint alleges Apple has known of the ’723 Patent since at least November 2018, when it cited the patent’s parent application in an IDS during the prosecution of its own patent. The complaint further highlights a statement from the USPTO Examiner in that prosecution noting the inventor's disclosure was "pertinent" to Apple's own disclosure on Apple Pay (Compl. ¶¶26-27).

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

  • A core issue will be one of technological translation: can claim terms from a patent family filed in 2000, which describes securing desktop e-commerce transactions, be construed to cover the fundamentally different architecture of a modern, tokenized mobile payment system? This will turn on whether elements like a "hardware identifier" read on a cryptographic key in a Secure Element, and whether a "user agreement identifier" reads on a Device Account Number (DAN) token.
  • A key evidentiary question will be one of functional specificity: does the Apple Pay system perform the exact sequence of claimed steps, particularly the explicit step of "determining whether said... hardware identifiers are valid"? The case may depend on whether the plaintiff can demonstrate that Apple’s system performs a discrete validation check on its hardware-based key, rather than simply using it as an input to generate a cryptogram.
  • Finally, the willfulness claim will raise a question of corporate knowledge: does an IDS citation of a patent application by an attorney prosecuting one of Apple's thousands of patents, combined with an examiner’s subsequent comment, constitute knowledge by Apple as a corporate entity sufficient to support a finding of willful infringement for a product as complex as Apple Pay?