PTAB
IPR2018-00127
Unified Patents Inc v. CrypTopeak Security LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2018-00127
- Patent #: 6,202,150
- Filed: November 22, 2017
- Petitioner(s): Unified Patents Inc.
- Patent Owner(s): CryptoPeak Security, LLC
- Challenged Claims: 1-4, 17
2. Patent Overview
- Title: Auto-Escrowable and Auto-Certifiable Cryptosystems
- Brief Description: The ’150 patent discloses methods for generating asymmetric public and private keys in a public key infrastructure (PKI) environment. The system also generates a "proof" (termed a "certificate of recoverability") that allows a third party to verify the keys were created according to a specific algorithm, thereby ensuring the private key is recoverable by an authorized escrow agent without compromising the private key during verification.
3. Grounds for Unpatentability
Ground 1: Claims 1-4 and 17 are anticipated and rendered obvious by McGrew.
- Prior Art Relied Upon: McGrew (Patent 6,249,585).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that McGrew discloses a verifiable key recovery protocol for Diffie-Hellman cryptosystems that meets every limitation of the challenged claims. In McGrew, communicating parties (Alice and Bob) generate public/private keys and a shared session key. Alice provides a "recovery agent" (Roger) with information to recover the session key. Crucially, Alice also provides "verification information" (a proof) to a verifier (Victor), which allows Victor to confirm that the recovery agent can indeed recover the key, all without revealing Alice's private key or the session key itself. Petitioner contended that McGrew’s "verification information" is the claimed "proof," and its private key (
xa) or session key (sa) constitutes the claimed "secret key" or "private key." The verification process provides confidence to a third party (Victor, or any member of the public) that the public key was generated properly, without giving that party access to the secret key. McGrew also explicitly teaches both interactive (mapping to claim 2) and non-interactive (mapping to claim 17) proof protocols. - Motivation to Combine (for §103 grounds): For the obviousness challenge, Petitioner asserted that any minor differences, such as the specific method of generating a random string "based on system parameters," would have been obvious. A person of ordinary skill in the art (POSITA) would have understood that generating cryptographic keys from random strings using system parameters (like predefined lengths or hash algorithms) was a conventional and necessary practice for ensuring security and interoperability, making it an obvious design choice.
- Expectation of Success (for §103 grounds): A POSITA would have had a high expectation of success in implementing any such minor modifications, as they involved applying well-known, predictable techniques in the field of cryptography.
- Prior Art Mapping: Petitioner argued that McGrew discloses a verifiable key recovery protocol for Diffie-Hellman cryptosystems that meets every limitation of the challenged claims. In McGrew, communicating parties (Alice and Bob) generate public/private keys and a shared session key. Alice provides a "recovery agent" (Roger) with information to recover the session key. Crucially, Alice also provides "verification information" (a proof) to a verifier (Victor), which allows Victor to confirm that the recovery agent can indeed recover the key, all without revealing Alice's private key or the session key itself. Petitioner contended that McGrew’s "verification information" is the claimed "proof," and its private key (
Ground 2: Claims 1 and 3 are anticipated by SSL and rendered obvious by the combination of SSL and Vanstone.
- Prior Art Relied Upon: SSL (The SSL Protocol Version 3.0 - Internet Draft, Mar. 1996) and Vanstone (Patent 6,141,420).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner asserted that SSL, a well-known prior art protocol, anticipates the core features of claims 1 and 3. The SSL handshake protocol discloses generating a public key (
pre_master_secret) and a secret key (master_secret) using a selected cipher suite (e.g., RSA, Diffie-Hellman). At the end of the handshake, the parties exchange a "finished message," which Petitioner argued functions as the claimed "proof." This message is derived from themaster_secretand verifies that the keys were generated correctly according to the protocol, without compromising themaster_secretitself. The recipient gains confidence from the finished message that the keys were properly generated. - Motivation to Combine (for §103 grounds): A POSITA would combine SSL with the teachings of Vanstone. SSL explicitly contemplates using various cipher suites and acknowledges the drawbacks of the long keys required by its default protocols (e.g., RSA, Diffie-Hellman), which are computationally intensive. Vanstone directly addresses this known problem by teaching the use of Elliptic Curve Cryptography (ECC) to generate keys that are shorter, faster, and more secure for a given size. A POSITA would have been motivated to substitute the cipher suites in SSL with Vanstone’s more efficient ECC method to improve the performance (speed, bandwidth) of the SSL protocol, a simple and advantageous modification.
- Expectation of Success (for §103 grounds): A POSITA would have had a reasonable expectation of success because the SSL protocol was explicitly designed to be modular and accommodate different cryptographic algorithms as cipher suites. Integrating ECC, a known and predictable key generation technique, into the SSL framework would have been a straightforward implementation.
- Prior Art Mapping: Petitioner asserted that SSL, a well-known prior art protocol, anticipates the core features of claims 1 and 3. The SSL handshake protocol discloses generating a public key (
4. Relief Requested
- Petitioner requested the institution of an inter partes review and cancellation of claims 1-4 and 17 of the ’150 patent as unpatentable under 35 U.S.C. §§ 102 and 103.
Analysis metadata