Cryptopeak Security LLC v. Jack Henry & Associates Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: CryptoPeak Security, LLC (Delaware)
  • Defendant: Jack Henry & Associates, Inc. (Delaware)
  • Plaintiff’s Counsel: DEVLIN LAW FIRM LLC
• Case Identification: 1:17-cv-00743, D. Del., 06/13/2017
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because the Defendant is a corporation organized and existing under the laws of Delaware.
• Core Dispute: Plaintiff alleges that Defendant’s servers, by using certain standard Transport Layer Security (TLS) ciphersuites, infringe a patent related to methods for generating cryptographic keys along with a verifiable proof of their recoverability.
• Technical Context: The lawsuit concerns foundational technologies for establishing secure, encrypted communication channels over computer networks, specifically the key generation and verification steps within the TLS protocol.
• Key Procedural History: The complaint notes that the patent-in-suit was previously litigated in the Eastern District of Texas against other defendants. In that prior litigation, the court denied motions to dismiss, finding at the pleadings stage that the asserted claims recited a patent-eligible method and were not indefinite, despite containing the preamble "method and apparatus."

Case Timeline

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

U.S. Patent No. 6,202,150 B1 - Auto-Escrowable And Auto-Certifiable Cryptosystems

• Patent Identification: U.S. Patent No. 6,202,150 B1, "Auto-Escrowable And Auto-Certifiable Cryptosystems," issued March 13, 2001.

The Invention Explained

