Xueshan Tech Inc v. Renesas Electronics Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Xueshan Technologies, Inc. (Delaware)
  • Defendant: Renesas Electronics Corporation (Japan)
  • Plaintiff’s Counsel: Nelson Bumgardner Conroy PC
• Case Identification: 2:23-cv-00091, E.D. Tex., 03/06/2023
• Venue Allegations: Plaintiff alleges that because Defendant is a foreign corporation not resident in the United States, venue is proper in any judicial district pursuant to the alien-venue rule.
• Core Dispute: Plaintiff alleges that Defendant’s semiconductor products, including various microcontrollers (MCUs), microprocessors (MPUs), and System-on-a-Chip (SoC) devices, infringe five U.S. patents related to firmware updating, interrupt control, image processing, device booting, and power management.
• Technical Context: The technologies at issue relate to fundamental operations in modern embedded systems, governing device reliability, performance, and power efficiency, which are critical features in the highly competitive semiconductor market.
• Key Procedural History: The complaint alleges that Plaintiff attempted to engage Defendant in licensing discussions, sending letters in March 2021, May 2021, and February 2022, which were allegedly ignored. Plaintiff also references a prior lawsuit filed against Defendant (2:22-cv-157). This history is presented to support allegations of willful infringement.

Case Timeline

Date	Event
2003-12-15	’321 Patent Priority Date
2004-10-18	’749 Patent Priority Date
2008-01-04	’565 Patent Priority Date
2008-09-15	’623 Patent Priority Date
2009-02-10	’321 Patent Issue Date
2010-03-30	’749 Patent Issue Date
2012-02-28	’565 Patent Issue Date
2012-07-11	’475 Patent Priority Date
2012-12-11	’623 Patent Issue Date
2015-10-20	’475 Patent Issue Date
2021-03-01	Plaintiff sends first licensing letter to Defendant (approx. date)
2021-05-01	Plaintiff sends second licensing letter to Defendant (approx. date)
2022-02-01	Plaintiff sends third licensing letter to Defendant (approx. date)
2023-03-06	Complaint Filing Date

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

U.S. Patent No. 7,490,321 - "Method for updating firmware via determining program code," issued February 10, 2009

The Invention Explained

• Problem Addressed: The patent addresses the risk of system failure when a firmware update process is interrupted, for example, by a power loss. Prior art methods for ensuring recoverability allegedly required significant extra memory to store a complete backup copy of the firmware or involved performance-degrading checksum calculations. (’321 Patent, col. 1:27-65).
• The Patented Solution: The invention proposes a method that uses a value stored at a specific memory address to act as a status flag. Before an update begins, the flag is set to a value indicating an "in-progress" or "failed" state. Upon successful completion, the flag is changed to a value indicating a "successful" state. At boot-up, an inspection instruction checks this flag; if it indicates success, the main firmware is executed, but if it indicates failure, only the basic boot code runs, allowing the device to safely attempt the update again. (’321 Patent, Abstract; col. 2:6-21).
• Technical Importance: This method provides a simple, low-cost, and memory-efficient mechanism to make embedded systems more robust and recoverable from failed firmware updates, a critical feature for device reliability. (’321 Patent, col. 2:22-34).

Key Claims at a Glance

• The complaint asserts independent Claim 1. (Compl. ¶34).
• The essential elements of Claim 1 are:
  • A method for updating program code in a memory module.
  • Before updating, setting a value at a specific address according to a "second rule" (representing an unsuccessful or in-progress update).
  • Replacing a program segment with a new program segment.
  • After successful updating, setting the value at the specific address according to a "first rule" (representing a successful update).
  • The first and second rules are mutually exclusive and are used to verify the correctness of the updated program code.
• The complaint reserves the right to assert additional claims. (Compl. p. 10, n.1).

U.S. Patent No. 7,689,749 - "Interrupt control function adapted to control the execution of interrupt requests of differing criticality," issued March 30, 2010

The Invention Explained

• Problem Addressed: On a single processor running both "critical" (e.g., real-time communication) and "non-critical" (e.g., user interface) applications, a low-priority but non-critical interrupt can preempt a high-priority critical task, potentially compromising the performance of the entire critical system. (’749 Patent, col. 1:45-54; col. 2:1-6).
• The Patented Solution: The patent describes an interrupt controller that distinguishes between "critical" and "non-critical" interrupts and tasks. The controller ensures that critical interrupts are always passed to the processor with preference over non-critical ones. It is further adapted to block non-critical interrupts from executing when a critical interrupt is pending or when the processor is already busy with a critical task, thereby protecting the integrity of the critical system's operation. (’749 Patent, Abstract).
• Technical Importance: This technology enables the consolidation of real-time systems and more general-purpose "open" operating systems onto a single processor core, which can significantly reduce hardware costs, size, and power consumption in complex devices like smartphones. (’749 Patent, col. 1:35-44).

