PTAB

CBM2018-00023

Apple Inc v. Universal Secure Registry LLC

Log In
Key Events
Petition
petition Intelligence

1. Case Identification

2. Patent Overview

  • Title: Universal Secure Registry
  • Brief Description: The ’539 patent describes a system and method for authenticating a user's identity to enable a transaction without revealing sensitive information (like a credit card number) to a service provider (like a merchant). The system, called a "Universal Secure Registry" (USR), uses a central database to verify an entity's identity based on a time-varying multicharacter code, secret codes, or biometric information, and then facilitates the transaction with a third party (e.g., a credit card company).

3. Grounds for Unpatentability

Ground 1: Claims 1-38 are Unpatentable Under 35 U.S.C. §101

  • Prior Art Relied Upon: This ground is based on patent-ineligible subject matter under 35 U.S.C. §101, as interpreted by Alice Corp. Pty. Ltd. v. CLS Bank Int’l. No prior art references are used for an anticipation or obviousness challenge.
  • Core Argument for this Ground: Petitioner argued that all challenged claims were directed to an abstract idea and lacked an inventive concept, failing both steps of the Alice test.
    • Alice Step 1 (Directed to an Abstract Idea): Petitioner asserted that the claims were directed to the long-standing, fundamental economic practice of verifying an account holder's identity before enabling a transaction. The petition contended that this is a pre-Internet business practice, and merely limiting it to a generic computer environment does not make it patent-eligible. Petitioner argued the claims recited standard computing tasks (receiving, mapping, determining, accessing) and were analogous to claims found abstract in cases like Alice (third-party settlement), Secured Mail Solutions (verifying authenticity of a mail object), and Smart Systems Innovations (using a bankcard for transit access). It was also argued that the claims were directed to an unpatentable mental process, as a human could perform the same comparison steps with a spreadsheet to grant access.
    • Alice Step 2 (Lacks an Inventive Concept): Petitioner contended that the claims, viewed individually and as an ordered combination, added nothing "significantly more" than the abstract idea itself. The implementation relied on wholly conventional, generic computer hardware (a general-purpose computer, any kind of database) that was well-known at the time of filing. The patent itself was cited as emphasizing this generic nature. The core "time-varying multicharacter code" was described in the patent as being generated by prior art devices like a smart card, not as an inventive element. The remaining limitations—such as receiving a request, mapping data, accessing information, and enabling a transaction—were argued to be routine data operations that did not supply an inventive concept. Dependent claims were said to add only well-known, post-solution limitations, such as using generic security tokens, retrieving specific personal information, or employing biometric verification, which are themselves abstract practices.

4. Key Claim Construction Positions

Petitioner proposed constructions for several key terms, arguing they were critical to understanding the claims' implementation of a non-technical, abstract business method.

  • Provider: Proposed as "the party to a transaction, such as a merchant, that provides a good or service to an entity." This construction was based on the specification's description of a financial context and prosecution history where the term "first party" was explicitly defined as representing a merchant.
  • Entity: Proposed as "the purchasing party to a transaction who has data stored in the secure registry." This was supported by the patent's consistent use of "entity" to refer to the user or person whose identity is being verified to complete a purchase.
  • Time-Varying Multicharacter Code: Proposed as "a sequence of numbers that varies with time." Petitioner argued the specification consistently described this element as a "number" or "value" used in a mathematical combination to produce a non-predictable code for database access.
  • Secure Registry: Proposed as "a database with access restrictions." This construction was based on claim language requiring "secure data" and the need to determine "compliance with access restrictions," as well as the specification's description of the USR as a database.

5. Key Technical Contentions (Beyond Claim Construction)

A central argument in the petition was that the ’539 patent was eligible for Covered Business Method (CBM) review because it was not directed to a "technological invention."

  • Use of Generic Components: Petitioner argued the patent failed the first prong of the "technological invention" test because it did not recite a novel or unobvious technological feature. Instead, it explicitly described implementation using well-known, off-the-shelf components like general-purpose processors and any kind of database, running on any operating system. The prosecution history was cited to show that amendments made to overcome prior art were non-technical distinctions.
  • Solving a Business Problem, Not a Technical One: Petitioner contended the patent also failed the second prong because it addressed the non-technical, business problem of identity verification for transactions. The core problem of "ensuring that people conducting a transaction are who they claim to be" was asserted to be inherently non-technical. The patent did not propose a technical solution, such as an improved computer or a novel encryption algorithm, but merely used conventional computers to perform routine functions.

6. Relief Requested

  • Petitioner requested that the Board institute a Covered Business Method review and enter a judgment that claims 1-38 of the ’539 patent are unpatentable under 35 U.S.C. § 101.