[go: up one dir, main page]

WO2017196883A1 - Système et procédé de gestion d'une flotte de balises - Google Patents

Système et procédé de gestion d'une flotte de balises Download PDF

Info

Publication number
WO2017196883A1
WO2017196883A1 PCT/US2017/031811 US2017031811W WO2017196883A1 WO 2017196883 A1 WO2017196883 A1 WO 2017196883A1 US 2017031811 W US2017031811 W US 2017031811W WO 2017196883 A1 WO2017196883 A1 WO 2017196883A1
Authority
WO
WIPO (PCT)
Prior art keywords
beacon
application
packet
beacons
settings
Prior art date
Application number
PCT/US2017/031811
Other languages
English (en)
Inventor
Marcin Klimek
Lukasz KOSTKA
Jakub KRZYCH
Original Assignee
Estimote Polska Sp. Z O.O.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Estimote Polska Sp. Z O.O. filed Critical Estimote Polska Sp. Z O.O.
Publication of WO2017196883A1 publication Critical patent/WO2017196883A1/fr

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S1/00—Beacons or beacon systems transmitting signals having a characteristic or characteristics capable of being detected by non-directional receivers and defining directions, positions, or position lines fixed relatively to the beacon transmitters; Receivers co-operating therewith
    • G01S1/02—Beacons or beacon systems transmitting signals having a characteristic or characteristics capable of being detected by non-directional receivers and defining directions, positions, or position lines fixed relatively to the beacon transmitters; Receivers co-operating therewith using radio waves
    • G01S1/68—Marker, boundary, call-sign, or like beacons transmitting signals not carrying directional information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
    • G01S5/02—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations using radio waves
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/10—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using wireless transmission systems

