DCT

2:25-cv-01242

Nodle Technology Inc v. Samsung Electronics Co Ltd

Log In
Key Events
Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:25-cv-01242, E.D. Tex., 12/19/2025
  • Venue Allegations: Plaintiff alleges venue is proper because Defendants maintain regular and established places of business in the Eastern District of Texas, including facilities in Plano and Frisco, and have committed the alleged acts of infringement within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s SmartThings Find service and associated devices infringe five patents related to decentralized, delay-tolerant networks that use low-power wireless beacons for device location services.
  • Technical Context: The technology enables location tracking for Internet of Things (IoT) devices by using a crowdsourced network of intermediary devices, such as smartphones, to detect and relay low-power beacons from offline endpoint devices to a central server.
  • Key Procedural History: The complaint alleges that Plaintiff Nodle and Defendant Samsung engaged in discussions regarding Nodle’s technology under a Mutual Non-Disclosure Agreement in September 2018, which included product demonstrations, and that Samsung has had knowledge of Nodle's patent protection since at least 2019.

Case Timeline

Date Event
2017-06-07 Priority Date for ’238 and ’232 Patents
2018-05-15 Priority Date for ’650, ’837, and ’838 Patents
2018-09-01 Nodle and Samsung allegedly engage in discussions under NDA
2019-10-15 ’238 Patent Issued
2020-10-30 Accused Samsung "SmartThings Find" Service Launched
2021-08-24 ’650 Patent Issued
2025-07-01 ’232 Patent Issued
2025-08-19 ’837 Patent Issued
2025-08-19 ’838 Patent Issued
2025-12-19 Complaint Filed

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

U.S. Patent No. 10,448,238 - "Delay Tolerant Decentralized Network"

  • Patent Identification: U.S. Patent No. 10,448,238, "Delay Tolerant Decentralized Network," issued October 15, 2019 (Compl. ¶19).

The Invention Explained

  • Problem Addressed: The patent addresses the challenges of connecting a massive number of Internet of Things (IoT) devices, noting that existing solutions like cellular networks are often expensive and power-intensive, while low-power alternatives may lack sufficient bandwidth or coverage (’238 Patent, col. 2:36-51).
  • The Patented Solution: The invention describes a crowdsourced network architecture where a low-power "endpoint device" (e.g., an asset tracker) transmits a "beacon." A nearby "intermediate device" (e.g., a smartphone) receives this beacon and relays it over a different, longer-range network (e.g., cellular or Wi-Fi) to a server. This server can then process the beacon's information, such as its location, and communicate it to an "endpoint manager server" associated with the device owner or manufacturer, effectively creating a wide-area network without requiring fixed infrastructure (’238 Patent, Abstract; Fig. 1).
  • Technical Importance: This architecture provides a method for locating low-cost, low-power devices over a wide area by leveraging the existing density of more powerful, network-connected devices like smartphones, obviating the need for each tracked device to have its own cellular or GPS module (’238 Patent, col. 9:1-8).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1 (Compl. ¶62).
  • Claim 1 (Method):
    • Receiving a beacon from a first intermediate device via a first network, where the beacon was first received from an endpoint device via a second network.
    • Identifying a characteristic of the beacon, including an identifier of the endpoint device.
    • Using the identifier to perform a lookup in a data record to identify a particular server associated with the beacon.
    • Selecting that particular server.
    • Sending a beacon message to the selected server via a third network.
    • Receiving a response message from the server.
    • Processing the response message.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 12,349,232 - "Delay Tolerant Decentralized Network"

  • Patent Identification: U.S. Patent No. 12,349,232, "Delay Tolerant Decentralized Network," issued July 1, 2025 (Compl. ¶22).