Key Claims at a Glance

• The complaint asserts independent Claim 1. (Compl. ¶49).
• The essential elements of Claim 1 are:
  • An interrupt control function for a processor that executes tasks of differing criticality.
  • The function recognizes critical and non-critical interrupt requests and recognizes when the processor is executing critical versus non-critical tasks.
  • The function passes critical interrupts to the processor in preference to non-critical interrupts.
  • The function blocks non-critical interrupts when they coexist with critical interrupts or when the processor is executing critical tasks.
  • The function passes non-critical interrupts when no critical interrupts or tasks are active.
• The complaint reserves the right to assert additional claims. (Compl. p. 10, n.1).

U.S. Patent No. 8,125,565 - "Image processing circuit and method thereof," issued February 28, 2012

• Technology Synopsis: The patent discloses an image processing circuit for de-interlacing video fields to create progressive-scan frames. The described solution aims to reduce memory requirements by storing only two previous fields (e.g., n-1 and n-2) and using them in combination with a current incoming field (n) to generate the output frame, as opposed to conventional methods that may require storing entire frames. (’565 Patent, Abstract; col. 2:1-12).
• Asserted Claims: Independent Claim 10 is asserted. (Compl. ¶65).
• Accused Features: The complaint accuses the Renesas RZ/G1 32-bit MPUs, alleging that their image processing circuits (identified as the "FDP1 Block") perform de-interlacing by generating an output frame from a current field, a previous field, and a next field stored in memory. (Compl. ¶¶63, 66-68).

U.S. Patent No. 8,332,623 - "Embedded electronic device and booting method thereof," issued December 11, 2012

• Technology Synopsis: The invention provides a flexible booting method for embedded devices that can load firmware from multiple different sources. The method uses the status of one or more option pins to select a specific "initiation image source sequence table" from boot memory. This table defines a prioritized sequence (e.g., 1. SD Card, 2. NAND, 3. UART) that the microprocessor follows to find and load a valid initiation image. (’623 Patent, Abstract).
• Asserted Claims: Independent Claim 1 is asserted. (Compl. ¶81).
• Accused Features: The Renesas RZ MPU Family is accused of infringement. The complaint alleges these products use a boot mode selection mechanism tied to external pins ("MD_BOOT[2:0]") to choose a boot sequence from a table, which dictates the order of attempts to load firmware from sources like eSD, eMMC, or serial flash memory. (Compl. ¶¶79, 83-84, 87).

U.S. Patent No. 9,166,475 - "Voltage regulator with fast and slow switching control," issued October 20, 2015

• Technology Synopsis: This patent addresses power efficiency in switching voltage regulators, particularly for devices with high-power active modes and low-power sleep modes. The invention describes a regulator with a dual-mode control system: a first control unit with a "fast clock" for efficient high-load operation, and a second control unit with a "slow clock" for efficient light-load operation. A control unit selects the appropriate mode based on the power demand, optimizing efficiency across the entire load range. (’475 Patent, Abstract).
• Asserted Claims: Independent Claim 1 is asserted. (Compl. ¶98).
• Accused Features: Renesas RAA23022x DC/DC Converters are accused. The complaint points to product datasheets describing an "Auto PFM mode" where the device automatically switches between Pulse Width Modulation (PWM) for heavy loads and Pulse Frequency Modulation (PFM) for light loads to achieve high efficiency, which is alleged to map to the claimed invention. (Compl. ¶¶96, 100, 102).

III. The Accused Instrumentality

Product Identification

• The complaint identifies several families of Renesas products, including the RL78 Microcontrollers, Renesas ARM Cortex-M and Cortex-A series processors (RA, RE, Synergy, and RZ Series), Renesas RZ/G1 32-bit MPUs, the broader Renesas RZ MPU Family, and RAA23022x DC/DC Converters. (Compl. ¶¶32, 47, 63, 79, 96).

Functionality and Market Context