• Problem Addressed: The patent describes a tension in public key cryptography: its strength in ensuring privacy also enables criminals to conduct untappable communications. Prior art key escrow systems designed to give authorities lawful access were often inefficient, required trust in specific hardware or a limited set of verifiers, or were susceptible to being bypassed. (’150 Patent, col. 2:40-51, col. 3:49-61).
• The Patented Solution: The invention is a method for generating a public/private key pair along with a "certificate of recoverability." This certificate acts as a mathematical proof that the private key was generated correctly according to a specific algorithm, ensuring it is recoverable by authorized escrow agents. Crucially, this verification can be performed by any entity ("universal verifiability") without needing access to the private key itself, thus decentralizing trust. ('150 Patent, Abstract; col. 4:50-54). The method achieves this through a series of specified mathematical operations that link the key generation process to the creation of the proof. ('150 Patent, col. 7:5-24).
• Technical Importance: The described approach sought to enable a key escrow system that could be implemented purely in software and publicly scrutinized, reducing the need for costly, tamper-proof hardware or reliance on a small number of centralized trusted authorities. ('150 Patent, Abstract; col. 4:20-36).

Key Claims at a Glance

• The complaint asserts independent claims 1 and 3. (Compl. ¶25, ¶41).
• Independent Claim 1 recites a method for generating public keys and a proof, comprising the key steps of:
  • the user's system generating a random string of bits based on system parameters;
  • the user running a key generation algorithm to get a secret key and public key using the random string and public parameters;
  • the user constructing a proof being a string of bits whose public availability does not compromise the secret key, wherein said constructing requires access to the secret key;
  • said proof provides confidence to other entities that the public key was generated properly by the specified algorithm, with said confidence gained without access to any portion of the secret key.
• Independent Claim 3 recites a method for publishing public keys and a proof, comprising the key steps of:
  • the user's system reading the system parameters;
  • the user's system running a key generation algorithm to get a private key and public key;
  • the user's system constructing a proof that the private key was generated properly using the system parameters, where constructing the proof requires access to the private key;
  • verification of said proof can be performed by any other entity with no access to any portion of said private key.
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

• The "Accused Instrumentalities" are identified as computers or servers operated by Defendant that utilize Transport Layer Security (TLS) version 1.2 with specific Elliptic Curve Cryptography (ECC) ciphersuites, namely those beginning with "TLS_ECDHE" (Elliptic Curve Diffie-Hellman Ephemeral). (Compl. ¶25, ¶29). The complaint specifically points to the server(s) for the website "www.netteller.com" as an example. (Compl. ¶29).

Functionality and Market Context

• The accused functionality is the server-side implementation of the TLS 1.2 handshake protocol, a standard process for establishing a secure, encrypted communication session between a client and a server over the internet. (Compl. ¶29, ¶32). The complaint alleges that when using an ECDHE ciphersuite, the server performs a method of key generation and verification that infringes the ’150 Patent. (Compl. ¶30). A screenshot from a third-party SSL server testing tool is included to show that the accused server supports the accused TLS_ECDHE ciphersuites. (Compl. ¶25).

IV. Analysis of Infringement Allegations

U.S. Patent No. 6,202,150 Infringement Allegations

• Identified Points of Contention:
  • Scope Questions: A primary question for the court will be whether the temporary, session-specific data generated during a TLS handshake (e.g., "master_secret", "Finished" message) fall within the scope of the patent's terms "secret key" and "proof." The patent's specification appears to contemplate more persistent, user-identity-based keys within a Public Key Infrastructure (PKI), raising the question of a potential scope mismatch with the accused ephemeral, automated protocol.
  • Technical Questions: The infringement theory equates the TLS "Finished" message with the claimed "proof." A technical question is whether the function of the "Finished" message—primarily to verify the integrity of the handshake and confirm that both parties derived the same session key—is the same as the function of the claimed "proof," which is to provide confidence "that said public key was generated properly by the specified algorithm." The analysis may turn on whether a check for key agreement and integrity is functionally and legally equivalent to a proof of proper algorithmic generation.

V. Key Claim Terms for Construction

• The Term: "proof"

• Context and Importance: The plaintiff's infringement theory hinges on the TLS "Finished" message being a "proof." Its construction is therefore central to the dispute. Practitioners may focus on this term because the accused feature is a standard message authentication code, whereas the patent specification discusses more complex cryptographic constructs.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the proof broadly as a "certificate of recoverability which is a string of information." ('150 Patent, col. 5:18-22). This language could support an interpretation that includes any data structure used for verification.
  • Evidence for a Narrower Interpretation: The detailed description of the preferred embodiment explains that the system processes "three non-interactive zero-knowledge proofs." ('150 Patent, col. 7:13-16). A defendant may argue this context limits the term "proof" to this specific and more complex type of cryptographic proof, and not a simpler integrity check like the TLS "Finished" message.

• The Term: "secret key" (and "private key")

• Context and Importance: The complaint alleges the "master_secret" generated during a TLS session is the claimed "secret key." Whether this temporary session key qualifies will be a critical issue.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The claim language itself does not impose a temporal or persistence requirement on the "secret key," potentially allowing it to read on ephemeral keys created for a single communication session.
  • Evidence for a Narrower Interpretation: The patent’s background and summary sections frame the invention in the context of Public Key Infrastructure (PKI), Certification Authorities (CAs), and user registration, which traditionally involve longer-term keys associated with an identity rather than transient session keys. ('150 Patent, col. 2:21-28, col. 4:30-41). This context may support a narrower construction.

VI. Other Allegations

• Indirect Infringement: The complaint does not contain a formal count for indirect infringement and does not allege specific facts to support the knowledge and intent elements required for such a claim.
• Willful Infringement: The complaint does not contain a formal count for willful infringement or allege that Defendant had pre-suit knowledge of the ’150 Patent.

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

• A core issue will be one of definitional scope: can the patent's claim terms "secret key" and "proof," which arise from a context of persistent, user-centric key escrow, be construed to cover the transient, automated data elements ("master_secret", "Finished" message) of a standard TLS 1.2 session key exchange protocol?
• A key technical question will be one of functional congruence: does the accused TLS "Finished" message, which primarily functions to verify handshake integrity and confirm both parties possess the same session key, perform the same function as the claimed "proof," which is described as demonstrating that a key was "generated properly by the specified algorithm"?
• A central, unstated issue that will likely emerge is the relationship between the patent and the public internet standards (IETF RFCs) that define the accused TLS functionality. The case may require the court to determine whether the patent claims a specific, inventive method distinct from the standard, or if the claims are broad enough to read on a widely adopted public standard, raising questions of novelty and non-obviousness.