ZT IP LLC v. National Instruments Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: ZT IP, LLC (Texas)
  • Defendant: National Instruments Corp. (Delaware)
  • Plaintiff’s Counsel: Ramey LLP
• Case Identification: 6:22-cv-00437, W.D. Tex., 04/29/2022
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district, conducts substantial business there, and a portion of the alleged infringement occurred in the district.
• Core Dispute: Plaintiff alleges that Defendant’s systems and products for developing real-time operating systems infringe patents related to software tools that automate the creation of real-time task management code.
• Technical Context: The technology at issue involves development tools for real-time operating systems (RTOS), which are essential for controlling hardware in time-critical embedded systems found in industries ranging from automotive to industrial automation.
• Key Procedural History: The complaint is the initiating pleading. U.S. Patent No. 7,882,488 was issued subject to a terminal disclaimer over U.S. Patent No. 6,934,947, which may create a common framework for claim scope and validity analysis across both patents.

Case Timeline

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

U.S. Patent No. 6,934,947 - Visual Tool for Developing Real Time Task Management Code (Issued Aug. 23, 2005)

The Invention Explained

• Problem Addressed: The patent identifies a trade-off in developing real-time systems. Using a commercial Real-Time Operating System (RTOS) kernel can be complex and inefficient, while manually creating a simpler "polling loop" is difficult, error-prone, and can lead to deadlocks where multiple tasks wait for each other indefinitely (’947 Patent, col. 1:10-44).
• The Patented Solution: The invention is a "virtual" RTOS tool that automates the creation of a polling loop. A developer uses a graphical interface and high-level commands (e.g., "VIRTOS_call", "VIRTOS_wait") to define tasks and their interactions (’947 Patent, col. 3:15-4:12). The tool then automatically "synthesizes" the underlying source code for the polling loop and the command functions, aiming to provide the simplicity of a polling loop while preventing deadlocks by design (’947 Patent, col. 2:1-9, col. 5:25-29).
• Technical Importance: The technology sought to simplify real-time software development by providing a higher-level abstraction that generates efficient, specialized task-management code, avoiding the overhead of a general-purpose RTOS kernel (’947 Patent, col. 2:1-9).

Key Claims at a Glance

• The complaint asserts infringement of claims 1-9 (Compl. ¶9).
• Independent Claim 1 recites a method with the following key steps:
  • Providing commands to be used in the source codes of a plurality of real time tasks, designed to provide synchronization.
  • Assigning a priority to each real time task.
  • Synthesizing source code for a polling loop that manages the tasks according to their assigned priority.
  • Synthesizing source code for the provided commands.
  • Converting the synthesized source code for execution by a computer.
• The assertion of claims 2-9 suggests that specific features recited in the dependent claims, such as how tasks are managed, are also at issue.

U.S. Patent No. 7,882,488 - Software Tool For Synthesizing A Real-Time Operating System (Issued Feb. 1, 2011)

The Invention Explained

• Problem Addressed: Similar to its parent patent, the ’488 Patent addresses the need for a development tool that avoids the cost and performance trade-offs between a full off-the-shelf RTOS and a manually coded polling loop for embedded systems (’488 Patent, col. 1:18-56).
• The Patented Solution: The invention is a tool for synthesizing an RTOS. It allows a user to define different types of tasks (e.g., INIT, F-LOOP for frequency-based execution, P-LOOP for period-based execution) and their properties, such as priority, via a graphical user interface (’488 Patent, col. 3:41-4:58). The tool then automatically generates the task management code, insulating the programmer from the complexities of task synchronization and preventing deadlocks (’488 Patent, col. 2:1-20).
• Technical Importance: This approach allows for the creation of a highly optimized, application-specific RTOS with a small memory footprint, which is a critical advantage for resource-constrained embedded systems (’488 Patent, col. 2:6-20).

Key Claims at a Glance

• The complaint asserts infringement of claims 1-24 (Compl. ¶14).
• Independent Claim 1 recites a method with the following key steps:
  • Specifying a set of "n" tasks to be scheduled for execution.
  • Specifying "t" init-tasks that are executed only once.
  • Using a data processor to synthesize source code from commands embedded in source code to implement a task scheduler for controlling the tasks.
  • Synthesizing source code to control the execution of the init-tasks.
• The assertion of a broad range of claims, including other independent claims (7, 13, 19), indicates Plaintiff is targeting both the method of using the tool and the apparatus (the tool itself).

III. The Accused Instrumentality

Product Identification

The complaint does not name specific accused products. It refers generally to Defendant’s "systems, products, and services that facilitate developing real time task management system" and "real time operating system" (Compl. ¶¶9, 14).

Functionality and Market Context

The complaint alleges that Defendant’s instrumentalities are used to develop real-time systems (Compl. ¶¶9, 14). However, it does not provide any specific technical description of how these accused products function or any details regarding their market context. The complaint references Exhibits A and B, which are not included in the filing, as containing support for the infringement allegations (Compl. ¶¶10, 15).