• The accused instrumentalities are described as foundational semiconductor components such as MCUs, MPUs, and SoCs. (Compl. ¶2). The complaint alleges that these products incorporate the specific functionalities claimed by the asserted patents, such as firmware update mechanisms, interrupt handling, image processing, boot-up sequences, and power management. Plaintiff characterizes Renesas as a "leading manufacturer and seller" of these components, which are used in a vast array of downstream electronic products. (Compl. ¶2).

IV. Analysis of Infringement Allegations

7,490,321 Patent Infringement Allegations

The complaint references a diagram from a Renesas application note titled "Figure 1-2 Code Flash Memory Map," which depicts the memory organization of an RL78/G23 microcontroller into distinct areas for the user program ("Execute area"), a temporary update area, and boot code sections. (Compl. ¶35).

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
A method for updating program code stored in a memory module having a normal firmware section in an electronic device...	The accused Renesas RL78 Microcontrollers perform a process for "Updating Firmware by Using UART Communication and Boot Swapping."	¶35	col. 13:1-4
before updating a first program segment stored in the memory module, setting values of at least one specific address according to a second rule;	Before copying new firmware, the "Execute area is erased," which initializes a "copy flag" at a specific address to a value other than AAAA5555H. This non-AAAA5555H value represents the "second rule" (update not successful).	¶36	col. 13:13-17
replacing the first program segment stored in the normal firmware section with a second program segment; and	A new program is copied from a "Temporary area" to the "Execute area."	¶37	col. 13:18-22
after successfully updating the first program segment stored in the normal firmware section, setting the values stored in the specific addresses according to a first rule,	If the program is "normally written," the copy flag is set to AAAA5555H. This value represents the "first rule" (update successful).	¶36	col. 13:23-26
wherein the second rule is a mutually exclusive condition of the first rule, the first rule represents that the normal firmware section has been updated successfully, the second rule represents that the normal firmware section has not been updated successfully...	The device checks the copy flag on startup. If the value is AAAA5555H, the update is considered successful. If the value is "not AAAA5555H" (e.g., due to a reset during a write), the update is considered unsuccessful, and the system takes corrective action. This use of the flag is alleged to verify the correctness of the update.	¶38	col. 13:27-36

Identified Points of Contention:

• Technical Question: The claim requires setting the flag "before updating" and "after successfully updating." The infringement allegation relies on an erase operation initializing the flag before the update. The court may need to determine if this initialization by erase constitutes "setting... a value... according to a second rule" in the manner claimed.
• Scope Question: The claim recites that the values are "employed to verify the correctness of updated program code." A question for the court will be whether the accused "copy flag" check, which triggers a rewrite and swap if the flag is not the success value, is a verification of "correctness" as contemplated by the patent, or merely an indicator of completion.

7,689,749 Patent Infringement Allegations

The complaint includes a "Functional block diagram" from an ARM Cortex-M0+ technical manual, which shows the "Nested Vectored Interrupt Controller (NVIC)" as the central component for handling interrupts for the processor core. (Compl. ¶52, p. 21).

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
An interrupt control function adapted to control the execution of interrupt requests of differing criticality by a processor which is required to execute tasks of differing criticality under the control of a computer operating system;	The accused products comprise an ARM processor and an interrupt control function (the NVIC). The ARMv6-M architecture is alleged to define a hierarchy for software operation including a "system level" that supports applications, services interrupts, and handles system events, which constitutes a computer operating system.	¶¶51, 52	col. 10:1-6
the interrupt control function being adapted to recognise critical and non-critical interrupt requests... and to recognise when the processor is required to execute each of critical and non-critical tasks;	The ARMv6-M architecture is alleged to support different exception types with varying levels of criticality. Exceptions like NMI and HardFault are described as having the highest, fixed priorities (critical), while other interrupts have configurable priorities (non-critical). The processor also supports privileged and unprivileged execution modes (critical and non-critical tasks).	¶53	col. 10:12-17
the interrupt control function being further adapted to pass critical interrupt requests to the processor for execution in preference to non-critical interrupt requests,	The ARMv6-M priority model is based on numerical value, where lower numbers have higher precedence. Exceptions like Reset (-3), NMI (-2), and HardFault (-1) are alleged to always have higher priority than any other software-configurable interrupt (which start at 0), thus ensuring their preference.	¶54	col. 10:18-20
to block non-critical interrupt requests to the processor when they coexist with critical interrupt requests or the processor is required to execute critical tasks,	The documentation allegedly states, "When an exception is active, only an exception with a higher priority can preempt it." This is alleged to mean that a non-critical interrupt (lower priority) cannot preempt an active critical one (higher priority).	¶54	col. 10:21-25
and to pass non-critical interrupt requests to the processor when they do not coexist with any critical interrupt requests and the processor has no critical tasks to be executed.	In the absence of active, higher-priority critical interrupts or tasks, the system processes non-critical interrupts according to their own configured priorities.	¶54	col. 10:25-28

