Embedded Software LLC v. Synopsys Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Embedded Software LLC (Delaware)
  • Defendant: Synopsys, Inc. (Delaware)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:20-cv-00292, E.D. Tex., 09/02/2020
• Venue Allegations: Venue is asserted based on Defendant allegedly committing acts of patent infringement in the district and maintaining an established place of business in the district.
• Core Dispute: Plaintiff alleges that Defendant’s unspecified software development products infringe a patent related to a generic framework for creating embedded software.
• Technical Context: The technology involves a software architecture designed to streamline the development of embedded systems by providing a set of reusable, generic code modules that are then linked to hardware-specific code.
• Key Procedural History: The complaint does not reference any prior litigation, inter partes review (IPR) proceedings, or licensing history related to the patent-in-suit.

Case Timeline

Date	Event
2001-12-03	’546 Patent Priority Date
2006-06-27	’546 Patent Issue Date
2020-09-02	Complaint Filing Date

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

U.S. Patent No. 7,069,546 - "Generic framework for embedded software development"

• Patent Identification: U.S. Patent No. 7,069,546, "Generic framework for embedded software development," issued June 27, 2006.

The Invention Explained

• Problem Addressed: The patent describes the development of embedded software for complex systems, such as electronics cards in communication networks, as a "major engineering task" ('546 Patent, col. 2:32-34). A key challenge is that developers often must "build from scratch specific application handlers for each hardware module," a time-consuming and inefficient process (col. 3:13-16).
• The Patented Solution: The invention proposes a framework to simplify this process by providing a set of "generic application handlers" that perform functions common to most hardware modules, such as configuration, alarm handling, and performance monitoring (col. 3:18-23). The framework separates this reusable "generic part" from a "specific part," which is the only portion a developer needs to write to link the generic functions to the device drivers of a particular hardware module ('546 Patent, col. 7:34-49; Fig. 3A).
• Technical Importance: This architectural separation is intended to reduce development work for new hardware and enhance the maintainability of the software by creating a "unified, transparent structure for all the application handlers" ('546 Patent, col. 3:35-38).

Key Claims at a Glance

• The complaint does not explicitly identify which claims it asserts, instead incorporating by reference claim charts from an exhibit not attached to the publicly filed document (Compl. ¶17). Analysis of the patent suggests that independent claim 1, a method claim, is a likely candidate for assertion.
• Independent Claim 1 of the ’546 Patent recites the following essential elements for a method of producing embedded software:
  • providing one or more generic application handler programs, each comprising code for performing generic functions common to multiple types of hardware modules;
  • generating specific application handler code to associate the generic functions with specific functions of a device driver for one of the hardware module types; and
  • compiling the generic and specific code together to produce machine-readable code for an embedded processor.
• The complaint does not explicitly reserve the right to assert dependent claims, but infringement allegations are made as to "one or more claims" (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products. It refers generally to "Defendant products" and "Exemplary Defendant Products" that are purportedly identified in an unattached exhibit (Compl. ¶11, ¶17).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality. It makes the conclusory allegation that the "Exemplary Defendant Products practice the technology claimed by the '546 Patent" (Compl. ¶17). No description of the products' operation, architecture, or market context is provided in the pleading.

IV. Analysis of Infringement Allegations

The complaint references a claim-chart exhibit that is not provided, so a detailed element-by-element analysis cannot be conducted based on the pleading. The infringement theory is summarized below.

The complaint alleges that Defendant directly infringes the ’546 Patent by "making, using, offering to sell, selling and/or importing" the accused products (Compl. ¶11). The core of the infringement theory, as stated in the pleading, is that the "Exemplary Defendant Products practice the technology claimed by the '546 Patent" and that these products "satisfy all elements of the Exemplary '546 Patent Claims" (Compl. ¶17). The complaint also alleges direct infringement through internal use, stating Defendant's "employees internally test and use these Exemplary Products" (Compl. ¶12). Without the referenced exhibit, the specific mapping of product features to claim limitations is unknown.

• Identified Points of Contention:
  • Scope Questions: Claim 1 is a method for producing embedded software. A central question will be whether Defendant’s alleged acts of "making" or "using" its products constitute performance of all steps of this method claim. The complaint's allegations may raise questions about whether Defendant performs the claimed "generating" and "compiling" steps.
  • Technical Questions: A key technical dispute will likely concern whether the accused products' software architecture actually embodies the "generic application handler" and "specific application handler" structure required by the claims. The complaint provides no technical facts to support the existence of this specific architectural division in Defendant's products.

No probative visual evidence provided in complaint.

V. Key Claim Terms for Construction

The Term: "generic application handler program"

• Context and Importance: This term is foundational to the claimed invention. Its construction will determine how closely an accused software architecture must match the patent's specific embodiments to infringe. Practitioners may focus on this term because its scope dictates whether any reusable software module could be considered "generic" or if it must conform to the specific handler types described in the patent.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification describes these programs as performing "generic application functions common to multiple types of hardware modules" (col. 11:50-53). This could be argued to encompass a wide range of software modules with reusable code.
  • Evidence for a Narrower Interpretation: The patent provides specific examples, such as a performance monitoring handler, alarm handler, configuration handler, and maintenance handler, which interact in a structured way through a defined API ('546 Patent, Fig. 2; col. 6:51-64). This could support an argument that the term is limited to this particular type of modular framework.

The Term: "generating specific application handler code to associate"

• Context and Importance: The definition of how the "generic" and "specific" parts are associated is critical for determining whether an act of infringement has occurred. The dispute may center on whether this requires a specific, structured process as outlined in the patent, or if any act of writing linking code suffices.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification describes this step as a developer "produc[ing] a specific part of the application handler, linking the generic application functions to the specific device driver" ('546 Patent, col. 3:30-33), which could be interpreted as a general manual coding task.
  • Evidence for a Narrower Interpretation: The patent describes a more structured process where a developer must "register a function for each generic element" and then "implement specific functions" ('546 Patent, Fig. 3B, steps 65-66). This may support a narrower construction requiring a formal registration mechanism.

VI. Other Allegations

• Indirect Infringement: The complaint alleges both induced and contributory infringement. The inducement claim is based on Defendant allegedly selling products to customers and distributing "product literature and website materials inducing end users" to use the products in an infringing manner (Compl. ¶14-15). The contributory infringement claim asserts that the accused products "are not a staple article of commerce suitable for substantial noninfringing use" (Compl. ¶16).
• Willful Infringement: The complaint does not use the term "willful," but it alleges that service of the complaint constitutes "actual knowledge" and that Defendant's continued infringement is therefore post-suit, which could form the basis for an enhancement of damages (Compl. ¶13-14). The prayer for relief requests that the case be declared "exceptional," which is consistent with a willfulness theory (Compl., p. 5).

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

• Pleading Sufficiency: A threshold issue is whether the complaint, which outsources all substantive infringement allegations to an unattached exhibit, provides sufficient factual detail to state a plausible claim for relief under the Iqbal/Twombly pleading standard.
• Method Infringement: A central question will be one of accused conduct vs. claim scope: can Plaintiff prove that Defendant’s actions of "making" or "using" its software products constitute direct infringement of the asserted method claims, which recite specific steps for producing embedded software? Proving that Defendant itself performs every claimed step will be critical.
• Architectural Correspondence: A key evidentiary question will be one of technical equivalence: does the architecture of the accused software possess the distinct "generic" and "specific" components as claimed, or is the infringement allegation based on a recharacterization of a software design that is fundamentally different from the one disclosed in the ’546 Patent?