IV. Analysis of Infringement Allegations

The complaint references "exemplary table[s] included as Exhibit A" and "Exhibit B" to provide support for its infringement allegations but does not include these exhibits in the provided court filing (Compl. ¶¶10, 15). In the absence of these exhibits, the infringement theory must be inferred from the high-level narrative allegations.

The complaint alleges that Defendant’s products and services "facilitate developing" systems that infringe the patents-in-suit (Compl. ¶¶9, 14). The core of the infringement theory appears to be that Defendant's software development tools for real-time systems function as the "visual tool" or "software tool" described in the patents, performing the claimed methods of specifying tasks and synthesizing task management code.

No probative visual evidence provided in complaint.

• Identified Points of Contention:
  • Pleading Sufficiency: A primary procedural issue may be whether the complaint’s general allegations, made without identifying specific products or providing the referenced claim charts, meet the plausibility standard for pleading patent infringement established by Twombly and Iqbal.
  • Technical Questions: A key factual question will be whether Defendant’s tools "synthesize" source code for a "polling loop" or "task scheduler" as claimed. The analysis will require determining if the accused tools generate new, executable task-management code from user specifications or if they merely configure a pre-existing, generic scheduler.
  • Scope Questions: The dispute may turn on the scope of "polling loop" (’947 Patent). The court may need to decide if this term is limited to the specific sequential, flag-checking architecture shown in the patent’s figures or if it can read on other scheduling architectures, such as event-driven or data-flow models that may be used in Defendant's products.

V. Key Claim Terms for Construction

’947 Patent

• The Term: "synthesizing source code for a polling loop" (Claim 1)
• Context and Importance: This phrase captures the central inventive concept. The case will likely depend on whether the accused products perform this specific action. Practitioners may focus on this term because its construction will define the boundary between infringing code generation and non-infringing code configuration.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent states the invention "automates the process of creating a polling loop," which could support a construction covering any automated generation of code that cyclically checks and manages tasks (’947 Patent, col. 2:1-2).
  • Evidence for a Narrower Interpretation: The specification and Figure 6(b) illustrate a very specific structure for the synthesized polling loop, involving sequentially checking state flags for each task and branching based on priority (’947 Patent, Fig. 6(b), col. 5:10-24). This could support a narrower definition tied to this particular implementation.

’488 Patent

• The Term: "synthesize source code... to implement the task scheduler" (Claim 1)
• Context and Importance: This is the core action of the claimed method. Infringement will hinge on whether Defendant's tools can be said to "synthesize" a "task scheduler." The definition will be critical to distinguishing the invention from conventional compilers or integrated development environments.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent describes the invention as creating a "'synthesized' RTOS" that automates creating "task management source code," suggesting the term could cover a range of automated code generation techniques for real-time systems (’488 Patent, col. 1:66-2:2).
  • Evidence for a Narrower Interpretation: The detailed description focuses on synthesizing code based on specific user-defined task types like "F-LOOP" and "P-LOOP" (’488 Patent, col. 4:1-29). This could be used to argue that "synthesize" requires a system that generates a scheduler specifically tailored to these defined task types.

VI. Other Allegations

• Indirect Infringement: For the ’488 Patent, the complaint alleges both induced and contributory infringement. It asserts that Defendant encourages infringement by instructing customers on how to use its products and that the products lack substantial non-infringing uses (Compl. ¶¶16, 17).
• Willful Infringement: The complaint alleges that Defendant knew of the ’488 patent "from at least the filing date of the lawsuit" (Compl. ¶¶16, 17), which may support a claim for post-suit willful infringement. For the ’947 patent, willfulness is not directly alleged, but Plaintiff reserves the right to amend its complaint upon discovery of pre-suit knowledge (Compl. p. 3, fn. 1). The prayer for relief seeks a finding of willfulness for infringement of both patents (Compl. p. 6, ¶e).

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

1. Pleading and Proof: The immediate question is procedural: does the complaint, which omits specific product names and fails to include its own referenced evidentiary exhibits, provide sufficient factual detail to state a plausible claim? Beyond the pleadings, a central evidentiary challenge for the Plaintiff will be to map the functionality of any accused National Instruments product onto the specific "synthesis" steps of the patent claims.
2. Definitional Scope: A core issue will be one of claim construction: can the term "synthesizing source code for a polling loop" be construed to cover the operation of a sophisticated, configurable software environment like those offered by Defendant, or is it limited to the de novo generation of a specific, standalone code structure as depicted in the patents' embodiments?
3. Technical Mismatch: A key technical question will be one of operational principle: do the accused products function by "synthesizing" a "task scheduler" in the manner claimed, or do they rely on an alternative, fundamentally different architecture for managing real-time tasks (e.g., a data-flow execution model) that does not align with the claimed methods?