Patent Grant
10771917
This invention relates generally to the wireless communication field, and more specifically to a new and useful data routing method in the wireless communication field.
Beacon fleet management can be extremely resource consuming for large numbers of beacons, which conventionally require that each beacon be connected to a fixed power source in a physical location, such as a mains power source. This can limit the number of beacons able to be placed in a physical location as well as the arrangement of the beacons within the physical location.
On-going beacon control is also difficult because information, such as updated settings and firmware, needs to be individually loaded onto each beacon. Conventionally, beacon management has required the management entity to walk through the physical space, and individually connect to and program each beacon. This can be extremely resource consuming, particularly when the managing entity has multiple locations. Furthermore, there is a risk that the managing entity forgets to update hidden beacons (e.g., beacons that the managing entity forgets are there, beacons that are visually obscured from view, etc.), leading to end-user experience inconsistencies within the beacon population.
Thus, there is a need in the wireless beacon field to create a new and useful system and method for beacon fleet management. This invention provides such new and useful system and method.
The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
1. Overview
As shown in
As shown in
2. Benefits
The wireless system and method can confer several benefits over conventional data transfer solutions. First, the system can be easily installed in a physical space, due to the small form factor and simple mounting mechanisms (e.g., adhesive) of the mesh nodes. Furthermore, because the mesh nodes are wireless and/or battery powered, the resultant mesh topology is not dictated by the availability of wall plugs or access points.
Second, because the mesh nodes are statically mounted within the physical space, the resultant mesh will have less link breaks. This can result in a more stable, better-understood mesh (e.g., network topology), which can facilitate more efficient information transfer within the mesh. Some variants use low-power nodes with short-range radios and/or communication protocols. These variants can also result in a more stable, better-understood mesh, because the short-range inter-nodal connections can be less susceptible to signal interference (e.g., due to a lower probability of physical or EMI obstacle presence in the inter-nodal path; due to more stable connections, etc.).
Third, the system and method can reduce power to communicate information to a set of beacons. This can be particularly compelling in variations in which one or more nodes are battery powered and/or not constantly plugged into mains power during operation.
In some variations, thanks to addressing, a single message can contain a piece of data dedicated for a particular device—in this setup, only the minimum number of required devices will consume the message using just a portion of their power, which can optimize the time of propagation over, for instance, conventional flooding schemes.
In some variations, parameters such as physical distance, node type and/or endpoint type, node battery levels and/or other node parameters can be used to determine the routing (e.g., the routing table(s)) and/or balance the traffic within a mesh. This can further optimize for battery lifetime and/or reliable data routing through the mesh.
In some variations, the method entirely or partially offloads or splits the node routing process between the nodes of the local mesh and the cloud (e.g., remote computing system). This can minimize on-node/per-node route calculation and/or storage, which can in turn decrease node energy consumption. In one variation, network topology and routing paths (e.g., optimum relay path between a first and second node) are determined and maintained by the cloud and transmitted to nodes on a per-packet basis, wherein the nodes temporarily store the routing path for data packet transmission. Alternatively, a routing table can be determined at the cloud, wherein the routing table has static paths, and wherein the routing table is pushed to each node. Alternatively, the routing tables can be determined and stored on each node, wherein the routing tables can be different across the set of nodes. However, the processes can be otherwise divided. This offloading can be applicable in various short-range mesh network applications, particularly in applications that forward high latency packets (e.g., long transmission times are acceptable), that have low traffic (e.g., such that optimal network bandwidth utilization can be deprioritized), that can accept high loss rates (e.g., such that very precise control over data transfer is not needed), and/or in any other suitable application. This process offloading/splitting can additionally or alternatively decrease the amount of RAM needed and/or used on each node.
In variants, the method can automatically (remotely) update the network topology and/or routing tables. For example, network topology changes can be determined (e.g., calculated, modeled, detected, etc.) based on node telemetry (e.g., broadcast by the respective node and transmitted to the remote computing system via an intermediary device, such as a user device), node presence (e.g., determined based on whether a device that should be receiving the node packets is receiving the node packets), be manually reported, or be otherwise determined.
In some variations, the system and method confer a low-latency, high-bandwidth, energy efficient system because the respective radios of the mesh nodes can be selectively operated in the more-power-consuming transmission modes on-demand (e.g., when data needs to be passed), instead of constantly operating the radios in the transmission mode (e.g., scanning mode), or scheduling radio operation in the transmission mode. Furthermore, the system and method can be more energy efficient by leveraging low-power, short-range radios and/or protocols, such as BLE or UWB.
Fourth, the mesh nodes can connect to and transfer data to and/or from endpoints within the physical space encompassed by the resultant mesh. In one variation, the mesh nodes function as an intermediary between a remote data source (e.g., a remote server) and an endpoint within the physical space, wherein data is transmitted from the remote data source, through an access point with long-range connectivity (e.g., user device, router) within transmission range of a mesh node, from the mesh node to a subset of the mesh nodes of the mesh, and to the endpoint within transmission range of a final mesh node (or in reverse, example shown in
Fifth, some variants of the system and method can route the data through a predetermined series of nodes (e.g., data routing path). Because the data can be transmitted to different endpoints via different paths through the mesh (e.g., (pre-planned static paths, dynamic routing paths determined based on current or anticipated node operation parameters, etc.), the transmission load on each node can be optimized (e.g., reduced), which can reduce transmission latency and power consumption by the node and/or mesh overall.
Sixth, the mesh nodes can double as physical location identifiers (e.g., each be associated with a predetermined geographic location) or as content nodes (e.g., broadcast packets for content retrieval by recipient devices). In one example, user devices receiving advertisement packets broadcast by a node associated with a location (e.g., kitchen) can be determined to be proximal the location. In a related example, the signal quality indicator of the packet (e.g., RSSI) can be used to determine the user device distance from the node's known location. In a second example, the physical location of user devices receiving advertisement packets broadcast by multiple nodes, each with a known physical location, can be determined based on the respective known physical locations and/or signal quality indicators of the respective advertisement packets
Seventh, the system and method can track how assets (e.g., devices, endpoints) move within the space, based on the known physical locations of each mesh node, which mesh node the asset is connected to, has received packets from, and/or is detected, and the parameters of packet receipt (e.g., RSSI, angle of receipt, receipt time, etc.).
Eighth, the communicated data can be endpoint-specific (e.g., endpoint control instructions, endpoint telemetry, etc.), mesh-node specific (e.g., updates for the mesh nodes themselves, node telemetry), or be any other suitable data.
Ninth, in some variations, the method includes one or more encryption processes, which function to enable secure data routing in the system (e.g., wherein data cannot be interpreted at an intermediary device). In some examples, for instance, node/beacon identifiers are initially encrypted and then decrypted at the cloud. Additionally or alternatively, any data or information can be un-encrypted, encrypted, or decrypted (e.g., by the target node) at any suitable location and point in the method. In one example, the remote computing system can encrypt the data with a key (e.g., symmetric key, public key of an asymmetric key pair), and the target node can decrypt the data with a complimentary key (e.g., the symmetric key, private key of the key pair). The complimentary key can be generated based on a seed (e.g., a shared seed, such as the manufacturer node ID, a timestamp, etc.), be manually stored (e.g., at manufacture), or otherwise determined.
Tenth, in some variations, the method reduces the time and/or effort to update settings (e.g., operational parameters) of a set of nodes. This can be accomplished through any or all of: individual addressing of nodes, optimized routing paths (e.g., optimized for physical distance, number of nodes along information path, etc.), or in any other suitable way.
3. System 100
The system 100 can be used with the method 200, or any other suitable method for routing data. The system 100 preferably includes a population of beacons 110, each beacon having one or more radios 120, and a data routing system 140, but can additionally or alternatively include any or all of: one or more objects 130, a set of power sources 150 (e.g., onboard batteries), or any other suitable element.
Each beacon 110 (node 110) of the population is preferably arranged within the broadcasting range of at least one adjacent beacon, but can be otherwise arranged. The beacons are preferably arranged between 4 and 5 meters apart, but can additionally or alternatively be arranged between 0 and 10 meters apart, less than 4 meters apart, greater than 10 meters apart, less than 100 meters apart, or at any suitable distance apart. The broadcasting range can be defined by the broadcasting power (e.g., vary as a function of the broadcasting power for the given beacon), by the radio type (e.g., of the broadcasting radio, of the data transmission radio, etc.), by the user (e.g., the distance from the beacon where the RSSI is above a predetermined value), be 5 m, 200 m, or otherwise defined. The population of beacons is preferably defined by a user (e.g., at a remote management system, by an application executing on the user device), but can include all beacons within broadcasting range of another beacon within the population, or be otherwise defined. The beacon population can be defined and/or configured before and/or after beacon deployment (e.g., physical attachment to the physical space). The beacons within a population are preferably the same type of beacon, but can optionally be different types of beacons (e.g., with different form factors, different radios, different protocols, etc.). The beacons of the population are preferably arranged within a common physical space, but can be otherwise distributed. Each physical space can include one or more beacon populations, wherein the beacon populations can share beacons or be formed from different beacons. However, the beacon population can be otherwise defined or configured.
The beacon population preferably includes multiple beacons (e.g., 2 beacons, 3 beacons, greater than 3 beacons, 20 beacons, 50 beacons, etc.) but can alternatively include a single beacon. The population (e.g., relative locations, composition, etc.) can remain static throughout the method; additionally or alternatively, beacons can be added to or removed from the population, intentionally or unintentionally (e.g., fall off the mounted surface) throughout the method. The beacon population is preferably all associated with a common user account (e.g., management entity) or security key (e.g., API key, which can be used to authenticate communications with and/or between beacons or nodes of the same population), but can alternatively be associated with different user accounts.
The beacon of the population can function as a mesh node (e.g., mesh router), an aggregation node, as a physical location identifier, an access point, as a sensor for the physical space, and/or to broadcast packets for content retrieval. The beacon can be operated as a mesh node: concurrently, asynchronously (e.g., interchangeably), periodically, or at any other suitable temporal relationship with beacon operation as a location and/or content beacon. Additionally or alternatively, the beacon can be operated as an aggregation node, or any other suitable type of node. The beacon can be mounted to surfaces (e.g., walls, ceiling, floor) of a physical space (e.g., physical venue). The beacon is preferably static (e.g., adhered to a wall, adhered to a stationary object in a room, placed on the floor, plugged into a power source, etc.) with respect to the physical space but can additionally or alternatively be at least partially mobile (e.g., mounted to a mobile object, carried by a user, attached to a moving object, attached to a vehicle, etc.), or attached to any other suitable mounting surface.
In some variations of a population of beacons, all the beacons are static. In other variations, a subset of the beacons can be static (e.g., forming a beacon mesh) and one or more beacons can be mobile (e.g., attached to or integrated with a mobile object). Additionally or alternatively, the system can have any combination of static and mobile beacons.
Each beacon (node) is preferably configured to be individually addressed (e.g., with a unicast address, virtual address, unassigned address, publish address, etc.). Additionally or alternatively, a set or subset of beacons can be addressed together (e.g., with a group address). The beacon address can be locally unique, globally unique, unique within a beacon population owned by a common entity (e.g., associated with a common user account, application client, or API key), or otherwise individually identifiable. The beacon address can be the same as, derived from (e.g., calculated from), or unrelated to the beacon identifier (e.g., manufacturer beacon identifier). The manufacturer beacon identifier can be globally unique, locally unique, or otherwise related to other beacon identifiers. The beacon can optionally broadcast: the manufacturer beacon identifier, a secure beacon identifier (e.g., automatically generated on-board the beacon using a rule shared between the beacon and the remote computing system), a UUID, major, and/or minor value, node telemetry (e.g., values encoding sensor measurements sampled by on-board sensors, such as state of charge, traffic, temperature, ambient light, noise, orientation, acceleration, etc.), link metrics, channel quality indicators, or any other suitable information in one or more advertisement packets.
The beacon is preferably a low-power device, but can alternatively be a continuously-powered device, a high-power device (e.g., uses a high-power consumption protocol or radio), or can be otherwise powered.
The beacon can include: one or more radios 120, processors (e.g., GPU, CPU, microprocessors, etc.), power sources 150 (e.g., batteries 152, primary batteries, secondary batteries, inductive charging systems, RF charging systems, etc.), sensors (e.g., orientation sensors, such as gyroscopes or IMUs, kinematic sensors, such as accelerometers, temperature sensors, ambient light sensors, acoustic sensors, pressure sensors, etc.), and mounting mechanisms (e.g., screws, adhesive, magnetic housings, etc.). The beacon can optionally include wired connectors (e.g., GPIO connectors), storage (e.g., RAM, Flash, etc.), or any other suitable component.
In one variation, all static beacons are battery-powered (e.g., CR2477 batteries, AAA alkaline batteries, etc.) with an onboard battery.
The radios can be short-range radios (e.g., UWB, BLE, Bluetooth, radios operating on IEEE 802.15 protocols, NFC, etc.), long-range radios (e.g., WiFi, Zigbee, etc.), radios configured to alternate between short-range and long-range communication, or be any other suitable radio. The radios can be high-bandwidth, low bandwidth, or support any other suitable communication. The radio system preferably forms a full-duplex system, but can alternatively form a half-duplex system or any other suitable system. The beacon can include one or more of each radio type.
Each beacon preferably has a radio operable in a set of operation modes but each beacon can additionally or alternatively have multiple radios (e.g., each configured to operate in a single operation mode, each configured to operate in multiple operation modes, etc.), or any number of radios in any arrangement.
The radio operation modes can include any or all of: an advertising mode (e.g., a slave mode, client mode, broadcast mode, etc.; wherein the beacon broadcasts/advertises packets but does not receive and/or process received packets); a scanning mode (e.g., a master mode, a server mode, transmission mode, listening mode, etc.; wherein the beacon listens for packets or can additionally both broadcasts and receives packets for processing); a default mode (e.g., off, standby, advertising, etc.), or any other suitable mode.
In some variations, the advertising mode includes conditional broadcasting, wherein the beacons do not broadcast if a set of one or more conditions are met, which can function to save energy. The conditional broadcasting can be based on (e.g., triggered by) any or all of: beacon orientation (e.g., does not broadcast when beacon is on back, motion (e.g., beacon does not broadcast while still, beacon does not broadcast while moving, etc.), environmental condition (e.g., light level, temperature, humidity, etc.), time (e.g., predetermined set period of time, predetermined time of day, in response to a scheduled event, etc.), beacon energy level (e.g., charge level, time of most recent charge, etc.), or any other suitable trigger.
The beacon preferably includes a low-bandwidth radio (e.g., operating in the client mode) and a high-bandwidth radio (e.g., selectively operated in the server mode, such as in response to receipt of a command by the low-bandwidth radio), but can additionally or alternatively include a second low-bandwidth radio (e.g., operating in a master mode, to monitor the number of devices passing by) or include any other suitable set of radios.
The system can optionally include one or more objects 130, which function as endpoints, intermediary devices, and/or data sources. The object can optionally function as a wireless access point (e.g., a mesh point), as the data routing system, or perform any other suitable functionality. The objects are preferably mobile (e.g., include translation mechanisms, such as wheels, treads, or rotors), but can alternatively be static.
Each object preferably defaults to operation in a scanning mode (e.g., listening mode, etc.), wherein the object is listening for signals broadcast by beacons. Additionally or alternatively, object can continuously or selectively operate in an advertising mode, serve as a beacon in the mesh, or be operating in any other operation mode. In one variation, the object is a user device (e.g., mobile phone).
Examples of objects that can be part of the system include: user devices (e.g., smartphones, tablets, etc.), robotic vacuums, drones, pets, connected devices (e.g., connected ovens, lightbulbs, desks, speakers, displays, etc.), or any other suitable object. The object can include one or more radios, processing systems (e.g., processors, on-board storage), sensors, or any other suitable component. The object and beacon preferably share one or more radio types (e.g., technologies, protocols, etc.), but can alternatively have different radio types, wherein an intermediary system (e.g., user device, secondary object) can function as a translation layer.
Examples of the user device include a tablet, smartphone, mobile phone, laptop, watch, wearable device (e.g., glasses), or any other suitable user device. The user device can include power storage (e.g., a battery), processing systems (e.g., CPU, GPU, memory, etc.), user outputs (e.g., display, speaker, vibration mechanism, etc.), user inputs (e.g., a keyboard, touchscreen, microphone, etc.), a location system (e.g., a GPS system), sensors (e.g., optical sensors, such as light sensors and cameras, orientation sensors, such as accelerometers, gyroscopes, and altimeters, audio sensors, such as microphones, etc.), data communication system (e.g., a WiFi module, BLE, cellular module, etc.), or any other suitable component
The set of objects 130 preferably includes multiple intermediary devices 132, which function to connect one or more beacons 110 to a data routing system 140. Each intermediary device 132 is preferably a mobile device (e.g., wireless device), further preferably a user device (e.g., mobile phone with client application). Additionally or alternatively, the set of objection 130 can include a single intermediary device, no intermediary device, or any number of intermediary devices in any suitable form(s).
In one variation (e.g., as shown in
The system can optionally include a data routing system 140, which functions to determine the data transmission route through the mesh. The data routing system can optionally determine and/or store the mesh topology (e.g., node locations, EMI topology, etc.), mesh operation parameters (e.g., node operation parameters, data load, etc.), the routing table(s) (e.g., for one or more beacon populations or mesh networks), or any other suitable information. In one variation, the data routing system can: determine the endpoint location within the physical space; determine the location of a data source within the physical space; determine a mesh topology for the nodes; determine a routing path through the mesh network, based on the known mesh topology; and facilitate data transport through the mesh from the data source to the endpoint location according to the routing path. The data routing system can optionally track endpoint and/or data source movement within the space, and/or route the data through the mesh based on an anticipated endpoint and/or data source location (e.g., at the time of data packet arrival). The data routing system is preferably local (e.g., to the mesh network) but can alternatively be remote (e.g., from the mesh network; located in a physically separate and distinct location from the mesh network). The data routing system can be a remote computing system (e.g., cloud-based computing system), distributed storage system (e.g., cooperatively formed by the beacons), application (e.g., executing on a user device), web browser, object (e.g., IoT device, etc.), WAP, beacon, data source, endpoint, or be any other suitable computing system or set thereof.
The system 100 can include a routing table, which can be determined by the data routing system 140 and/or stored in storage associated with the data routing system 140 (e.g., cloud-based storage). The routing table can be used to determine routing paths, based on one or more parameters of the beacon mesh, such as, but not limited to: beacon (node) battery levels, physical distance (e.g., between nodes; as determined based on the respective RSSI for each node determined by a tertiary device, based on the RSSI for a node determined at a neighboring node, etc.), mesh topology, the type of node (and/or endpoint), node or cluster lifespan (actual, anticipated), node traffic (current, historic, or anticipated), node stability, node acceleration, and node operation environment (e.g., temperature, acoustic environment, ambient light, etc.). Additionally or alternatively, any other node parameters can be used to determine the routing table(s) and/or balance the traffic among the system 100. Alternatively, some or all of the node parameters can be ignored when determining the routing paths.
The system 100 can include one or more routing paths, which are preferably included in and/or determined by one or more routing tables. The routing paths are preferably optimal paths (e.g., optimized for time, optimized for distance, optimized for battery life, optimized for latency, etc.) among beacons in a mesh, but can alternatively be sub-optimal paths (e.g., for one or more metrics or variables). The routing path can be static or dynamic, and can include: one or more endpoints (e.g., starting node, target node, etc.), all hops (e.g., intermediate nodes) in the path, a limited subset of hops in the path (e.g., next 3 hops), a transmission schedule, and/or any other information. Alternatively, the routing path can be dynamically determined on a hop-by-hop basis by the nodes in the path.
In one variation, the starting node can be the node that the intermediary device just received a packet from, and/or the node identified in a packet received by the data routing system.
In a second variation, the starting node can be another node within the local mesh, wherein the intermediary device does not transmit data received from the data routing system until the intermediary device receives an advertisement packet from (and/or connects to) the starting node.
4. Method
The method 200, which can be used with the system 100 or any other suitable system, can include: generating a routing table S210, determining a data routing path based on the routing table S220, and routing data to an endpoint based on the data routing path S230. The method 200 can additionally or alternatively include determining an object position S205, receiving a data packet from a data source S215, iteratively refining data routing path determination method S235, verifying data transmission to target node S240, sending a notification to a user device S245, or any other suitable step or set of steps, performed in any suitable order.
4.1 Determining an Object Position S205
The method can optionally include determining an object position S205, which functions to determine where an object (e.g., intermediary device) is in a predetermined volume (e.g., physical space, such as a room or building). The object 130 can receive the data packet from and/or transmit the data packet to the mesh network. The object can be a static device, mobile device, wireless access point, beacon, or be any other suitable object. The object preferably operates in a master or server mode (e.g., searches for slave or client devices to connect to), but can optionally operate in a slave or client mode or in any other suitable mode.
The object position can be determined by the object itself, by the mesh network, by a secondary system, or by any other suitable system. The determined object position is preferably stored by the data routing system but can optionally be stored by the object itself (e.g., retrieved upon system receipt of a data packet addressed to the object), or be otherwise stored. The object position can be the current, historical, and/or anticipated object position. The object position is preferably the physical location (e.g., coordinates, altitude) of the object within the space (e.g., such that the object can be mapped on a virtual map of the space), but can alternatively be a relative location (e.g., relative to the beacons cooperatively forming the mesh network), or be any other suitable location. The object position can be determined: periodically, upon receipt of data addressed to the object, once (e.g., for static objects), whenever the object is within a beacon's broadcasting range, or at any suitable time. The object position can be determined based on: the object kinematics (e.g., determined by object sensors; using dead reckoning, etc.), the known physical location(s) of the beacon(s) or secondary system(s) that connected to the object, the beacon packets received by the object, or based on any other suitable information.
In some variations, S205 includes broadcasting a set of node identifiers at a set of beacons, receiving the set of node identifiers at the remote computing system through the object (e.g., intermediary device, wherein the intermediary device acts as an intermediary and forwards all or portions of the received packet to the remote computing system), and determining a location of the object at the remote computing system based on the set of node identifiers.
S205 can be performed prior to or during the determination of the routing path (e.g., to determine access node), after the determination of the routing path (e.g., where the starting node is determined based on the data routing table, based on the data routing path, etc.), multiple times throughout the method (e.g., to locate multiple objects, to track the location of an object, etc.), or at any other time during the method.
In some variations, the locations of one or more intermediary devices 132 are determined based on the routing table.
In a first variation, example shown in
In a second variation, example shown in
However, the object location can be retrieved from a lookup table (e.g., based on the object address) or otherwise determined.
4.2 Generating a Routing Table S210
Generating a routing table S210 functions to determine one or more routing paths for a mesh network. Additionally or alternatively, S210 functions to store one or more mesh or node parameters, determine one or more mesh or node parameters (e.g., calculate a second set of parameters based on a first set of parameters), or perform any other suitable function.
S210 is preferably performed prior to receiving a data packet at the beacon mesh but can additionally or alternatively be performed after receiving a data packet at the beacon mesh, regularly (e.g., at a predetermined interval), after determining an object location S205, before determining an object location S205, in response to a trigger (e.g., updated operational parameters determined at data routing system), randomly, or at any other point.
S210 is preferably performed at the data routing system (e.g., remote computing system) but can additionally or alternatively be performed at a separate remote computing system, another processing system (e.g., at a client application of user device), a combination of systems, or at any other system.
S210 preferably includes: determining node telemetry and determining the routing table based on the node telemetry, but can additionally or alternatively include any number of steps and any other steps. The routing table can be determined in any or all of the following ways: manually (wherein an intermediary device with an application client is moved around the venue and receives packets broadcast by each node); using a flooding protocol (e.g., wherein each node or node cluster floods the network with node telemetry or other data); using a routing protocol (e.g., wherein each node forwards the respective node telemetry to a designated access point); or in any other suitable way.
In one variation, the routing table is determined initially through flooding, wherein the proximity and/or relative pose of adjacent nodes relative to each node can be determined through the flooded information and/or parameters thereof (e.g., transmission paths). Node telemetry (e.g., state of charge) for each node can optionally be determined from flooding (e.g., wherein the flooded information can include the respective node's telemetry). S210 can be static or repeated (e.g., upon change in the beacon mesh such as an added beacon, removed beacon, change in location of one or more beacons, etc.).
In a second variation, the routing table (and/or mesh topology) is determined from node telemetry, broadcast by the nodes of the mesh network. The node telemetry is preferably broadcast by each node and forwarded to the data routing system through one or more intermediate devices. In this variation, the intermediate device(s) can optionally be used to determine the relative proximity and/or poses of the nodes in the mesh (e.g., based on which nodes the advertisement packets are received from within a predetermined time window at the intermediary device, based on the intermediary device location or kinematic information, etc.). However, the mesh topology and/or routing table can be otherwise determined.
S210 can further include receiving and/or determining one or more parameters of the set of beacons, wherein the routing table is determined based on the parameters. Each of the parameters is preferably tagged with a corresponding beacon identifier (e.g., encrypted beacon identifier) but can additionally or alternatively be tagged with a group (e.g., beacon mesh) identifier, a set of coordinates (e.g., positional coordinates), any other suitable tag, or can be untagged.
The parameters can be determined from node telemetry, a user input, a set of predetermined settings, an algorithm (e.g., predictive algorithm, deep learning algorithm, etc.), or any other suitable source. Parameters preferably include a power level (e.g., charge level battery) of each beacon but can additionally or alternatively include a beacon location (e.g., relative to another beacon, within a physical space, height, etc.), temporal parameter (e.g., time since beacon last broadcast a signal), data from a sensor associated with one or more beacons (e.g., motion sensor, temperature sensor, optical sensor, etc.), strength of a signal broadcast by a beacon (e.g., RSSI), type of signal broadcast by a beacon (e.g., default signal, emergency signal, etc.), message cache parameters (e.g., message identifiers, message numbers in the cache, etc.), or any other suitable parameter.
The parameters (e.g., node telemetry) are preferably received at the data routing system (e.g., remote computing system) via one or more intermediary devices (e.g., user devices) but can additionally or alternatively be received directly at the data routing system (e.g., from user input, from the beacon mesh, etc.), predetermined (e.g., static) and stored at the data routing system, or received at the data routing system in any suitable way.
S210 can optionally include determining mesh topology, wherein the routing table is determined at least in part from mesh topology. The mesh topology can be automatically determined by the mesh nodes, determined by an application executing on a user device, or otherwise determined. In a first variation, the mesh nodes operate the respective radios in the transmission mode upon satisfaction of a setup condition (e.g., mesh node attachment to a surface, mesh node orientation in a predetermined orientation, etc.), wherein the identities and relative positions of neighboring nodes can be automatically determined based on the signal parameters (e.g., RSSI, time of flight, angle of arrival, etc.), the node telemetry (e.g., orientation relative to gravity, etc.), and/or any other suitable information. In this variation, the identifiers for the neighboring beacons can be stored on-board the beacon (e.g., in on-board memory), transmitted through the mesh to the data routing system for indexing and/or storage, or otherwise managed. In a second variation, the application on the user device automatically logs user device parameters, such as location and time, along with the beacon packet parameters (e.g., beacon identifiers, RSSI, angle of arrival, etc.) that are received as a user walks within the space. In this variation, the application can optionally determine whether a beacon is located within the broadcasting range (e.g., of the broadcasting radio, communication radio) of an adjacent beacon (e.g., the RSSI for a first beacon's signal is above a first RSSI threshold, and the RSSI for a second beacon's signal is above a second RSSI threshold, the second RSSI threshold lower than the first and associated with an outer limit of a broadcasting range).
In one variation, the data routing table is eventually used to determine a routing path S220 (e.g., routing path determined to minimize distance between beacons through which data packet travels). Alternatively, the data routing table can be composed of routing paths (e.g., determined simultaneously). Each routing path preferably optimized for one or more network parameters (e.g., overall battery life, overall bandwidth, overall latency, etc.), or optimized based on the parameters (e.g., battery life, bandwidth, latency, etc.) for each node or cluster, but can be otherwise determined.
The data routing system can generate and store a different routing path for each endpoint pair permutation. Alternatively, the data routing system can dynamically determine a routing path in response to occurrence of a trigger event (e.g., receiving an identifier for a node within the local mesh, determining that data needs to be pushed to a node within the local mesh, etc.). The data routing system can dynamically update the routing paths within the routing table in response to receiving updated beacon telemetry, at a predetermined frequency, or at any suitable time.
In one variation, node telemetry is received at the data routing system (e.g., remote computing system), wherein the node telemetry includes a battery level for each node and wherein the routing table is determined at least in part from the set of battery levels. In a specific example, the node telemetry is received at the remote computing system through a user device.
In a second variation, node telemetry is received at the data routing system (e.g., remote computing system), wherein the node telemetry includes a signal strength of a data packet received at a first beacon from an adjacent beacon, wherein the routing table is determined at least in part based on the signal strength. In a specific example, the signal strength is used at the data routing system to determine (e.g., calculate) a physical distance between the beacons.
4.3 Receiving a Data Packet from a Data Source S215
The method 200 can optionally include receiving a data packet from a data source 215. The data source can be a static device (e.g., beacon, connected fixture, wireless access point), a mobile device (e.g., user device), or any other suitable object. The data packet is preferably received at a mesh node, but can alternatively or additionally be received at the data routing system or be received at any other suitable system. The data can be: beacon data (e.g., addressed to one or more beacons or beacon populations), object data, or be any other suitable data. The data packet preferably includes data associated with the mesh network (e.g., addressed to a node within the mesh network), but can alternatively or additionally include data associated with a client executing on a mobile device that receives packets from the mesh network, or any other suitable data associated with the local mesh in any suitable manner.
The data packet is preferably received (and/or transmitted) to the mesh network (e.g., via an intermediary device within communication distance of the mesh network) when an intermediary device receives a packet from a node in the mesh. In one variation, the data packet is transmitted (e.g., from the remote computing system, data routing system) when the first node is part of a mesh network that is associated with a data packet (e.g., unsent data packet) that, in turn, is associated with a target node within the mesh network (e.g., wherein a data packet is transmitted in response to determination that the data packet, addressed to a target node within a mesh shared with the first node: exists, is unsent, or has not been received by the target node). However, the data packet can be received and/or transmitted at any suitable time.
In some variations, the beacon data includes beacon settings (e.g., broadcasting scheme) and/or operational parameters. These can include any or all of: location settings (e.g., advertising interval, broadcasting power, etc.), telemetry (e.g., connection parameters), conditional broadcasting parameters, conditional receipt parameters, and/or any other suitable parameters. These settings and/or parameters can be updated (e.g., routinely updated, updated in response to an update received at a remote server, updated in response to a change in the beacon mesh, etc.) or static. The settings and/or parameters can be automatically updated, updated once one or more communication radios are in a predetermined operation mode (e.g., listening mode, master mode, etc.), updated in response to a user input (e.g., user input at a client application executing on a user device, user input at a remote server, etc.). The beacon data can include one or more beacon identifiers (BID), which function to associate a data packet with a specific (e.g., individually-addressed) beacon.
The data is preferably encrypted (e.g., wherein the endpoint has the corresponding cryptographic key), but can alternatively be unencrypted. The data can include: beacon updates (e.g., setting changes, etc.), beacon outputs (e.g., beacon telemetry, beacon operation parameters), object outputs generated by the in-situ object (e.g., telemetry data, operation parameters or operation notifications, sampled data, etc.), device control instructions (e.g., remote control instructions), or be any other suitable information.
Each of the BIDs are preferably encrypted, but can additionally or alternatively be unencrypted, decrypted, or have a subset that are encrypted. In one variation, encrypted BIDs are decrypted at the data routing system (e.g., remote computing system, cloud-based server, etc.). In a specific example, the method involves data transfer between a beacon mesh, intermediary device (e.g., mobile phone), and remote computing system (e.g., cloud-based server), where the BID is encrypted at the beacon, decrypted at the remote server, and used to determine a data packet transmitted from the remote server to a user device (e.g., intermediary device).
Receiving the data packet from the data source preferably includes: operating the data source in a scanning or master mode, detecting a mesh node within range (e.g., within broadcasting range), connecting to the mesh node, and transmitting data to the mesh node over the established connection. However, the data can be otherwise received. The mesh node (e.g., beacon) receiving the data packet is preferably the beacon most proximal the data source (e.g., the beacon with the highest RSSI), but can alternatively be all beacons within range (e.g., wherein the beacons can bid for control or otherwise determine which of the received beacon packets control) or be received by any other suitable system. The mesh node can be determined based on the location of an intermediary device (e.g., beacon closes to intermediary device), can be a node within broadcasting range of a previous node or device, can be the first node in a data routing path, can be the node with a high (e.g., highest) charge, or can be determined in any other way.
The data can include: the data packet, routing instructions (e.g., routing path; wherein the data source functions as the data routing system and retrieves the mesh topography from a local or remote repository), and/or any other suitable information. When the data lacks routing instructions, receiving the data packet can optionally include: routing the data packet to the data routing system (e.g., through the mesh, using a flooded technique or a predetermined transmission route for each node), wherein the data routing system subsequently determines the data routing path. Additionally or alternatively, receiving the data packet can optionally include: determining data packet parameters from the data packet (e.g., packet size, information type, header information, which node the data packet is stored at, etc.), routing data packet parameters to the data routing system, and subsequently routing the data packet from the recipient mesh node to the endpoint based on the routing path determined by the data routing system. However, the data packet can be otherwise received.
S215 can further include determining the data packet, which can include operation parameter settings (e.g., conditional broadcasting settings, frequency of broadcasting, frequency of switching radio operation mode, etc.) for one or more beacons, a message (e.g., to be sent to a user through a user device), command, or any other suitable data type, wherein the endpoint can operate according to the operation parameter settings upon packet receipt. The data packet can be determined based on input from an intermediary device, predetermined, include data uploaded to the data routing system, or include any data determined in any suitable way.
4.4 Determining a Data Routing Path Based on the Data Routing Table S220
Determining a data routing path through the wireless system mesh S220 functions to identify a series of mesh nodes to be used to transmit data to the endpoint. Alternatively, the mesh network can relay messages using a flooding technique, or any other suitable technique. Additionally or alternatively, S220 can function to minimize a routing parameter (e.g., energy consumption, time, etc.) for data transfer, minimize the number of beacons involved in the transfer of data, preserve energy within one or more beacons in a mesh (e.g., transfer data between beacons having the highest power), determine the locations and/or layout of one or more beacons (e.g., relative to each other, absolute, within a physical space, etc.), or perform any other suitable function.
The data routing path is preferably determined by the data routing system, but can additionally or alternatively be determined by any other suitable system. The data routing path is preferably transmitted with the data packet, but can alternatively be transmitted separate from the data packet (e.g., over a different channel, before data packet transmission, etc.).
S220 is preferably performed after a data routing table has been generated but can additionally or alternatively be performed simultaneously (e.g., with partial overlap) with the determination of the routing table, without the use of a routing table (e.g., dynamically determined at beacon(s)), multiple times throughout the method, during transfer of data (e.g., after receipt at multiple beacons in the routing path, after transmission to multiple beacons in the routing path, in response to a change in mesh, in response to a change in a beacon parameter, etc.), or at any other suitable time. Additionally or alternatively, S220 can be performed after a data packet has been received at a first node, before a data packet has been received at the first node, or at any other suitable time or set of times. In some variations, S210 and S220 can be combined into a single step (e.g., when data routing table includes only one or more multiple data routing paths). Alternatively, the method can be performed without one of S210 or S220.
In one example, the data routing path can be predetermined and distributed to the mesh (e.g., using the flooded technique, using the data routing table), wherein each node in the path stores the address of the respective child node (e.g., for a given packet identifier, packet type, etc.). However, the data routing path can be otherwise passed or stored. The data routing scheme preferably enables a unicast addressing method, but can additionally or alternatively enable an anycast scheme, a multicast scheme, a geocast scheme, a broadcast scheme, or any other suitable scheme. The data routing path preferably identifies the beacons the data packet should be transmitted through, when the data packet should be transmitted to the next beacon in the path (e.g., timestamp for scheduled transmission), and/or the order of beacons within the transmission path). However, the data routing path can include which radio (communication radio) to use for packet communication (e.g., for each node, for the path, etc.), the transmission duration, the transmission power, or include any other suitable information. For example, the communication radio can be: a predetermined radio, a radio selected based on the data packet parameters (e.g., based on the required latency, determined based on the packet header, packet analysis etc.; packet priority; packet size, etc.), a radio or channel selected based on the parent node's communication radio or channel (e.g., be the same or different radio or channel), or be otherwise determined. Alternatively, the node can determine all or part of the transmission parameters discussed above.
The data routing path can be static (e.g., predefined for a specific endpoint, such as a static object), dynamic (e.g., change based on mesh operation parameters, endpoint location, etc.), updated at predetermined intervals of time, updated at random intervals of time, or otherwise variable. The data routing path is preferably determined before routing the data through the mesh (e.g., once, in response to receipt of data addressed to the endpoint, upon determination that the endpoint has moved, etc.), but can alternatively be determined while the data is being routed through the mesh, or at any other suitable time. The data routing path is preferably determined based on the known mesh topology (e.g., physical beacon locations, EMI regions, etc.) and the endpoint's position within the physical space (e.g., current, historical, or anticipated), but can additionally or alternatively be determined based on data packet parameters (e.g., size, latency requirement, data source priorities), each node's operating parameters (e.g., current or anticipated; such as battery level or state of charge, device connection frequency, which radios will be available, etc.), each node's communication load (e.g., current and/or anticipated data traffic for each node), or any other suitable parameter (example shown in
The data routing path can be: estimated based on the parameters above, iteratively refined, randomly determined, calculated (e.g., optimized), predetermined, determined based on an algorithm, partially or fully determined through deep learning (e.g., machine learning), or otherwise determined. Examples of methodologies that can be used to determine the data routing path include: position-based routing, proactive routing (e.g., OLSR, Babel FRC, DSDV, DREAM), reactive routing (e.g., ABR, AODV, FRC, flow state in RFC, power-aware DSR-based routing), hybrid routing (e.g., ZRP, ZHLS), hierarchical routing protocols (e.g., CBRP, FSR, Order one network protocol, ZHLS), distance vector algorithm (e.g., Bellman-Ford algorithm, RIP, OSPF, IS-IS, EIGRP), link-state routing protocol (e.g., Dijkstra), optimized link state routing protocol, path vector routing, heuristic routing, fuzzy routing, policy-based routing, wormhole routing, small world routing, turn restriction routing, edge disjoint shortest pair algorithms, or any other suitable protocol or combination thereof. Determining the data routing path can employ self-healing algorithms (e.g., shortest path bridging), and/or use any other suitable method.
The data routing path is preferably determined at the data routing system (e.g., remote computing system where routing table is generated). Additionally or alternatively, the data routing path can be determined at a local computing system, a user device (e.g., client application executing on user device), at multiple computing systems (e.g., at two remote computing systems, at a remote computing system and at a client application executing on a user device, etc.), or any other suitable location. In some variations, the routing path is at least partially determined and/or stored at a beacon or group of beacons. Additionally or alternatively, the routing path can be predetermined.
The data routing path preferably includes all beacons at which a data packet will be received (e.g., child node; successive node) and optionally transmitted from (e.g., parent node; preceding node). This can include just a first beacon (e.g., endpoint, starting beacon, etc.); a first beacon and a target beacon (e.g., endpoint); a first beacon, a target beacon, and all beacons in between (e.g., all hops in between first and target beacons); or any other suitable set of beacons. The beacons are preferably individually addressed in the routing path through a beacon identifier (e.g., unencrypted beacon identifier, encrypted beacon identifier, decrypted beacon identifier, etc.), but can additionally or alternatively be individually addressed with any suitable tag (e.g., physical location tag, battery level tag, etc.), addressed as a group, or identified in any other suitable way.
In some variations, the routing path includes one or more mobile objects (e.g., intermediary device, user device, mobile beacon, etc.), wherein a data packet is transferred to and/or received from the mobile object. In these variations, the routing path can include an access node proximal to (e.g., adjacent to, in closest proximity to out of the set of beacons, within range, in the same physical venue, etc.) the mobile object. The access node can be predetermined, dynamically determined (e.g., based on location of mobile object), or otherwise determined.
In a specific example, for instance, the target node includes a mobile object (e.g., intermediary device), wherein the routing path includes an access node, the access node immediately preceding the target node in the routing path.
In some variations, the data routing path can be determined to maximize the overall mesh lifespan, each node's lifespan, the overall power consumption, probability of packet receipt, or any other suitable parameter. Alternatively or additionally, the data routing path can be determined to minimize the number of node hops, the latency, network path length, physical path length, or any other suitable parameter. In a specific example, the data routing path can route around high-traffic beacons (e.g., beacons detecting devices passing by at a rate higher than a threshold rate), which can minimize energy consumption and/or maximize beacon broadcasting time.
4.5 Routing Data to an Endpoint Through the Mesh S230
Routing the data to the endpoint through the mesh S230 functions to communicate data from the source object (data source) to the endpoint object. The data is preferably routed to the endpoint through the determined data routing path, but the data can alternatively be flooded into the mesh or otherwise transmitted through the mesh to the endpoint.
Routing the data through the determined path preferably includes selectively operating the radio(s) of each successive node (beacon) within the determined path to send and/or receive the data packet(s), then switching the radio(s) into a default operation mode (e.g., standby, client mode) after the data has been transmitted. This selective radio operation can function to minimize beacon power consumption while enabling data transmission functionality. Alternatively or additionally, S230 can include selectively operating the nodes (e.g., all nodes in the mesh, a subset of the nodes, etc.) in a scanning mode for a predetermined duration (e.g., 1 minute) at a predetermined frequency (e.g., according to a schedule, every 3 minutes, etc.), wherein the data can be routed through as many nodes (hops) in the routing table while the mesh operates in the scanning mode. The data can be temporarily cached in the intermediary node (e.g., along the routing path) when the mesh collectively switches back to operation in the advertising mode, and forwarded along the remainder of the routing path the mesh next operates in the scanning mode. However, the nodes of the mesh can otherwise implement S230.
The radio used to communicate the data (communication radio) is preferably the beacon's high bandwidth radio (e.g., UWB, WiFi), but can alternatively be the beacon's low bandwidth radio (e.g., BLE 5.0), or be any other suitable radio. The communication radio can be the radio used to broadcast beacon packets (e.g., location packets, content packets) or be a different radio. For example, different radios can be selected for streaming video, versus transmitting control instructions or device updates. However, the data can be otherwise routed through the data routing path.
Routing data preferably includes, for each node: determining transmission condition satisfaction, selectively operating the communication radio in the transmission mode in response to transmission condition satisfaction, receiving the data packet from a parent node in the data routing path, transmitting the data packet to a child node in the data routing path, and selectively operating the radio in a default mode after data packet transmission, example shown in
The transmission condition can be predetermined, determined by the data routing system, or otherwise determined. The transmission condition can be: timer expiration, the current time matching a scheduled time, receipt of instructions to operate the communication radio, receipt of a data packet at the node, or any other suitable transmission condition. The instructions can be determined by and/or received from the data source, a parent node (e.g., in the data path, in a flooded system), a secondary object (e.g., wherein the parent node transmits the instruction to the secondary object, which relays the instruction to the node), or from any other suitable source. The instructions can include: the radio selection, the broadcasting parameters, the data routing path, an identifier for the child node (e.g., next node in the path), or any other suitable information. The instruction can be received by the broadcast radio, the communication radio, or by any other suitable radio. In a first variation, determining transmission condition satisfaction includes: scanning for beacon packets broadcast by the node with a broadcast radio of the parent node operating in a transmission mode; establishing a connection between the node and a parent node over a broadcast radio (e.g., broadcasting a low-bandwidth beacon packet), and receiving an instruction to operate the communication radio (e.g., of the child node) over the broadcast radio. In a second variation, determining transmission condition satisfaction includes: broadcasting an instruction packet addressed to the node from the parent node, and scanning for and receiving the broadcast instruction packets addressed to the node at the node. However, the instructions can be otherwise received. However, the transmission condition can be otherwise satisfied. The transmission condition can additionally or alternatively include determining a setting update for one or more beacons within the mesh network (e.g., a request received through an intermediary device), determining the generation of new settings at a remote computing system (e.g., routine updates), determining a need to update a routing table and/or routing path in response to a change in beacon mesh (e.g., in response to receiving an “emergency signal” from one or more beacons, in response to detecting a new BID, in response to receiving updated node telemetry values, etc.), or determining any other suitable need or event.
The transmission condition can optionally be prompted by a user (e.g., at a user device, remote computing system interface, etc.). In one variation, a user prompts updating beacon settings (e.g., operational settings, operational parameters, etc.) at a client application executing on user device (e.g., mobile phone, computer, etc.). In a second variation, a user prompts updating beacon settings through an interface with a remote computing system (e.g., cloud computing system), wherein the updated settings are generated and/or stored at the remote computing system.
S230 can include selectively operating the communication radio in a predetermined mode (e.g., scanning mode, advertising mode, etc.), which functions to enable high-bandwidth beacon data receipt and/or transmission.
For example, when the communication radio is in a scanning mode, it is configured to receive signals at the beacon. In some variations, the beacon can additionally advertise (e.g., broadcast) while scanning. The scanning mode can require higher energy/power to operate in than a default mode (e.g., advertising mode, standby mode, etc.) of the beacons, wherein the beacons are simply broadcasting. The scanning mode can be selectively initiated in response to satisfaction of a transmission condition, wherein the transmission condition requires a data packet to be received at the beacon (e.g., based on routing path), or otherwise initiated.
In a first variation, S230 includes selectively operating the broadcasting radio (e.g., BLE radio) in the transmission mode, which can include ceasing beacon packet broadcasting. In a second variation, S230 includes selectively operating the high-bandwidth radio (e.g., UWB radio) in the transmission mode. In this variation, the beacon can temporarily cease broadcasting radio operation, maintain broadcasting radio operation (e.g., keep broadcasting beacon packets during data transmission), or otherwise operate other radios.
In a third variation, a first beacon (node) receives the packet and floods the packet to the mesh (e.g., when other nodes switch into the scanning mode at a predetermined schedule).
In a fourth variation, a first beacon (e.g., mesh node) of the beacon network receives information (e.g., a data packet and routing path) from the data routing system.
The information is preferably addressed to at least a target node (e.g., tagged with a target node beacon identifier), further preferably addressed to each node in the routing path (e.g., endpoints, hops, etc.), but can additionally or alternatively be addressed to any number of nodes, addressed to a group of nodes, or not addressed.
Routing the packet preferably includes: sequentially switching each node identified in the routing path from an advertising mode, to a scanning mode, and back to the advertising mode, wherein each node transmits and/or receives the information (e.g., data packet and/or routing path) while in the scanning mode. The packet is preferably unicast to the successive node (e.g., identified in the routing path), but can alternatively be multicast to a set of potential successive nodes or otherwise broadcast to the rest of the mesh network.
In some variations, routing the packet includes: at a preceding node identified in the routing path, scanning for a successive packet advertised by the next node (successive node) identified in the routing path; and in response to receiving the successive packet, transmitting the packet to the successive node (e.g., by connecting to the successive node), wherein the successive node subsequently operates as the preceding node. The preceding node can optionally decrement the TIL value in the received packets and/or routing path, maintain a packet cache for forwarded packets, or maintain and/or adjust any other information.
The preceding node can optionally discard the packets, packet cache, routing path, or other information. The information is preferably discarded after the data (packet) is routed to the successive node, but can alternatively be discarded independent of successive node packet receipt. The preceding node can discard the information upon receiving confirmation that the successive node received the packet (e.g., upon receipt of a confirmation packet from the successive node), after a predetermined number of transmission cycles or advertisement cycles (e.g., 1 cycle, 10 cycles, etc.; wherein the cycle number can be specified by the packet, be a default number, or be otherwise determined), after the data routing system determines that the endpoint received the packet (e.g., based on target node or endpoint behavior change; target node packet information; confirmation packet transmission, etc.), or upon occurrence of any other suitable discard event.
Receiving the data packet from the parent node in the data routing path functions to receive the data packet and/or data routing path information. This can optionally include caching the data packet in on-board beacon storage, authenticating the parent node (e.g., as a node that can inject packets into the network), or any other suitable process. The data packet can be received from the parent node using the same or different communication radio as that used to transmit the data packet to the child node. Receiving the data packet can include: establishing a connection with the parent node and receiving the data packet over the connection. The connection is preferably controlled by the parent node, but can alternatively be controlled by the node. In one example, this includes: operating the communication radio in the client mode in response to instruction receipt from the parent node; at the parent node, connecting to the node using the communication radio protocol; and transmitting the data packet from the parent node to the node. In a second example, this includes: operating the communication radio in a master mode in response to instruction receipt from the parent node; scanning for the parent node (e.g., with the communication radio and/or broadcasting radio, wherein the parent node identifier is determined from the received instructions); connecting to the parent node using the communication radio; and retrieving the data packet from the parent node. However, the connection can be otherwise established.
Transmitting the data packet to the child node functions to pass the data packet to the next node in the data routing path. The child node identifier is preferably extracted from the data routing path (e.g., received from the parent node, retrieved from on-board storage, etc.), but can additionally or alternatively be extracted from on-board storage, from the instruction (e.g., received from the parent node), or otherwise determined. Transmitting the data packet to the child node can include: establishing a connection with the child node and receiving the data packet over the connection. The child node connection can be established before data packet receipt and/or parent node connection (e.g., when the child node identifier is received as part of the instruction, when the transmission is scheduled and the child node identifier is stored on-board the beacon, etc.), be established after data packet receipt and/or parent node connection (e.g., wherein the child node identifier is received from the parent node, extracted from the data routing path received with the data packet, etc.), or be established at any other suitable time. In a first variation, the same radio is used to receive and send the data packet. The radio can be concurrently connected to both the parent and child nodes (e.g., wherein the node radio is operating in the master or server mode); serially connected to the parent, then to the child node (e.g., wherein the parent node can terminate the connection after a receipt confirmation from the node, the node can operate the communication radio in a master or server mode and search for and connect to the child node); or be connected to any suitable set of nodes at any suitable time. In a second variation, different radios and/or channels are used to receive and send the data packet. The data packet can be periodically re-transmitted until a receipt confirmation is received from the child node, until a threshold number of attempts are made, or until any other suitable condition is met. However, the data packet can be otherwise transmitted to the child node.
Selectively operating the radio in the default mode functions to conserve node power. This is preferably automatically performed after the receipt confirmation is received from the child node, but can be performed at any other suitable time or not performed at all. In a default mode (e.g., low energy mode), the radio preferably only broadcasts, but can alternatively perform any suitable functionality. The radio can broadcast continuously, at a predetermined interval of time (e.g., every three minutes), based on sensor data (e.g., when light is above a threshold based on an optical sensor, based on motion sensor data, etc.), broadcast according to the node settings, or at any other suitable time(s).
Routing the data can optionally include verifying data packet transfer. In a first variation, this includes the parent node receiving a receipt confirmation from the child node. In a second variation, this includes: receiving a beacon packet from a node that should have received the data packet, and verifying that the beacon received the data packet based on packet information (e.g., checking the firmware version number). However, the data packet transfer can be otherwise verified.
4.6 Additional Steps
The method 200 can optionally include any number of additional steps, such as, but not limited to, those described below.
The method 200 can include iteratively refining the path-determination method (e.g., to accommodate for wireless interference, such as EMI topology, specific to the physical space; to refine the object location determination methods; etc.). Refining the path-determination method can include: adjusting parameter weights, selecting a new path determination method, or otherwise refining the method. The path determination method can be refined periodically, after each data packet is transmitted, or at any other suitable time. In a first variation, this can include refining the path determination methods based on packet receipt data from the endpoint (e.g., receipt time, number of lost packets, etc.), the data routing path for the respective data packet (e.g., retrieved from the intervening nodes, from the data routing system, etc.), the mesh operation parameters for the data transmission time, and/or any other suitable information. The path determination methods can be refined (e.g., generated, calculated, etc.) using supervised learning (e.g., using logistic regression, using back propagation neural networks, using random forests, decision trees, etc.), unsupervised learning (e.g., using an Apriori algorithm, using K-means clustering), semi-supervised learning, reinforcement learning (e.g., using a Q-learning algorithm, using temporal difference learning), or otherwise determined. However, the path determination method can be otherwise optimized (e.g., using RF mapping techniques, using historic paths of object travel through the physical monitored space, etc.). In some variations, the path-determination method is refined in response to detecting a change in the mesh (e.g., beacon added, beacon removed, beacon unresponsive, threshold change in beacon telemetry values, etc.) as described previously.
The method 200 can optionally include setting up the mesh network. This can include: physically arranging the mesh nodes within the space and determining the mesh topology. The physical arrangement of the mesh nodes within the space is preferably defined by a user, but can be defined based on a physical map of the space (e.g., optimal node positions determined based on estimated foot traffic paths, estimated EMI topology, etc.), or be otherwise defined. The mesh topology can include the node physical locations (e.g., x, y, z, orientation angle, matrix distance to other beacons, etc.), the traffic for each node (e.g., current, anticipated; determined based on the determined data routing paths, etc.), or any other suitable information. The mesh topology can be represented as a random geometric graph, physical map, or otherwise represented.
The method 200 can optionally include sending one or more notifications to a user device (e.g., intermediary device). The notifications can be related to any or all of: beacon parameters, such as power (e.g., battery needs to be replaced, battery will die in next 2 weeks, etc.), status (e.g., beacon has fallen off wall, additional beacon has been added), targeted content based on user device location (e.g., as determined in step above), or any other information.
The method 200 can optionally include verifying data transmission to a target node, which can include: at the remote computing system, receiving one or more advertisement packets broadcast by the target node and determining that the target node is operating according to the operation parameter settings (within the data packet) based the advertisement packets. In one variation, data packets are received at the remote computing system through one or more intermediary devices. However, data transmission to the target node can be otherwise verified.
The method 200 can optionally include determining a physical location for the intermediary device, which can function to locate the intermediary device with high precision. The intermediary device is preferably located using the methods described in U.S. application Ser. No. 15/921,844 filed 15 Mar. 2018, Ser. No. 15/436,564 filed 17 Feb. 2017, Ser. No. 15/466,680 filed 22 Mar. 2017, and/or Ser. No. 15/900,171 filed 20 Feb. 2018, each of which are incorporated herein in their entireties by this reference, but can alternatively or additionally be located in any other suitable manner. In one variation, determining a physical location for the intermediary device includes: receiving a set of advertisement packets broadcast by a set of beacons (nodes), each with a known physical location (e.g., within a predetermined time window, such as a broadcast window); and determining the device location based on the known physical locations of the beacons associated with the advertisement packets (e.g., associated with the beacon identifiers within the advertisement packets) and, optionally, the respective packet RSSIs, the beacon telemetry, or other factor. The device location can be determined by the device, a third party system, the data routing system, a remote computing system, or any suitable system. The device location can be determined using trilateration, triangulation, or any suitable method.
4.7 Variations
In a first variation, the method 200 includes generating a data routing table through flooding and sending data to the data routing system. In a specific example, the routing table is generated once (e.g., wherein the routing table can include static routing paths) and then stored in a remote server (e.g., cloud, data routing system, etc.). The routing table is then used to route data (e.g., updated settings/operational parameters) throughout a mesh of individually-addressed beacons, wherein the routing paths can be transmitted to the mesh (e.g., each mesh node in the routing path) or otherwise used. Data routing through the mesh is preferably proactive, but can alternatively be reactive.
In a second variation, the method 200 includes determining a location of an intermediary device by broadcasting BIDs from a set of beacons, determining a first beacon based on proximity to the intermediary device, generating a routing path, transmitting the routing path along with a data packet for the first beacon from a remote computing system (e.g., data routing system) to the intermediary device to the first beacon, transmitting the data packet and routing path to any number of intermediate beacons including finally a target beacon, and verifying transfer of data packet to target beacon.
Embodiments of the system and/or method can include every combination and permutation of the various system components and the various method processes, wherein one or more instances of the method and/or processes described herein can be performed asynchronously (e.g., sequentially), concurrently (e.g., in parallel), or in any other suitable order by and/or using one or more instances of the systems, elements, and/or entities described herein.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
This application is a continuation of U.S. application Ser. No. 16/685,805, filed on 15 Nov. 2019, which is a continuation of U.S. application Ser. No. 16/152,254, filed on 4 Oct. 2018, which is a continuation of U.S. application Ser. No. 15/997,567 filed 4 Jun. 2018, each of which is incorporated in its entirety by this reference. U.S. application Ser. No. 15/997,567 claims the benefit of U.S. Provisional Application No. 62/514,110, filed 2 Jun. 2017, and is a continuation in part of U.S. application Ser. No. 15/900,171, filed 20 Feb. 2018, which is a continuation of U.S. application Ser. No. 15/784,774, filed 16 Oct. 2017, which is a continuation of U.S. application Ser. No. 15/590,939, filed 9 May 2017, which claims the benefit of U.S. Provisional Application No. 62/416,395, filed 2 Nov. 2016, and U.S. Provisional Application No. 62/334,115, filed 10 May 2016, each of which is incorporated in its entirety by this reference. This application is related to U.S. application Ser. No. 15/829,800, filed 1 Dec. 2017, which is a continuation of U.S. application Ser. No. 15/644,428, filed 7 Jul. 2017, which claims the benefit of U.S. Provisional Application No. 62/416,344, filed 2 Nov. 2016, and U.S. Provisional Application No. 62/359,543, filed 7 Jul. 2016, each of which is incorporated in its entirety by this reference. This application is related to U.S. application Ser. No. 15/897,817, filed 15 Feb. 2018, which is a continuation of U.S. application Ser. No. 15/789,767, filed 20 Oct. 2017, which is a continuation of U.S. application Ser. No. 15/446,165, filed 1 Mar. 2017, which is a continuation of U.S. application Ser. No. 15/253,376, filed 31 Aug. 2016, which claims the benefit of U.S. Provisional Application No. 62/213,467, filed 2 Sep. 2015, each of which is incorporated in its entirety by this reference. This application is related to U.S. application Ser. No. 15/921,844, filed 15 Mar. 2018, which is a continuation of U.S. patent application Ser. No. 15/620,014, filed 12 Jun. 2014, which is a continuation of U.S. patent application Ser. No. 15/288,302, filed 7 Oct. 2016, now issued as U.S. Pat. No. 9,712,967, which is a continuation of U.S. patent application Ser. No. 14/956,209, filed 1 Dec. 2015, now issued as U.S. Pat. No. 9,491,586, which is a continuation of U.S. patent application Ser. No. 14/463,582, filed on 19 Aug. 2014, now issued as U.S. Pat. No. 9,202,245, which claims the benefit of U.S. Provisional Application No. 61/867,493, filed on 19 Aug. 2013 and to U.S. Provisional Application No. 61/867,498, filed on 19 Aug. 2013, each of which is incorporated in its entirety by this reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6091358 | Maniscalco et al. | Jul 2000 | A |
| 6362778 | Neher | Mar 2002 | B2 |
| 6775258 | Van et al. | Aug 2004 | B1 |
| 6873258 | Marples et al. | Mar 2005 | B2 |
| RE38899 | Fischer | Nov 2005 | E |
| 6965575 | Srikrishna et al. | Nov 2005 | B2 |
| 7027808 | Wesby | Apr 2006 | B2 |
| 7038584 | Carter | May 2006 | B2 |
| 7072671 | Leitch | Jul 2006 | B2 |
| 7146178 | Lehikoinen et al. | Dec 2006 | B2 |
| 7283846 | Spriestersbach et al. | Oct 2007 | B2 |
| 7312752 | Smith et al. | Dec 2007 | B2 |
| 7366113 | Chandra et al. | Apr 2008 | B1 |
| 7458825 | Atsmon et al. | Dec 2008 | B2 |
| 7499462 | MacMullan et al. | Mar 2009 | B2 |
| 7564812 | Elliott | Jul 2009 | B1 |
| 7639131 | Mock et al. | Dec 2009 | B2 |
| 7683761 | Burghard et al. | Mar 2010 | B2 |
| 7705728 | Mock et al. | Apr 2010 | B2 |
| 7706282 | Huang | Apr 2010 | B2 |
| 7835505 | Toyama et al. | Nov 2010 | B2 |
| 7855679 | Braiman | Dec 2010 | B1 |
| 7865306 | Mays | Jan 2011 | B2 |
| 7983677 | Dacosta | Jul 2011 | B2 |
| 8058988 | Medina et al. | Nov 2011 | B1 |
| 8139945 | Amir et al. | Mar 2012 | B1 |
| 8160056 | Van et al. | Apr 2012 | B2 |
| 8260320 | Herz | Sep 2012 | B2 |
| 8265621 | Kopikare et al. | Sep 2012 | B2 |
| 8407417 | Matsuda et al. | Mar 2013 | B2 |
| 8489112 | Roeding et al. | Jul 2013 | B2 |
| 8520648 | Cordeiro | Aug 2013 | B2 |
| 8559975 | Basu et al. | Oct 2013 | B2 |
| 8566839 | Johnson et al. | Oct 2013 | B2 |
| 8594850 | Gourlay et al. | Nov 2013 | B1 |
| 8600341 | Johnson | Dec 2013 | B2 |
| 8612604 | Beatty et al. | Dec 2013 | B2 |
| 8634796 | Johnson | Jan 2014 | B2 |
| 8639267 | Johnson | Jan 2014 | B2 |
| 8644255 | Burcham et al. | Feb 2014 | B1 |
| 8694060 | Vanderaa et al. | Apr 2014 | B2 |
| 8694782 | Lambert | Apr 2014 | B2 |
| 8718598 | Johnson | May 2014 | B2 |
| 8723720 | Moffatt et al. | May 2014 | B2 |
| 8750823 | Johnson | Jun 2014 | B2 |
| 8750841 | Johnson et al. | Jun 2014 | B2 |
| 8761751 | Johnson et al. | Jun 2014 | B2 |
| 8761804 | Johnson | Jun 2014 | B2 |
| 8781502 | Middleton et al. | Jul 2014 | B1 |
| 8791901 | Mallinson | Jul 2014 | B2 |
| 8797144 | Hinman et al. | Aug 2014 | B2 |
| 8797214 | Taylor et al. | Aug 2014 | B2 |
| 8844007 | Vicente et al. | Sep 2014 | B2 |
| 8847754 | Buchheim et al. | Sep 2014 | B2 |
| 8855922 | Starenky et al. | Oct 2014 | B1 |
| 8867993 | Perkins et al. | Oct 2014 | B1 |
| 8868133 | Rosenbaum et al. | Oct 2014 | B1 |
| 8886226 | Johnson | Nov 2014 | B2 |
| 8886230 | Sydir et al. | Nov 2014 | B2 |
| 8887177 | Johnson et al. | Nov 2014 | B2 |
| 8896485 | Mendelson | Nov 2014 | B2 |
| 8897741 | Johnson | Nov 2014 | B2 |
| 8897742 | Johnson | Nov 2014 | B2 |
| 8911932 | Sun | Dec 2014 | B2 |
| 8923806 | Johnson | Dec 2014 | B2 |
| 8934389 | Kuehnel et al. | Jan 2015 | B2 |
| 8938196 | Bradish et al. | Jan 2015 | B2 |
| 8942693 | Johnson | Jan 2015 | B2 |
| 8942732 | Johnson | Jan 2015 | B2 |
| 8942733 | Johnson | Jan 2015 | B2 |
| 8971850 | Klein et al. | Mar 2015 | B2 |
| 8971932 | Mapes | Mar 2015 | B2 |
| 8988221 | Raji et al. | Mar 2015 | B2 |
| 8996030 | Grainger et al. | Mar 2015 | B2 |
| 8997243 | Epstein | Mar 2015 | B2 |
| 9000892 | Hinman et al. | Apr 2015 | B2 |
| 9014658 | Johnson | Apr 2015 | B2 |
| 9014715 | Alizadeh-Shabdiz et al. | Apr 2015 | B2 |
| 9026134 | Edge | May 2015 | B2 |
| 9033255 | Tessier et al. | May 2015 | B2 |
| 9036792 | Cacioppo et al. | May 2015 | B2 |
| 9055406 | Johnson | Jun 2015 | B2 |
| 9063212 | Jones | Jun 2015 | B2 |
| 9078095 | Johnson | Jul 2015 | B2 |
| 9088868 | Johnson | Jul 2015 | B2 |
| 9088869 | Johnson | Jul 2015 | B2 |
| 9100792 | Johnson | Aug 2015 | B2 |
| 9113295 | Johnson | Aug 2015 | B2 |
| 9113309 | Uilecan et al. | Aug 2015 | B2 |
| 9113343 | Moshfeghi | Aug 2015 | B2 |
| 9140796 | Zhou | Sep 2015 | B2 |
| 9143890 | Jose et al. | Sep 2015 | B2 |
| 9154565 | Monighetti | Oct 2015 | B2 |
| 9202245 | Kostka et al. | Dec 2015 | B2 |
| 9204275 | Johnson et al. | Dec 2015 | B2 |
| 9237506 | Brown et al. | Jan 2016 | B2 |
| 9253597 | Johnson | Feb 2016 | B2 |
| 9258674 | Chen | Feb 2016 | B2 |
| 9282436 | Chitre et al. | Mar 2016 | B2 |
| 9282582 | Dunsbergen et al. | Mar 2016 | B1 |
| 9307355 | Nehrenz et al. | Apr 2016 | B2 |
| 9325723 | Son et al. | Apr 2016 | B2 |
| 9351114 | Chatterjee et al. | May 2016 | B2 |
| 9361630 | Goswami | Jun 2016 | B1 |
| 9392408 | Johnson | Jul 2016 | B2 |
| 9398422 | Zampini | Jul 2016 | B2 |
| 9408060 | Helms et al. | Aug 2016 | B2 |
| 9424699 | Kusens et al. | Aug 2016 | B2 |
| 9445238 | Johnson et al. | Sep 2016 | B2 |
| 9445305 | Lyon et al. | Sep 2016 | B2 |
| 9456303 | Johnson | Sep 2016 | B2 |
| 9462469 | Hillyard | Oct 2016 | B2 |
| 9471917 | Govindarajan et al. | Oct 2016 | B2 |
| 9474962 | Barney et al. | Oct 2016 | B2 |
| 9491575 | Edge et al. | Nov 2016 | B2 |
| 9544744 | Postrel | Jan 2017 | B2 |
| 9551774 | Ishida et al. | Jan 2017 | B2 |
| 9558507 | Zilkha | Jan 2017 | B2 |
| 9571957 | Granbery | Feb 2017 | B2 |
| 9571985 | Bottazzi et al. | Feb 2017 | B2 |
| 9584993 | Johnson et al. | Feb 2017 | B2 |
| 9591570 | Kubo et al. | Mar 2017 | B2 |
| 9608999 | Somani et al. | Mar 2017 | B2 |
| 9609487 | Alshihi | Mar 2017 | B2 |
| 9621446 | Pugh et al. | Apr 2017 | B2 |
| 9622046 | Otis et al. | Apr 2017 | B2 |
| 9622208 | Mycek et al. | Apr 2017 | B2 |
| 9629064 | Graves et al. | Apr 2017 | B2 |
| 9634928 | Choudhury et al. | Apr 2017 | B2 |
| 9642173 | Granbery | May 2017 | B2 |
| 9648662 | Herrala et al. | May 2017 | B2 |
| 9652124 | Cotier et al. | May 2017 | B2 |
| 9684826 | Dubuque | Jun 2017 | B2 |
| 9684925 | Khalid et al. | Jun 2017 | B2 |
| 9689955 | Rosenbaum | Jun 2017 | B2 |
| 9712967 | Kostka et al. | Jul 2017 | B2 |
| 9801062 | Niewczas et al. | Oct 2017 | B2 |
| 9826356 | Mycek et al. | Nov 2017 | B2 |
| 9832194 | Krieger et al. | Nov 2017 | B2 |
| 9866996 | Krzych et al. | Jan 2018 | B1 |
| 9867009 | Mycek et al. | Jan 2018 | B2 |
| 9886696 | Roeding et al. | Feb 2018 | B2 |
| 9922294 | Raina et al. | Mar 2018 | B2 |
| 9998867 | Keithley | Jun 2018 | B2 |
| 10092245 | LeBoeuf | Oct 2018 | B2 |
| 10094907 | Niewczas et al. | Oct 2018 | B2 |
| 10111034 | Johnson | Oct 2018 | B2 |
| 10292011 | Johnson | May 2019 | B2 |
| 20010026240 | Neher | Oct 2001 | A1 |
| 20020167919 | Marples et al. | Nov 2002 | A1 |
| 20020176388 | Rankin et al. | Nov 2002 | A1 |
| 20030084539 | Wartian | May 2003 | A1 |
| 20030100315 | Rankin | May 2003 | A1 |
| 20030146835 | Carter | Aug 2003 | A1 |
| 20030148775 | Spriestersbach et al. | Aug 2003 | A1 |
| 20040008663 | Srikrishna et al. | Jan 2004 | A1 |
| 20040190447 | Dacosta | Sep 2004 | A1 |
| 20040264372 | Huang | Dec 2004 | A1 |
| 20040264466 | Huang | Dec 2004 | A1 |
| 20050124380 | Rokusek | Jun 2005 | A1 |
| 20050162271 | Leitch | Jul 2005 | A1 |
| 20050201301 | Bridgelall | Sep 2005 | A1 |
| 20050222933 | Wesby | Oct 2005 | A1 |
| 20060163349 | Neugebauer | Jul 2006 | A1 |
| 20060164213 | Burghard et al. | Jul 2006 | A1 |
| 20060209745 | MacMullan et al. | Sep 2006 | A1 |
| 20060259942 | Toyama et al. | Nov 2006 | A1 |
| 20060290519 | Boate et al. | Dec 2006 | A1 |
| 20070067104 | Mays | Mar 2007 | A1 |
| 20070069923 | Mendelson | Mar 2007 | A1 |
| 20070123166 | Sheynman | May 2007 | A1 |
| 20070243769 | Atsmon et al. | Oct 2007 | A1 |
| 20070247366 | Smith et al. | Oct 2007 | A1 |
| 20080056215 | Kopikare et al. | Mar 2008 | A1 |
| 20080062891 | Van et al. | Mar 2008 | A1 |
| 20080068519 | Adler et al. | Mar 2008 | A1 |
| 20080139306 | Lutnick et al. | Jun 2008 | A1 |
| 20080143516 | Mock et al. | Jun 2008 | A1 |
| 20080143604 | Mock et al. | Jun 2008 | A1 |
| 20080146265 | Valavi | Jun 2008 | A1 |
| 20080146890 | LeBoeuf | Jun 2008 | A1 |
| 20080231460 | Owen et al. | Sep 2008 | A1 |
| 20090005079 | Shields et al. | Jan 2009 | A1 |
| 20090009398 | Taylor et al. | Jan 2009 | A1 |
| 20090036066 | Chiu et al. | Feb 2009 | A1 |
| 20090102296 | Greene | Apr 2009 | A1 |
| 20090131079 | Sekhar | May 2009 | A1 |
| 20090311976 | Vanderaa et al. | Dec 2009 | A1 |
| 20090327135 | Nguyen et al. | Dec 2009 | A1 |
| 20100019924 | D et al. | Jan 2010 | A1 |
| 20100093374 | Dacosta | Apr 2010 | A1 |
| 20100099435 | Druzinic-Fiebach et al. | Apr 2010 | A1 |
| 20100100582 | Beatty et al. | Apr 2010 | A1 |
| 20100105353 | Cacioppo et al. | Apr 2010 | A1 |
| 20100120450 | Herz | May 2010 | A1 |
| 20100168924 | Tessier et al. | Jul 2010 | A1 |
| 20100317371 | Migos et al. | Dec 2010 | A1 |
| 20110028160 | Roeding et al. | Feb 2011 | A1 |
| 20110029359 | Roeding et al. | Feb 2011 | A1 |
| 20110085442 | Lin et al. | Apr 2011 | A1 |
| 20110102171 | Raji et al. | May 2011 | A1 |
| 20110125063 | Shalon | May 2011 | A1 |
| 20110238188 | Washiro | Sep 2011 | A1 |
| 20110305228 | Cordeiro | Dec 2011 | A1 |
| 20110306357 | Alizadeh-Shabdiz et al. | Dec 2011 | A1 |
| 20120032876 | Tabe | Feb 2012 | A1 |
| 20120057518 | Herrala et al. | Mar 2012 | A1 |
| 20120095805 | Ghosh et al. | Apr 2012 | A1 |
| 20120112055 | Castro-Perez et al. | May 2012 | A1 |
| 20120172055 | Edge | Jul 2012 | A1 |
| 20120190386 | Anderson | Jul 2012 | A1 |
| 20120258730 | Tinnakornsrisuphap et al. | Oct 2012 | A1 |
| 20120260323 | San Vicente et al. | Oct 2012 | A1 |
| 20120262365 | Mallinson | Oct 2012 | A1 |
| 20120280862 | Moffatt et al. | Nov 2012 | A1 |
| 20120284517 | Lambert | Nov 2012 | A1 |
| 20120295535 | Bradish et al. | Nov 2012 | A1 |
| 20120309256 | Theodore | Dec 2012 | A1 |
| 20120316960 | Yang | Dec 2012 | A1 |
| 20120320815 | Massena | Dec 2012 | A1 |
| 20130023282 | Lin et al. | Jan 2013 | A1 |
| 20130030915 | Statler et al. | Jan 2013 | A1 |
| 20130063303 | Zhou | Mar 2013 | A1 |
| 20130065584 | Lyon et al. | Mar 2013 | A1 |
| 20130165157 | Mapes | Jun 2013 | A1 |
| 20130182625 | Kuehnel et al. | Jul 2013 | A1 |
| 20130184002 | Moshfeghi | Jul 2013 | A1 |
| 20130203445 | Grainger et al. | Aug 2013 | A1 |
| 20130225197 | McGregor et al. | Aug 2013 | A1 |
| 20130307972 | Stone | Nov 2013 | A1 |
| 20130312043 | Stone | Nov 2013 | A1 |
| 20130337771 | Klein et al. | Dec 2013 | A1 |
| 20140018002 | Jose et al. | Jan 2014 | A1 |
| 20140087758 | Maor | Mar 2014 | A1 |
| 20140106782 | Chitre et al. | Apr 2014 | A1 |
| 20140122703 | Pugh et al. | May 2014 | A1 |
| 20140122855 | Maneval | May 2014 | A1 |
| 20140135042 | Buchheim et al. | May 2014 | A1 |
| 20140148196 | Bassan-Eskenazi et al. | May 2014 | A1 |
| 20140149577 | Monighetti | May 2014 | A1 |
| 20140180817 | Zilkha | Jun 2014 | A1 |
| 20140219118 | Middleton et al. | Aug 2014 | A1 |
| 20140220883 | Emigh et al. | Aug 2014 | A1 |
| 20140228044 | Jones | Aug 2014 | A1 |
| 20140277654 | Reinhardt et al. | Sep 2014 | A1 |
| 20140302869 | Rosenbaum et al. | Oct 2014 | A1 |
| 20140304004 | Trethewey | Oct 2014 | A1 |
| 20140361906 | Hughes | Dec 2014 | A1 |
| 20150005011 | Nehrenz et al. | Jan 2015 | A1 |
| 20150031388 | Chatterjee et al. | Jan 2015 | A1 |
| 20150038171 | Uilecan et al. | Feb 2015 | A1 |
| 20150058355 | Naqvi | Feb 2015 | A1 |
| 20150079942 | Kostka et al. | Mar 2015 | A1 |
| 20150081474 | Kostka et al. | Mar 2015 | A1 |
| 20150094140 | Barney et al. | Apr 2015 | A1 |
| 20150106196 | Williams et al. | Apr 2015 | A1 |
| 20150163828 | Vandwalle et al. | Jun 2015 | A1 |
| 20150245305 | Camps Mur | Aug 2015 | A1 |
| 20150248667 | Govindarajan et al. | Sep 2015 | A1 |
| 20150269624 | Cheng | Sep 2015 | A1 |
| 20150276432 | Repyevsky et al. | Oct 2015 | A1 |
| 20150279115 | Vukicevic | Oct 2015 | A1 |
| 20150289207 | Kubo et al. | Oct 2015 | A1 |
| 20150294398 | Khalid et al. | Oct 2015 | A1 |
| 20150295333 | Shibuya et al. | Oct 2015 | A1 |
| 20150296048 | Gerding et al. | Oct 2015 | A1 |
| 20150296333 | Chen | Oct 2015 | A1 |
| 20150334548 | Liu et al. | Nov 2015 | A1 |
| 20150347959 | Skaaksrud | Dec 2015 | A1 |
| 20150351008 | Mayor | Dec 2015 | A1 |
| 20150355308 | Ishida et al. | Dec 2015 | A1 |
| 20150365790 | Edge et al. | Dec 2015 | A1 |
| 20150373521 | Olesen | Dec 2015 | A1 |
| 20150379576 | Otis et al. | Dec 2015 | A1 |
| 20150382153 | Otis et al. | Dec 2015 | A1 |
| 20160006837 | Reynolds et al. | Jan 2016 | A1 |
| 20160007315 | Lundgreen et al. | Jan 2016 | A1 |
| 20160014609 | Goel et al. | Jan 2016 | A1 |
| 20160021687 | Granbery | Jan 2016 | A1 |
| 20160042767 | Araya et al. | Feb 2016 | A1 |
| 20160049028 | Kusens et al. | Feb 2016 | A1 |
| 20160050219 | Niewczas et al. | Feb 2016 | A1 |
| 20160055428 | Raina et al. | Feb 2016 | A1 |
| 20160063550 | Caldwell | Mar 2016 | A1 |
| 20160086029 | Dubuque | Mar 2016 | A1 |
| 20160086460 | King et al. | Mar 2016 | A1 |
| 20160094398 | Choudhury et al. | Mar 2016 | A1 |
| 20160094598 | Gedikian | Mar 2016 | A1 |
| 20160094946 | Keithley | Mar 2016 | A1 |
| 20160099758 | Bell et al. | Apr 2016 | A1 |
| 20160105788 | Helms et al. | Apr 2016 | A1 |
| 20160123745 | Cotier et al. | May 2016 | A1 |
| 20160127875 | Zampini | May 2016 | A1 |
| 20160182365 | Chang et al. | Jun 2016 | A1 |
| 20160188919 | Gao et al. | Jun 2016 | A1 |
| 20160192407 | Fyfe et al. | Jun 2016 | A1 |
| 20160203522 | Shiffert | Jul 2016 | A1 |
| 20160277999 | Graves et al. | Sep 2016 | A1 |
| 20160291127 | Huang et al. | Oct 2016 | A1 |
| 20160345126 | Granbery | Nov 2016 | A1 |
| 20170019765 | Hover et al. | Jan 2017 | A1 |
| 20170064667 | Mycek et al. | Mar 2017 | A1 |
| 20170079001 | Lewis | Mar 2017 | A1 |
| 20170099567 | Kwon et al. | Apr 2017 | A1 |
| 20170171795 | Wang et al. | Jun 2017 | A1 |
| 20170188191 | Aldana et al. | Jun 2017 | A1 |
| 20180288563 | Krzych et al. | Oct 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 2016101053 | Aug 2016 | AU |
| 101494599 | Jul 2009 | CN |
| 2296407 | Sep 2014 | EP |
| 3047681 | Jul 2016 | EP |
| 20030084539 | Nov 2003 | KR |
| 20040050425 | Jun 2004 | KR |
| 101113052 | Feb 2012 | KR |
| 0221429 | Mar 2002 | WO |
| 2005006128 | Jan 2005 | WO |
| 2008135432 | Nov 2008 | WO |
| 2015026862 | Feb 2015 | WO |
| 2016025175 | Feb 2016 | WO |
| 2016043388 | Mar 2016 | WO |
| 2017007719 | Jan 2017 | WO |
| 2017040690 | Mar 2017 | WO |
| 2017196883 | Nov 2017 | WO |
| Entry |
|---|
| EPO Examination Report for Application No. 14838745.9, dated Jul. 11, 2018. |
| Paterson, Kenneth G., et al., “Time-Specific Encryption”, Information Security Group, Royal Holloway, University of London, https://eprint.iacr.org/2010/347.pdf. |
| International Search Report and the Written Opinion of the International Searching Authority, Application No. PCT/IB2018/000692, dated Sep. 28, 2018. |
| International Search Report and Written Opinion for International Application No. PCT/US2017/031811 dated Sep. 1, 2017. |
| International Search Report and Written Opinion of the ISA dated Jan. 22, 2020 for Application No. PCT/IB2019/000828. |
| U.S. Appl. No. 16/375,836. |
| Reality Matters, The Estimote Team Blog, https://blog.estimote.com/post/172115262320/presence-verification-and-security-is-more-refined, Mar. 29, 2018. |
| Hassidim, Avinatan , et al., “Ephemeral Identifiers: Mitigating Tracking & Spoofing Threats to BLE Beacons”, Google Inc., Apr. 14, 2016. |
| Jung, Changsu , et al., “Topology Configuration and Multihop Routing Protocol for Bluetooth Low Energy Networks”, IEEE Access, Dec. 13, 2017, 9587-9598. |
| Jung, Chanhsu , et al., “Maximum Power Plus RSSI Based Routing Protocol for Bluetooth Low Energy Ad Hoc Networks”, Wireless Communications and Mobile Computing, Dec. 13, 2017, 1-13. |
| Number | Date | Country | |
|---|---|---|---|
| 20200196090 A1 | Jun 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62514110 | Jun 2017 | US | |
| 62416395 | Nov 2016 | US | |
| 62334115 | May 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16685805 | Nov 2019 | US |
| Child | 16803111 | US | |
| Parent | 16152254 | Oct 2018 | US |
| Child | 16685805 | US | |
| Parent | 15997567 | Jun 2018 | US |
| Child | 16152254 | US | |
| Parent | 15784774 | Oct 2017 | US |
| Child | 15900171 | US | |
| Parent | 15590939 | May 2017 | US |
| Child | 15784774 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15900171 | Feb 2018 | US |
| Child | 15997567 | US |