Definitions

  • This invention relates generally to the wireless beacon field, and more specifically to a new and useful system and method for remote beacon fleet management in the wireless beacon field.
  • beacon fleet deployment, monitoring, and control are difficult due to the logistical issues posed by the massive number of beacons. This is because each beacon must be individually dealt with. This issue is compounded when a single entity (e.g., a retailer) has multiple physical locations (e.g., venues), each with multiple beacons.
  • beacon fleet deployment is particularly difficult because each beacon must be individually programmed (e.g., associated with the managing entity, assigned settings, assigned permissions, associated with content, etc.). For example, each beacon must be individually placed within and assigned to a physical location to enable location-based contextual experiences; this not only requires a virtual map of the physical space for beacon deployment, but also requires a managing entity to manually assign beacons (e.g., via the respective beacon identifiers) to virtual locations on the virtual map.
  • beacons can fail (e.g., fall off the wall, cease broadcasting, crash, etc.) between physical checkups, resulting suboptimal beacon operation until the next physical checkup.
  • 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 fleet.
  • hidden beacons e.g., beacons that the managing entity forgets are there, beacons that are visually obscured from view, etc.
  • FIGURE l is a schematic representation of the system.
  • FIGURE 2 is a schematic representation of the method.
  • FIGURE 3 is a schematic representation of a specific example of a first variation of automatic beacon deployment.
  • FIGURE 4 is a schematic representation of a specific example of a second variation of automatic beacon deployment.
  • FIGURE 5 is a schematic representation of a specific example of beacon monitoring.
  • FIGURE 6 is a schematic representation of a variation of beacon monitoring.
  • FIGURE 7 is a schematic representation of a specific example of beacon updating.
  • FIGURE 8 is a schematic representation of a variation of beacon updating.
  • FIGURE 9 is a schematic representation of an example of crowdsourced beacon population management, including a first and second example of the management interface.
  • FIGURE 10 is a schematic representation of an example of crowdsourced beacon population updating.
  • FIGURE 11 is a schematic representation of an example of beacon updating using a mesh network.
  • FIGURE 12 is a specific example of a beacon management interface.
  • FIGURE 13 is an exploded view of an example of the beacon.
  • the system for beacon fleet management includes: a set of beacons 100, a management system 200, and an application executed on a set of user devices 300. This system functions to automatically (or pseudo-automatically) deploy, monitor, and manage the beacons.
  • the remote computing system functions as a centralized version control system for the beacon fleet software (e.g., source of truth for settings, content, broadcasting parameters, firmware, etc.), while the application, running on a set of customer devices, functions as the gateway (e.g., communication intermediary) between each beacon and the remote computing system.
  • the gateway e.g., communication intermediary
  • each beacon can substantially continuously record operation parameters about itself and transmit the operation parameters to the remote computing system through the application when the beacon is connected to a user device, wherein the remote computing system can track beacon operation histories to detect anomalies (e.g., changes in orientation measurements indicative of f alien-off beacons).
  • the remote computing system can optionally notify the managing entity of the anomaly, and/ or recommend corrective action.
  • the managing entity can specify updated beacon parameters (e.g., settings), which are stored at the remote computing system.
  • the remote computing system subsequently pushes the updated beacon parameters to the application, wherein the application pushes the updated settings to the beacons when the user device running the application is connected to said beacon(s).
  • the updated beacon parameters can be individually addressed (e.g., to individual beacons), universal to a beacon population, or be otherwise assigned to segments of the beacon population.
  • the system and method can enable easy and/or automated physical space beacon mapping. This can be enabled by using beacons that: include sensors (e.g., orientation sensors, etc.), can selectively scan for beacon identifiers and/or broadcast beacon identifiers, or have other functionalities.
  • beacons that: include sensors (e.g., orientation sensors, etc.), can selectively scan for beacon identifiers and/or broadcast beacon identifiers, or have other functionalities.
  • the system and method can enable automated, continuous status monitoring for a plurality of beacons.
  • This can be enabled by using beacons that monitor their own operation parameters and selectively transmit the operation parameters (or information derived therefrom) to the remote computing system.
  • the system has a central repository for beacon operation analysis.
  • This centralized system enables comparison between data, received from different user devices, for the same beacon to identify anomalies.
  • This centralized system also allows for beacon parameter comparison to parameters for other beacons (e.g., within the same population or different populations) to automatically normalize beacon parameters.
  • This centralized system also enables parallel prototyping of multiple anomaly determination modules, rapid training set development across multiple beacon populations, or confers any other suitable benefit.
  • the system and method can enable automatic control for a plurality of beacons.
  • This can be enabled by providing a centralized version control system (CVCS; e.g., the remote computing system) that manages each beacon's operation parameters (e.g., settings, firmware, etc.), such that the managing entity can interface with the CVCS instead of with the beacons directly.
  • CVCS centralized version control system
  • the system and method can confer any other suitable benefit.
  • the system and method can crowdsource beacon control and/or monitoring (examples shown in FIGURES 9 and 10), which can reduce the burden of managing a beacon population on a beacon manager (e.g., IT personnel). This is preferably accomplished by leveraging a plurality of user devices, more preferably the applications executing on the user devices, as a gateway or intermediary to the centralized system.
  • the remote computing system can push beacon updates 210 to instances of an application associated with the beacon population (to be updated), wherein the update is propagated to each beacons within the beacon population as instances of the application encounter (e.g., connect) to said beacons through typical use.
  • the update for TargetTM beacons can be pushed to a DawnTM application, wherein mobile devices (e.g., user devices, smartphones, etc.) executing the DawnTM application can update TargetTM beacons as the users pass by the respective beacons within multiple TargetTM locations.
  • mobile devices e.g., user devices, smartphones, etc.
  • different instances of the application executing on separate and distinct mobile devices can forward beacon operation parameters to the centralized system as the beacon packets are received by the respective applications, such that operation records for each beacon can be aggregated from multiple sources over time.
  • the system for beacon fleet management can include: a set of beacons 100, a management system 200, and an application 300. They system functions to facilitate simple and/or automatic beacon set deployment, monitoring, and control.
  • the beacon(s) 100 of the system functions to broadcast a packet, wherein the packet can be used to retrieve information (e.g., settings) associated with the beacon.
  • the beacons can be statically positioned within a physical space (e.g., at known locations, with known orientations, etc.) to enable location-based user experiences, wherein the location of the user device can be determined (e.g., trilaterated) based on the known location of the beacon(s) from which packets are received (e.g., within a predetermined time period).
  • the beacons can additionally or alternatively be coupled to a mobile object to enable automatic retrieval of object-related content. However, the beacons can be otherwise used.
  • the retrieved information can be product information for a product associated with the beacon.
  • the retrieved information can be for a geographic region associated with (e.g., encompassing or proximal) the beacon.
  • the retrieved information can be a link (e.g., a URI) from which information can be retrieved.
  • the information associated with the beacon can be any other suitable information.
  • the packet 110 can include: a beacon identifier (e.g., broadcast identifier, static identifier, etc.), protocol version, hardware revision, software version (e.g., operation setting version number, firmware version number, etc.), sensor measurements (e.g., temperature, battery voltage, x,y,z-axis acceleration, current and previous motion state duration, power, uptime, x,y,z-axis magnetometer data, ambient light level, etc.), radio metrics (e.g., number of pairings, number of unique devices that have been paired with, etc.), information based on the measurements, operation alerts (e.g., beacon fallen), or any other information.
  • the beacon can additionally function to process the measurements into summary data, operation alerts, or any other suitable information.
  • the beacon can additionally erase transient data (e.g., sensor measurements) periodically, after connection to a connected user device (e.g., application), after transmission to a connected user device, or at any other suitable time.
  • the beacons 100 are preferably associated with a static identifier and a broadcast identifier, wherein the beacon broadcasts the broadcast identifier and the remote computing system translates the broadcast identifier into the static identifier to identify the beacon.
  • the broadcast identifier can remain substantially static, change (e.g., at a predetermined frequency, upon occurrence of a predetermined event, etc.), or be otherwise controlled.
  • the beacons 100 preferably function as slave devices, but can additionally or alternatively constantly or periodically function as master devices.
  • Each beacon can additionally function to substantially continuously monitor its own operation by recording sensor measurements (e.g., periodically, every second, etc.), communicate the recorded sensor measurements to connected systems (e.g., user devices, other beacons, etc.), identify anomalous beacon operation (e.g., based on sensor measurement processing, etc.) and automatically take action on the anomaly (e.g., broadcast a distress signal), function as a master device (e.g., scan for broadcasts), function as an intermediary between a second beacon and an endpoint (e.g., the application, the remote computing system, etc.), or perform any other suitable functionality.
  • sensor measurements e.g., periodically, every second, etc.
  • connected systems e.g., user devices, other beacons, etc.
  • identify anomalous beacon operation e.g., based on sensor measurement processing, etc.
  • automatically take action on the anomaly e.g., broadcast a distress
  • the system preferably includes a plurality of beacons, but can alternatively include a single beacon or any other suitable number of beacons.
  • the plurality of beacons is preferably associated with a single account (e.g., user account associated with the managing entity), but can alternatively be associated with a plurality of accounts.
  • the system can include multiple beacon pluralities (e.g., each associated with a different user account), but can alternatively include any suitable number of beacons.
  • the beacon can include: a radio, a sensor, a processing system, a power source, or any other suitable component (example shown in FIGURE 13).
  • the radio of the beacon functions to transmit and/ or receive data packets.
  • the data packets can be beacon identifiers, control instructions, information identifiers (e.g., a URI), or any other suitable data.
  • the beacon identifier can be a globally unique identifier, a locally unique identifier (e.g., unique among beacons within a geographic region), a temporally unique identifier (e.g., unique among beacons concurrently active), a non-unique identifier, or any other suitable identifier.
  • the beacons preferably broadcast the beacon identifier periodically, continuously, when a trigger event occurs, or at any other suitable time.
  • the beacon identifier can be static (e.g., permanently assigned to the beacon), variable or dynamic (e.g., periodically assigned to the beacon), or otherwise configured.
  • the variable beacon identifier can be automatically generated based on a static identifier associated with the beacon (e.g., calculated), randomly assigned, or otherwise determined.
  • the variable beacon identifier can be generated by a remote computing system, the beacon, a secondary beacon system, a user device, or any other suitable computing system.
  • the variable beacon identifier can be resolved into the beacon's static identifier by a receiving device or system connected to the receiving device (e.g., using the equation, etc.).
  • variable beacon identifier can be resolved in the manner disclosed in US Application number 14/463,582 filed 19-AUG-2014, which is incorporated in its entirety by this reference, or be otherwise resolved.
  • the broadcast beacon identifier can be received by the user device, beacon system(s), other beacons, or by any other suitable device proximal the beacon.
  • the beacon can broadcast multiple packet types.
  • Packet types that can be broadcasted include: content packets (e.g., used to retrieve and/or display content), telemetry packets (e.g., e.g., used to monitor the beacon operation parameters), or any other suitable packet. All packets preferably include a beacon identifier (e.g., broadcast identifier, etc.), but can include any suitable information. Examples of the packets include: iBeacon, Eddystone (e.g., Eddystone-UID, Eddystone-URL, Eddystone-TLM, Eddystone-EID, etc.), Estimote telemetry, or any other suitable packet.
  • Eddystone e.g., Eddystone-UID, Eddystone-URL, Eddystone-TLM, Eddystone-EID, etc.
  • Estimote telemetry or any other suitable packet.
  • the beacon can broadcast one or more packet types throughout a broadcasting period, wherein different packet types are broadcast by the same or different radios.
  • a single radio alternates between broadcasting different packet types.
  • multiple radios substantially concurrently (e.g., within a predetermined time interval) each broadcasts a different packet type (e.g., a primary and secondary packet broadcast by a primary and secondary radio, respectively).
  • the packets can be otherwise broadcast.
  • the beacon can broadcast only, listen only, broadcast and listen (e.g., concurrently or asynchronously), or perform any other suitable functionality.
  • the beacon can use the same radio to broadcast and listen, or use different radios.
  • the beacon can broadcast and listen using the same protocol or different protocols.
  • the radio is preferably selectively operable between broadcasting and listening (e.g., periodically switch states, etc.), wherein the processing system preferably operates the radio between the two modes, but can alternatively be otherwise operated.
  • the beacon can unpack the data packet, forward the data packet, or otherwise manage the data packet.
  • the beacon can additionally determine the strength of the received signal, wherein the signal strength can be used to determine the transmitting beacon's SOC, trilaterate or triangulate the transmitting beacon's location, or otherwise used.
  • the radio can include a transceiver and an antenna, but can alternatively include any other suitable component.
  • the transceiver can be integrated into the processing system or be separate.
  • the antenna can extend along the beacon system length (e.g., along the longitudinal axis, along the inner or outer perimeter, etc.), extend along the beacon system width, or extend along any other suitable portion of the beacon system.
  • the antenna is preferably arranged distal the data connector (e.g., to avoid electromagnetic interference), but can alternatively be arranged proximal the data connector or be arranged in any other suitable location on the beacon system.
  • the antenna is preferably an omnidirectional antenna, but can alternatively be a directional antenna or be any other suitable type of antenna.
  • the beacon can include one or more radios.
  • the radio is preferably for a short-range communication technology, but can additionally or alternatively be for a long-range communication technology.
  • the radio include: a Bluetooth radio, a BLE radio, a UWB radio, a BLE long range radio (e.g., lodB), an LTE-M radio, a WiFi radio, a WLAN radio, a WiMAX radio, a Zigbee radio, a NFC radio, or any other suitable short or long range repeater, extender, protocol translator, or other suitable means for conducting a one-way or two-way communication protocol.
  • the radio includes a 2.4GHz BLE radio.
  • the beacon can concurrently broadcast multiple packets from the same or different radios.
  • the beacon radio can be dynamically reconfigurable (e.g., by the processing system).
  • the beacon radio can be reconfigured based on a selected beacon operation mode (e.g., broadcasting mode, updated parameter distribution mode, etc.), based on the operating environment (e.g., adjusted to compensate for EMI and/or magnetic field disturbances, as determined using the magnetometer), or be otherwise reconfigured.
  • a selected beacon operation mode e.g., broadcasting mode, updated parameter distribution mode, etc.
  • the operating environment e.g., adjusted to compensate for EMI and/or magnetic field disturbances, as determined using the magnetometer
  • the sensor(s) functions to monitor operation parameters of the beacon system (e.g., beacon telemetry data).
  • the operation parameters can include beacon system parameters (e.g., power storage SOC, user connection frequency, internal temperature, physical orientation, etc.), environmental parameters (e.g., ambient temperature, ambient light, ambient noise, vibration, etc.), or include any other suitable parameter.
  • the beacon system can include one or more sensors of the same or different type.
  • the sensors can be on-board the beacon (e.g., mounted to or within the beacon housing), connected to the beacon (e.g., via a wired connection, such as GPIO pins, via a wireless connection, etc.), or otherwise associated with the beacon.
  • the sensor can be an orientation sensor (e.g., accelerometer, gyroscope, etc.), magnetometer, altimeter, microphone, transducer, temperature sensor, pressure sensor, light sensor (e.g., camera, ambient light sensor), or be any other suitable sensor.
  • orientation sensor e.g., accelerometer, gyroscope, etc.
  • magnetometer e.g., magnetometer, altimeter, microphone, transducer, temperature sensor, pressure sensor, light sensor (e.g., camera, ambient light sensor), or be any other suitable sensor.
  • the processing system of the beacon system functions to control identifier broadcasting, control data transfer between the beacon system and the user device, control data transfer between the beacon system and remote computing system, manage beacon system operation between the set of operation modes, or perform any other suitable functionality.
  • the beacon system can include one or more processing systems of the same or different type.
  • the processing system can be a CPU, GPU, microprocessor, or be any other suitable processing system.
  • the processing system can additionally include memory (e.g., RAM, flash) that stores the beacon settings, firmware, sensor measurements, content (e.g., URLs, location-or context-specific content), or other information.
  • the processing system can additionally include clocks or include any other suitable component.
  • the processing system is preferably electrically coupled to (e.g., connected to) and communicates with the radio, sensor(s), or any other suitable component.
  • the power source of the beacon system functions to power the beacon system components.
  • the beacon can be operable in a single power class, multiple power classes, or any other suitable power class.
  • the power source is preferably wired to the powered components, but can alternatively be wirelessly connected to the powered components (e.g., via induction).
  • the beacon system can include one or more power sources of the same or different type.
  • the power source is a battery housed within the beacon system.
  • the battery is preferably a secondary battery (e.g., rechargeable battery), but can alternatively be a primary battery or be any other suitable battery. Examples of the battery can include lithium chemistry batteries, nickel cadmium batteries, CR2477 batteries, or any other suitable battery.
  • the power source is a power connector configured to plug into an external power source.
  • the power connector can be integrated with the data connector, but can alternatively be a separate power connector.
  • Examples of the power connector include: a wall outlet plug, a set of pins, an induction coil, or any other suitable power connector.
  • the beacon system can include any other suitable power source.
  • the beacon can additionally include a housing that functions to mechanically encapsulate the beacon components.
  • the housing can be made of plastic, metal, ceramic, or from any other suitable material.
  • the housing preferably entirely encapsulates the beacon components, but can alternatively partially expose the components or otherwise encapsulate the components.
  • the housing can optionally include a mounting mechanism that functions to mount the beacon to a mounting surface. Examples of the mounting mechanism include: adhesive, hooks, clips, screws, or any other suitable transient or permanent mounting mechanism.
  • the beacon can optionally include external connectors (e.g., GPIO pins) that connect to auxiliary devices and communicate information (e.g., control information, sensor information, etc.) to and/or from the auxiliary device. However, the beacon can include any other suitable component.
  • the management system 200 of the system functions as a centralized system for beacon parameter control.
  • the management system can receive an update 210 (e.g., settings) for a set of beacons from a management entity (e.g., through an application programming interface, such as a RESTful API or graphic user interface, example shown in FIGURE 12), push the new settings to the beacon set, track which beacons of the set have and have not received the new settings, and initiate alternative updating paths to update those beacons that have not received the new settings.
  • the management system functions as a centralized repository for beacon measurement aggregation over time, which allows the management system to function as a beacon monitor.
  • the management system can additionally function as an automated mapping system that automatically determines the relative location of each beacon within a physical space.
  • the management system can function to store beacon identifier associations with content, wherein the associations can be received from the management entity or otherwise determined.
  • the management system can function to return content associated with a beacon identifier to an application on a user device connected to and/or detected the beacon identifier.
  • the management system can function to store preferences, beacon identifiers, beacon settings (e.g., for a beacon set), virtual maps of physical spaces, permissions (e.g., management entity permissions for the population beacons, etc.), or other information in association with a user account (e.g., managing entity).
  • the management system can function to store static identifier(s), broadcast identifier(s), settings, firmware version(s), protocol version(s), operation history (e.g., sensor measurement history), location identifiers (e.g., virtual or physical; relative or absolute), or any other suitable information for a beacon.
  • static identifier(s) e.g., broadcast identifier(s), settings, firmware version(s), protocol version(s), operation history (e.g., sensor measurement history), location identifiers (e.g., virtual or physical; relative or absolute), or any other suitable information for a beacon.
  • the management system can additionally or alternatively: resolve broadcast beacon identifiers into static beacon identifiers, verify access to beacon information, verify access for beacon setting adjustment, monitor beacon performance (e.g., wherein the management system automatically sends a notification to replace a beacon or clone the beacon settings when the beacon SOC falls below a threshold, etc.), migrate beacon settings from a first beacon identifier to a second beacon identifier, determine and/or coordinate multi-beacon broadcast, or perform any other suitable functionality.
  • the management system can perform any other suitable functionality.
  • the management system preferably includes a remote computing system (e.g., a DNS system) including one or more servers, but can alternatively or additionally include a beacon (e.g., a master beacon), a user device (e.g., a native application executing on the user device, a browser application on the user device, etc.), or be any other suitable computing system.
  • the servers can be RESTful, RESTless, or be otherwise configured.
  • the application 300 of the system functions as an interface between the beacon, the management system, and the user.
  • the application can scan for beacon packets, request content from the management system based on the beacon packets, and display the content to the user.
  • the application can additionally connect to the beacons, push updated beacon parameters (e.g., settings) to the beacons, associate user device information (e.g., sensor measurements) with the beacon information (e.g., beacon packets, information extracted from beacon packets, etc.) prior to transmission to an endpoint (e.g., the management system, a second beacon, etc.), or perform any other suitable functionality.
  • beacon parameters e.g., settings
  • user device information e.g., sensor measurements
  • the application is preferably executed by a user device, but can be otherwise run.
  • the application can be automatically launched (e.g., in response to detection of a beacon associated with the application; in response to user device location within a predefined geofence, etc.), manually launched, launched based on content received from the beacon (e.g., a URI), constantly run in the background, or otherwise executed.
  • the user device can be a customer device, employee device, a managing entity device, or belong to any other suitable user.
  • the system can function to crowdsource beacon setup, monitoring, and/or maintenance by leveraging the frequency of other users being proximal the beacons.
  • the application can be a native application, a browser application, an integrated operating system-level application, or any other suitable application.
  • the system can include multiple applications, each associated with a different managing entity. For example, TargetTM can be associated with a first application, while NikeTM can be associated with a second application different from the first application. All applications are preferably connected to the management system through a common SDK (software development kit), but can alternatively be connected to the management system or other endpoint in any other suitable manner.
  • Each application instance e.g., wherein an instance is the application running on one user device or logs in one user account
  • the user device functions to execute the application, to present information to a user, and as a gateway and/or translation layer. For example, the user device can forward the beacon information, transmitted by the beacon to the user device over a short-range protocol, to a router or cellular tower supporting a long-range communications protocol that enables transmission to the centralized system.
  • the system is preferably implemented with a plurality of user devices, more preferably a plurality of application instances, each application instance executing on a separate and distinct user device, but can be otherwise implemented.
  • the user device preferably functions as a master device, but can alternatively or additionally function as a slave device (e.g., periodically, continuously, etc.).
  • the user device is preferably a mobile device associated with the user (e.g., through a user account), and can include mobile phones, laptops, smartphones, tablets, watches, or any other suitable mobile device.
  • the user device can include: one or more data connections (e.g., radios), user outputs (e.g., display, speakers, etc.), user inputs (e.g., touchscreen, keyboard, microphone, camera, etc.), sensors (e.g., orientation sensors, optical sensors, acoustic sensors, location systems, etc.), power storage, and/or any other suitable component.
  • the one or more data connections function to communicate data with the remote computing system and/ or one or more beacons.
  • the data connection is preferably a wireless connection, such as WiFi, a cellular network service, or any other suitable wireless connection, a near field connection, such as radiofrequency, Bluetooth, or any other suitable near field communication connection, or a wired connection, such as a LAN line.
  • the user device can additionally or alternatively function as the server, such as in a distributed network system.
  • the method for remote beacon fleet management includes: broadcasting a packet from the beacon S200; receiving the packet at the application S300; and transmitting beacon information extracted from the packet to the management system from the application S400.
  • the method can optionally include: recording a set of measurements at the beacon S100; and storing the information in association with the beacon identifier at the management system S500, wherein the packet includes beacon information based on the set of measurements.
  • the method can optionally include automatically deploying the beacons, including: automatically determining initial settings for the beacons based on the information.
  • the method can optionally include automatically monitoring beacon performance based on the information, including automatically determining anomalous beacon operation based on the stored information and sending an alert to a user account associated with the beacon in response to anomalous operation determination.
  • the method can optionally include remotely controlling the beacons, including: determining an update for the beacon; sending the update to the application S600; in response to application connection with the beacon, sending the update from the application to the beacon S700; and automatically updating the beacon in response to receipt of the update S800.
  • the method can be performed by the system disclosed above, or be performed by any other suitable system.
  • the method can include, at the beacon: measuring a set of parameters; packaging the measurements into a packet; and broadcasting the packet.
  • the method can additionally include: receiving an update from an application and installing the update.
  • the method can additionally include, at the beacon: forming a mesh network with secondary beacons within the physical space (e.g., within a predetermined distance of the beacon); and transmitting the update to secondary beacons via the mesh network.
  • the method can additionally include, at the beacon: identifying an anomaly based on the parameter set; generating an alert based on the anomaly; and broadcasting the alert (e.g., concurrently with the packet, asynchronously with the packet, in lieu of the packet, etc.).
  • the method can additionally include, at the beacon: scanning for broadcast packets; determining a physical distance to a second beacon (e.g., based on time-of-flight, as determined from the packet transmission time and receipt time); and transmitting the physical distance value to the application.
  • This can additionally include creating a graph of RSSI values based on the physical distances, wherein the graph is transmitted (e.g., retrieved, pushed, etc.) to the management system via the user device.
  • the beacon can additionally or alternatively perform any other suitable process.
  • the method can include, at the application (e.g., at an instance of the application running on a user device): scanning for beacon packets; receiving a beacon packet from a beacon; transmitting the beacon packet to the management system; receiving content from the management system based on the packet; and displaying the content.
  • the method can additionally or alternatively include: determining the user device location based on a known location for the beacon (e.g., using trilateration based on multiple beacon signals and the respective beacon locations, signal analysis such as RSSI, beacon range association with a geofence or label, etc) using the same or different packet received from the beacon.
  • the method can additionally or alternatively include: recording user device parameters with the application; packaging the user device parameters with the beacon packet into a transmission packet; and transmitting the transmission packet to the management system.
  • the method can additionally or alternatively include: receiving an update for the beacon from the management system; and transmitting the update to the beacon.
  • the method can additionally or alternatively include: comparing the new update version received from the management system with the update version identified by the beacon packet, and selectively transmitting the update to the beacon in response to the new update version differing from (e.g., sequentially following) the beacon update version.
  • the application can additionally or alternatively perform any other suitable process.
  • the method can include, at the management system: receiving a beacon identifier from an application; retrieving content associated with the beacon identifier; and sending the content to the application.
  • the method can additionally include, at the management system: receiving relative beacon positioning data (e.g., orientation data for the beacon; positioning data between the beacon and a second beacon) from the beacon (e.g., directly or via the application); and automatically generating a map of the physical space based on relative beacon positioning data from multiple beacons associated with the management entity.
  • relative beacon positioning data e.g., orientation data for the beacon; positioning data between the beacon and a second beacon
  • the method can additionally include: receiving beacon sensor data for a beacon; storing the beacon sensor data in a beacon history for the beacon; analyzing the beacon history and/ or beacon sensor data for anomaly events; and automatically generating an alert for a managing entity in response to identification of an anomaly event.
  • the method can additionally include: receiving updates for a set of beacons from a user account (e.g., from a managing entity); sending an update package to a set of applications, wherein the applications transmit the update package to the respective beacons; receiving beacon packet from the beacons within the set (e.g., via the same or other application instances); and verifying that the beacon has been updated based on the beacon package (e.g., when the setting version matches the most recent setting version; when the time of last update is after the update had been pushed to the applications, etc.).
  • the method can alternatively include: receiving a beacon packet from an application; determining the beacon's update version; and in response to the beacon's update version differing from the current version, pushing the current update version to the application for transmission to the beacon.
  • the management system can additionally or alternatively perform any other suitable process.
  • Recording a set of measurements at the beacon S100 functions to gather data that can be subsequently used to: deploy the beacon (e.g., automatically determine initial settings for the beacon), monitor beacon operation (e.g., identify anomalous operation events), or be used in any other suitable manner. Measurements that can be recorded include: system temperature, ambient temperature, power storage parameters (e.g., voltage, current, SOC, etc.), acceleration (e.g., x,y,z-axis acceleration), processor operation (e.g., uptime, power draw, etc.), EMI data (e.g., x,y,z-axis magnetometer measurements), ambient light level, ambient pressure, humidity, or any other suitable measurement.
  • the measurements can be timestamped or otherwise associated with a reference value.
  • the measurements can be temporarily stored by the beacon on-board storage (e.g., until transmission or processing), but can alternatively be permanently stored, not stored (e.g., immediately processed then discarded), or otherwise retained.
  • Broadcasting a packet from the beacon S200 functions to communicate beacon information, such as beacon identifiers, beacon locations, on-board sensor measurements, data derived therefrom, or other information to an external system.
  • the information based on the set of measurements can include measurement summaries (e.g., measurement value duration, such as current and previous motion state duration, uptime, etc.; parameter ratios, such as power consumption to SOC ratios, etc.), anomalous beacon operation alerts, the raw measurement values, or any other suitable information.
  • the method can additionally include: storing an anomaly detection module on the beacon; and identifying anomalous beacon operation, based on the measurements using the anomaly detection module, by the beacon.
  • the packet can include: a beacon identifier (e.g., broadcast identifier, static identifier, etc.), protocol version, hardware revision, software version, sensor measurements, information based on the measurements, operation alerts, or any other suitable information.
  • the packet can be continuously broadcast, broadcast at a predetermined frequency, broadcast on a schedule, broadcast in response to the occurrence of a predetermined event, or at any other suitable time.
  • Packets broadcast at adjacent times can include the same information types, different information types, or any other suitable set of information types. Packets broadcast at adjacent times can include the same information or different information.
  • Different packets can be broadcast using different radios (e.g., beacon information using a low-energy, low-range protocol; measurement information using a high-energy, short-range protocol, etc.).
  • the beacon can broadcast a single packet type using the same radio.
  • the beacon can broadcast a first information set (determined based on a first measurement set) until beacon connection with an application (e.g., with a user device); and delete the information based on the first information set after beacon connection with the application.
  • the beacon can record a second measurement set while the beacon broadcasts the first information set, and begin broadcasting the second measurement set after beacon connection with the application.
  • the first and second measurement sets preferably include measurements recorded during separate and discrete timepoints, but can alternatively include overlap temporally, or be otherwise related.
  • the beacon can switch between broadcasting the first and second information sets, concurrently broadcast both information sets, or broadcast the information sets at any other suitable time in any suitable order.
  • the beacon can broadcast any other suitable information.
  • Receiving the packet at the application S300 functions to leverage the user device as an intermediary between the beacon and the management system.
  • the packet is preferably received by the user device (e.g., a customer device, managing entity device, etc.), more preferably at an instance of the application running on a user device, but can alternatively be received by any other suitable system.
  • Receiving the packet at the application preferably includes: scanning for beacon packets with the application and receiving packets broadcast by beacons proximal the user device.
  • the application can scan for beacon packets at a predetermined frequency, continuously, in response to the occurrence of a predetermined event, or at any other suitable time.
  • the application preferably scans using a short-range radio of the user device (e.g., the BLE radio), but can alternatively scan using any other suitable radio.
  • the application preferably operates the user device in a master mode, but can alternatively or additionally operate the user device in a slave mode (e.g., continuously, periodically, etc.). However, the packet can be otherwise received.
  • the method can additionally include launching the application prior to packet receipt. In a first variation, the application is run in the background of the user device, and is launched upon user device operation (e.g., when the user device is turned on).
  • the application is automatically executed in response to user device location within (or proximity to) a predetermined geofence (e.g., venue boundary), wherein a secondary application on the user device monitors user device location and automatically launches the application.
  • a secondary application on the user device monitors user device location and automatically launches the application.
  • the user manually launches the application.
  • the application is automatically executed in response to receipt of a beacon packet.
  • the user device radio can scan for packets (e.g., the Bluetooth radio can remain active), receive a packet broadcast by a beacon, and launch the application based on information within the packet.
  • the application can be otherwise initiated.
  • Transmitting beacon information to the management system from the application S400 functions to communicate the information based on the measurement set to the management system.
  • This preferably includes transmitting the packet from the user device that received the packet, but can alternatively include transmitting the packet from any other suitable device. All or a portion of the packet can be transmitted.
  • the application can unpack the packet, select and/or process information from the packet for transmission (e.g., extract a beacon identifier, telemetry data, version numbers, etc.), and transmit the selected and/or processed information to the management system.
  • the packet information can be transmitted immediately after receipt, within a predetermined time after receipt, after a predetermined duration after receipt, or at any other suitable time.
  • the packet is preferably transmitted via a long- range communication protocol supported by the user device (e.g., WiFi, wherein the data is transmitted to the management system through an intermediary router or other WAP; cellular; etc.), but can be otherwise transmitted.
  • Storing the information in association with the beacon identifier at the management system S500 functions to record a beacon operation history.
  • the information is preferably stored in association with the beacon identifier, more preferably the beacon static identifier but alternatively the beacon broadcast identifier (e.g., resolved into the static identifier by the application or management system based on a rule set shared with the beacon, wherein the rule set can be static or rotate, etc.), but can alternatively or additionally be stored in association with the user account or otherwise stored.
  • the beacon operation history can be stored for all time (e.g., for the entire duration that the beacon is associated with the user account), stored for a predetermined duration (e.g., for the last day, last week, last month, etc.), or stored for any other suitable time duration.
  • a predetermined duration e.g., for the last day, last week, last month, etc.
  • different beacon operation resolutions can be stored for different time durations. For example, current beacon operation instructions are summarized into summary data once it surpasses a predetermined age.
  • the method can optionally include automatically deploying the beacons, which functions to automate or partially automate initial beacon setting assignment. This can include automatically determining initial settings for the beacons, where initial settings can include: physical beacon location, beacon orientation, ambient parameter values for a predetermined setting (e.g., ambient light level associated with a broadcasting mode), or any other suitable setting.
  • initial settings can include: physical beacon location, beacon orientation, ambient parameter values for a predetermined setting (e.g., ambient light level associated with a broadcasting mode), or any other suitable setting.
  • the management entity can position the beacons within the physical space, launch the application on their device (e.g., smartphone), and walk around the physical space. This can enable a user to automatically assign the beacon locations by simply walking by the beacons.
  • their device e.g., smartphone
  • the application can scan for beacon packets broadcast by the beacons as the entity walks through the space, associate the packets with the device location (e.g., measured or estimated), and automatically virtually locate the beacons within the space.
  • the system e.g., management system
  • the system can additionally automatically generate a virtual map or determine parameters of the space (e.g., length of walls, angles between walls, etc.).
  • the beacon can be virtually located within a preexisting virtual map of the space, based on the device location associated with the time of beacon identifier receipt.
  • the beacon location can additionally be determined based on the map, the device location, and the beacon sensor measurements.
  • the beacon location can be determined based on a position on the map proximal the device location, wherein the space surface (e.g., wall, floor, ceiling, etc.) is determined based on the beacon accelerometer measurements.
  • the beacon can be virtually located within a preexisting virtual map of the space based on the beacon's location relative to other beacons within the space.
  • a beacon receives packets from adjacent secondary beacons, determines the secondary beacon distance from the beacon (e.g., based on time of flight, as determined from the broadcast time and receipt time), and determines the secondary beacon locations within the space based on a known location of the beacon within the space, the secondary beacon distance from the beacon, and the virtual map (e.g., locations within the virtual map having similar distances as the secondary beacon distances).
  • the application can scan for beacon packets broadcast by the beacons as the entity walks through the space, receive beacon packets from the beacons as the entity walks through the space, associate the packet information with the receipt time, record a timestamped series of device locations and/ or orientation information (e.g., accelerometer, etc.) as the entity walks through the space, and send the timestamped beacon packet information (e.g., beacon identifier) and device locations to the management system.
  • the management system can associate a physical location with the beacon identifier (e.g., determined from the beacon packet information).
  • the physical location can be the device location timestamped with a time within a threshold time duration of the beacon packet receipt timestamp, an estimated physical beacon location, or be any other suitable location.
  • the estimated physical beacon location can be determined from the device location and the packet time of flight (e.g., determined from the difference between the packet broadcast time and the packet receipt time).
  • the management system can identify a first beacon identifier recorded at a first and second timestamp from the timestamped beacon packet information, identify the first and second device locations associated with the first and second timestamps, determine a first and second time of flight for the first and second instances, respectively, of first beacon identifier recordation, and determine (e.g., triangulate) the location of the first beacon based on the first and second device locations and the first and second times of flight.
  • the physical beacon location can be otherwise determined.
  • the management entity can position the beacons within the physical space, wherein the beacons can cooperatively automatically map the physical space based on the relative position of other beacons within the space (e.g., based on packet broadcast time of flight, beacon orientation, etc.). This can further simplify beacon setup, since the user can merely mount the beacons in the desired physical locations, and the system automatically determines the floorplan layout and relative beacon positions based on beacon measurements.
  • the beacons can share the information received during scanning
  • scanning information e.g., beacon identifiers, broadcast timestamps, receipt timestamps
  • scanning information e.g., beacon identifiers, broadcast timestamps, receipt timestamps
  • the management system receives and tracks the beacon identifiers received by the scanning beacons (e.g., via a user device or application); or through any other suitable sharing system.
  • a first beacon scans for packets broadcast by secondary beacons and records scanning information for each received packet (e.g., the packet broadcast time, the broadcasting beacon identifier, and the packet receipt time).
  • the first beacon preferably switches to a higher-power protocol (e.g., BLE long range radio) when scanning, but can alternatively scan with the low-power protocol (e.g., BLE, UWB) used for broadcasting packets, or use any other suitable protocol.
  • the first beacon can then switch to a lower-power protocol and broadcast its beacon identifier. All or a subset of the remainder of the beacons within the space or population (e.g., defined by the managing entity or account) repeat the process.
  • all beacons can be deemed to have performed the process when no new beacon identifiers are identified from the beacon population's collective scanning process.
  • the scanning information from the scanning beacons can then be aggregated, wherein a virtual map can be automatically generated from the collective scanning information.
  • automatically generating the virtual map can include determining the relative beacon distances between each beacon of the plurality from the scanning information, wherein the virtual map can be generated from the relative distances.
  • the virtual map can additionally be generated from beacon sensor data (e.g., orientation data, such as accelerometer or gyroscope data; measured light emitted by secondary beacons, indicative of line-of-sight; magnetometer data, indicative of a wall beam; etc.), received signal characteristics (e.g., phase, strength, etc.), beacon identifiers, or any other suitable information.
  • beacon sensor data e.g., orientation data, such as accelerometer or gyroscope data; measured light emitted by secondary beacons, indicative of line-of-sight; magnetometer data, indicative of a wall beam; etc.
  • received signal characteristics e.g., phase, strength, etc.
  • beacon identifiers e.g., a beacon identifiers, or any other suitable information.
  • the beacon sensor data can be used to determine whether the beacon is arranged on a wall (e.g., when a gravity vector is parallel a known mounting surface).
  • this can be performed by operating the high-power or high-bandwidth radios of the beacon in a setup mode (e.g., scanning mode, master mode, etc.), wherein the system (e.g., beacon, application, management system) can determine the relative arrangement of the beacons based on the and/or any other suitable information.
  • a setup mode e.g., scanning mode, master mode, etc.
  • the system e.g., beacon, application, management system
  • the virtual map can be generated by iterating through different beacon arrangements until the measured relative distances match the virtual distances.
  • the virtual map can be generated by using an optimization method.
  • the virtual map can be otherwise determined (e.g., using an analysis module, such as one running a genetic algorithm).
  • the beacons can additionally be automatically virtually located within the newly generated map, wherein the physical location associated with the virtual beacon location can be assigned to the beacon.
  • the system and method can otherwise automatically map the beacons to the physical space.
  • each beacon of a set sequentially scans for and discovers other beacons within the scanning range and creates a graph of RSSI values (e.g., distance) to nearby beacons.
  • the graph is retrieved from each beacon when the application (e.g., a user device running the application) connects to the beacon, wherein the graph is subsequently used to determine the physical space layout.
  • the graph(s) from one or more beacons can be used to determine the relative beacon positions within the space, and the physical barriers within the space (e.g., walls) determined from the beacon mounting points (e.g., as determined from the beacon sensor measurements).
  • the physical layout can be otherwise determined.
  • the method can optionally include automatically monitoring beacon performance based on the information, which functions to automatically identify anomalous events requiring managing entity attention or action.
  • anomalous events can include: beacon displacement (e.g., falling off the wall), beacon removal (e.g., theft), missing beacons, low beacon SOC, beacon signal interference, or any other suitable anomalous event indicative of a change in or suboptimal beacon performance.
  • Monitoring beacon performance can additionally or alternatively function to provide information about beacon performance degradation over time, ambient environment change over time, or any other suitable information.
  • the beacon performance can be monitored based on the sensor measurements, beacon identifier requests (e.g., in aggregate, across multiple application instances or user devices, etc.), features extracted from beacon operation (e.g., new beacon identifier requests, new beacon sensor measurements, historic beacon identifier requests, historic beacon sensor measurements, etc.), or based on any other suitable information.
  • beacon identifier requests e.g., in aggregate, across multiple application instances or user devices, etc.
  • features extracted from beacon operation e.g., new beacon identifier requests, new beacon sensor measurements, historic beacon identifier requests, historic beacon sensor measurements, etc.
  • monitoring beacon performance can include: automatically determining occurrence of a predetermined event based on the stored information (e.g., historic operation parameter values) and performing an action in response to predetermined event occurrence, example shown in FIGURE 5.
  • the anomalous event can additionally be stored in association with the beacon identifier in the management system, which can subsequently be used to identify harsh beacon operating environments, bad beacon batches, or used in any other suitable manner.
  • the beacon performance can be otherwise monitored.
  • the predetermined event can be anomalous beacon operation, be an ambient environment event, or be any other suitable event.
  • the anomalous event can be determined when the new sensor measurements deviate beyond a threshold difference from historic values.
  • This analysis can consider measurements from one or more sensors. For example, a change in acceleration can be indicative of beacon movement (e.g., a fall).
  • low beacon SOC can be determined when the reported beacon voltage falls below a voltage threshold.
  • the anomalous event can be determined when a beacon trend substantially matches a predetermined pattern. For example, a sudden acceleration (e.g., from the accelerometer measurements) followed by a change in resting orientation (e.g., from the gyroscope measurements) can be indicative of a fall. In a second example, a sudden acceleration coupled with an increase in ambient temperature can be indicative of manual beacon removal (e.g., theft).
  • a sudden acceleration e.g., from the accelerometer measurements
  • a change in resting orientation e.g., from the gyroscope measurements
  • a sudden acceleration coupled with an increase in ambient temperature can be indicative of manual beacon removal (e.g., theft).
  • a sudden drop on beacon identifier receipt frequency by application instances (e.g., user devices) known to be within the beacon's broadcasting range can be indicative of beacon failure or broadcast blockage.
  • the anomalous event is determined using a machine learning module (e.g., anomalous event determination module), based on features extracted from beacon operation (e.g., the beacon's telemetry data).
  • the anomalous event determination module includes a different module for each anomalous event.
  • the anomalous event determination module outputs a probability for each anomaly event, wherein the recommended anomaly event can be the one with the highest probability. For example, a first module can determine the probability that a beacon has fallen, while a second module can determine the probability that the beacon has crashed.
  • the anomalous event determination module includes a series of modules that serially narrow the set possible anomalous events, wherein the anomalous event determination module outputs the recommended anomaly event.
  • the anomalous event can be otherwise determined.
  • the analysis modules can utilize one or more of: 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), and any other suitable learning style.
  • 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 e.g., using a Q-learning algorithm, using temporal difference learning
  • reinforcement learning e.g., using a Q-learning algorithm, using temporal difference learning
  • the analysis module can implement any one or more of: a regression algorithm (e.g., ordinary least squares, logistic regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing, etc.), an instance-based method (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, etc.), a regularization method (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, etc.), a decision tree learning method (e.g., classification and regression tree, iterative dichotomiser 3, C4.5, chi-squared automatic interaction detection, decision stump, random forest, multivariate adaptive regression splines, gradient boosting machines, etc.), a Bayesian method (e.g., naive Bayes, averaged one-dependence estimators, Bayesian belief network, etc.), a kernel method (e.g., a support vector machine, a radial basis function, a linear discriminate analysis, etc.), a clustering
  • the modules can be run or updated concurrently, serially, at varying frequencies, or at any other suitable time.
  • the modules can be validated, verified, reinforced, calibrated, or otherwise updated based on newly received, up-to-date data; past data or be updated based on any other suitable data.
  • the modules can be run or updated: periodically, in response to the user-specified event differing from the recommended event, or at any other suitable frequency.
  • Performing the action functions to treat the beacon anomaly as a trigger event, and can mitigate adverse effects arising from the detected event.
  • the action can be performed by the management system, the application, an application instance, the beacon, or by any other suitable component. Examples of actions that can be taken include: automatically ordering a new beacon (e.g., upon occurrence of a certain anomalous event class), automatically determining and pushing new operation instructions for neighboring beacons (e.g., increasing the broadcast frequency or strength to accommodate for a non-operational beacon), sending an alert to a user account associated with the beacon, or include any other suitable action.
  • Sending an alert to a user account functions to notify the managing entity of the anomalous event.
  • the alert can be automatically generated based on the determined anomalous event, based on managing entity preferences, or otherwise generated.
  • the alert can be a notification, text message, message to a linked social networking system account, email, or be any other suitable alert.
  • the alert can include a description of the anomalous event (e.g., "beacon fallen,” “replace beacon,” anomalous event class, etc.), a beacon identifier (e.g., a user-assigned beacon identifier, such as "kitchen beacon,” visual beacon identifier, such as “blue beacon,” beacon broadcast identifier, beacon static identifier, etc.), a beacon physical location (e.g., based on the location associated with the beacon in the management system, an estimated location based on beacon orientation sensor data, an estimated location based on locations of user devices that detected the beacon after the anomalous event, etc.), or include any other suitable information.
  • the alert can be sent to the application, a managing entity account, a managing entity device, or any other suitable endpoint.
  • the alert can be actionable (e.g., wherein a user can interact with the management system through the alert), or be unactionable (e.g., wherein the alert simply notifies the user of a problem).
  • the method can additionally include receiving an anomalous event confirmation, which functions to verify that the detected event occurred.
  • This can additionally provide a supervised training set, which can be used to train the anomalous event detection module.
  • the management system can automatically calibrate the anomalous event detection module based on the underlying beacon operation data and the confirmation.
  • the management system can automatically reinforce the anomalous event detection module based on the underlying beacon operation data and the confirmation.
  • the anomalous event detection module can be otherwise trained on the confirmation.
  • the confirmation is preferably received from the managing entity, but can alternatively be received from any other suitable user.
  • the confirmation can be received through the alert (e.g., through the notification), through subsequent managing entity action (e.g., rebooting the beacon, purchasing a new beacon, assigning a new beacon with the physical location previously associated with the beacon, etc.), or otherwise received.
  • the confirmation can additionally be stored in the management system in association with the managing entity, which functions to log managing entity actions on the anomalous event. This log can be used by multiple sub-entities of the managing entity to avoid redundant actions on the anomalous event. This can additionally function to prevent false negatives, which can skew the supervised training set.
  • the method can optionally include remotely controlling the beacons, which functions to control beacon operation (e.g., set settings, update the beacon, etc.) without being physically proximal the beacon.
  • remotely controlling the beacons can include: determining an update for the beacon; sending the update to the application S600; in response to application connection with the beacon, sending the update from the application to the beacon S700; and automatically updating the beacon in response to receipt of the update S800.
  • the beacon can be otherwise remotely controlled.
  • a software change (e.g., setting update, firmware upgrade, etc.) is received from the managing entity at the management system (e.g., through a RESTful API, a management interface, etc.).
  • the management system transmits the update to the user devices running the application (e.g., running the SDK; as a beacon update notification, as an application update, etc.).
  • the update can be sent to the beacon and applied at the beacon.
  • the beacon can then be marked as updated (e.g., by the application, the management system, etc.).
  • Determining an update for the beacon S610 functions to receive new information for the beacon.
  • the update can include: new firmware, new settings (e.g., operation schedules, broadcast identifier equations, content sent within the packet, etc.), new accounts associated with the beacon, or any other suitable information.
  • the update can be received from the managing entity (e.g., through a management interface or application, from a management account, etc.), generated by a manufacturer, received from an advertising company, or otherwise determined.
  • the update is preferably determined by the management system, but can alternatively be otherwise determined.
  • the update can be determined for a single beacon of the set, for a subset of the set, for the entirety of the set, for beacons associated with multiple managing entities, or for any other suitable population of beacons.
  • the update can be individually addressed to the beacons, globally addressed, or otherwise addressed.
  • the update can be an update packet, including all information required to update the beacon; an update reference (e.g., an update link), wherein the application instance or beacon subsequently retrieves the update packet from the management system based on the update reference; or be any other suitable data structure.
  • the beacon set to be updated can be associated with the management entity, associated with a beacon population (e.g., for a store or geofence), have identifiers on an update list, or be otherwise designated for updating
  • Sending the update to the application S600 functions to transfer the new information to an intermediary, wherein the intermediary communicates the information to the beacon.
  • the update can be sent to all applications (e.g., to applications associated with multiple managing entities).
  • the update can be sent to only the application associated with the managing entity.
  • the update can be sent to instances of the application(s) running on user devices within a predetermined geographic region of the beacon.
  • These user devices can be: user devices with geographic locations within a predetermined distance of the beacon location; user devices (or application instances) that have detected the beacon before; user devices (or application instances) associated with a user within a user demographic, wherein the demographic has a probability over a threshold probability of being physically proximal the beacon in the future; or be any other suitable user device.
  • the update can be sent to instances of the application that have previously detected one or more of the beacons to be updated.
  • the update can be sent to application instances requesting information associated with a beacon of the beacon population (e.g., sending the remote computing system the beacon identifier).
  • the update can be sent to any other suitable set of applications or application instances.
  • sending the update to the application includes: pushing the update to the application, wherein the application pushes the update to the application instances executing on the user devices.
  • Each user device stores the update until the respective application instance detects a beacon of the beacon population, wherein the update is sent to the beacon (e.g., retrieved by the beacon or pushed to the beacon) upon beacon detection.
  • sending the update to the application includes: detecting the beacon at an application instance; determining that the beacon is to be updated by the application instance (e.g., based on a list of beacons to be updated, wherein the list is received from the management system and stored by the respective user device); requesting the update from the management system (e.g., based on the beacon identifier), by the application instance, in response to determination that the beacon is to be updated; and sending the update to the beacon in response to receipt of the update from the management system.
  • sending the update to the application includes: detecting the beacon at an application instance; receiving the beacon packet at the management system from the application instance; in response to the update version (e.g., firmware version, setting version, etc.) differing from the current update version, sending the current update to the application instance from the management system (e.g., along with content associated with the beacon; in response to update receipt at the application instance, sending the update to the beacon).
  • the update can be otherwise sent to the beacon.
  • the method can include individually applying the updates to the respective beacons.
  • this can include pushing all updates to a given beacon, wherein the beacon selects and applies the update addressed to itself.
  • this can include receiving a broadcast beacon packet at the application instance or remote computing system, extracting a beacon identifier from the beacon packet, selecting the update for the beacon based on the beacon identifier, and transmitting the selected update to the beacon.
  • individual updates for each beacon can be otherwise individually applied.
  • beacon Automatically updating the beacon in response to receipt of the update S8oo functions to overwrite or otherwise adjust the parameters used by the beacon to operate.
  • the beacon preferably automatically controls the updating process in response to receipt of the update (or update link) at the beacon, but the application instance or any other suitable device can alternatively or additionally control beacon updating.
  • the beacon preferably receives the update packet, stores the update packet until a predetermined time (e.g., after operation hours, when traffic is low, when sensor data satisfies a predetermined condition, etc.), and updates its parameters based on the update packet.
  • the beacon can immediately update itself in response to receipt of the update packet. However, the beacon be updated at any other suitable time.
  • the method can optionally include version control.
  • Version control can be performed by the beacon, the application instance, the remote computing system, or by any other suitable system.
  • the beacon can apply any received update, only apply updates addressed to itself, only apply updates having a version number different (e.g., higher) than the current version number (e.g., operating beacon setting number), or control updating in any other suitable manner.
  • the application instance compares the beacon's current version (e.g., extracted from the beacon packet and/ or retrieved from the beacon itself) with the update packet's version, and transmits the update packet to the beacon when the beacon's current version is older than the update packet's version (or satisfies another condition).
  • the remote computing system receives the beacon's current version from the application instance, compares the beacon's current version and update packet's version, and controls beacon updating when the beacon's current version is older than the update packet's version (e.g., instructs the application instance to transmit the update; sends the update for the beacon to the application instance for forwarding, etc.).
  • the operation parameter version control can be otherwise achieved.
  • the method can optionally include tracking which beacons have been updated, which can function to minimize the beacon power expenditure wasted by updating the same beacon with the same update. This can additionally or alternatively function to identify which beacons need further updating action.
  • the beacon can track whether it has been updated.
  • the beacon can check the update version in response to update receipt, prior to automatic beacon updating. For example, the beacon can determine the update version (e.g., by reading the update packet, reading the update link, etc.), compare the received update version to the update version stored by the beacon, and initiate the update process in response to the stored update version differing from the received update version.
  • the beacon can otherwise track its own update history.
  • the management system can track whether the beacon has been updated.
  • the management system can monitor the beacon packets received from application instances after the update has been sent to the application, wherein a beacon identifier is marked as updated in response to receipt of a beacon packet with the updated version number.
  • the management system can mark the beacon identifier as updated when the beacon identifier is received from an application instance that has received the beacon update.
  • the management system can additionally analyze the population of beacons associated with the managing entity, identify beacon identifiers that have not been updated, and send beacon information (e.g., beacon location, visual identifiers, etc.) associated with the identified beacon identifiers to the managing entity.
  • the management system can decline to send the update packet to updated beacons in response to receipt of an update request from the updated beacon.
  • the management system can otherwise control update release to the beacons.
  • the application can track whether the beacon has been updated, wherein the application tracks the beacons that the application instances (e.g., individual user devices) have connected to and pushed updates to.
  • the application can additionally verify beacon update based on the beacon packets (e.g., update version in the packets) received by the application instances (e.g., same instances that pushed the update or different instances).
  • the beacon update status can be tracked in any other suitable manner.
  • taking further updating actions functions to update beacons that were not updated through the application intermediary. This can be performed in response to determination that a beacon within the designated set has not been updated within a predetermined time period.
  • taking further updating actions includes sending a notification to the managing entity to manually re-program the un-updated beacon.
  • taking further updating actions includes controlling the beacons to form a mesh network, and passing updates through the mesh network to the un-updated nodes.
  • the beacon population can form a mesh, wherein the application sends the update instructions (e.g.
  • the beacon can receive the instruction and control the population of beacons to form a mesh network (e.g., immediately, at a predetermined time, etc.).
  • the beacons can use a high-power protocol (e.g., BLE long range, Zigbee, UWB, etc.) to form the mesh, use a low-power protocol to form the mesh, or use any other suitable protocol.
  • the beacon population can be otherwise controlled to form a mesh network.
  • any other suitable action can be taken.
  • the second variation can optionally include configuring the mesh.
  • configuring the mesh includes: operating a beacon's radio in a scanning mode (e.g., master mode, server mode), scanning for neighboring beacons (e.g., scanning for and/ or receiving beacon packets broadcast by neighboring beacons operating in a scanning or broadcast mode), and storing the neighboring beacons' identifiers in association with the receiving beacon (e.g., stored on-board the receiving beacon, in a remote system in association with the receiving beacon's identifier).
  • a scanning mode e.g., master mode, server mode
  • scanning for neighboring beacons e.g., scanning for and/ or receiving beacon packets broadcast by neighboring beacons operating in a scanning or broadcast mode
  • storing the neighboring beacons' identifiers in association with the receiving beacon (e.g., stored on-board the receiving beacon, in a remote system in association with the receiving beacon's identifier).
  • the mesh can be formed using the beacon's high-bandwidth, short-range radio (e.g., UWB); low-bandwidth, short- range radio (e.g., BLE), or any other suitable radio.
  • the mesh can be formed automatically (e.g., upon installation), in response to occurrence of a mesh formation event (e.g., formation command receipt, etc.), or at any other suitable time.
  • forming the mesh can include: operating a beacon as a slave or client mode (e.g., wherein the beacon does not scan/ listen for other devices and just broadcast the beacon's information); in response to detection of an updating event, operating the beacon in a master or server mode (e.g., wherein the beacon can discover and connect to other BLE devices, such as other beacons; wherein the beacon automatically connects to the neighboring beacons based on the stored identifiers; etc.); connecting to other auxiliary beacons in the master/ client mode; transmitting data from the beacon to the auxiliary beacons over the resultant connection; and optionally operating the beacon in the slave or client mode after data transmission.
  • a beacon as a slave or client mode
  • a master or server mode e.g., wherein the beacon can discover and connect to other BLE devices, such as other beacons; wherein the beacon automatically connects to the neighboring beacons based on the stored identifiers; etc.
  • connecting to other auxiliary beacons in the master/ client mode transmitting data from
  • Data can be communicated through the mesh using the radio used to form the mesh or using a different radio (e.g., having different or similar range).
  • Transmitting the data (e.g., update) through the mesh can optionally include verifying update receipt, such as by receiving a verification from the auxiliary beacon, receiving an update version number (e.g., firmware version) for the beacon through subsequent beacon interactions (e.g., with application instances subsequently receiving packets broadcast by the beacon) at a monitoring system (e.g., the remote computing system, application, etc.), or otherwise verifying update receipt.
  • verifying update receipt such as by receiving a verification from the auxiliary beacon, receiving an update version number (e.g., firmware version) for the beacon through subsequent beacon interactions (e.g., with application instances subsequently receiving packets broadcast by the beacon) at a monitoring system (e.g., the remote computing system, application, etc.), or otherwise verifying update receipt.
  • verifying update receipt such as by receiving a verification from the auxiliary beacon, receiving an update version number (
  • the updating event can be: updated setting application to the beacon; a predetermined time being met; GPIO readings satisfying a predetermined value, frequency, or other parameter; or any other suitable event.
  • the transmitted data can include settings (e.g., the updated settings applied to the beacon), firmware, or any other suitable information.
  • the information can be used to build intelligent data routes— how to relay data from one beacon to another. This increase the data routing efficiency (and/or power or resource usage) over conventional flooded architectures.
  • the beacons can cooperatively form a fully functional, real-time mesh (e.g., using WiFi, Zigbee, BLE, UWB etc.) and communicate information through the mesh.
  • An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions.
  • the instructions are preferably executed by computer-executable components preferably integrated with a beacon management system.
  • the beacon management system can include a set of beacons associated with a managing entity, an application (e.g., associated with the managing entity or with a second managing entity), and a management system.
  • the computer-readable medium may be stored on any suitable computer readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device.
  • the computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device.
  • the preferred embodiments include every combination and permutation of the various system components and the various method processes, wherein the method processes can be performed in any suitable order, sequentially or concurrently.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de gestion de balises distribuées consistant à : diffuser un paquet à partir de la balise; recevoir le paquet au niveau d'une application exécutée sur une pluralité de dispositifs utilisateurs; et transmettre des informations de balise extraites du paquet au système de gestion à partir de l'application.
PCT/US2017/031811 2016-05-10 2017-05-09 Système et procédé de gestion d'une flotte de balises WO2017196883A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662334115P 2016-05-10 2016-05-10
US62/334,115 2016-05-10
US201662416395P 2016-11-02 2016-11-02
US62/416,395 2016-11-02

Publications (1)

Publication Number Publication Date
WO2017196883A1 true WO2017196883A1 (fr) 2017-11-16

Family

ID=60266757

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/031811 WO2017196883A1 (fr) 2016-05-10 2017-05-09 Système et procédé de gestion d'une flotte de balises

Country Status (1)

Country Link
WO (1) WO2017196883A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108387866A (zh) * 2018-01-16 2018-08-10 南京航空航天大学 一种基于强化学习的无人机查找非法广播电台方法
WO2020039252A1 (fr) * 2018-08-22 2020-02-27 Estimote Polska Sp Z.O.O. Système et procédé pour vérifier la sécurité d'un dispositif
US10616709B2 (en) 2015-09-02 2020-04-07 Estimote Polska Sp z o.o. System and method for lower power data routing
CN111027915A (zh) * 2019-12-17 2020-04-17 哈尔滨工业大学 一种基于蓝牙技术的智能物流安全辅助系统
US11632343B2 (en) 2017-11-08 2023-04-18 Carrier Corporation Mesh networking using peer to peer messages for a hospitality entity

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150334548A1 (en) * 2014-05-19 2015-11-19 Aerohive Networks, Inc. Deployment of proximity beacon devices
US9202245B2 (en) * 2013-08-19 2015-12-01 Estimote Polska Sp. Z O.O. Wireless beacon and methods
US20150351008A1 (en) * 2014-05-27 2015-12-03 Apple Inc. Centralized Beacon Management Service
US9282582B1 (en) * 2014-10-31 2016-03-08 Aruba Networks, Inc. Sleep control for network of bluetooth low energy devices
WO2016043388A1 (fr) * 2014-09-18 2016-03-24 Hana Micron Inc. Serveur de gestion de balise pour la lutte anti-contrefaçon
US9307355B2 (en) * 2013-06-27 2016-04-05 Bluecats Australia Pty Limited Location enabled service for enhancement of smart device and enterprise software applications
US20160105788A1 (en) * 2014-10-14 2016-04-14 Radius Networks Inc. Interleaving multiple bluetooth low energy advertisements

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9307355B2 (en) * 2013-06-27 2016-04-05 Bluecats Australia Pty Limited Location enabled service for enhancement of smart device and enterprise software applications
US9202245B2 (en) * 2013-08-19 2015-12-01 Estimote Polska Sp. Z O.O. Wireless beacon and methods
US20150334548A1 (en) * 2014-05-19 2015-11-19 Aerohive Networks, Inc. Deployment of proximity beacon devices
US20150351008A1 (en) * 2014-05-27 2015-12-03 Apple Inc. Centralized Beacon Management Service
WO2016043388A1 (fr) * 2014-09-18 2016-03-24 Hana Micron Inc. Serveur de gestion de balise pour la lutte anti-contrefaçon
US20160105788A1 (en) * 2014-10-14 2016-04-14 Radius Networks Inc. Interleaving multiple bluetooth low energy advertisements
US9282582B1 (en) * 2014-10-31 2016-03-08 Aruba Networks, Inc. Sleep control for network of bluetooth low energy devices

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10616709B2 (en) 2015-09-02 2020-04-07 Estimote Polska Sp z o.o. System and method for lower power data routing
US10771917B2 (en) 2015-09-02 2020-09-08 Estimote Polska Sp z o.o. System and method for low power data routing
US11006237B2 (en) 2015-09-02 2021-05-11 Estimote Polska Sp z o.o. System and method for low power data routing
US11632343B2 (en) 2017-11-08 2023-04-18 Carrier Corporation Mesh networking using peer to peer messages for a hospitality entity
US11784950B2 (en) 2017-11-08 2023-10-10 Carrier Corporation Mesh networking using peer to peer messages for a hospitality entity
CN108387866A (zh) * 2018-01-16 2018-08-10 南京航空航天大学 一种基于强化学习的无人机查找非法广播电台方法
WO2020039252A1 (fr) * 2018-08-22 2020-02-27 Estimote Polska Sp Z.O.O. Système et procédé pour vérifier la sécurité d'un dispositif
US11218492B2 (en) 2018-08-22 2022-01-04 Estimote Polska Sp. Z .O.O. System and method for verifying device security
CN111027915A (zh) * 2019-12-17 2020-04-17 哈尔滨工业大学 一种基于蓝牙技术的智能物流安全辅助系统

Similar Documents

Publication Publication Date Title
US9942706B2 (en) System and method for beacon fleet management
US10142786B2 (en) System and method for multi-beacon interaction and management
JP6825159B2 (ja) 無線ノードネットワーク内の事象候補を識別する向上したモニタリングのシステム、マスターノード装置及び方法
WO2017196883A1 (fr) Système et procédé de gestion d'une flotte de balises
Priyadarshi et al. Wireless sensor networks deployment: a result oriented analysis
US9997963B2 (en) Techniques for scheduling delivery of wireless power in wireless power delivery environments
JP7495944B2 (ja) 動き検出システムにおいて新しい動きゾーンを検出するためのオフラインチューニングシステム
US20180321356A1 (en) Asset location and management system with distributed processing
Luo et al. Enhancing Wi-Fi fingerprinting for indoor positioning using human-centric collaborative feedback
Hoang et al. Realisation of a cluster‐based protocol using fuzzy C‐means algorithm for wireless sensor networks
CN104620642A (zh) 便携式资源管理系统和方法
KR20160111473A (ko) 무선 전력 및 통신을 위한 시스템 및 방법
Estanjini et al. Optimizing warehouse forklift dispatching using a sensor network and stochastic learning
Shen et al. When RSSI encounters deep learning: An area localization scheme for pervasive sensing systems
US20220353328A1 (en) Methods and apparatus to dynamically control devices based on distributed data
JP6624780B2 (ja) 測位方法、サーバ及びプログラム
US10432459B2 (en) Method for the automatic configuration of portable terminals
US20150281807A1 (en) Wireless Sensory and Data Transmission System
WO2022070548A1 (fr) Système d'estimation de position, dispositif sans fil fixe et dispositif sans fil mobile
US20230037710A1 (en) Smart security assistant for residential and office environments
US12232073B2 (en) Method and system for searching and locating radio devices
Mohd Sabri Design of an adaptive RF fingerprint indoor positioning system
Huu et al. Enhancing Indoor Localization with Machine Learning and WiFi Signals from Mobile Devices

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17796712

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17796712

Country of ref document: EP

Kind code of ref document: A1