Venadium LLC v. Electronic Theatre Controls Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Venadium LLC (Texas)
  • Defendant: Electronic Theatre Controls, Inc. (Wisconsin)
  • Plaintiff’s Counsel: Media Litigation Firm, P.C.
• Case Identification: 3:17-cv-00884, W.D. Wis., 11/20/2017
• Venue Allegations: Venue is alleged to be proper based on Defendant having a "regular and established place of business" in the district, conducting business there, and deriving revenue from the district.
• Core Dispute: Plaintiff alleges that Defendant’s corporate website infringes a patent related to methods for controlling software functionality using digitally signed authorization messages.
• Technical Context: The patent addresses technology for distributing software under a "shareware" or "try-before-you-buy" model, where cryptographic methods are used to unlock or enable features after a user is authorized.
• Key Procedural History: The complaint does not mention any prior litigation, inter partes review (IPR) proceedings, or licensing history related to the patent-in-suit. The allegation of knowledge for willfulness is based only on the service of the complaint itself.

Case Timeline

Date	Event
1997-10-30	'549 Patent Priority / Filing Date
2001-12-11	'549 Patent Issue Date
2017-11-20	Complaint Filing Date

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

U.S. Patent No. 6,330,549, “Protected Shareware” (issued Dec. 11, 2001)

The Invention Explained

• Problem Addressed: The patent identifies a core challenge in software distribution: how to allow for informal, widespread distribution (i.e., "shareware") while still providing a mechanism for software suppliers to receive compensation and prevent unauthorized use (U.S. Patent No. 6,330,549, col. 1:11-37). Conventional methods like physical copy-protection ("dongles") were described as inconvenient, and simple encryption was deemed insufficient because the decryption key would have to be widely distributed ('549 Patent, col. 2:1-17).
• The Patented Solution: The invention proposes a system where "protective code" is embedded within the shareware program ('549 Patent, col. 2:40-41). This code controls the program's functionality based on "authorization messages" received from a trusted source, such as a supplier or billing agency ('549 Patent, col. 3:25-33). These messages are authenticated using a public-key cryptography scheme: the message is digitally signed with the supplier's private "secret signing key," and the shareware program contains the corresponding "public checking key" to verify the message's authenticity before enabling full or extended functionality ('549 Patent, col. 2:45-49). The system also incorporates an "integrity self-checking routine" to ensure the protective code itself has not been disabled or altered ('549 Patent, col. 2:50-55).
• Technical Importance: The technology provides a framework to enforce commercial terms (e.g., payment for use) on software that can be freely copied and distributed, seeking to make the "shareware" model more economically viable for suppliers ('549 Patent, col.2:18-24).

Key Claims at a Glance

• The complaint asserts infringement of "one or more claims" without specifying them (Compl. ¶12). Independent claim 1 is representative.
• Independent Claim 1 requires a method with the following essential elements:
  • Inhibiting a functional feature of a computer program on a user's computer until an "authorization message" is received.
  • The authorization message must be "digitally signed by an authorized party using a secret signing key."
  • Providing the program's "embedded protective code" with access to the corresponding "public checking key."
  • Running an "integrity self-check" to confirm the program is in an "anticipated state."
  • Communicating the authorization message to the user's computer.
  • Applying the public checking key to authenticate the authorization message.
  • Enabling the functional feature only if the message is authenticated and the integrity check confirms the program's state.
• The complaint reserves the right to assert additional claims, which may include dependent claims (Compl. ¶15).

III. The Accused Instrumentality

Product Identification

• The complaint identifies the "Accused Product" as Defendant's website, https://www.etcconnect.com/ (Compl. ¶10).

Functionality and Market Context

• The complaint alleges that Defendant "makes, uses, sells, offers for sale, or imports" the Accused Product (Compl. ¶9). It further alleges infringement occurs through the "making and using (including testing) its Accused Product with the sales and offering for sale of its products and services" (Compl. ¶12). The complaint does not describe any specific technical functionality of the website, such as features that are inhibited and later enabled, or any process involving authorization messages.
  No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint does not provide specific factual allegations mapping the functionality of the accused website to the elements of any asserted claim. It references an "Exhibit B" for these details, but this exhibit was not included with the filed complaint document (Compl. ¶12, ¶14). Therefore, a claim chart summary cannot be constructed from the provided materials.

Identified Points of Contention

• Evidentiary Question: The primary issue for the court will be whether Plaintiff can produce evidence that the accused website performs the highly specific steps recited in the claims. The complaint itself offers no factual basis for its conclusory allegations of infringement.
• Technical Questions: A fundamental question is whether the architecture of a commercial website for selling physical goods (theatrical lighting controls) aligns with the patent's "protected shareware" model. For example:
  • Does the website contain "inhibited" features that are later "enabled" for a user?
  • Does the website receive a "digitally signed" authorization message to trigger this enablement, as distinct from standard web protocols like SSL/TLS certificates used for securing connections?
  • Does the website software perform an "integrity self-check" to prevent tampering with its own code?

V. Key Claim Terms for Construction

While the complaint's infringement theory is not detailed, the following terms from claim 1 are fundamental to the patent's scope and would likely be central to any dispute.

The Term: "authorization message"

• Context and Importance: This term is the lynchpin of the claimed method. Its definition will determine what kind of data transfer qualifies as the trigger for enabling software features. Practitioners may focus on this term to determine if it is limited to the specific cryptographically signed communications described in the patent or if it can cover more generic web-based interactions.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The term itself is not explicitly defined with limiting language in the claims.
  • Evidence for a Narrower Interpretation: The specification consistently describes the "authorization message" as a discrete communication that is "digitally signed in whole or part" by a supplier and authenticated by the shareware, which contains a corresponding public key ('549 Patent, col. 2:42-49). FIG. 1 depicts a specific protocol for generating and transmitting such messages between a billing computer and a user's computer ('549 Patent, FIG. 1).

The Term: "integrity self-check"

• Context and Importance: This term defines a key security feature of the invention. The dispute will likely center on whether this requires a specific anti-tampering mechanism, as described in the patent, or if any standard software error-checking routine could suffice.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language requires the check to confirm the program is in an "anticipated state," which could arguably be interpreted broadly.
  • Evidence for a Narrower Interpretation: The specification describes this feature as a countermeasure against bypassing the protective code, for example, by using a "check sum routine" and invoking "predetermined countermeasures" if the program's integrity is "compromised" ('549 Patent, col. 4:3-17). This suggests a specific security purpose beyond general code stability.

VI. Other Allegations

Willful Infringement

• The complaint alleges that Defendant has known of its direct infringement "[s]ince at least the date that Defendant was served with a copy of this Complaint" (Compl. ¶16). This allegation appears to support a claim for post-suit willful infringement only. The prayer for relief also requests a judgment that the case is "exceptional" under 35 U.S.C. § 285 (Compl. p. 3, ¶D).

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

1. Pleading Sufficiency: A threshold legal question is whether the complaint's conclusory allegations, which lack any specific facts explaining how the accused website allegedly infringes and instead refer to a missing exhibit, satisfy the plausibility standard for pleading patent infringement established by the Supreme Court in Iqbal and Twombly.

2. Technical Applicability: The central substantive issue is one of technical applicability: can the patent's detailed cryptographic protocol for "protected shareware"—which involves inhibiting software features, transmitting digitally signed authorization messages, and running integrity checks—be plausibly mapped onto the operations of a public-facing corporate and e-commerce website? The complaint provides no factual basis to suggest such a mapping exists.