DCT
1:17-cv-04001
Venadium LLC v. Hyatt Corp
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Venadium LLC (Texas)
- Defendant: Hyatt Hotels Corporation (Delaware)
- Plaintiff’s Counsel: Andreou & Casson, Ltd. (with Corcoran IP Law, PLLC of counsel)
- Case Identification: 1:17-cv-04001, N.D. Ill., 05/25/2017
- Venue Allegations: Venue is alleged to be proper in the Northern District of Illinois because Defendant conducts business in the district, a portion of the alleged infringement occurred there, and Defendant regularly solicits business in the district.
- Core Dispute: Plaintiff alleges that Defendant’s website infringes a patent related to methods for protecting a computer program from unauthorized use.
- Technical Context: The technology at issue involves using cryptographic protocols and digitally signed messages to control the functionality of software, originally conceived in the context of "shareware" distribution models.
- Key Procedural History: The complaint does not mention any prior litigation, inter partes review proceedings, or licensing history related to the patent-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 1997-10-30 | U.S. Patent No. 6,330,549 Priority Date |
| 2001-12-11 | U.S. Patent No. 6,330,549 Issues |
| 2017-05-25 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,330,549 - "Protected Shareware"
The patent-in-suit is U.S. Patent No. 6,330,549, issued December 11, 2001 (the “'549 Patent”).
The Invention Explained
- Problem Addressed: The patent addresses the challenge of protecting computer software from unauthorized use, particularly in the "shareware" context where programs are distributed informally and without restriction. Traditional protection mechanisms like physical "dongles" or cumbersome copy-protection were seen as inconvenient for legitimate users, while simple encryption was vulnerable if the decryption key was widely available (’549 Patent, col. 1:11-39, col. 2:1-15).
- The Patented Solution: The invention proposes a system where "protective code" embedded within a software program controls its functionality. This code interacts with digitally signed "authorization messages" sent from a trusted source (e.g., a supplier or billing agency). The software contains a public key to verify the signature on these messages, and it also performs an "integrity self-check" to ensure the protective code itself has not been tampered with (’549 Patent, Abstract; col. 2:38-56). This framework allows for controlling software usage—for instance, by revoking access for non-payment—without restricting the software's initial distribution (’549 Patent, col. 7:36-57).
- Technical Importance: This approach provided a mechanism to enforce commercial terms (e.g., payment for use) directly within the software itself, aiming to make the shareware distribution model more commercially viable for suppliers (’549 Patent, col. 1:56-65).
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶13).
- The essential elements of independent claim 1 are:
- A method for protecting a computer program from unauthorized use independently of its distribution methodology, where the program includes embedded protective code.
- (a) Inhibiting at least one functional feature until the user computer receives a digitally signed authorization message.
- (b) Providing the embedded protective code with access to a public checking key.
- (c) Running an integrity self-check to confirm the program is in an anticipated state.
- (d) Communicating the authorization message to the user computer.
- (e) Applying the public checking key to authenticate the authorization message.
- (f) Enabling the functional feature if the message is authenticated and the integrity check confirms the program is in the anticipated state.
- The complaint reserves the right to modify its infringement theory as discovery progresses (Compl. ¶16).
III. The Accused Instrumentality
Product Identification
Defendant’s website, "https://www.hyatt.com/" (the "Accused Product") (Compl. ¶10).
Functionality and Market Context
The complaint alleges that the Accused Product utilizes the Transport Layer Security ("TLS") 1.2 protocol to establish secure Hypertext Transfer Protocol ("HTTPS") connections for client-server communications (Compl. ¶13). The functionality at issue involves the processes for establishing this secure connection, which the complaint alleges prevents unauthorized access to certain web interface features, such as user logon, until a secure connection is established via the exchange of a digitally signed certificate (Compl. ¶13(a)). No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
’549 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a method for protecting a computer program...from unauthorized use...the computer program including an embedded protective code... | The Accused Product (Defendant's website) provides a method for protecting the program from unauthorized access, with the embedded protective code being the cryptographic functions (RSA, Diffie-Hellman, HMAC) required by the TLS 1.2 protocol. | ¶13 | col. 8:50-55 |
| (a) inhibiting via the embedded protective code at least one functional feature of the computer program from running on a user computer until the user computer receives an authorization message that is digitally signed by an authorized party using a secret signing key... | Unauthorized access for a user logging into the web interface is prevented until a secure HTTPS connection is established. This connection is established after the user computer receives an authorization message (a certificate digitally signed by a certificate authority). | ¶13(a) | col. 10:50-57 |
| (b) providing the embedded protective code...with access to the public checking key... | The embedded protective code (the code instituting the HTTPS connection) is provided access to the public checking key via the signed certificate. | ¶13(b) | col. 10:58-59 |
| (c) running an integrity self-check over the computer program...to confirm that the computer program is in an anticipated state... | An HMAC process is used to confirm the integrity of messages between the client and server, which confirms that the website has not been compromised and can accept a user logon. This self-check is alleged to be embedded in the website's application code via the TLS 1.2 implementation. | ¶13(c) | col. 10:60-64 |
| (d) communicating the authorization message...to the user computer... | The server's signed certificate is communicated to the user computer (the client). | ¶13(d) | col. 10:65 |
| (e) applying the public checking key to the authorization message for authenticating it | The client allegedly uses the server's public key (from the certificate) to encrypt a pre-master secret key, sends it to the server, and verifies the server's subsequent decryption to authenticate the authorization message. | ¶13(e) | col. 10:66-67 |
| (f) enabling said functional feature...to run on the user computer if the authorization message is authenticated and if the integrity self-check result confirms that the computer program is in the anticipated state. | The logon feature is enabled to run if the server's signed certificate is authenticated and the HMAC check confirms the website is not compromised. | ¶13(f) | col. 9:1-5 |
Identified Points of Contention
- Scope Questions: The complaint's theory raises the question of whether a standard, ubiquitous internet security protocol (TLS/HTTPS) constitutes the specific "method for protecting a computer program from unauthorized use" envisioned by the ’549 Patent. The patent’s specification appears to describe a system for controlling commercial usage rights and monetization of shareware, which may present a mismatch with the function of TLS, which is primarily to secure communication channels and authenticate server identity.
- Technical Questions: A central question may be whether a standard server certificate, as used in a TLS handshake, functions as an "authorization message" in the manner required by the claim. The complaint alleges it does (Compl. ¶13(a)), but the patent describes this message as a mechanism to grant, deny, or revoke usage rights, often based on commercial conditions like payment (e.g., ’549 Patent, col. 7:36-57). The function of a standard TLS certificate in authenticating a server's identity for establishing a secure channel may not align with the patent's description of a message that authorizes software execution based on user-specific entitlements.
V. Key Claim Terms for Construction
The Term: "authorization message"
- Context and Importance: This term is critical because the plaintiff’s infringement theory equates a standard, digitally-signed server certificate used in a TLS handshake with the claimed "authorization message." The viability of the infringement case may depend on whether this interpretation is adopted.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself does not explicitly tie the message to payment or specific commercial terms, only that it is "digitally signed by an authorized party" and enables a "functional feature" to run (’549 Patent, col. 8:52-55). This may support an argument that any signed message that acts as a precondition for functionality, such as a server certificate enabling a secure session, falls within the term's scope.
- Evidence for a Narrower Interpretation: The specification repeatedly frames the authorization message in a commercial context, linking it to a "billing agency," payment status, and the granting or revocation of "usage rights" (’549 Patent, Fig. 1; col. 2:25-30; col. 7:8-15). This context suggests the term may be construed more narrowly to mean a message that specifically conveys permission to use the software based on business rules, rather than a message that simply authenticates identity to secure a communication link.
The Term: "integrity self-check"
- Context and Importance: The complaint alleges that the HMAC process in TLS 1.2 meets this limitation. Practitioners may focus on this term because the patent describes the check as confirming "the computer program is in an anticipated state" (’549 Patent, col. 10:62-63), which is alleged to mean the "website has not been compromised" (Compl. ¶13(c)). The dispute may center on whether the integrity check described in the patent is meant to verify the program code itself, versus the TLS/HMAC function of verifying the integrity of messages transmitted over a channel.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states the check is to "ensure that shareware, including its protective code, is in an anticipated state," which could "conceivably" mean the code might be "dynamically altered in some authorized...way" (’549 Patent, col. 2:50-56). This could support a reading where the check verifies the system's operational state rather than just static code integrity.
- Evidence for a Narrower Interpretation: The specification also describes the check as a mechanism to detect if the "program code" has been altered, for example, by computing a "check sum...over the existing version of the program code" and comparing it to a reference (’549 Patent, col. 4:7-15). This suggests a narrower function of verifying the integrity of the software code itself, which may differ from the function of HMAC in TLS, which verifies the integrity of data in transit.
VI. Other Allegations
Willful Infringement
The complaint does not contain a formal count for willful infringement. It alleges that Defendant has had knowledge of its infringement "since at least the date that Defendant was served with a copy of this Complaint" (Compl. ¶17). The prayer for relief requests an award of damages under 35 U.S.C. § 284 and a judgment that the case is exceptional under 35 U.S.C. § 285 (Compl., Prayer for Relief ¶C-D).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the claims of the ’549 Patent, which arose from the technical problem of monetizing and controlling "shareware," be construed to cover the ubiquitous and standardized internet protocol for securing website communications (TLS/HTTPS)? The outcome may depend on whether terms like "authorization message" are interpreted broadly to cover any cryptographic precondition or are limited by the specification's context of commercial usage rights.
- A second key question will be one of technical correspondence: Does the accused functionality of the TLS protocol perform the same function in the same way as the system claimed in the patent? Specifically, the court will have to determine if a TLS integrity check (HMAC) on transmitted data is equivalent to the claimed "integrity self-check" on the computer program itself, and whether a server's identity certificate functions as a message that "authorizes" software use in the manner described by the patent.