DCT

1:17-cv-00585

Universal Secure Registry LLC v. Apple Inc

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:17-cv-00585, D. Del., 05/21/2017
  • Venue Allegations: Plaintiff alleges venue is proper in the District of Delaware because Defendant Visa Inc is incorporated in Delaware, and Defendant Apple Inc maintains a regular and established place of business (a retail store) in the district and conducts substantial business through the sale of its products and the use of its services by customers at numerous retailers in Delaware.
  • Core Dispute: Plaintiff alleges that Defendant’s Apple Pay mobile payment service, operating on Apple devices and utilizing Visa’s payment network, infringes four patents related to secure, multi-factor authentication for financial transactions.
  • Technical Context: The technology concerns systems and methods for using personal electronic devices, such as smartphones, to conduct secure payments by replacing static credit card numbers with dynamically generated, encrypted authentication data, often involving biometric verification.
  • Key Procedural History: The complaint alleges that Plaintiff disclosed its patented technology to both Apple and Visa in 2010 during partnership discussions, years before the 2014 launch of Apple Pay. Subsequent to the filing of this complaint, U.S. Patent No. 8,577,813 and U.S. Patent No. 9,530,137 were subject to Inter Partes Review (IPR) proceedings, which resulted in the cancellation of several claims, including the lead asserted claims from each patent (Claim 1 of the ’813 Patent and Claim 12 of the ’137 Patent). Additionally, U.S. Patent No. 8,856,539 was subject to a terminal disclaimer, and later a statutory disclaimer of several claims, though not the lead asserted claim.

Case Timeline

Date Event
2001-03-16 Priority Date for U.S. Patent No. 8,856,539
2006-02-21 Priority Date for U.S. Patent Nos. 8,577,813; 9,100,826; and 9,530,137
2010-07-14 Plaintiff allegedly sent letter to Apple describing patented technology
2013-01-01 Apple and Visa allegedly began working on Apple Pay (approximate date)
2013-11-05 U.S. Patent No. 8,577,813 Issued
2014-09-09 Apple Pay publicly launched
2014-10-07 U.S. Patent No. 8,856,539 Issued
2015-08-04 U.S. Patent No. 9,100,826 Issued
2016-12-27 U.S. Patent No. 9,530,137 Issued
2017-05-21 Complaint Filed
2017-10-16 IPR filed against U.S. Patent No. 8,577,813 (IPR2018-00067)
2018-04-04 IPR filed against U.S. Patent No. 9,530,137 (IPR2018-00809)
2018-08-17 Statutory disclaimer filed for U.S. Patent No. 8,856,539

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

U.S. Patent No. 8,577,813 - "Universal Secure Registry"

  • Issued: November 5, 2013 (the "’813 Patent")

The Invention Explained

  • Problem Addressed: The patent background describes challenges in authenticating identity for access to secure systems, noting the vulnerabilities of traditional methods that rely on software residing on company computers or physical credentials that can be falsified, particularly in high-security contexts like airports. It also highlights the limitations of magnetic stripe cards and the need for more secure, contactless transaction methods. (’813 Patent, col. 2:5-33).
  • The Patented Solution: The invention is an "electronic ID device" that allows a user to select a financial account for a transaction. The user provides both a biometric input (e.g., fingerprint) and secret information (e.g., PIN) to the device. The device's processor then generates a "non-predictable value" and combines it with the user's information to create encrypted authentication data, which is sent to a "secure registry" to authorize the transaction. This process avoids transmitting the actual account number. (’813 Patent, Abstract; col. 6:40-67).
  • Technical Importance: The technology proposed a framework for multi-factor authentication on a personal device to generate dynamic, single-use credentials, thereby enhancing security over the static, easily compromised data stored on traditional payment cards. (Compl. ¶¶22-23).

Key Claims at a Glance

  • The complaint asserts independent claim 1. (Compl. ¶43).
  • The essential elements of independent claim 1, an electronic ID device, include:
    • A biometric sensor for receiving a biometric input from a user.
    • A user interface for receiving secret information and selecting an account.
    • A communication interface for communicating with a secure registry.
    • A processor programmed to activate the device upon successful authentication (via biometric or secret info), generate a non-predictable value and encrypted authentication information, and communicate that information to the secure registry.
    • The communication interface is further configured to wirelessly transmit the encrypted information to a Point-of-Sale (POS) device.
  • The complaint reserves the right to identify additional infringing activities and claims. (Compl. ¶42). Post-filing, an IPR certificate indicates that claim 1 has been canceled. (’813 Patent, IPR Certificate, p. 2).

U.S. Patent No. 8,856,539 - "Universal Secure Registry"

  • Issued: October 7, 2014 (the "’539 Patent")