Identified Points of Contention:

• Scope Question: Does the term "critical task," as used in the patent, read on the standard architectural privilege levels (e.g., "privileged execution") of a general-purpose ARM processor? The patent's background discusses "fatal" consequences like in flight control systems, raising the question of whether the claimed "criticality" requires a higher standard than what is inherent in a standard processor's exception model.
• Technical Question: What evidence does the complaint provide that the accused products' standard NVIC and ARM architecture "block" non-critical interrupts in the specific manner claimed, versus simply prioritizing them according to a numerical scheme? The analysis will likely focus on whether standard preemption rules equate to the claimed "blocking" function.

V. Key Claim Terms for Construction

’321 Patent

• The Term: "verify the correctness" (Claim 1)
• Context and Importance: This term is central to the purpose of the claimed method. Infringement hinges on whether the accused "copy flag" is used to "verify the correctness" of the firmware or merely to indicate a state of completion/incompletion. Practitioners may focus on this term because its definition will determine if the accused product's functionality meets the claimed functional requirement.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent states that if the flag matches the "second rule" (failure), "the program code stored in the normal firmware section has an error." (’321 Patent, col. 2:18-19). This suggests that checking the flag is equivalent to checking for an error, supporting a broader reading of "verify the correctness."
  • Evidence for a Narrower Interpretation: The detailed description contrasts the invention with prior art that uses checksums to determine correctness. (’321 Patent, col. 1:54-58). A defendant could argue that "verify the correctness" implies a more substantive check of the code's integrity, akin to a checksum, rather than just checking a status bit that indicates whether the write process was interrupted.

’749 Patent

• The Term: "critical" (as in "critical... interrupt requests" and "critical tasks") (Claim 1)
• Context and Importance: The entire inventive concept rests on the functional distinction between what is "critical" and what is "non-critical." The infringement case equates architectural features of ARM processors (e.g., high-priority exceptions, privileged modes) with the claimed "critical" events. The construction of this term will be dispositive for infringement.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent broadly defines the context as any system with "timing critical" processes running alongside "additional applications." (’749 Patent, col. 2:57-63). This could support applying the term to any function whose timely execution is essential for the primary purpose of a device, a standard feature of many embedded systems.
  • Evidence for a Narrower Interpretation: The background section provides specific, high-stakes examples of critical systems: "flight control systems for aircraft; engine management systems," where failure is "fatal." (’749 Patent, col. 1:30-32). A defendant may argue that "critical" should be limited to this narrow class of mission-critical or life-or-death systems, and does not automatically cover the standard exception handling in a general-purpose consumer electronics processor.

VI. Other Allegations

• Indirect Infringement: For each asserted patent, the complaint alleges that Renesas induces infringement by providing customers and subsidiaries with products, datasheets, application notes, user manuals, and technical support that instruct and encourage the use of the accused functionalities. (Compl. ¶¶39, 55, 71, 88, 104).
• Willful Infringement: The complaint alleges willful infringement for all five patents. The basis for this allegation is Defendant's alleged pre-suit knowledge of the patents and infringement via licensing letters sent in 2021 and 2022 and a prior lawsuit, as well as post-suit knowledge from the filing of the instant complaint. (Compl. ¶¶25-26, 40, 56, 72, 89, 105).

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

• A central issue will be one of definitional scope: can terms like "critical task" and "verify the correctness," which are described in the patents with specific functional contexts (e.g., life-or-death systems, integrity checks), be construed to read on the standard, architecturally-defined features of general-purpose commercial processors (e.g., exception priority levels, boot-up status flags)?
• A key evidentiary question will be one of functional equivalence: do the accused products' operations, as described in their own technical manuals, perform the specific steps and achieve the specific outcomes required by the claims? For instance, does the ARMv6-M priority system "block" interrupts in the manner claimed by the ’749 patent, or does it merely preempt them, and is that distinction legally significant?
• A primary strategic question concerns the breadth of the assertion: by asserting five patents covering a wide range of distinct semiconductor technologies against numerous product families, the case raises the question of whether this is a series of targeted technical disputes or a broader portfolio-level licensing effort, a distinction that could shape the entire trajectory of the litigation.