DCT

6:24-cv-00371

Foras Tech Ltd v. Bayerische Motoren Werke AG

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 6:24-cv-00371, E.D. Va., 03/06/2024
  • Venue Allegations: Plaintiffs assert venue is proper because the Defendant is an entity that does not reside in the United States and may therefore be sued in any judicial district.
  • Core Dispute: Plaintiffs BMW and Bosch seek a declaratory judgment that they do not infringe, and that the claims are invalid, for a patent owned by Defendant Foras related to fault-tolerant microprocessor systems.
  • Technical Context: The technology concerns methods for ensuring computer system reliability by using paired "lockstep" processors, and specifically, for recovering from errors in such systems without requiring a complete system crash.
  • Key Procedural History: This declaratory judgment action follows a patent infringement lawsuit filed by Foras against BMW and Bosch on May 19, 2023, in the Western District of Texas. BMW and Bosch assert in this action that the Texas court lacks personal jurisdiction over them. The complaint also notes that BMW and Bosch filed a petition for Inter Partes Review (IPR) against the patent-in-suit on September 8, 2023.

Case Timeline

Date Event
2004-10-25 '958 Patent Priority Date
2009-03-10 '958 Patent Issue Date
2023-05-19 Foras files infringement lawsuit against BMW/Bosch in W.D. Texas
2023-09-08 BMW/Bosch file IPR petition against the '958 Patent
2024-03-06 BMW/Bosch file this Declaratory Judgment Complaint

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

U.S. Patent No. 7,502,958 - "System and Method for Providing Firmware Recoverable Lockstep Protection," issued March 10, 2009

The Invention Explained

  • Problem Addressed: In high-reliability computing, "lockstep" systems use paired processors that perform identical operations and compare results to detect errors. A key problem is that a detected error, or "loss of lockstep" (LOL), traditionally forces a complete system crash to prevent the propagation of corrupted data. For large, multi-processor systems where transient errors (e.g., from cosmic rays) are more common, frequent crashes are highly undesirable and impact system availability (’958 Patent, col. 1:40-53, col. 3:5-15).
  • The Patented Solution: The patent describes a firmware-based method to manage and recover from a loss of lockstep without crashing the entire system. Upon detecting an error, the firmware determines if the error is recoverable. If so, it interacts with the operating system (OS) through a standard interface (like ACPI) to temporarily "idle" the faulty processor pair. The firmware then attempts to reset and re-synchronize the processors to recover lockstep. Once recovered, the firmware signals the OS to recognize the processor pair as available for use again, allowing the system to continue operating seamlessly (’958 Patent, Abstract; Fig. 6; col. 6:40-65).
  • Technical Importance: This approach aims to increase the "high availability" of complex computer systems by treating certain processor errors as transient, recoverable events rather than catastrophic failures requiring a system-wide halt (’958 Patent, col. 3:5-11).

Key Claims at a Glance

  • The complaint identifies independent claims 1, 13, 19, and 23, and focuses its non-infringement arguments on claim 19 (Compl. ¶¶13, 18, 24).
  • Independent Claim 19 (System Claim): The essential elements of this system claim include:
    • A pair of lockstep processors.
    • Computer-executable firmware code stored to a computer-readable medium.
    • Firmware code for determining if the lockstep is recoverable, which includes determining if a lockstep mismatch has occurred.
    • Firmware code, responsive to determining recoverability, for triggering an operating system to idle the processors.
    • Firmware code for attempting to recover lockstep between the pair of processors.
    • Firmware code for, if lockstep is successfully recovered, triggering the operating system to recognize the processors as being available for receiving instructions.
  • The complaint notes that Plaintiffs reserve the right to assert additional non-infringement grounds against other claims (Compl. ¶30).

III. The Accused Instrumentality

Product Identification

  • The complaint identifies the accused instrumentalities as BMW-branded automobiles (models X3, X4, and X5) that incorporate Bosch electronic control units (ECUs). These ECUs, in turn, contain Infineon TriCore TC29XX chipsets (Compl. ¶¶15, 17).

Functionality and Market Context

  • The complaint alleges that Foras's infringement claims are directed at the functionality of the Bosch ECUs containing the Infineon chipsets (Compl. ¶18). The core of the dispute centers on the error-handling and processing logic within these automotive microprocessor systems. The complaint does not provide further technical detail on the operation of the accused ECUs beyond denying that they perform the functions claimed in the '958 Patent. No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint seeks a declaratory judgment of non-infringement. It outlines its non-infringement position by directly refuting that its products meet several "firmware code" limitations of exemplary independent claim 19.

'958 Patent Infringement Allegations

