DCT

4:25-cv-05421

Empi Inc v. Integrated Engineering LLC

Log In
Key Events
Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 4:25-cv-05421, N.D. Cal., 06/27/2025
  • Venue Allegations: Plaintiffs allege venue is proper in the Northern District of California because Defendant initially sent a cease and desist letter asserting patent infringement to an EMPI executive located in the district.
  • Core Dispute: Plaintiffs seek a declaratory judgment that Defendant’s U.S. Patent No. 12,112,159, related to updating vehicle computer modules, is invalid as anticipated and/or rendered obvious by prior art.
  • Technical Context: The dispute is in the automotive aftermarket sector, specifically concerning performance tuning, where software updates are delivered to a vehicle's Engine Control Unit (ECU) via the On-Board Diagnostics (OBD-2) port.
  • Key Procedural History: The complaint notes that this declaratory judgment action follows a cease and desist letter from Defendant Integrated Engineering (IE) and a separate lawsuit IE filed in the Central District of California against a third party. The complaint alleges that IE prosecuted the patent-in-suit without submitting any prior art references to the U.S. Patent and Trademark Office in an Information Disclosure Statement (IDS), a fact Plaintiffs characterize as unusual.

Case Timeline

Date Event
2012 Priority date year for U.S. Patent No. 9,128,798 (cited as primary prior art)
2023-10-29 Priority Date for ’159 Patent
2024-10-08 U.S. Patent No. 12,112,159 Issues
2025-02-15 Defendant (IE) sends cease and desist letter to Plaintiff (EMPI)
2025-04-28 Defendant (IE) files infringement suit against a third party in C.D. Cal.
2025-06-27 Complaint for Declaratory Judgment of Invalidity Filed

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

U.S. Patent No. 12,112,159 - "System and Methods for Staging Data and Updating Vehicle Modules Using Staged Data"

The Invention Explained

  • Problem Addressed: The patent's background section identifies the risk of damaging a vehicle's computer modules or systems during the software update process if the byte-level data being written is not precisely correct or timely, potentially causing the module to shut down or fail (’159 Patent, col. 1:25-34).
  • The Patented Solution: The invention is a two-part system for updating vehicle modules. It consists of a user's device (e.g., a smartphone) and a separate "programming device" (e.g., a smart dongle) that connects to the vehicle's onboard port. The user device receives a re-program file from a server and sends it to the dongle in a "defined sequence of messages." The dongle's key function is to receive this data, store it in a local cache, and perform verification checks (e.g., checksums) before directly re-programming the vehicle module. This "staging" process is intended to ensure data integrity and reduce failures caused by data transmission errors between the user's device and the vehicle (’159 Patent, Abstract; col. 3:35-50).
  • Technical Importance: This approach aims to improve the reliability of aftermarket vehicle tuning by isolating the potentially error-prone wireless communication (e.g., Bluetooth from a phone) from the critical, direct-write process to the vehicle's sensitive electronic modules (’159 Patent, col. 4:26-34).

Key Claims at a Glance

  • The complaint focuses its invalidity analysis on independent claim 1 (Compl. ¶27).
  • Essential elements of Claim 1 include:
    • A system with a "user interface device" and a separate "programming device".
    • The "user interface device" is configured to receive a re-program file from a server and display a GUI to initiate the process.
    • The "programming device" physically couples to an "onboard port" of the vehicle.
    • The "programming device" communicates with the "user interface device" (wired or wireless).
    • The "programming device" is configured to receive data from the user device via a "defined sequence of messages" and store it in a "local cache".
    • The stored data includes combinations of "data checksum map metadata", "protocol map metadata", and other "mapping-and-byte data".
    • In response to an instruction, the "programming device" re-programs the module using this stored data.
    • After determining a "checksum condition is satisfied", the "programming device" transmits a success message to the "user interface device".
  • The complaint seeks a declaration that all claims of the patent are invalid (Compl. Prayer for Relief ¶A).

III. The Accused Instrumentality

Product Identification

  • The complaint states that Defendant IE accused Plaintiffs' "034SPI Mobile Flashing Application, smart dongle, or infringing methods of delivering software products" of infringement (Compl. ¶6). The complaint also references "Dynamic+ Performance Software" and "Dynamic+ Tuning Suite" as accused products (Compl. ¶9).

Functionality and Market Context

  • The complaint alleges that Plaintiff EMPI is a supplier of European automotive performance parts and accessories, and that IE and EMPI's 034Motorsport brand "compete directly as providers of ECU tuning software and updates" (Compl. ¶6, ¶14). The products appear to comprise a system for users to apply performance-enhancing software updates to their vehicles, which is the subject of the patent-in-suit.

IV. Analysis of Invalidity Allegations

The complaint does not allege infringement. Instead, it alleges that Claim 1 of the ’159 Patent is invalid because it is anticipated by U.S. Patent No. 9,128,798 ("the '798 Patent"), which issued in 2015 (Compl. ¶29, ¶44). The core of the complaint is a mapping of the '159 Patent's claim elements to the teachings of the '798 Patent.

'159 Patent Invalidity Allegations (based on U.S. Patent No. 9,128,798)

