DCT

8:25-cv-00882

Integrated Engineering LLC v. Euro Motorparts Group Uk Ltd

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 8:25-cv-00882, C.D. Cal., 10/06/2025
  • Venue Allegations: Plaintiff alleges venue is proper in the Central District of California because Defendants maintain a regular and established place of business in Anaheim, California, and have committed acts of infringement in the district, including selling the accused products through an online store and a network of local dealers.
  • Core Dispute: Plaintiff alleges that Defendants’ mobile vehicle tuning products, which allow users to reprogram a vehicle’s engine control unit via a smartphone and a hardware dongle, infringe a patent related to a method for safely staging and verifying data before updating vehicle modules.
  • Technical Context: The technology at issue operates in the automotive aftermarket sector, where consumers use specialized hardware and software to modify vehicle performance parameters by "flashing," or reprogramming, onboard electronic modules.
  • Key Procedural History: The operative complaint is a Second Amended Complaint. The complaint also alleges that Plaintiff notified Defendants of the asserted patent and their alleged infringement via correspondence dated February 14, 2025, approximately eight months prior to filing suit.

Case Timeline

Date Event
2023-05-01 Accused "Dynamic+ End User Flashing Dongle" becomes available
2023-10-29 U.S. Patent No. 12,112,159 Priority Date
2024-10-08 U.S. Patent No. 12,112,159 Issues
2025-02-14 Plaintiff notifies Defendants of alleged infringement via letter
2025-10-06 Complaint 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 a risk in reprogramming vehicle electronic modules where data transmission errors—wired or wireless—can cause "bits or bytes to be scrambled." This can result in a failed programming attempt that may damage the vehicle's module (Compl. ¶8; ’159 Patent, col. 4:17-23).
  • The Patented Solution: The invention proposes a two-device system to mitigate this risk. A user interface device (e.g., a smartphone) sends a complete "re-program file" to a separate programming device (e.g., a "smart dongle") that is physically connected to the vehicle. The programming device receives and stores the entire file in a "local cache," verifies the data's integrity via checksums, and only after successful verification does it initiate the programming of the vehicle's module. This "staging" process isolates the sensitive vehicle module from potential data corruption during the initial, less reliable transmission (’159 Patent, Abstract; col. 3:25-34). The complaint references Figure 5C of the patent, which illustrates a dataflow for receiving and writing "Protocol Map Info" to a chip, a step in this staging process (Compl. ¶9).
  • Technical Importance: This method is designed to increase the reliability and safety of aftermarket vehicle tuning by creating an intermediate, verified data buffer that prevents corrupted data from being written to a critical vehicle component (’159 Patent, col. 4:31-34).

Key Claims at a Glance

  • The complaint asserts infringement of at least independent claim 1 (Compl. ¶24, 27).
  • The essential elements of independent claim 1 include:
    • A system comprising a "user interface device" and a "programming device."
    • The user interface device is configured to receive a "re-program file" and display a GUI to initiate the process.
    • The programming device physically couples to the vehicle's onboard port.
    • The programming device receives data from the user interface device via a "defined sequence of messages" and stores it in a "local cache." This stored data is referred to as "mapping-and-byte data."
    • The programming device reprograms the vehicle's onboard module using this mapping-and-byte data.
    • The programming device transmits a "re-program success message" to the user interface device only after a "checksum condition is satisfied."
  • The complaint’s use of "one or more claims" is standard language that may implicitly reserve the right to assert additional claims, including dependent claims (Compl. ¶24).

III. The Accused Instrumentality

Product Identification

  • The accused instrumentality is a combination of products comprising the "Dynamic+ Performance Software, Dynamic+ End User Flashing Kit (including smart dongle), and 034SPI (Smartphone Interface) Mobile Flashing application" (collectively, the "Accused Products") (Compl. ¶11).

Functionality and Market Context

  • The Accused Products form a system that enables customers to "update or 'flash' a vehicle ECU via the factory on-board diagnostic (OBD) port" (Compl. ¶11). The 034SPI mobile application functions as the user interface, while the "Dynamic+ End User Flashing Kit" is a hardware dongle that connects to the vehicle (Compl. ¶11). The complaint includes a screenshot from the 034SPI app showing a "DYNAMIC+ CABLE CONNECTED" status and a list of "FLASHED FILES," illustrating the system's operational state (Compl. p. 6). A separate image depicts two versions of the hardware dongles used in the "Flashing Kits" (Compl. p. 6). The system allows users to "easily flash your car, change fuel maps, configure live data displays, record and submit data logs," among other functions (Compl. ¶13). The products are allegedly sold throughout the United States via an online store and a network of physical dealers (Compl. ¶12, 22). The complaint provides a screenshot of the defendant's online shopping cart to demonstrate sales and shipping into the district (Compl. p. 8).

IV. Analysis of Infringement Allegations