The Invention Explained

  • Problem Addressed: As a continuation of the same family as the ’238 Patent, this patent addresses the same problem of providing scalable, low-power connectivity for a growing number of IoT devices (’232 Patent, col. 2:36-51).
  • The Patented Solution: The patent discloses a system embodying the same crowdsourced, delay-tolerant network concept as the ’238 Patent. The system architecture involves endpoint devices, intermediate relay devices, and servers configured to receive and process beacon information to enable device location and management without reliance on fixed infrastructure (’232 Patent, Abstract; col. 3:14-21).
  • Technical Importance: This system provides the hardware and software framework for implementing the cost- and power-efficient IoT network described in the ’238 Patent (’232 Patent, col. 3:59-4:4).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1 (Compl. ¶96).
  • Claim 1 (System):
    • A system with a memory and one or more processors configured to perform operations comprising the same steps recited in claim 1 of the ’238 Patent.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 11,102,650 - "Secure Beacon Identity"

  • Patent Identification: U.S. Patent No. 11,102,650, "Secure Beacon Identity," issued August 24, 2021 (Compl. ¶25).
  • Technology Synopsis: This patent addresses security and privacy in beacon-based networks. It discloses a method of generating a secure beacon containing a hash value derived from the device's identity and a "time unit." This allows an intermediate device to relay the beacon without being able to decrypt its contents, while a server can validate the hash to authenticate the beacon's origin and timeliness (Compl. ¶27; ’650 Patent, col. 3:57-4:16).
  • Asserted Claims: At least independent claim 1 (Compl. ¶131).
  • Accused Features: The complaint alleges that Samsung's SmartThings Find system generates beacons comprising a hash value based on a unique device identity that changes every fifteen minutes, which is alleged to be a "time unit" (Compl. ¶¶135, 136).

U.S. Patent No. 12,395,837 - "Secure Beacon Identity"

  • Patent Identification: U.S. Patent No. 12,395,837, "Secure Beacon Identity," issued August 19, 2025 (Compl. ¶28).
  • Technology Synopsis: This patent focuses on using secure beacons for service registration within a decentralized network. It describes a system where an endpoint device broadcasts a beacon containing a service registration request and a "time-based precomputed hash value." A service provider can then validate the beacon's hash value before establishing a service connection with the endpoint device (’837 Patent, Abstract; Compl. ¶163).
  • Asserted Claims: At least independent claim 1 (Compl. ¶163).
  • Accused Features: The complaint accuses the registration process for devices like the Samsung SmartTag on the SmartThings network. It alleges this process uses beacons with time-based hash values to create a unique device ID, which is validated by the SmartThings Cloud (the "service provider") to establish a connection (Compl. ¶¶166-172).

U.S. Patent No. 12,395,838 - "Secure Beacon Identity"

  • Patent Identification: U.S. Patent No. 12,395,838, "Secure Beacon Identity," issued August 19, 2025 (Compl. ¶31).
  • Technology Synopsis: This patent discloses a system for securely locating devices that builds upon the concept of time-based hash values. A key feature is the invalidation of older hash values. The system is configured to invalidate beacon hash values whose associated time units differ from the current time by more than a predetermined threshold, preventing the use of stale location data (’838 Patent, Abstract; Compl. ¶193).
  • Asserted Claims: At least independent claim 1 (Compl. ¶193).
  • Accused Features: The complaint accuses the SmartThings Find system's management of beacon data, specifically alleging that Samsung's servers "invalidate" or mark a tag as "expired if it has not appeared in the BLE scanning for 15 minutes," which is alleged to satisfy the claim's invalidation step (Compl. ¶202).

III. The Accused Instrumentality

  • Product Identification: The accused instrumentality is "Samsung's SmartThings Network with the Find feature for locating devices and associated devices" (the "Accused Products"). This includes Samsung's servers and cloud-based systems, as well as devices capable of interacting with the platform, such as the Galaxy S, Z, A, and Note series phones, Galaxy Watches, Galaxy Buds, and Samsung SmartTags (Compl. ¶53).
  • Functionality and Market Context: The SmartThings Find service is a mobile solution designed to locate registered devices, even when they are offline (Compl. ¶51). When a registered device, termed an "endpoint device," is disconnected from a network for over thirty minutes, it begins to emit a beacon using Bluetooth Low Energy (BLE) technology (Compl. ¶66). Other nearby Samsung devices that are part of the SmartThings Find network, acting as "intermediate devices," constantly scan for these beacons. Upon receiving a beacon, an intermediate device relays the information, including its own location, to Samsung's servers. The owner of the lost device can then use the SmartThings application to query the servers and view the last reported location of their device on a map (Compl. ¶¶68-72). The complaint includes a diagram illustrating this architecture of a lost tag, potential helper devices, a server, and the tag owner's device (Compl. Ex. 15, p. 25).

IV. Analysis of Infringement Allegations