The Invention Explained

  • Problem Addressed: The patent background identifies the need for a centralized, secure system to manage and verify identity for various purposes, from financial transactions to locating individuals, without unnecessarily exposing private information. (’539 Patent, col. 1:11-18, col. 2:11-24).
  • The Patented Solution: The patent describes a method, performed by a secure registry system, for enabling transactions. The registry receives a request from a provider (e.g., a merchant) containing a "time-varying multicharacter code" for a user. The system maps this code to the user's identity, determines if the provider has the right to access the user's data, and, if compliant, accesses the user's sensitive account information (e.g., PAN). It then provides this account information to a third party (e.g., an issuing bank) for authorization, while enabling or denying the transaction for the original provider without revealing the sensitive account data to them. (’539 Patent, Abstract; col. 15:6-48).
  • Technical Importance: This invention details the architecture of a backend "tokenization" service, which acts as a secure intermediary that de-links the public-facing transaction identifier (the token) from the underlying sensitive financial account number, a foundational concept in modern secure digital payments. (Compl. ¶¶37-38).

Key Claims at a Glance

  • The complaint asserts independent claim 22. (Compl. ¶65).
  • The essential elements of independent claim 22, a method, include:
    • Receiving a transaction request including a time-varying multicharacter code and an indication of the provider.
    • Mapping the time-varying code to an entity's identity.
    • Determining compliance with access restrictions for the provider.
    • Accessing the entity's account identifying information based on compliance.
    • Providing the account identifying information to a third party.
    • Enabling or denying the transaction for the provider without providing the account identifying information to the provider.
  • The complaint reserves the right to identify additional infringing activities and claims. (Compl. ¶64).

U.S. Patent No. 9,100,826 - "Method and Apparatus for Secure Access Payment and Identification"

  • Issued: August 4, 2015 (the "’826 Patent")

Technology Synopsis

The ’826 Patent describes a multi-factor authentication method involving two devices. A user authenticates to a first handheld device using information like a fingerprint or passcode. The first device then wirelessly transmits "first authentication information." A second device (e.g., a server) receives this, retrieves or receives "second authentication information" associated with the user, and authenticates the user's identity based on the combination of both pieces of information. (’826 Patent, Abstract; Compl. ¶84).

Asserted Claims

The complaint asserts independent claim 10. (Compl. ¶84).

Accused Features

The accused functionality is the Apple Pay transaction flow, where an iPhone acts as the first handheld device and the Visa/Apple backend servers act as the second device, authenticating the user based on information sent from the phone and information stored on the servers. (Compl. ¶84). A flowchart in the complaint illustrates this alleged process flow. (Compl. p. 57, Fig. 2).

U.S. Patent No. 9,530,137 - "Method and Apparatus for Secure Access Payment and Identification"

  • Issued: December 27, 2016 (the "’137 Patent")

Technology Synopsis

The ’137 Patent claims a system for authenticating a user to enable a transaction. The system includes a first device with a biometric sensor and a processor. The processor is programmed to authenticate the user based on both secret information (e.g., passcode) and biometric information, and then generate signals that include authentication information, an indicator of biometric authentication, and a time-varying value. These signals are then transmitted to a second device for processing. (’137 Patent, Abstract; Compl. ¶106). A diagram in the complaint shows the alleged structure of an encrypted payment token containing such information. (Compl. p. 85).

Asserted Claims

The complaint asserts independent claim 12. (Compl. ¶106).

Accused Features

The accused system comprises the iPhone (as the first device) and the Visa payment network/token service (as the second device), which work together to authenticate a user and generate the secure data payload for an Apple Pay transaction. (Compl. ¶106). Post-filing, an IPR certificate indicates that claim 12 has been canceled. (’137 Patent, IPR Certificate, p. 2).

III. The Accused Instrumentality

Product Identification

The accused instrumentalities are collectively the Apple Pay service, the Apple devices that support it ("Accused Apple Devices"), and the backend systems that process its transactions, including the Visa payment processing network and the Visa Token Service (collectively, "Accused Products"). (Compl. ¶¶39, 42).

Functionality and Market Context

The complaint describes Apple Pay as a service enabling users to make secure payments in stores, in apps, and online. (Compl. ¶¶13, 76). A user provisions a payment card (e.g., a Visa card) into the Apple Wallet application on an iPhone. (Compl. ¶13). During an in-store transaction, the user holds the iPhone near a contactless NFC reader and authenticates using Touch ID (fingerprint) or a passcode. (Compl. ¶15). The iPhone’s Secure Element then transmits a Device Account Number (a token substitute for the actual card number) and a transaction-specific dynamic security code to the terminal. (Compl. ¶18). This data is routed through Visa’s network, where the Visa Token Service maps the token back to the user's actual card number to seek authorization from the issuing bank, without exposing the card number to the merchant. (Compl. ¶¶18-19, 37). The complaint alleges the mobile payments business is a multi-trillion dollar market and that Apple Pay's growth has been "explosive." (Compl. ¶¶29, 36).

