# US 2019/0357040 A1 · Secure beacon identity > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 2019/0357040 A1 - Document ID: US20190357040A1 - Status: Published application - Kind: A1 - Application number: 16/412,200 - Filed: 2019-05-14 - Published: 2019-11-21 - Earliest claimed: 2018-05-15 - Assignees: Noodle Technology Inc. - Applicants: Noodle Technology, Inc. - Inventors: Micha Anthenor Benoliel; Kyude Karyan - Web page: https://patentgrep.com/patent/US20190357040A1 ## CPC - H04W 12/0433: Key management protocols - H04L 7/0037: {Delay of clock signal} - H04L 9/0643: {Hash functions, e.g. MD5, SHA, HMAC or f9 MAC} - H04L 9/3242: {involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC} - H04W 12/106: Packet or message integrity - H04W 12/61: Time-dependent - H04W 12/71: Hardware identity - H04W 40/244: {using a network of reference devices, e.g. beaconing} - H04W 56/003: {Arrangements to increase tolerance to errors in transmission or reception timing} - H04L 2101/622: Layer-2 addresses, e.g. medium access control [MAC] addresses - H04W 12/33: using wearable devices, e.g. using a smartwatch or smart-glasses - H04W: WIRELESS COMMUNICATION NETWORKS (broadcast communication H04H; communication systems using wireless links for non-selective communication, e.g. wireless extensions H04M1/72) - H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M) ## Abstract A method may include receiving a beacon from a first intermediate device via a first network, the beacon being received by the first intermediate device from an endpoint device via a second network. The beacon may include a hash value based at least in part on the identity of the endpoint device and a time unit when the beacon was generated. The hash value of the beacon may be validated based on the identity of the endpoint device and the time unit when the beacon was generated. The beacon may be forwarded to a server via a third network in response to the hash value of the beacon being valid. ## Claims ### Claim 1 A method, comprising: receiving a beacon from a first intermediate device via a first network, wherein the beacon was received by the first intermediate device from an endpoint device via a second network, the beacon comprising a hash value based at least in part on the identity of the endpoint device and a time unit when the beacon was generated; validating the hash value of the beacon based on the identity of the endpoint device and the time unit when the beacon was generated; and forwarding the beacon to a server via a third network in response to the hash value of the beacon being valid. ### Claim 2 (depends on 1) The method of claim 1, wherein validating the hash value of the beacon further comprises: precomputing hash values for all unique device identities and for all values of time units up to a fixed time value; storing the precomputed hash values; comparing the hash value received with the beacon with the stored precomputed hash values; and validating the hash value of the beacon in response to the hash value received with the beacon matching one of the stored precomputed hash values. ### Claim 3 (depends on 1) The method of claim 1, wherein the stored precomputed hash values are sorted according to hash values. ### Claim 4 (depends on 1) The method of claim 1, further comprising invalidating hash values that have a time unit that is earlier than the latest resolved time. ### Claim 5 (depends on 1) The method of claim 1, wherein the hash value is further based on a secret key known to the endpoint device and a relay manager server. ### Claim 6 (depends on 1) The method of claim 1, wherein the hash value is further based on a MAC address of the endpoint device. ### Claim 7 (depends on 1) The method of claim 1, further comprising continuing to receive additional beacons in response to the hash value of the beacon not being valid. ### Claim 8 (depends on 1) The method of claim 1, wherein the time unit is predetermined before the beacon is generated. ### Claim 9 (depends on 1) The method of claim 1, further comprising compensating for clock drift of the endpoint device such that the time unit when the beacon was generated is correct. ### Claim 10 (depends on 9) The method of claim 9, further comprising adjusting a clock of the endpoint device based on temperature variation or crystal inaccuracy. ### Claim 11 (depends on 1) The method of claim 1, wherein the hash value of the beacon prevents the identity of the endpoint device from being discernible by a third party. ### Claim 12 A method, comprising: calculating hash values for all unique device identities and for all values of time units up to a fixed time value; storing the precomputed hash values; receiving a beacon from a first intermediate device via a first network, wherein the beacon was received by the first intermediate device from an endpoint device via a second network, the beacon comprising a hash value based at least in part on the identity of the endpoint device and a time unit when the beacon was generated; comparing the hash value received with the beacon with the stored precomputed hash values; validating the hash value of the beacon in response to the hash value received with the beacon matching one of the stored precomputed hash values as a result of the identity of the endpoint device and the time unit when the beacon was generated; and forwarding the beacon to a server via a third network in response to the hash value of the beacon being valid. ### Claim 13 (depends on 12) The method of claim 12, further comprising deleting stored computed hash values for time unit values whose difference from the current time is greater than a predetermined threshold value. ### Claim 14 (depends on 12) The method of claim 12, wherein the stored computed hash values are sorted according to hash values. ### Claim 15 (depends on 12) The method of claim 12, further comprising: invalidating the hash value of the beacon in response to the hash value received with the beacon not matching one of the stored computed hash values; and continuing to receive additional beacons in response to the hash value of the beacon being invalidated. ### Claim 16 (depends on 12) The method of claim 12, further comprising: invalidating the computed hash values as time units elapse; deleting the invalidated hash values from storage; and calculating new computed hash values as time units elapse. ### Claim 17 A method, comprising: receiving a beacon from a first intermediate device via a first network, wherein the beacon was received by the first intermediate device from an endpoint device via a second network, the beacon comprising a hash value based at least in part on the identity of the endpoint device and a time unit when the beacon was generated; calculating a clock drift of the endpoint device; adjusting the time unit of the based on the calculated clock drift; validating the hash value of the beacon based on the identity of the endpoint device and the time unit when the beacon was generated; and forwarding the beacon to a server via a third network in response to the hash value of the beacon being valid. ### Claim 18 (depends on 17) The method of claim 17, wherein the clock drift is based on a temperature of a timing crystal of the endpoint device, and the clock drift is calculated and adjusted based on the temperature of the timing crystal of the endpoint device. ### Claim 19 (depends on 17) The method of claim 17, wherein the clock drift is based on a crystal frequency deviation and an elapsed time since a last clock synchronization, and the clock drift is calculated and adjusted based on the crystal frequency deviation and the elapsed time since the last clock synchronization. ### Claim 20 (depends on 17) The method of claim 17, further comprising periodically synchronizing a clock of the endpoint device with a clock of a relay manager server.