DCT

2:25-cv-01002

Ziedman Tech II LLC v. IBM Corp

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:25-cv-01002, E.D. Tex., 10/07/2025
  • Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains a regular and established place of business in the district and has committed the alleged acts of patent infringement there.
  • Core Dispute: Plaintiff alleges that Defendant’s IBM Engineering Systems Design Rhapsody software infringes three patents related to tools that automatically generate, or "synthesize," source code for real-time operating systems and task management.
  • Technical Context: The technology at issue involves software development tools for creating specialized operating systems used in embedded systems, where efficient management of time-critical tasks within a small memory footprint is essential.
  • Key Procedural History: The complaint notes that Plaintiff is a non-practicing entity that has never sold a product. It also discloses that Plaintiff and its predecessors have entered into settlement licenses with other entities in prior litigation and preemptively addresses patent marking requirements under 35 U.S.C. § 287(a).

Case Timeline

Date Event
1999-05-10 ’947 Patent Priority Date
2003-10-20 ’488 Patent Priority Date
2005-08-23 ’947 Patent Issued
2006-04-25 ’187 Patent Priority Date
2011-02-01 ’488 Patent Issued
2011-03-01 ’187 Patent Issued
2025-10-07 Complaint Filing Date

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 August 23, 2005

The Invention Explained

  • Problem Addressed: The patent’s background section describes a dilemma for developers of real-time systems: using a commercial Real-Time Operating System (RTOS) kernel is robust but can be complex and inefficient in terms of memory, while creating a custom "polling loop" is simpler and more efficient but requires significant manual programming effort and lacks safeguards like deadlock prevention (’947 Patent, col. 1:10-63).
  • The Patented Solution: The invention is a "virtual" RTOS tool that automates the creation of a polling loop. It provides a programmer with specific commands (e.g., "VIRTOS_call", "VIRTOS_wait") to embed in their task source code to manage synchronization. The tool then uses these commands and user-defined task priorities to automatically generate, or "synthesize," the complete task management code, including the polling loop, in a way that prevents deadlocks by design (’947 Patent, Abstract; col. 2:1-9; col. 4:11-22).
  • Technical Importance: This approach sought to provide the efficiency and small footprint of a custom polling loop while incorporating the reliability and automated features, such as deadlock prevention, typically associated with more complex commercial RTOS kernels (’947 Patent, col. 2:1-9).

Key Claims at a Glance

  • The complaint asserts independent claim 1 and dependent claims 2-9 (Compl. ¶19).
  • Independent Claim 1 recites a method with the essential elements of:
    • 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 of said real time tasks.
    • Synthesizing source code for a polling loop that manages the tasks in accordance with the assigned priority.
    • Synthesizing source code for the commands used in the tasks.
    • Converting the synthesized source codes for execution by a computer.

U.S. Patent No. 7,882,488 - "Software Tool for Synthesizing a Real-Time Operating System," Issued February 1, 2011

The Invention Explained

  • Problem Addressed: The patent addresses the need for a tool to develop real-time software for embedded systems, again noting the trade-offs between a full RTOS kernel and a manually created RTOS polling loop, also known as a cyclic executive (’488 Patent, col. 1:15-61).
  • The Patented Solution: The invention is a software tool that automatically generates a real-time operating system. A user defines various software tasks and specifies their properties—such as task type (e.g., initialization, frequency-based, period-based), priority, and timing characteristics—through a graphical user interface. The tool then synthesizes the task management source code that schedules and controls the execution of these tasks, with built-in deadlock prevention (’488 Patent, Abstract; col. 2:1-17). The tool can be optimized for a specific hardware platform or microprocessor (’488 Patent, col. 2:11-14).
  • Technical Importance: The tool enables the creation of an application-specific, optimized RTOS that offers performance advantages and a smaller memory footprint compared to general-purpose commercial RTOSes, which is a key consideration for resource-constrained embedded devices (’488 Patent, col. 2:6-17).

Key Claims at a Glance

  • The complaint asserts independent claim 1 and dependent claims 2-24 (Compl. ¶26).
  • Independent Claim 1 recites a method with the essential elements of:
    • Specifying a set of "n" tasks to be scheduled.
    • Specifying "t" init-tasks that are executed only once upon initial execution of a task scheduler.
    • Using a data processor to synthesize source code from commands embedded in source code to implement the task scheduler for controlling execution of the "n" tasks and the "t" init-tasks.
    • Synthesizing source code from commands embedded in source code to control the execution of the "t" init-tasks.

U.S. Patent No. 7,900,187 - "Using Readily Available Driver and Application Source Code with a Synthesized Operating System," issued March 1, 2011

  • Technology Synopsis: This invention provides a method for adapting readily available or open-source software (such as hardware drivers or applications) for use with a synthesized RTOS. The method involves a tool that automatically searches the existing source code for standard operating system Application Program Interfaces (APIs), such as POSIX thread calls, and replaces them with simpler "primitives" that the synthesis tool can understand. This allows complex, pre-existing code originally written for systems like LINUX to be incorporated into a small, fast, synthesized operating system (’187 Patent, Abstract; col. 1:15-52).
  • Asserted Claims: Independent claim 1 and dependent claims 2-6 are asserted (Compl. ¶33).
  • Accused Features: The complaint alleges that IBM’s software programs and related methods of use practice the methods claimed in the ’187 Patent (Compl. ¶¶ 17, 33).