Claim Element (from Independent Claim 1) Alleged Prior Art Teaching ('798 Patent) Complaint Citation Prior Art Patent Citation
a user interface device... configured to: receive and store a re-program file from a server; and display a graphical user interface... The '798 patent discloses a Human-Machine Interface (HMI) on the vehicle dashboard that receives a "new file" from a server and displays information to the user. Figure 2 of the prior art patent shows this HMI. ¶33, ¶35, ¶37 ('798 Patent) 4:2-8
a programming device configured to be physically and communicably coupled to an onboard port of the vehicle... The '798 patent's "controller 20" is alleged to be a programming device, and its "exterior port 32" (a USB port) is alleged to be an onboard port. ¶38 ('798 Patent) 3:57-60
the programming device is configured to be communicably coupled, via a wired or wireless communication, to the user interface device... The '798 patent discloses that its controller (the alleged programming device) can communicate with the HMI (the alleged user interface) via wired or wireless signaling. ¶40 ('798 Patent) 3:35-38
the programming device is configured to: receive, via a defined sequence of messages... and store, via defined operations with a local cache, one or combinations of: data checksum map metadata, protocol map metadata... (collectively, mapping-and-byte data) The '798 patent allegedly teaches storing files in a local cache and discloses "mapping-and-byte data" with "metadata 170" that "may include a checksum for verifying proper programming." Figure 3 of the '798 patent, included in the complaint, illustrates a new file stored in memory. ¶41 ('798 Patent) 13:52-55
in response to receiving an instruction message from the user interface device, re-program the at least one onboard module using the mapping-and-byte data... The '798 patent allegedly teaches that a user can provide instructions through the HMI to initiate an update, causing the controller to transmit corresponding instructions to the module. ¶42 ('798 Patent) 12:37-41
in response to determining a checksum condition is satisfied, transmit a re-program success message to the user interface device. The '798 patent allegedly teaches that a module can transmit a "completion message" to determine if an update was successful, and that the HMI is able to receive this message. ¶43 ('798 Patent) 12:63-66
  • Identified Points of Contention: The invalidity argument appears to hinge on mapping the component parts and functions of the '798 patent's system onto the specific claim language of the '159 patent.
    • Scope Questions: A central question will be whether the '798 patent's integrated, in-dash "HMI 30" and "controller 20" can be fairly read upon the '159 patent's claimed system, which describes a distinct "user interface device" (like a phone) communicating with a separate, physically coupled "programming device" (like an OBD-2 dongle).
    • Technical Questions: Another point of contention may be whether the '798 patent’s general disclosure of using a "checksum for verifying proper programming" anticipates the '159 patent's more detailed recitation of receiving and storing specific data types like "data checksum map metadata" and "protocol map metadata" in a "local cache" via a "defined sequence of messages".

V. Key Claim Terms for Construction

  • The Term: "programming device"
  • Context and Importance: The complaint's invalidity theory depends on construing the '798 patent's "controller 20" as a "programming device" (Compl. ¶38, ¶40). Whether this mapping is appropriate will be a central issue. Practitioners may focus on this term because the patent appears to describe the programming device as a distinct, aftermarket component (like a "smart dongle") that interfaces with a user's separate device, whereas the '798 patent's "controller" appears to be an integrated vehicle component.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The claims do not explicitly limit the "programming device" to being an external or aftermarket device, only that it is "configured to be physically and communicably coupled to an onboard port" (’159 Patent, col. 31:35-37).
    • Evidence for a Narrower Interpretation: The patent's background describes updating modules using an "aftermarket programming device" (’159 Patent, col. 1:20-21). The detailed description repeatedly refers to the device as a "smart dongle" that interfaces with an OBD-2 port, suggesting a specific type of external device separate from the vehicle's native systems (’159 Patent, col. 3:20-22).

VI. Other Allegations

  • Potential Inequitable Conduct: The complaint does not contain a formal count for inequitable conduct but lays a significant foundation for one. It alleges that Defendant IE prosecuted the ’159 Patent without submitting a single Information Disclosure Statement (IDS) to the patent office, which it calls "shocking" (Compl. ¶48, ¶52). It further alleges, upon information and belief, that IE was aware of "numerous prior art references," including its own prior devices and those of its competitors (Compl. ¶53). The complaint explicitly reserves the right to amend to include allegations of inequitable conduct after discovery (Compl. ¶59). These allegations suggest Plaintiffs will argue that Defendant intentionally withheld material prior art from the patent examiner with an intent to deceive.

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

  • A core issue will be one of anticipation and claim scope: Does the disclosure of an integrated vehicle update system in the '798 prior art patent teach every element of the '159 patent's claims, which describe a two-part system comprising a distinct "user interface device" and a separate "programming device"? The outcome may turn on whether the prior art's "controller" and "HMI" can be mapped onto these claim terms.
  • A second critical issue will be one of patent prosecution conduct: What is the significance of the alleged failure by the patentee to submit any prior art to the USPTO during prosecution? If discovery reveals that the patentee was aware of material prior art (such as the '798 patent) and withheld it, the case could expand to include a defense of inequitable conduct, which, if proven, would render the entire patent unenforceable.