AttestWave LLC v. Microsoft Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: AttestWave LLC (Delaware)
  • Defendant: Microsoft Corporation (Washington)
  • Plaintiff’s Counsel: Ramey LLP
• Case Identification: 6:22-cv-01114, W.D. Tex., 10/26/2022
• Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains an established place of business in the district and has allegedly committed acts of infringement there.
• Core Dispute: Plaintiff alleges that unspecified Microsoft products infringe a patent related to methods for managing and validating trusted data flows in a computer network.
• Technical Context: The technology addresses network security and quality of service by providing a system to cryptographically verify that software on an end-user device is behaving according to predefined network rules.
• Key Procedural History: The complaint states that Plaintiff is the assignee of the patent-in-suit, possessing the right to sue for infringement. No other procedural events are mentioned.

Case Timeline

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

• Patent Identification: U.S. Patent No. 7,305,704, "Management of trusted flow system," issued December 4, 2007.
• The Invention Explained:
  • Problem Addressed: The patent identifies a fundamental problem in TCP/IP networks where users can access and modify the very software that is supposed to regulate their network usage, allowing them to overburden the network in ways that are not possible on traditional, centrally controlled telephone networks (e.g., causing denial-of-service attacks or unstable throughput) (’704 Patent, col. 1:16-22; col. 2:34-41).
  • The Patented Solution: The invention proposes a system to ensure that software at an end-station is "trusted" and operating correctly. It uses a "Trusted Flow Generator" (TFG) on the end-user's device, which "interlocks" a standard program (like a TCP protocol handler) with a cryptographic signal generator. This TFG adds a unique, unpredictable "security tag" to data packets. A "Trusted Tag Checker" (TTC) at a network interface (e.g., a firewall) then validates this tag. If the tag is correct, the packet is considered trustworthy and forwarded; if not, it can be dropped or deprioritized, thus enforcing network rules without having to trust the end-user. (’704 Patent, Abstract; Fig. 1; col. 10:7-15).
  • Technical Importance: This approach provides a mechanism for network operators to validate software integrity and enforce performance rules remotely, ensuring that only "well-behaved" applications receive premium service or access to the network. (’704 Patent, col. 5:1-9).
• Key Claims at a Glance:
  • The complaint fails to identify any specific asserted claims, instead referring to an unattached exhibit (Compl. ¶12). Claim 1, as the broadest independent system claim, is representative of the patent's core invention.
  • Independent Claim 1:
    • A system for validating proper execution of software modules on a computing subsystem at a remote location, comprising:
    • means for validating proper execution via messages containing security tags, including a trusted flow generator (TFG) subsystem at a remote network location;
    • at least one validating location with a trusted tag checker (TTC) subsystem;
    • wherein the TFG subsystem locally generates a sequence of security tags responsive only to proper execution of the software module;
    • a communications network coupling the TFG and TTC subsystems;
    • wherein the TFG subsystem's logic is responsive to rules of transmission;
    • wherein the TTC subsystem's logic provides its own sequence of security tags for comparison; and
    • wherein the TTC subsystem validates proper execution by comparing its locally provided security tags against the sequence of security tags received from the TFG subsystem.
  • The complaint does not explicitly reserve the right to assert dependent claims, though this is standard practice.

III. The Accused Instrumentality

• Product Identification: The complaint identifies the accused products only as the "Exemplary Defendant Products" listed in an external "Exhibit B" (Compl. ¶12). This exhibit was not filed with the complaint.
• Functionality and Market Context: The complaint does not provide sufficient detail for analysis of the accused products' functionality or market context.

IV. Analysis of Infringement Allegations

The complaint provides no factual allegations of infringement in its main body, instead incorporating by reference "claim charts of Exhibit B" (Compl. ¶18). As Exhibit B is not publicly available, a substantive analysis of the infringement allegations is not possible.

No probative visual evidence provided in complaint.

V. Key Claim Terms for Construction

The asserted claims appear to heavily rely on means-plus-function language, making the construction of these terms central to the dispute.

• The Term: "means for validating proper execution of respective software modules" (from Claim 1)

• Context and Importance: This term captures the core function of the "checker" side of the invention. The court's interpretation will define the necessary structure an accused product must have to infringe. Practitioners may focus on this term because its construction will determine whether a general-purpose security feature in an accused product is equivalent to the specific structure disclosed in the patent.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the function broadly as a "checking component for the signals" and a mechanism for handling a "trusted flow coming from station that use the combined functionality" (’704 Patent, col. 4:51-56).
  • Evidence for a Narrower Interpretation: The specification discloses a specific corresponding structure: the "Trusted Tag Checker (TTC) Operation" detailed in the flowchart of Figure 9. This structure includes specific steps for receiving a packet (911), computing and checking the security tag (913), and then either discarding (914) or sending (915) the packet based on the check's outcome (’704 Patent, Fig. 9; col. 16:47-65).

• The Term: "compliance logic that generates a valid sequence of security taps responsive only to proper execution of each said respective software module" (from Claim 1)

• Context and Importance: This term defines how the "generator" side of the invention works, linking the creation of a security tag to the correct functioning of the user's software. The scope of "compliance logic" and the strict limitation "responsive only to" will be critical.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the general concept as an "interlocking" of a program with a signal generator to "assure compliance" (’704 Patent, col. 2:10-14). Plaintiff may argue this covers any system that cryptographically ties program execution to packet marking.
  • Evidence for a Narrower Interpretation: A specific embodiment describes interlocking a TCP program with a "cryptographic pseudo-random generator" whose output is placed on data packets (’704 Patent, col. 2:14-22). The "hidden program portion" (414) in Figure 4 is shown generating the security signal. A defendant may argue that "compliance logic" is limited to this specific architecture of a hidden, interlocked cryptographic module.

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, claiming that Microsoft distributes "product literature and website materials inducing end users...to use its products in the customary and intended manner that infringes" (Compl. ¶15). The specific factual support for this allegation is deferred to the unattached Exhibit B (Compl. ¶15).
• Willful Infringement: While not pleaded as a separate count, the complaint alleges that service of the complaint itself provides "actual knowledge of infringement" and that Defendant's continued infringement thereafter supports a finding of willfulness (Compl. ¶14-15). The prayer for relief seeks a declaration that the case is "exceptional" under 35 U.S.C. § 285 (Compl. p. 5).

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

• Evidentiary Sufficiency: A threshold issue for the court will be one of pleading sufficiency: does a complaint that contains no factual allegations of infringement and relies entirely on an unattached exhibit meet the plausibility standard required to survive a motion to dismiss?
• Claim Construction: The case will likely turn on a question of claim construction, specifically the scope of the patent's numerous "means-for" limitations. The outcome will depend on whether the court ties these terms narrowly to the specific algorithms and flowcharts in the specification (e.g., Fig. 9) or interprets them more broadly.
• Architectural Equivalence: A key technical question will be one of architectural equivalence: can the patent's system, which describes distinct "Trusted Flow Generator" and "Trusted Tag Checker" components operating at different network locations, be mapped onto the potentially more integrated software architecture of the accused Microsoft products? The dispute may focus on whether the accused systems contain corresponding, structurally equivalent components or operate in a fundamentally different manner.