III. The Accused Instrumentality

Product Identification

The accused instrumentalities are identified as "IBM's software programs as provided at the product website and related methods of use" (Compl. ¶17). This product line is known as IBM Engineering Systems Design Rhapsody.

Functionality and Market Context

The complaint alleges the accused products are software programs but does not describe their specific technical functionality in detail (Compl. ¶17). The product family is generally known in the market as a tool for model-based systems engineering, which often includes features for generating executable code from system models. The complaint asserts that these products are available to businesses and individuals throughout the United States (Compl. ¶23). No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint references preliminary claim charts and tables in Exhibits B, D, and F as support for its infringement allegations (Compl. ¶¶ 20, 27, 34). As these exhibits were not provided with the complaint, the specific mapping of accused functionality to claim elements cannot be analyzed. The complaint’s narrative theory is that by making, using, and selling the Accused Instrumentalities, Defendant’s actions directly infringe the asserted claims (Compl. ¶¶ 19, 26, 33).

  • Identified Points of Contention:
    • Scope Questions: A central dispute may concern the meaning of "synthesizing source code for a polling loop" (’947 Patent) and implementing a "task scheduler" (’488 Patent). The analysis may raise the question of whether the code generation capabilities of IBM's Rhapsody product, which operates on high-level models, fall within the scope of these terms as understood in the context of the patents' specifications.
    • Technical Questions: A key factual question will be how the Accused Instrumentalities actually generate and manage executable code. The complaint does not provide evidence to show that the accused software generates a "polling loop" or a "cyclic executive" as described in the patents, versus, for example, generating code that relies on a pre-existing, third-party RTOS kernel or employs a different scheduling architecture altogether.

V. Key Claim Terms for Construction

For the ’947 Patent

  • The Term: "synthesizing source code for a polling loop"
  • Context and Importance: This term is the central inventive concept of claim 1. The outcome of the case may depend on whether IBM’s code generation process is properly characterized as "synthesizing" a "polling loop." Practitioners may focus on this term because it distinguishes the invention from systems using a conventional RTOS kernel.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes "synthesizing" as a process that "automates the process of creating a polling loop" (’947 Patent, col. 2:1-2). This language could support a construction covering a range of automated code generation techniques that result in a task management structure.
    • Evidence for a Narrower Interpretation: The background explicitly contrasts the invention with a "kernel of a real time operating system (RTOS)" (’947 Patent, col. 1:13-15). The embodiment shown in Figure 6(b) depicts a specific structure where code checks "StateFlag" variables in a sequential loop. This could support a narrower construction limited to the generation of such a flat, state-based polling architecture.

For the ’488 Patent

  • The Term: "synthesize source code from commands embedded in source code to implement the task scheduler"
  • Context and Importance: This phrase defines the core functionality of the claimed method. The dispute will likely involve whether the user-defined models and properties in the accused Rhapsody tool constitute "commands embedded in source code" and whether the resulting generated code is properly defined as a "synthesized...task scheduler."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The summary states the invention "automates the process of creating task management source code" (’488 Patent, col. 1:67-col. 2:2), suggesting a broad scope for the automation process.
    • Evidence for a Narrower Interpretation: The patent describes specific task types like "F-LOOP" (frequency-based) and "P-LOOP" (period-based) that the tool processes (’488 Patent, col. 3:51-54; Figs. 4-5). A defendant could argue this term should be limited to a system that synthesizes a scheduler by directly processing source code containing specific, command-like primitives, rather than translating from a higher-level graphical model.

VI. Other Allegations

  • Indirect Infringement: The complaint includes a general allegation of direct and/or indirect infringement (Compl. ¶3). However, it does not plead specific facts to support the knowledge and intent required for claims of induced or contributory infringement.
  • Willful Infringement: Willfulness is alleged on "information and belief," based on assertions that Defendant "made no attempt to design around the claims" and lacked a reasonable basis to believe the patents were invalid (Compl. ¶¶ 21-22, 28-29, 35-36). The prayer for relief requests a finding of willfulness and enhanced damages if discovery reveals Defendant had pre-suit knowledge of the patents (Compl., Prayer for Relief ¶e).

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

  • A core issue will be one of technical mechanism: Does the code generation architecture of IBM's Rhapsody software function by "synthesizing" a "polling loop" or "task scheduler" from user inputs as claimed in the patents, or does it operate on a fundamentally different principle, such as by generating code that interfaces with a pre-packaged RTOS or uses an event-driven scheduling model not contemplated by the patents?
  • A dispositive question will be one of claim construction: Can the term "synthesizing source code," which in the patents arises from a context of processing embedded commands and user-defined parameters, be construed broadly enough to read on the code generation functions of a modern, model-based systems engineering tool? The court's interpretation of this term will likely determine the scope of the claims and the ultimate question of infringement.