Claim Element (from Independent Claim 19) Alleged Infringing Functionality Complaint Citation Patent Citation
firmware code, responsive to detection of loss of lockstep between the pair of lockstep processors, for determining if the lockstep is recoverable for the pair of lockstep processors, wherein said firmware code for determining if the lockstep is recoverable further comprises firmware code for determining if a lockstep mismatch has occurred between the pair of lockstep processors Plaintiffs assert that the Bosch ECUs with Infineon chipsets do not include "firmware code...for determining if the lockstep is recoverable" or "firmware code for determining if a lockstep mismatch has occurred." ¶¶25, 26 col. 16:30-39
firmware code, responsive to determining that the lockstep is recoverable, for triggering an operating system to idle the processors, attempting to recover lockstep between the pair of processors Plaintiffs assert that the accused products do not include "firmware code, responsive to determining that the lockstep is recoverable, for triggering an operating system to idle the processors, attempting to recover lockstep between the pair of processors." ¶27 col. 16:40-44
and if lockstep is successfully recovered between the pair of processors, triggering said operating system to recognize the processors as being available for receiving instructions. Plaintiffs assert that the accused products do not include "firmware code for...triggering said operating system to recognize the processors as being available for receiving instructions." ¶28 col. 16:45-49
  • Identified Points of Contention:
    • Technical Question: The primary dispute appears to be factual: does the code resident on the Infineon TriCore TC29XX chipsets, as used in Bosch ECUs, actually perform the specific sequence of determining recoverability, triggering the OS to idle, recovering lockstep, and triggering the OS to re-recognize the processors, as claimed? The complaint's position is that it does not (Compl. ¶¶25-29).
    • Scope Questions: The case raises the question of whether the functions that are present in the accused chipsets fall within the scope of the claim term "firmware code." The dispute will likely involve differentiating between firmware, operating system software, and hardwired logic, and determining which of these the patent claims cover.

V. Key Claim Terms for Construction

  • The Term: "firmware code"
  • Context and Importance: This term appears repeatedly in the dispositive limitations of claim 19. The Plaintiffs' entire non-infringement argument, as laid out in the complaint, is that their products lack "firmware code" for performing the claimed functions (Compl. ¶¶25-28). The definition of this term will be critical to determine whether the software or logic in the accused Infineon chipsets meets these limitations. Practitioners may focus on this term because its scope relative to other types of code (e.g., OS-level, application-level) or hardware logic is central to the infringement analysis.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes "firmware" as potentially including multiple layers, such as a Processor Abstraction Layer (PAL) and a System Abstraction Layer (SAL), which interface between the hardware and the operating system (’958 Patent, col. 7:29-44, Fig. 2). This could support a construction that includes various forms of low-level code that are not part of the main OS.
    • Evidence for a Narrower Interpretation: The patent consistently depicts "firmware" as a distinct entity that interacts with, but is separate from, the "operating system" (’958 Patent, Fig. 1). The claims require the "firmware code" to "trigger" the operating system, suggesting two separate components. This could support a narrower construction where code that is considered part of the operating system itself would not qualify as the claimed "firmware code."

VI. Other Allegations

  • Indirect Infringement: Plaintiffs seek a declaratory judgment of non-infringement for both direct and indirect infringement (Compl. ¶29). The complaint does not detail the specific factual allegations Foras may have made to support indirect infringement claims in the underlying Texas litigation.
  • Invalidity: Plaintiffs allege that all claims of the '958 Patent are invalid under 35 U.S.C. §§ 101, 102, 103, and 112 (Compl. ¶34). They specifically incorporate by reference an IPR petition they filed (IPR2023-01373) as well as invalidity contentions from a separate case involving Foras and Kia, alleging invalidity over various prior art references and combinations (Compl. ¶¶35, 36, 39, 40).

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

  • A central issue will be one of claim construction: how should the term "firmware code" be defined? The outcome will likely depend on whether the court construes this term to be strictly limited to code separate from the operating system, or more broadly to include various forms of low-level logic present in the accused chipset.
  • A key evidentiary question will be one of technical operation: assuming a definition for "firmware code," does the accused Infineon chipset actually execute the complete, multi-step recovery process recited in claim 19? This will require a detailed factual analysis comparing the patent's claimed method against the real-world functionality of the accused automotive electronics.
  • The case is framed by a jurisdictional dispute: the existence of this declaratory judgment action in Virginia is predicated on the Plaintiffs' belief that the initial lawsuit in Texas is improper. While not a patent law question, the resolution of the jurisdictional and venue challenges will dictate where and how these substantive patent questions are ultimately decided.