’238 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
receiving a beacon from a first intermediate device via a first network... Samsung's servers receive forwarded beacon data from nearby "helper" or "intermediate" Samsung devices via Wi-Fi or a cellular network. ¶68 col. 7:5-8
...wherein the beacon was received by the first intermediate device from an endpoint device via a second network; The intermediate devices are described as constantly scanning for and receiving beacons from lost "endpoint devices" (e.g., a SmartTag) via BLE or UWB. ¶68 col. 5:1-5
identifying a characteristic of the beacon, the characteristic of the beacon including an identifier of the endpoint device; The beacons are alleged to contain a "unique device identifier" that allows Samsung's servers to know which devices are communicating. ¶65 col. 8:10-14
using the identifier of the endpoint device to perform a lookup in a data record to identify a particular server that is associated with the beacon; Samsung's servers are alleged to "perform a lookup using the unique identifying information contained within the beacon so that Samsung's servers know where to store or transmit this data." ¶69 col. 8:15-20
selecting the particular server based on a result of the lookup in the data record; The complaint alleges this step is met by the lookup described above, though it does not detail a separate selection action. ¶62 col. 18:24-27
sending a beacon message to the server via a third network, the beacon message including at least one of the beacon, or information pertaining to the beacon; The intermediate devices are alleged to "act as a relay and forward the data to Samsung's servers via Wi-Fi or a cellular network." ¶68 col. 8:25-30
receiving, from the server, a response message pertaining to the beacon message; and A user's device (identified as a "second intermediate device") queries Samsung's servers and receives information back, including the location of the endpoint device. ¶71 col. 8:59-62
processing the response message. The user's device receives the location information, processes it, and displays the endpoint device's location on an electronic map. ¶72 col. 8:63-64
  • Identified Points of Contention:
    • Scope Questions: A central question may be the interpretation of "identify a particular server." The complaint alleges Samsung's servers perform a "lookup" to determine how to "store or transmit" data (Compl. ¶69). A dispute may arise over whether this internal data handling by the receiving server satisfies the claim language, which could be interpreted to require identifying a separate, distinct server as a destination.
    • Technical Questions: The complaint's infringement theory appears to bifurcate the role of the "intermediate device." It describes a "first intermediate device" (a helper phone) that finds the beacon and sends it to the server, and a "second intermediate device" (the owner's phone) that queries the server and receives the response (Compl. ¶¶68, 70). It may be a point of contention whether this architecture maps cleanly onto the claim, which refers to a "first intermediate device" without explicitly mentioning a second one for receiving the server response.

’232 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A system, comprising: a memory; and one or more processors operatively coupled to the memory...configured to execute operations...comprising: The Accused Products, including Samsung's servers and devices, contain processors and memory capable of executing the SmartThings Find software and service. The complaint provides a screenshot of the system managing multiple device types (Compl. Ex. 8, p. 33). ¶98 col. 5:46-51
receive a beacon from a first intermediate device via a first network... Samsung's servers are configured to receive beacon data forwarded by intermediate "helper" devices via Wi-Fi or a cellular network. ¶103 col. 7:5-8
...wherein the beacon was received by the first intermediate device from an endpoint device via a second network; The system relies on intermediate devices to be configured to receive beacons from endpoint devices via a short-range network like BLE. ¶103 col. 5:1-5
identify a characteristic of the beacon, the characteristic of the beacon including an identifier of the endpoint device; The system is configured to process beacons containing a unique device identifier for device registration and location. ¶100 col. 8:10-14
use the identifier of the endpoint device to perform a lookup in a data record to identify a particular server that is associated with the beacon; Samsung's servers are configured to perform a lookup using the beacon's unique identifier to determine how to store or transmit the location data. ¶104 col. 8:15-20
select the particular server based on a result of the lookup in the data record; The system is configured to perform the operations as alleged for the '238 Patent. ¶96 col. 18:24-27
send a beacon message to the server via a third network... The system relies on intermediate devices being configured to forward beacon data to Samsung's servers. ¶103 col. 8:25-30
receive, from the server, a response message...; and The system's servers are configured to receive a request from a user's device and transmit location information back to it. ¶106 col. 8:59-62
process the response message. The user's device, as part of the system, is configured to process the received server data and display it on a map. ¶107 col. 8:63-64
  • Identified Points of Contention: The points of contention identified for the ’238 Patent apply equally to this system claim, as the recited functional steps are identical. The analysis will likely focus on the same questions regarding the "identify a particular server" step and the mapping of the "first intermediate device" role.

