DCT
1:17-cv-00733
Cryptopeak Security LLC v. 1 800 Contacts Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: CryptoPeak Security, LLC (Delaware)
- Defendant: 1-800 Contacts, Inc. (Delaware)
- Plaintiff’s Counsel: Devlin Law Firm LLC
- Case Identification: 1:17-cv-00733, D. Del., 06/13/2017
- Venue Allegations: Venue is based on Defendant’s incorporation in the State of Delaware.
- Core Dispute: Plaintiff alleges that Defendant’s secure web servers, which use standard Transport Layer Security (TLS) protocols, infringe a patent related to methods for generating cryptographic keys and providing a corresponding proof that the keys were generated correctly.
- Technical Context: The technology concerns public-key cryptography, specifically methods to ensure and verify that cryptographic keys used for secure online communications are generated according to a specific, verifiable process.
- Key Procedural History: The complaint notes that the patent-in-suit was previously asserted against multiple defendants in the Eastern District of Texas. In that litigation, the court reportedly denied motions to dismiss challenging the patent’s validity under 35 U.S.C. §§ 101 and 112, holding at the pleadings stage that the asserted claims recite a patent-eligible method rather than an invalid mixture of method and apparatus.
Case Timeline
| Date | Event |
|---|---|
| 1997-05-28 | U.S. Patent No. 6,202,150 Priority Date |
| 2001-03-13 | U.S. Patent No. 6,202,150 Issues |
| 2017-06-13 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,202,150 - Auto-Escrowable And Auto-Certifiable Cryptosystems
- Patent Identification: U.S. Patent No. 6,202,150, issued March 13, 2001.
The Invention Explained
- Problem Addressed: The patent describes a challenge in public-key cryptography where encrypted communications may be used for criminal activity, creating a need for law enforcement to recover decryption keys. However, prior key escrow systems suffered from drawbacks, such as requiring hardware-based "tamper-proof" devices, creating protocol overhead, or being vulnerable to covert "shadow public key" systems that circumvent the escrow mechanism (U.S. Patent No. 6,202,150, col. 1:41-50; col. 3:4-15).
- The Patented Solution: The invention proposes a system for generating a key pair along with a "certificate of proof" that the key was created according to a specific algorithm. This proof, which does not reveal the private key, allows any entity (like a Certification Authority) to verify that the private key is properly escrowed and thus recoverable by authorized parties. The system is designed to be "overhead-free" and implementable in software ('150' Patent, Abstract; col. 5:6-23).
- Technical Importance: This approach sought to enable a verifiable key escrow framework that did not depend on specialized hardware or trusted third parties for the verification step, aiming to make such systems more scalable and publicly scrutable ('150 Patent, Abstract).
Key Claims at a Glance
- The complaint asserts infringement of at least independent claims 1 and 3 (Compl. ¶25, ¶41).
- Independent Claim 1 recites a method for generating public keys and a corresponding proof, comprising the key steps of:
- A user's system generating a random string of bits based on system parameters;
- Running a key generation algorithm to produce a secret key and a public key; and
- Constructing a "proof" that requires access to the secret key but can be verified by another entity without access to that secret key, providing confidence that the public key was generated properly.
- Independent Claim 3 recites a similar method for publishing public keys and a proof, comprising the key steps of:
- A user's system reading system parameters;
- Running a key generation algorithm to produce a private key and public key; and
- Constructing a "proof" that the private key was generated properly, which requires access to the private key for its construction but can be verified by any other entity without such access.
III. The Accused Instrumentality
Product Identification
The "Accused Instrumentalities" are identified as computer servers operated by Defendant, including those for the 1800contacts.com website, that use the Transport Layer Security (TLS) version 1.2 protocol with specific Elliptic Curve Cryptography (ECC) ciphersuites, namely those beginning with "TLS_ECDHE" (Elliptic Curve Diffie-Hellman Ephemeral) (Compl. ¶25, ¶29).
Functionality and Market Context
The accused functionality is the implementation of the TLS 1.2 handshake protocol on Defendant’s servers to establish secure online communication sessions (Compl. ¶29). The complaint alleges that the steps performed during this standard cryptographic handshake—specifically the exchange of random values, generation of session keys, and validation of the handshake's integrity—constitute infringement of the patented methods (Compl. ¶30-40). The complaint provides a list of specific ciphersuites supported by the 1-800 Contacts server, allegedly identified using a public testing tool, as evidence. A screenshot in the complaint lists specific "TLS_ECDHE" ciphersuites allegedly supported by the Defendant's server (Compl. ¶25).
IV. Analysis of Infringement Allegations
'150 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| the user's system generating a random string of bits based on system parameters | The server (the "user's system") generates and exchanges random values ("ServerHello.random") with a client during the TLS 1.2 handshake protocol. A screenshot from an RFC document is provided to show this step. | ¶31, ¶33, Fig. 1 | col. 11:25-29 |
| the user running a key generation algorithm to get a secret key and public key using the random string and public parameters | The server uses the exchanged random values and public parameters (e.g., elliptic curve specifications) to compute a "premaster secret" (alleged "public key") and subsequently a "master_secret" (alleged "secret key"). A visual from an RFC shows the derivation of the "master_secret". | ¶34, ¶35, Fig. 8 | col. 11:30-34 |
| the user constructing a proof being a string of bits whose public availability does not compromise the secret key... and wherein said constructing of said proof requires access to said secret key | The server constructs and sends a "Finished" message, which is a function of the "master_secret" and all preceding handshake messages. This "Finished" message is alleged to be the claimed "proof." A visual from an RFC details the structure of this message. | ¶36, ¶37, ¶38, Fig. 11 | col. 11:35-49 |
| but at the same time said proof provides confidence to at least one of a plurality of other entities that said public key was generated properly... and wherein said confidence is gained without having access to any portion of said secret key | A client receiving the "Finished" message validates it to confirm the integrity of the key exchange. The client performs this validation without having access to the server's "master_secret", thereby gaining "confidence" that the keys were generated correctly for the session. | ¶38, ¶39 | col. 11:43-49 |
- Identified Points of Contention:
- Scope Questions: The infringement theory equates the standard TLS "Finished" message with the patent's "proof." A central dispute may be whether this message, primarily designed to authenticate a session and prevent man-in-the-middle attacks, meets the claim limitation of a "proof that the... key was generated properly by the specified algorithm." The patent's specification, with its focus on "auto-certifiable" and "auto-recoverable" escrow systems, may suggest a different purpose and function for the "proof" than that of the TLS "Finished" message ('150 Patent, Abstract).
- Technical Questions: The complaint maps the TLS "master_secret" to the claimed "secret key" and the "premaster secret" to the "public key." It raises the question of whether these ephemeral, session-specific values in the TLS protocol are technically equivalent to the public/private key pairs described in the patent. The relationship and generation process of keys in TLS may not align with the key generation model contemplated in the '150 patent specification.
V. Key Claim Terms for Construction
The Term: "proof"
Context and Importance: The plaintiff's case depends on construing "proof" to encompass the "Finished" message in the standard TLS handshake. The definition of this single term appears dispositive for infringement. Practitioners may focus on this term because its construction will determine whether a standard, ubiquitous security protocol falls within the scope of a patent centered on a novel key escrow methodology.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The plain language of Claim 1 defines "proof" functionally: it "provides confidence" that the key was generated properly and can be verified without access to the secret key (col. 12:43-49). Plaintiff may argue that the TLS "Finished" message meets this functional description.
- Evidence for a Narrower Interpretation: The patent's abstract and detailed description repeatedly frame the invention in the context of "auto-recoverable," "auto-certifiable," and "escrow" systems ('150 Patent, Abstract; col. 9:15-24). The specification also refers to "non-interactive zero-knowledge proofs," a specific and formal type of cryptographic proof, as an implementation detail (col. 7:13-15). A party could argue these passages limit the term "proof" to a formal certificate of recoverability, not a general-purpose handshake authentication message.
The Term: "public key" and "secret key"
Context and Importance: The infringement allegation requires mapping components of the TLS protocol ("premaster secret", "master_secret") to these fundamental cryptographic terms. The technical accuracy of this mapping is critical.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent claims do not specify a particular type of public/secret key pair, potentially allowing for a functional interpretation where any pair of values that operate as public and secret components would suffice.
- Evidence for a Narrower Interpretation: The background section of the patent describes conventional Public Key Cryptosystems (PKCs) like Diffie-Hellman and RSA (col. 1:15-38). This context may support a narrower construction where "public key" and "secret key" refer to a more traditional, persistent key pair with a specific mathematical relationship, rather than the ephemeral, derived secrets used in a TLS session.
VI. Other Allegations
The complaint does not contain specific counts or factual allegations for indirect or willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the term "proof," as used in a patent describing a novel key escrow and certification system, be construed to cover the standard "Finished" message of the TLS protocol, whose established purpose is to authenticate a session handshake?
- A key evidentiary question will be one of technical mapping: Do the ephemeral keys and secrets generated during a modern TLS handshake (e.g., "premaster secret", "master_secret") function as the "public key" and "secret key" pair contemplated by the '150 patent, or does a fundamental difference in their cryptographic structure and purpose place them outside the claim scope?
- A final question relates to estoppel and claim differentiation: Given the patent’s heavy emphasis on key escrow and recoverability in the specification, what weight will a court give to that disclosure when interpreting claims that do not explicitly recite "escrow," and how will the prior litigation history in Texas influence the court's analysis of claim validity and scope?