The complaint alleges that the Accused Products directly infringe the ’159 Patent, with the detailed theory of infringement incorporated by reference from an exhibit that was not included with the filing (Compl. ¶25). However, the narrative allegations in the complaint map the components of the Accused Products to the elements of claim 1.

’159 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation 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 "034SPI (Smartphone Interface) Mobile Flashing application" allegedly serves as the user interface device for managing and initiating the flashing process. ¶11, 13 col. 31:42-49
a programming device configured to be physically and communicably coupled to an onboard port of the vehicle... The "Dynamic+ End User Flashing Kit (including smart dongle)" is a hardware device that allegedly connects to the vehicle's OBD port. ¶11 col. 31:50-53
the programming device is configured to: receive, via a defined sequence of messages... and store, via defined operations with a local cache... mapping-and-byte data The complaint alleges the system enables customers to "flash" a vehicle ECU, a process which entails the dongle receiving programming data from the mobile application before writing it to the vehicle module. The specific details of this data staging process are not enumerated. ¶11 col. 31:59 - col. 32:2
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 Accused Products are marketed as allowing users to "easily flash your car, change fuel maps." ¶13 col. 32:3-6
in response to determining a checksum condition is satisfied, transmit a re-program success message to the user interface device The complaint does not provide sufficient detail for analysis of this element. N/A col. 32:7-10
  • Identified Points of Contention:
    • Technical Questions: A primary factual question will concern the internal operation of the accused dongle. What evidence demonstrates that it receives and stores the entire re-program file in a "local cache" and performs a "checksum" verification on that cached data before initiating communication with the vehicle's module, as the patent requires? The complaint's general allegations of "flashing" may not be specific enough to establish this key technical step.
    • Scope Questions: The dispute may turn on whether the accused system's data handling protocol meets the specific limitations of "defined operations with a local cache" and "checksum condition is satisfied." An open question is whether these claim terms require a specific, heightened data integrity process distinct from standard data buffering and communication-layer error checking.

V. Key Claim Terms for Construction

  • The Term: "local cache"

  • Context and Importance: This term is foundational to the patent's asserted novelty. The infringement analysis depends on whether the accused dongle merely acts as a data conduit or if it performs the claimed function of storing and verifying the data locally before programming begins. Practitioners may focus on this term because the distinction between simple buffering and the patent's more robust "staging" concept is critical.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The patent does not provide an explicit definition for "local cache," which may support an argument that the term should be given its ordinary meaning, covering any form of temporary data storage within the programming device (’159 Patent, col. 3:62).
    • Evidence for a Narrower Interpretation: The specification repeatedly links the "local cache" and associated "defined operations" to the solution for data transmission errors, suggesting it is not just any memory but a component specifically used to ensure data integrity before reprogramming (’159 Patent, col. 4:25-34).

  • The Term: "checksum condition is satisfied"

  • Context and Importance: This phrase defines the specific trigger for completing the patented method. The case may hinge on what type of "checksum condition" is required. If it covers standard, protocol-level checks, infringement may be easier to show. If it requires a distinct, application-level verification of the entire staged data file, the evidentiary burden increases.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The term "checksum" is a general term in computing, and an argument could be made that it encompasses any form of error-checking, including those inherent in communication protocols like Bluetooth.
    • Evidence for a Narrower Interpretation: The patent describes a system where "the smart dongle/programming device may eliminate or reduce failures in programming from data transmission errors" by performing its own verification after the data is "completely transferred" but before it is sent to the module. This context suggests the "checksum condition" is an application-level integrity check on the staged file itself, not just a check on the transmission packets (’159 Patent, col. 4:29-34, 50-54).

VI. Other Allegations

  • Indirect Infringement: The complaint alleges inducement of infringement, stating that Defendants encourage infringing use through the "creation and dissemination of promotional and marketing materials, instructional materials, [and] product manuals" (Compl. ¶28). It also pleads contributory infringement by alleging the Accused Products are "especially made and/or especially adapted for use in infringement" and are not a staple article of commerce with substantial non-infringing uses (Compl. ¶29).
  • Willful Infringement: The claim for willfulness is based on alleged pre-suit knowledge of the patent. The complaint asserts that Defendants have known of the ’159 patent "since at least February 14, 2025," the date of a notice letter sent by Plaintiff's counsel (Compl. ¶26).

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

  • A core issue will be one of technical evidence: Does discovery reveal that the accused "smart dongle" operates according to the patent's specific two-stage architecture? Specifically, does it first download and store the entire tuning file in its own memory, and only after performing a distinct integrity check on that stored file, begin the process of reprogramming the vehicle's module?
  • The central legal dispute will likely be one of claim scope: Will the term "local cache," in the context of the patent, be construed to mean any temporary data buffer, or will it be limited to a storage mechanism sufficient to hold and verify an entire re-program file before flashing? Similarly, does the "checksum condition" require a specific, application-level verification of the staged data, or can it be satisfied by standard, underlying communication protocol error-checking?