V. Key Claim Terms for Construction

  • The Term: "a particular server that is associated with the beacon" (from '238 Claim 1 and '232 Claim 1)

    • Context and Importance: This term is critical to the infringement analysis for the two lead patents. The dispute may center on whether this requires looking up and selecting a different server to route the message to, or if a server processing a message internally based on an identifier (e.g., deciding which database table to write to) satisfies the limitation. Practitioners may focus on this term because the complaint's allegation of a "lookup" for where to "store or transmit" data could be framed by a defendant as routine internal data management rather than the identification and selection of a "particular server."
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The claim language recites "a particular server" and does not explicitly require it to be a different server from the one performing the lookup. The specification describes the system as including "one or more relay servers" and "one or more endpoint manager servers," which could be interpreted as distinct entities or as logical roles that could be co-located on the same physical hardware (’238 Patent, col. 3:16-19).
      • Evidence for a Narrower Interpretation: The sequence of "perform a lookup... to identify" followed by "selecting the particular server" suggests a process of discovery and choice among potential destinations. The patent's Figure 1 depicts the "Relay Server" and "Endpoint Manager Server" as distinct boxes connected by a network, which may support an argument that the claims contemplate communication between separate server entities (’238 Patent, Fig. 1). The specification also states the message manager in the relay server may access data storage to "identify... an endpoint manager server 135 that is associated with the beacon" (’238 Patent, col. 8:1-3).

  • The Term: "first intermediate device" (from '238 Claim 1 and '232 Claim 1)

    • Context and Importance: The complaint's infringement narrative involves two distinct intermediate devices: a "helper" device that detects the beacon and a "user" device that queries the server (Compl. ¶¶68, 70). The construction of "first intermediate device" will determine if this two-device model fits the claim. If the term is construed to require the same device to perform both the initial relay and receive the final response, it could create a mismatch with the plaintiff's infringement theory.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The claim requires "receiving a beacon from a first intermediate device," but the subsequent steps of "receiving... a response message" and "processing the response message" are not explicitly tied back to that same device. This separation could support an interpretation where different devices perform different roles in the method.
      • Evidence for a Narrower Interpretation: The specification suggests a bidirectional role for the intermediate device, stating it "may perform one or more operations responsive to receiving the message from the endpoint manager server 135," which implies the same device that relayed information to the server is also receiving information back from it (’238 Patent, col. 6:40-43).

VI. Other Allegations

  • Indirect Infringement: The complaint alleges Samsung induces infringement by instructing and encouraging customers to use the Accused Products in an infringing manner. This is allegedly done through user manuals, support websites, instructional videos, and in-app prompts that guide users to enable and use the "Offline Finding" feature (Compl. ¶¶79-85). Contributory infringement is alleged on the basis that the Accused Products are specially designed to utilize BLE technology for locating devices and are not staple articles of commerce (Compl. ¶¶86-87).
  • Willful Infringement: Willfulness is alleged based on Samsung's purported pre-suit knowledge of the patents-in-suit. The complaint claims this knowledge arises from business discussions between Nodle and Samsung under an NDA beginning in September 2018, which included product demonstrations, and alleges Samsung was aware of Nodle's patent protection by 2019 (Compl. ¶57).

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

  • A core issue will be one of definitional scope: Does Samsung's server-side processing, where a server receives a beacon and uses its identifier for internal storage or routing, meet the claim requirement to "perform a lookup... to identify a particular server"? The case may turn on whether this language requires identifying an external server destination or can be read on internal data management functions.
  • A key evidentiary question will be one of pre-suit knowledge: What was the specific nature of the 2018 discussions between Nodle and Samsung, and what level of technical detail was shared? The answers will be central to determining Samsung's state of mind and proving the allegations of willful infringement.
  • A central technical question will be one of functional implementation: How does Samsung's use of a rotating "privacy ID" and "aging counter" in its SmartThings Find beacons technically map onto the claims for "secure beacon identity"? The analysis will likely focus on whether this implementation constitutes the claimed "hash value" based on a "device identity and a time unit" and whether the 15-minute expiration policy functions as the claimed "invalidation" of older hash values.