IV. Analysis of Infringement Allegations

’813 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
An electronic ID device configured to allow a user to select any one of a plurality of accounts... The iPhone allows a user to add up to eight credit, debit, or rewards cards to the Wallet app and select one as a default or choose a different card at the time of purchase. (Compl. p. 15). ¶43 col. 6:40-42
a biometric sensor configured to receive a biometric input provided by the user; The iPhone includes a Touch ID fingerprint sensor built into the Home button that scans a user's fingerprint to authorize a payment. (Compl. p. 16). ¶43 col. 6:40-42
a user interface configured to receive a user input including secret information known to the user and identifying information concerning an account selected by the user...; The iPhone's multi-touch display serves as a user interface for entering a passcode (secret information) and for selecting a payment card (account information) from the Wallet app. ¶43 col. 6:43-48
a communication interface configured to communicate with a secure registry; The iPhone’s Near Field Communication (NFC) interface communicates with the Visa payment processing network and Visa Token Service, which are alleged to be the "secure registry." ¶43 col. 6:48-50
a processor...programmed to activate the electronic ID device based on successful authentication by...at least one of the biometric input and the secret information, The iPhone's A-series processor, Secure Enclave, and Secure Element collectively process the Touch ID or passcode authentication to enable a payment transaction to proceed. ¶43 col. 6:52-58
the processor also being programmed such that once the...device is activated the processor is configured to generate a non-predictable value and to generate encrypted authentication information...and to communicate the encrypted authentication information via the communication interface to the secure registry; After authentication, the processor and Secure Element generate a transaction-specific dynamic security code (a non-predictable, encrypted value) and communicate it, along with the Device Account Number, via the NFC interface to the POS terminal and ultimately the Visa network. ¶43 col. 6:58-67
wherein the communication interface is configured to wirelessly transmit the encrypted authentication information to a point-of-sale (POS) device. The iPhone’s NFC interface wirelessly transmits the dynamic security code and Device Account Number to the merchant’s contactless POS terminal. ¶43 col. 25:24-27
  • Identified Points of Contention:
    • Claim Viability: A threshold issue is that claim 1 of the ’813 Patent was canceled in IPR2018-00067 after the complaint was filed, which may render this count moot.
    • Scope Questions: A central dispute may be the definition of "electronic ID device." The claim requires the device to have a processor, sensor, and interface. The complaint’s theory appears to treat the iPhone itself as the device. A defense may argue that because crucial steps like authorization occur on remote Visa servers (the alleged "secure registry"), the accused system does not meet the claim limitation of a self-contained "device" performing the claimed functions. The construction of "secure registry" itself will also be critical, questioning whether it reads on a distributed payment network like VisaNet.

’539 Patent Infringement Allegations

Claim Element (from Independent Claim 22) Alleged Infringing Functionality Complaint Citation Patent Citation
A method for providing information to a provider to enable transactions between the provider and entities who have secure data stored in a secure registry in which each entity is identified by a time-varying multicharacter code, the method comprising; Apple and Visa practice a method where the provider is a merchant and the entity is a user. The Visa Token Service (VTS) is the secure registry, and the time-varying code is the token/cryptogram used in an Apple Pay transaction. ¶65 col. 15:6-12
receiving a transaction request including at least the time-varying multicharacter code...and an indication of the provider requesting the transaction; Visa’s payment network receives a transaction request from a merchant (the provider) that includes the Device Account Number (token) and a transaction-specific dynamic security code (a time-varying code). ¶65 col. 15:13-17
mapping the time-varying multicharacter code to an identity of the entity...; The Visa Token Service maps the received token and dynamic security code to the user's underlying Primary Account Number (PAN) stored in its secure vault. ¶65 col. 15:30-33
determining compliance with any access restrictions for the provider...; VTS checks "domain restrictions" associated with the token to validate that the circumstances of the transaction (e.g., specific device, merchant, or channel) are permissible. ¶65 col. 15:34-40
accessing information of the entity required to perform the transaction based on the determined compliance...the information including account identifying information; If the token is authentic and domain restrictions are met, VTS accesses the user's PAN from its Token Vault to proceed with the transaction. ¶65 col. 15:41-45
providing the account identifying information to a third party without providing the account identifying information to the provider to enable or deny the transaction; Visa passes the PAN to the issuing bank (the third party) for authorization but does not provide the PAN to the merchant (the provider). ¶65 col. 15:46-51
enabling or denying the provider to perform the transaction without the provider's knowledge of the account identifying information. Visa sends an approval or denial response back to the merchant, allowing the transaction to be completed or denied without the merchant ever knowing the user's actual PAN. ¶65 col. 15:52-55
  • Identified Points of Contention:
    • Technical Questions: A key question will be whether the combination of a largely static token (Device Account Number) and a per-transaction dynamic security code constitutes a single "time-varying multicharacter code" as required by the claim. A defense may argue these are two separate data points and that the token itself is not "time-varying."
    • Scope Questions: The construction of claim terms like "provider," "entity," and "third party" will be central. While the complaint’s mapping of these terms to "merchant," "user," and "issuing bank" appears plausible on its face, any nuances in the patent’s definition of these roles could create a basis for a non-infringement argument.

