Lucio Development LLC v. Cadence Design Systems Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Lucio Development LLC (Texas)
  • Defendant: Cadence Design Systems, Inc. (Delaware)
  • Plaintiff’s Counsel: Kizzia Johnson, PLLC
• Case Identification: 6:19-cv-00033, E.D. Tex., 01/31/2019
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district and has committed acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant’s embedded software development platform infringes a patent related to a generic framework for developing software for modular electronic systems.
• Technical Context: The technology concerns software development frameworks for complex, configurable hardware, such as System-on-a-Chip (SoC) processors, a market where efficient and reusable code is critical.
• 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.

Case Timeline

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

• 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 addresses the engineering challenge of developing embedded software for complex communication systems composed of multiple, different hardware modules or cards. It notes that developers often must "build from scratch specific application handlers for each hardware module," a time-consuming and inefficient process (’546 Patent, col. 4:13-15).
• The Patented Solution: The invention proposes a software development framework built around a set of "generic application handlers" that perform functions common to most hardware modules (e.g., configuration, alarm handling, performance monitoring) (’546 Patent, Abstract; col. 4:15-22). A developer then only needs to create a smaller "specific part" of the code that links these generic functions to the device drivers of a particular hardware module (’546 Patent, col. 7:31-49; Fig. 3A). The generic and specific code parts are then compiled together to create the final executable software for the embedded processor.
• Technical Importance: This approach aimed to reduce development work and improve the maintainability of embedded software by providing a "unified, transparent structure for all the application handlers" across different hardware types (’546 Patent, col. 4:35-37).

Key Claims at a Glance

• The complaint asserts at least independent claim 1.
• Claim 1 recites a method for producing embedded software with three primary steps:
  • Providing one or more "generic application handler programs" with code for functions common to multiple types of hardware modules in a communication system.
  • "Generating specific application handler code" to associate the generic functions with the specific functions of a hardware module's device driver.
  • "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.

III. The Accused Instrumentality

Product Identification

• The complaint names Tensilica's Eclipse-based Xtensa Xplorer Integrated Development Environment (IDE), referred to as "Xtensa," and any similar products (Compl. ¶14).

Functionality and Market Context

• The complaint describes Xtensa as a software development toolkit (SDK) for creating applications for customizable Tensilica dataplane processors (DPUs) (Compl. ¶15). It includes a Graphical User Interface (GUI), a C/C++ compiler, a debugger, and simulators (Compl. p. 4). A key feature is the ability to generate a customized software toolkit that matches a user-configured, custom processor design (Compl. p. 6).
• The accused product provides what the complaint terms "generic" components, such as a Hardware Abstraction Layer (HAL) and a "Library Loader," which are described as being "common and uniform across all supported Xtensa Dataplane Processor[s]" (Compl. ¶15). A diagram in the complaint shows the Xtensa software stack includes a "Hardware Abstraction Layer (HAL)" and a "Library Loader" that sit between the processor and customer applications (Compl. p. 7).

IV. Analysis of Infringement Allegations

’546 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: The patent claims are directed to a framework for "communication systems." A potential issue is whether the accused Xtensa IDE, which is presented as a tool for creating customized processors for a wide range of applications (e.g., imaging, audio, general-purpose DSP), falls within the patent's more specific "communication system" context.
• Technical Questions: A central question will be whether the architecture of the accused Xtensa product maps onto the specific architecture claimed in the patent. The analysis may focus on whether Xtensa's HAL and libraries function as the claimed "generic application handler programs" and, critically, whether the tool's output constitutes "generating specific application handler code to associate" the generic and specific functions, as opposed to simply providing a development environment in which a programmer manually writes such code.

V. Key Claim Terms for Construction

The Term: "generic application handler program"

• Context and Importance: This term is the foundational component of the claimed invention. The outcome of the infringement analysis depends heavily on whether the components of the accused Xtensa product (e.g., its HAL, Library Loader, and other libraries) meet the definition of this term.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification describes these programs as performing "functions that are common to substantially all of the modules in the system, such as configuration, alarm handling, performance monitoring and maintenance" (’546 Patent, col. 4:18-22). This language could support an interpretation covering any software library with functions common across different hardware targets.
  • Evidence for a Narrower Interpretation: The patent consistently provides specific examples of handlers related to system management, such as the "performance monitoring (PM) handler," "alarm handler," and "maintenance handler" (’546 Patent, col. 6:51-60; Fig. 2). A party could argue the term is limited to these types of high-level management handlers and does not read on more fundamental components like a general-purpose Hardware Abstraction Layer or a library loader.

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

• Context and Importance: This limitation defines the crucial link between the generic and specific parts of the framework. Infringement requires showing that the accused tool automates the creation of this "associative" code, rather than merely facilitating its manual creation by a developer. Practitioners may focus on this term because the level of automation is a key technical distinction.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent describes the overall goal as reducing the developer's task to "tying the generic elements invoked by these functions to specific hardware components of the module" (’546 Patent, col. 4:27-30). This focus on simplifying the developer's task could support a broad reading that includes GUI-driven configuration and code generation.
  • Evidence for a Narrower Interpretation: The detailed description outlines a method where a programmer explicitly performs steps like "register a function for each generic element" and "implement specific functions" (’546 Patent, Fig. 3B; col. 8:11-53). This could support a narrower construction requiring the generation of code that performs specific registration or linking actions, which may or may not be present in the accused product's workflow.

VI. Other Allegations

The complaint alleges only direct infringement and does not contain allegations of indirect or willful infringement.

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

• A core issue will be one of definitional scope: can the term "generic application handler program", which is described in the patent with examples like alarm and performance monitors for "communication systems," be construed to cover the Hardware Abstraction Layer and general-purpose software libraries provided by the accused Xtensa toolkit for developing custom SoCs?
• A key evidentiary question will be one of architectural mapping: does the complaint provide sufficient evidence that the accused Xtensa tool "generates specific application handler code" that "associates" generic and specific functions in the manner required by the patent's two-part architecture (generic part + specific part), or does it merely provide a compiler and IDE that a developer uses to manually structure and write such code?