1:17-cv-01154
Lucio Development LLC v. NVIDIA Corp
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Lucio Development LLC (Texas)
- Defendant: NVIDIA Corporation (Delaware)
- Plaintiff’s Counsel: Kizzia Johnson, PLLC
- Case Identification: 1:17-cv-01154, W.D. Tex., 12/11/2017
- Venue Allegations: Venue is alleged to be proper in the Western District of Texas because Defendant has a regular and established place of business in the district and acts of infringement are allegedly occurring there.
- Core Dispute: Plaintiff alleges that Defendant’s NVIDIA Capture SDK, a software development kit for graphics processing, infringes a patent related to a generic framework for embedded software development.
- Technical Context: The technology at issue concerns software frameworks that aim to simplify and standardize the development of applications for specialized hardware, such as graphics processing units (GPUs).
- 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
| Date | Event |
|---|---|
| 2001-12-03 | ’546 Patent Priority Date |
| 2006-06-27 | ’546 Patent Issue Date |
| 2017-12-11 | Complaint Filing Date |
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 systems containing multiple, different hardware modules (e.g., electronics cards). It notes that developers often must build specific "application handlers" (software to manage configuration, performance, alarms, etc.) from scratch for each new type of hardware, a time-consuming and inefficient process. (’546 Patent, col. 1:16-2:65).
- The Patented Solution: The invention proposes a method and framework that separates software development into two parts: a "generic part" containing application functions common to all hardware modules, and a "specific part" written by a developer to link those generic functions to the device driver of a particular hardware module. (’546 Patent, Fig. 3A; col. 7:31-50). These two parts are then compiled together to create the final executable code, providing a standardized and reusable structure for software development. (’546 Patent, col. 8:65-68).
- Technical Importance: This architectural approach aims to reduce development effort and improve the maintainability of embedded software by creating a unified, transparent structure for application handlers across disparate hardware platforms. (’546 Patent, col. 3:5-11, 35-44).
Key Claims at a Glance
- The complaint asserts at least independent claim 1. (Compl. ¶13).
- Independent Claim 1: A method for producing embedded software, comprising the steps of:
- providing one or more generic application handler programs, each such program comprising computer program code for performing generic application functions common to multiple types of hardware modules used in a communication system;
- generating specific application handler code to associate the generic application functions with specific functions of a device driver for at least one of the types of the hardware modules, wherein generating the specific application handler code comprises defining a specific element in the specific application handler code to be handled by one of the generic application functions for the at least one of the types of the hardware modules, and registering one of the specific functions of the device driver for use in handing the defined specific element; and
- compiling the generic application handler programs together with the specific application handler code to produce machine-readable code to be executed by an embedded processor in the at least one of the types of the hardware modules.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
- The NVIDIA Capture SDK and any similar products. (Compl. ¶14).
Functionality and Market Context
- The accused product is a software development kit (SDK) that provides tools for developers to create software for multiple hardware modules, specifically NVIDIA GPUs. (Compl. ¶15). The SDK includes Application Programming Interfaces (APIs) such as NVIDIA Framebuffer Capture (NVFBC) and NVIDIA Inband Frame Readback (NVIFR), which are described as providing common, uniform functionality across a plurality of supported NVIDIA GPUs. (Compl. ¶16). A diagram in the complaint illustrates how these APIs interface between an application, a graphics engine, and system memory. (Compl. p. 4, "NVIDIA Capture SDK Interfaces"). The complaint alleges that developers use the SDK and associated compilers (like the CUDA compiler) to create applications that interact with specific GPU hardware. (Compl. ¶19).
- The complaint alleges the product is a "framework" for creating embedded software that targets multiple operating systems (Linux, Windows, Mac) and various GPU hardware modules (NVIDIA Quadro, Tesla). (Compl. ¶15).
IV. Analysis of Infringement Allegations
’546 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| providing one or more generic application handler programs... for performing generic application functions common to multiple types of hardware modules... | The NVIDIA Capture SDK allegedly provides generic application handler programs like NVFBC and NVIFR, which include code and libraries that are common and uniform across multiple supported NVIDIA GPUs. | ¶16 | col. 7:35-43 |
| generating specific application handler code to associate the generic application functions with specific functions of a device driver... | The NVIDIA Capture SDK allegedly includes specific application handler code for particular applications (e.g., on Windows, Linux) and specific GPU hardware (e.g., display heads, drivers). | ¶17 | col. 7:43-50 |
| wherein generating the specific application handler code comprises defining a specific element in the specific application handler code to be handled by one of the generic application functions... and registering one of the specific functions of the device driver for use in handing the defined specific element... | The complaint alleges the SDK generates system-specific code by defining elements like NVFBC and NVIFR "objects" for individual GPU display heads. It further alleges that when specific functions are written to handle these elements, they must be registered, pointing to code examples for creating and using these objects. A diagram illustrates the association of NVFBC objects with specific GPU display heads. | ¶18, p. 7 (Fig. 3), p. 9 | col. 8:1-17 |
| compiling the generic application handler programs together with the specific application handler code to produce machine-readable code... | NVIDIA and/or its customers allegedly compile the generic and specific functions together using the NVIDIA Capture SDK, CUDA compiler, or other supported IDEs to yield machine-readable code. A diagram from NVIDIA's documentation shows this compilation trajectory. | ¶19, p. 10 (Fig. 1) | col. 8:65-68 |
- Identified Points of Contention:
- Scope Questions: A potential issue is whether the term "embedded software" for "communication systems" as described in the patent (’546 Patent, col. 1:19-25) can be interpreted to cover a software development kit for high-performance graphics capture on general-purpose computing systems.
- Technical Questions: The core of the dispute may turn on whether the accused SDK's method of creating and using API "objects" (Compl. p. 9) meets the claim requirement of "registering one of the specific functions of the device driver." The patent specification provides examples of explicit registration function calls (e.g.,
setAlarmFunction,setSelfTestElement) (’546 Patent, col. 8:21-48), raising the question of whether the object-oriented instantiation and method calls in the accused product are technically and legally equivalent to this claimed step. - Act of Infringement: The claim is for a method of "producing embedded software," which includes steps of "generating" and "compiling." A key question will be identifying the infringing actor. The complaint alleges NVIDIA infringes by "making, using, importing, selling, and/or offering for sale" the SDK. (Compl. ¶13). The court may need to determine whether providing the SDK constitutes performing the claimed method steps, or whether the developers who use the SDK to write and compile code are the ones performing them.
V. Key Claim Terms for Construction
The Term: "generating specific application handler code"
Context and Importance: This term is critical because it relates directly to the act of infringement. The dispute may focus on whether the NVIDIA Capture SDK itself "generates" code, or whether it is merely a tool that enables a third-party developer to write (i.e., generate) the code. Practitioners may focus on this term because its construction could determine whether NVIDIA is a direct infringer.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent describes the developer's role as "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). This could suggest that "generating" encompasses the manual coding process facilitated by the framework.
- Evidence for a Narrower Interpretation: The patent's background discusses prior art tools that use a "wizard to produce software code." (’546 Patent, col. 2:42-43). This could support a narrower construction where "generating" requires the automated creation of source code by the accused tool itself, not manual writing by a developer.
The Term: "registering one of the specific functions of the device driver"
Context and Importance: The infringement allegation hinges on showing that the accused SDK performs this specific technical step. The complaint points to code for creating an "NVIFR object" as evidence of this step. (Compl. p. 9). The definition of "registering" will determine if this activity meets the claim limitation.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states that the goal is to "link the standard functions and parameters of generic part 60 with the specific device driver." (’546 Patent, col. 7:45-48). This broader purpose could support an interpretation where any form of linking, including object-oriented instantiation that associates a specific hardware resource with a set of functions, constitutes "registering."
- Evidence for a Narrower Interpretation: The patent provides specific examples of registration, such as
setAlarmFunction(HANDLER_ALARM_DUMMY1_ON, (void*)AlarmFunctionOneOn);. (’546 Patent, col. 8:43-45). This could support a narrower definition requiring an explicit call to a registration-type function that passes a function pointer or similar handle, as opposed to merely creating an object instance.
VI. Other Allegations
- Indirect Infringement: The complaint does not plead a separate count for indirect infringement.
- Willful Infringement: The complaint does not contain allegations of pre- or post-suit knowledge of the patent and does not explicitly plead willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
This case appears to center on fundamental questions of claim scope and technical equivalence, which are common in software patent litigation. The key questions for the court will likely be:
A central question of definitional scope: Can the claims, which are rooted in the context of "embedded software" for "communication systems" with distinct hardware cards, be construed to cover a modern software development kit for creating high-performance graphics applications on systems with GPUs?
A key question of technical equivalence: Does the accused SDK's object-oriented programming model—where a developer instantiates an API object to interact with hardware—perform the same function, in the same way, to achieve the same result as the explicit function "registering" described and claimed in the ’546 Patent?
A critical question of infringing action: Who performs the claimed method of "producing" software? Does NVIDIA directly infringe by providing the SDK and compilers, or is the allegedly infringing conduct performed by third-party developers, raising questions about whether direct infringement has been adequately pleaded against the named defendant?