DCT

3:25-cv-05421

Empi Inc v. Integrated Engineering LLC

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 4:25-cv-05421, N.D. Cal., 06/27/2025
  • Venue Allegations: Venue is asserted based on the Defendant having sent a cease and desist letter to the Plaintiff, EMPI, Inc., within the Northern District of California.
  • Core Dispute: Plaintiffs seek a declaratory judgment that Defendant's patent, related to systems for updating vehicle software modules, is invalid as anticipated or rendered obvious by prior art.
  • Technical Context: The technology concerns aftermarket automotive systems that use a combination of a user device (e.g., a smartphone) and a physical "dongle" connected to a vehicle's On-Board Diagnostics (OBD-II) port to reprogram and tune vehicle computer modules.
  • Key Procedural History: The complaint alleges that this declaratory judgment action was precipitated by Defendant's enforcement activities, including a cease and desist letter sent to Plaintiff EMPI on February 15, 2025, and a separate patent infringement lawsuit filed by Defendant against a third party on April 28, 2025. The complaint further alleges that Defendant prosecuted the patent-in-suit without submitting any prior art references to the U.S. Patent and Trademark Office.

Case Timeline

Date Event
2023-10-29 U.S. Patent No. 12,112,159 Priority Date
2024-10-08 U.S. Patent No. 12,112,159 Issue Date
2025-02-15 Defendant sends cease and desist letter to Plaintiff EMPI
2025-04-28 Defendant files infringement action against a third party
2025-06-27 Complaint for Declaratory Judgment 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

  • Patent Identification: U.S. Patent No. 12,112,159, SYSTEM AND METHODS FOR STAGING DATA AND UPDATING VEHICLE MODULES USING STAGED DATA, issued October 8, 2024 (’159 Patent).

The Invention Explained

  • Problem Addressed: The patent's background section identifies the risk of damaging vehicle modules during software updates if the byte-level data is not precisely correct or delivered in a timely manner, a problem exacerbated by potentially unreliable data transmission to the vehicle. (’159 Patent, col. 1:25-34, col. 4:5-24).
  • The Patented Solution: The invention is a two-part system for updating vehicle modules. It consists of a "user interface device" (e.g., a smartphone) and a "programming device" (e.g., a smart dongle). The user device receives a complete re-program file from a server. The programming device, physically connected to the vehicle's onboard port, receives the entire file from the user device, stores it in a local cache, and performs verification checks (e.g., checksums). Only after the data is successfully staged and verified on the programming device does it then directly re-program the vehicle's onboard module. This process aims to isolate the critical programming step from potential transmission errors between the user device and the programming device. (’159 Patent, Abstract; col. 3:5-41).
  • Technical Importance: This approach seeks to improve the reliability of aftermarket vehicle tuning by creating a secure, verified data staging area on a device directly connected to the vehicle, thereby minimizing the risk of "bricking" a vehicle's electronic control unit during an update. (’159 Patent, col. 4:25-34).

Key Claims at a Glance

  • The complaint’s invalidity analysis focuses on independent claim 1. (Compl. ¶27).
  • The essential elements of independent claim 1 include:
    • A "user interface device" configured to receive and store a re-program file and display a GUI to initiate the process.
    • A "programming device" configured to be physically coupled to an onboard vehicle port.
    • The programming device is communicably coupled (wired or wireless) to the user interface device.
    • The programming device is configured to receive and store "mapping-and-byte data" (e.g., data checksum maps, protocol maps) from the user interface device via a "defined sequence of messages" and "defined operations with a local cache."
    • The programming device, in response to an instruction, re-programs the onboard module using the stored mapping-and-byte data.
    • The programming device, after determining a "checksum condition is satisfied," transmits a success message to the user interface device.
  • The complaint does not explicitly reserve the right to assert dependent claims but seeks a declaration that "the claims" of the patent are invalid. (Compl. ¶61; Prayer for Relief ¶A).

III. The Accused Instrumentality

Product Identification

  • The products identified in the Defendant's prior cease and desist letter, and therefore the subject of this declaratory judgment action, are the Plaintiffs' "034SPI Mobile Flashing Application," "Dynamic+ Performance Software," and "Dynamic+ Tuning Suite." (Compl. ¶6).

Functionality and Market Context

  • The complaint describes these as EMPI products, sold by EMPI and Plaintiff RacingLine, that compete directly with the Defendant's products in the market for ECU tuning software and updates. (Compl. ¶¶6, 8).
  • The complaint does not provide specific technical details regarding the operation of these products, as its primary focus is on establishing the invalidity of the ’159 Patent rather than non-infringement.

IV. Analysis of Invalidity Allegations