V. Key Claim Terms for Construction

For the ’813 Patent:

  • The Term: "secure registry"
  • Context and Importance: This term appears in claim 1 and is fundamental to the system's architecture. The complaint alleges this term reads on the Visa payment processing network and Visa Token Service. (Compl. ¶43). The patent's specification, however, repeatedly refers to a "Universal Secure Registry" or "USR." Practitioners may focus on whether "secure registry" is limited to the specific, centralized database architecture described in the patent, or if it can be construed more broadly to cover a distributed, federated system like Visa's network.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The claim itself uses the generic phrase "a secure registry," not the more specific "Universal Secure Registry" used throughout the specification, which could suggest the patentee did not intend to limit the claim to the specific embodiment.
    • Evidence for a Narrower Interpretation: The specification consistently describes the invention in the context of a centralized "Universal Secure Registry" system, as depicted in Figure 1, which acts as a single repository for various types of user data. (’813 Patent, Fig. 1; col. 9:35-42).

For the ’539 Patent:

  • The Term: "time-varying multicharacter code"
  • Context and Importance: This term from claim 22 is the core data element that identifies the user and secures the transaction. The complaint alleges it is met by the combination of the Device Account Number and the dynamic security code/cryptogram. (Compl. ¶65). The dispute will likely center on whether "time-varying" modifies "code," meaning the entire code must change over time, or if a code that includes a time-varying component is sufficient.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification discusses generating a "one-time nonpredictable code" which is transmitted to the computer system, supporting the idea that a per-transaction cryptogram fulfills the "time-varying" aspect. (’539 Patent, col. 12:53-56).
    • Evidence for a Narrower Interpretation: The claim recites "a" (singular) "time-varying multicharacter code" that is used for multiple distinct steps (mapping, checking restrictions, etc.). A defense may argue this requires a single data structure that is itself time-varying, not a static token (the DAN) paired with a separate dynamic value (the cryptogram).

VI. Other Allegations

Indirect Infringement

The complaint alleges both induced and contributory infringement against Apple and Visa. Inducement is based on allegations that Defendants encourage and instruct end-users and partners on how to use the Apple Pay service in an infringing manner through websites, developer guides, and user instructions. (Compl. ¶¶50-52, 56-58). Contributory infringement is based on allegations that Defendants provide components, such as Apple's Secure Enclave hardware and Visa's tokenization service, that are especially made for use in the infringing system, are a material part of the invention, and have no substantial non-infringing use. (Compl. ¶¶53, 59).

Willful Infringement

While not using the word "willful," the complaint alleges facts that may support such a claim. It asserts that Plaintiff disclosed its patented technology and discussed potential partnerships with both Apple and Visa in 2010, four years prior to the launch of Apple Pay, allegedly putting them on pre-suit notice of the technology. (Compl. ¶¶32-34). The complaint itself serves as a basis for post-suit knowledge. (Compl. ¶¶49, 55).

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

  • A primary issue is one of claim viability: Plaintiff has asserted lead claims from the ’813 and ’137 patents that were subsequently canceled in IPR proceedings initiated after the complaint was filed. A threshold question for the court will be whether these counts can proceed or are moot, potentially narrowing the case to the two remaining patents.
  • A core issue will be one of definitional scope: The case will likely depend on whether the term “secure registry” from the ’813 patent, described in the specification as a centralized "Universal Secure Registry," can be construed to cover the distributed architecture of the VisaNet payment network.
  • A key evidentiary question will be one of technical construction: The infringement reading of the ’539 patent hinges on whether Apple Pay's use of a semi-static token (Device Account Number) combined with a per-transaction cryptogram satisfies the claim requirement for "a time-varying multicharacter code" that is used to perform all subsequent steps of the claimed method.