The complaint does not allege non-infringement but instead alleges that the '159 Patent is invalid as anticipated by prior art, specifically U.S. Patent No. 9,128,798 ("the '798 Patent"). The core of the complaint maps the elements of '159 Patent's Claim 1 to the teachings of the '798 Patent.

  • ’159 Patent Invalidity Allegations (based on the '798 Patent)
Claim Element ('159 Patent, Claim 1) Alleged Prior Art Teaching (from '798 Patent) Complaint Citation '798 Patent Citation
a user interface device The '798 Patent allegedly discloses a "Human-Machine Interface (HMI)" on the vehicle's dashboard, which serves as a user interface. A visual from the '798 Patent showing the HMI is included in the complaint. (Compl. p. 7, Fig. 2). ¶33 col. 4:2-8
...configured to: receive and store a re-program file from a server The '798 Patent allegedly discloses that a "new file" is communicated from a server and stored in a memory within the HMI. A visual from the '798 Patent showing the new file in memory is included. (Compl. p. 8, Fig. 3). ¶¶35-36 col. 2:32-40
...display a graphical user interface configured to receive a user input to initiate a re-program process... The '798 Patent allegedly discloses displaying an "update available message" through the HMI and receiving a corresponding input to authorize an update. ¶37 col. 7:37-55
a programming device configured to be physically and communicably coupled to an onboard port of the vehicle The '798 Patent allegedly discloses a "controller" as the programming device and a "Universal Serial Bus (USB) port" as the onboard port. ¶38 col. 3:57-60; col. 4:2-6
...configured to be communicably coupled, via a wired or wireless communication, to the user interface device... The '798 Patent allegedly discloses that its "controller" (the programming device) can be coupled to its "HMI" (the user interface) via wired or wireless signaling. ¶40 col. 3:35-38
...receive, via a defined sequence of messages... and store, via defined operations with a local cache, ...mapping-and-byte data The '798 Patent allegedly teaches that files are stored in a local cache and that metadata may include a "checksum for verifying proper programming." ¶41 col. 13:52-55
...re-program the at least one onboard module using the mapping-and-byte data The '798 Patent allegedly discloses that its controller transmits instructions to the module to perform an update based on user input from the HMI. ¶42 col. 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 be instructed to transmit a "completion message" to determine if the update was successful, which can be received by the HMI. ¶43 col. 12:63-66; col. 3:54-60
  • Identified Points of Contention:
    • Scope Questions: The complaint's invalidity theory raises the question of whether the '159 patent's claimed "user interface device" and "programming device," which are described as distinct components (e.g., a phone and a dongle), are indistinct from the '798 patent's integrated "HMI" and "controller," which are both part of the vehicle's built-in systems.
    • Technical Questions: A key technical question is whether the '798 patent's general disclosure of using checksums and transmitting completion messages teaches the specific "staging" process claimed in the '159 patent, which involves receiving and verifying the entire program on the dongle's local cache before initiating the re-program of the vehicle module.

V. Key Claim Terms for Construction

  • The Term: "user interface device"

  • Context and Importance: This term's construction is critical because the '159 Patent's system appears to rely on a separate, general-purpose device (like a phone), whereas the prior art cited in the complaint ('798 patent) discloses a vehicle's integrated "Human-Machine Interface (HMI)." Practitioners may focus on whether the term is limited to a device separate from the vehicle or if it can be broadly construed to read on an integrated vehicle dashboard screen.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claims do not explicitly state that the device must be external to the vehicle, only that it is communicably coupled to the programming device. (’159 Patent, col. 26:53-56).
    • Evidence for a Narrower Interpretation: The specification repeatedly discusses the user interface device in the context of a device that connects to the programming device via "WIFI or Bluetooth," which strongly suggests a separate, likely portable, device rather than a built-in HMI. (’159 Patent, col. 3:32-34). The figures also depict the "User Device 105" as external to the "Vehicle 115." (’159 Patent, Fig. 3).

  • The Term: "programming device"

  • Context and Importance: The '159 Patent's commercial embodiment is a "smart dongle." The complaint asserts the '798 patent's built-in "controller" meets this limitation. The dispute will likely center on whether the "programming device" must be an aftermarket device physically coupled to an existing port (like an OBD-II dongle) or if it can encompass an original equipment controller already integrated within the vehicle's architecture.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claim language requires the device to be "physically and communicably coupled to an onboard port of the vehicle," which does not foreclose the possibility of an internal controller being coupled to an internal port or bus. (’159 Patent, col. 26:46-48).
    • Evidence for a Narrower Interpretation: The patent is explicitly titled and described as relating to updating modules "using an aftermarket programming device." (’159 Patent, col. 1:20-21). The abstract and detailed description both describe the programming device as a "smart dongle that interfaces with an OBD 2 port," suggesting a specific type of aftermarket hardware. (’159 Patent, col. 3:19-21).

VI. Other Allegations

  • Inequitable Conduct / Duty of Disclosure Allegations:
    • The complaint alleges that the Defendant prosecuted the ’159 Patent without submitting a single Information Disclosure Statement ("IDS") to the USPTO. (Compl. ¶¶48, 52).
    • It further alleges, "upon information and belief," that the Defendant was aware of numerous material prior art references, including its own prior devices and those of its competitors (like the Plaintiffs), but withheld them from the patent examiner. (Compl. ¶53).
    • The complaint argues that Defendant's alleged failure to identify specific structures for key claim limitations in its own separate infringement lawsuit is an admission that such limitations were inherent in prior art technology. (Compl. ¶¶54-57). The Plaintiffs reserve the right to amend their complaint to add a formal count of inequitable conduct. (Compl. ¶59).

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

  1. A core issue will be one of invalidity over prior art: Does the '798 patent, which discloses an integrated in-vehicle update system, anticipate or render obvious the claims of the '159 patent, which are directed to a two-part system involving a separate user device and an aftermarket programming "dongle"? The resolution will depend on whether the specific "staging" architecture of the '159 patent is disclosed or suggested by the prior art.
  2. The case will likely turn on a question of claim construction: Can the terms "user interface device" and "programming device", which are described in the '159 patent's specification in the context of a smartphone and an OBD-II dongle, be construed broadly enough to read on the integrated HMI and internal controller components of the cited '798 prior art?
  3. A key evidentiary question will be one of intent: Can Plaintiffs produce evidence to show that Defendant, during prosecution, knew of material prior art (such as the '798 patent or competing products) and made a deliberate decision to withhold it from the USPTO with an intent to deceive, which could render the '159 patent unenforceable for inequitable conduct.