U.S. patent application number 17/665416 was filed with the patent office on 2022-05-19 for method and system for asset management.
The applicant listed for this patent is Estimote Polska Sp z o.o.. Invention is credited to Lukasz Kostka, Jakub Krzych.
Application Number | 20220155461 17/665416 |
Document ID | / |
Family ID | 1000006125325 |
Filed Date | 2022-05-19 |
United States Patent
Application |
20220155461 |
Kind Code |
A1 |
Krzych; Jakub ; et
al. |
May 19, 2022 |
METHOD AND SYSTEM FOR ASSET MANAGEMENT
Abstract
An asset management system can include one or more beacons, a
remote computing system, and a program. The asset tracking method
can include operating the beacon according to programmable
instructions, and can additionally or alternatively learn to detect
events.
Inventors: |
Krzych; Jakub; (San
Francisco, CA) ; Kostka; Lukasz; (San Francisco,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Estimote Polska Sp z o.o. |
Krakow |
|
PL |
|
|
Family ID: |
1000006125325 |
Appl. No.: |
17/665416 |
Filed: |
February 4, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
17082513 |
Oct 28, 2020 |
|
|
|
17665416 |
|
|
|
|
16551379 |
Aug 26, 2019 |
10852441 |
|
|
17082513 |
|
|
|
|
62881766 |
Aug 1, 2019 |
|
|
|
62772534 |
Nov 28, 2018 |
|
|
|
62722397 |
Aug 24, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G01S 19/11 20130101;
G01S 19/49 20130101; H04B 17/318 20150115; G06F 7/588 20130101;
H04L 67/02 20130101; H04W 12/069 20210101; H04W 4/029 20180201;
H04W 4/80 20180201; H04W 12/03 20210101 |
International
Class: |
G01S 19/11 20060101
G01S019/11; G01S 19/49 20060101 G01S019/49; H04B 17/318 20060101
H04B017/318; G06F 7/58 20060101 G06F007/58; H04W 4/029 20060101
H04W004/029; H04W 4/80 20060101 H04W004/80; H04L 67/02 20060101
H04L067/02; H04W 12/03 20060101 H04W012/03; H04W 12/069 20060101
H04W012/069 |
Claims
1. A system, comprising a remote computing system and an anchor
beacon, the anchor beacon comprising: a first processor operably
connected to an inertial measurement unit, wherein the first
processor is operable between a training mode and a processing
mode, wherein the first processor is configured to log data
associated with an event in the training mode, and is configured to
detect the event in the processing mode; a Bluetooth system,
wherein the Bluetooth system is operable between a plurality of
modes comprising a scanning mode and an offline mode, and wherein
the Bluetooth system is configured to scan for a venue beacon
packet associated with a venue beacon in the scanning mode; and a
second processor, separate and distinct from the first processor,
that is configured to process the venue beacon packet and generate
a payload according to custom instructions; a cellular system,
wherein the cellular system is configured to: transmit the payload
to a remote computing system; and receive a remote payload from the
remote computing system; a security system, wherein the security
system comprises a random number generator.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. Nonprovisional
application Ser. No. 17/082,513 filed 28 Oct. 2020, which is a
continuation of U.S. Nonprovisional application Ser. No. 16/551,379
filed 26 Aug. 2019 which claims the benefit of U.S. Provisional
Application number 62/722,397 filed 24 Aug. 2018, US Provisional
Application number 62/772,534 filed 28 Nov. 2018, and US
Provisional Application number 62/881,766 filed 1 Aug. 2019, each
of which is incorporated in its entirety by this reference.
[0002] This application is related to U.S. application Ser. No.
15/620,014 filed 12 Jun. 2017, U.S. application Ser. No. 16/271,080
filed 8 Feb. 2019, U.S. application Ser. No. 15/789,767 filed 20
Oct. 2017, U.S. application Ser. No. 15/836,291 filed 8 Dec. 2017,
and U.S. application Ser. No. 15/784,774 filed 16 Oct. 2017, each
of which is incorporated in its entirety by this reference.
TECHNICAL FIELD
[0003] This invention relates generally to the field of wireless
communication, and more specifically to a new and useful method for
managing an asset in the field of wireless communication.
BRIEF DESCRIPTION OF THE FIGURES
[0004] FIG. 1 is a schematic representation of the method.
[0005] FIG. 2 is a schematic representation of the method.
[0006] FIG. 3 is a schematic representation of the system.
[0007] FIG. 4 depicts variants of information shared between
components of system.
[0008] FIG. 5 is an example of information shared between
components of system associated with S200.
[0009] FIG. 6 depicts variants of information shared between
components of system.
[0010] FIG. 7 depicts an example set of components of an anchor
beacon.
[0011] FIG. 8 depicts an example of the radio layout of an anchor
beacon.
[0012] FIG. 9 depicts an example set of components of the secondary
beacon 300.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0013] The following description of the preferred embodiments of
the invention is not intended to limit the invention to these
preferred embodiments, but rather to enable any person skilled in
the art to make and use this invention.
1. Overview.
[0014] As shown in FIG. 1, the method includes: operating an anchor
beacon according to instructions determined by a client S100, and
additionally or alternatively includes operating the anchor beacon
according to a learned model S200. The method functions to enable
users to specify custom beacon responses (e.g., through
user-provided programs), while maintaining centralized beacon
population control (e.g., by the remote computing system, beacon
registry, etc.)
[0015] As shown in FIG. 3, the system 30 preferably includes: a
client 360, a program 380, a remote computing system 400, one or
more anchor beacons 320, and can additionally or alternatively
include one or more secondary beacons 300. The system additionally
or alternatively includes any other suitable element.
[0016] The method is preferably performed using the system 30,
however, the method can additionally or alternatively be performed
using any other suitable system.
2. Benefits.
[0017] The inventors have discovered that a mobile device can be
deployed to aid in asset management.
[0018] First, the inventors have discovered that conventional
methods to program mobile devices, such as IoT devices, can be
challenging. The inventors have developed a system that enables a
user (e.g., via a client) to program a beacon (e.g., mobile device)
by compiling code (e.g., user-provided code, template functions,
etc.) into bytecode, wherein the bytecode can be sent to (e.g.,
flashed onto; transmitted to, such as via Web Bluetooth.TM.; etc.)
the beacon (e.g., after beacon manufacture, after beacon sale). In
variants, the client can be a web browser, wherein the code can be
written in a web-based programming language (e.g., javascript)
using a set of beacon parameter abstractions (e.g., beacon
abstractions, location abstractions, etc.), and compiled at the
remote computing system into bytecode, wherein the bytecode can be
sent to the beacon (e.g., via the client, directly to the beacon
via a cellular connection). These variants can be particularly
compelling because it allows users to program in a familiar
language (e.g., a web-based programming language), and also to use
a set of human-understandable abstractions. In these variants, the
remote computing system can disambiguate or resolve the
abstractions (used for facile programming purposes) into the
specific beacon identifier strings, the specific list of beacon
identifiers associated with a given geographic identifier, the
geofence or geocoordinates associated with the geographic
identifier, and/or any other suitable information, wherein the
disambiguated information can be compiled into the bytecode and
sent to the beacon for execution. Furthermore, this frees beacon
memory by reducing the parameters and/or associations stored at
each beacon.
[0019] Second, in variants, the beacon can be trained to identify
events. For example, a beacon can log sensor data during a training
session (e.g., while the beacon is in a training mode and the
beacon is subjected to the event) and send the sensor data to a
remote computing system (e.g., in a batch, streamed, etc.), wherein
the remote computing system can generate a model based on the
sensor data, compile the model into bytecode, and send the model
back to the beacon. In specific examples where the model is being
executed on a dedicated on-board processor (e.g., coupled to the
IMU, separate and distinct from the main processor, etc.), the
model can be received at the main processor and sent to the
on-board processor for storage and execution. However, the beacon
can be otherwise trained.
[0020] Third, the beacon can provide high-accuracy location
measurements (e.g., sub-io-cm measurements) in a low-power manner
when stationary and/or during translation. In one example, the
beacon can determine an initial beacon location using one or more
UWB radios (e.g., using time of flight of the UWB signal),
determine the amount of beacon translation using an on-board IMU,
and determine the beacon location based on the initial beacon
location and the IMU readings (e.g., using odometry).
[0021] However, the beacon can confer any other suitable set of
benefits.
3. System 30.
[0022] The system 30 preferably includes: a client 360, a program
380, a remote computing system 400, one or more anchor beacons 320,
and can additionally or alternatively include one or more secondary
beacons 300.
[0023] The system 30 can include one or more secondary beacons 300.
The secondary beacon preferably aids in determining the anchor
beacon's location (e.g., indoor position; presence within a
predetermined geographic region, such as a building; etc.), but can
additionally or alternatively provide any other suitable set of
functionalities.
[0024] The secondary beacon (e.g., venue beacon) is preferably
positioned in a venue (e.g., in a manufacturing facility, office
building, store, center, vehicle etc.), but can additionally or
alternatively be positioned on a venue (e.g., on a vehicle, tent,
gate, doorway etc.), on an asset (e.g., person, cart, package,
item, etc.), or otherwise positioned. The secondary beacon is
preferably statically mounted to the mounting point, but can be
transiently mounted to the mounting point. The secondary beacon is
preferably associated with the mounting point (e.g., in the beacon
registry, maintained by the remote computing system), more
preferably representative of the mounting point's location (e.g.,
geolocation, indoor position, etc.), but can be additionally or
alternatively associated with any other suitable information.
[0025] In variants, the secondary beacon can have limited
processing power and/or functionality. In one example, the
secondary beacon operates according to manufacturer-provided,
standard bytecode, wherein the user can set variable values (e.g.,
determining scanning and advertising frequency), but the user
cannot specify event detection and transmission. However, the
secondary beacon can be otherwise configured.
[0026] The secondary beacon is preferably operable during an active
session. The active session can be determined by the client, remote
computing system, by the secondary beacon (e.g., in response to
packet detection, motion detection, presence detection, etc.),
and/or otherwise determined. However, the secondary beacon can be
otherwise operable.
[0027] The secondary beacon is preferably operable between one or
more modes. The secondary beacon can operate in each mode at a
frequency and according to operation conditions specified by the
standard bytecode (e.g., periodically at a predetermined
advertising period), but can operate according to predetermined
settings, according to settings received from the remote computing
system (e.g., wherein the remote computing system can control a
limited set of beacon functions, such as advertising schedules,
wake schedules, scanning schedules, etc,), or according to any
other suitable set of instructions.
[0028] The modes can include: an advertising mode, a scanning mode,
an offline mode, and/or any other suitable set of modes.
[0029] The advertising mode preferably includes using one or more
Bluetooth radios to advertise a secondary beacon identifier, but
can be otherwise executed. The secondary beacon can optionally
transmit a payload (e.g., wherein both the secondary beacon
identifier and the payload can be included in a frame broadcast by
the secondary beacon), and/or any other suitable information in the
advertising mode.
[0030] The secondary beacon is preferably operable in a scanning
mode. The scanning mode preferably includes using one or more
Bluetooth radios to scan for secondary beacon packets, the packets
comprising one or more beacon identifiers. The Bluetooth radio can
optionally collect signal processing information (e.g., RSSI, TOF,
etc.), and/or any other suitable information associated with the
received packets.
[0031] The secondary beacon is preferably operable in an offline
mode. The secondary beacon can operate in the offline mode when the
secondary beacon is not in an active session, and/or at any other
suitable time. After determining an instruction to operate in the
offline mode, the secondary beacon can instruct all sensors and/or
radios to operate in the offline mode, and/or a subset of the
sensors and/or radio to operate in the offline mode. However, the
secondary beacon can additionally or alternatively be operable in
any other suitable mode.
[0032] As shown in FIG. 9, the secondary beacon 300 can include one
or more communication systems 306 (e.g., Bluetooth radios executing
one or more Bluetooth protocol and/or specifications, such as
Bluetooth Low Energy (BLE), Bluetooth Classic, Ultra Wide Band,
Bluetooth 1,0, 1.1. 1.2, 2.0, 2.1, 3.0, 4.0, 4.1, 4.2, 5.1, etc.),
one or more processing systems 308, one or more power supplies 310,
one or more secondary adhesive layers 312, a secondary housing 302
enclosing and mounting the aforementioned components, and/or any
other suitable component. In a specific example, the secondary
beacon consists essentially of one or more: short-range
communication systems (e.g., one or more Bluetooth radios, NFC
radios, etc.), processing systems, power supplies, inertial sensors
(e.g., accelerometers), optionally ambient environment sensors
(e.g., light sensors, microphones), and a housing (e.g., with
adhesive). However, the secondary beacon can be otherwise
configured.
[0033] The secondary beacon is preferably associated with a
secondary beacon identifier 605. The secondary beacon identifier
can be static (e.g., be a static public identifier that can be used
by user devices, clients, and/or third-party applications to
trigger predetermined actions associated with the secondary
beacon's public identifier), be transient or ephemeral (e.g.,
require a resolver to resolve the transient identifier into the
public identifier), and/or otherwise vary. The secondary beacon
identifier is preferably advertised within a packet 615 advertised
by the secondary beacon, but can be otherwise used.
[0034] The association between the beacon identifier, the specific
beacon, and any auxiliary beacon information (e.g., beacon location
or mounting point information, transient identifier, etc.) is
preferably stored by a beacon registry (e.g., managed by the remote
computing system), but can be otherwise stored. In one variation,
the remote computing system returns information (e.g., location
associated with the beacon, mounting point identifier, etc.)
associated with a secondary beacon identifier received from the
remote computing system from an intermediary (e.g., user device,
anchor beacon, etc.). In a second variation, the anchor beacon
performs a predetermined set of actions (e.g., user-specified
actions, standard actions, etc.) specified by the anchor beacon
bytecode in response to receipt of a packet with the secondary
beacon identifier. In variants wherein the secondary beacon
identifier is secured, the anchor beacon can optionally resolve the
secured secondary beacon identifier into the static public
identifier (e.g., based on a deterministic calculation, based on a
lookup table retrieved from the beacon registry, etc.).
[0035] In another variation, the secondary beacon identifier can be
encrypted using a secondary beacon key to obtain a secondary beacon
token. The secondary beacon key can be stored at both the remote
computing system and at the secondary beacon. The secondary beacon
identifier can be encrypted at a predetermined interval. The
predetermined interval can be based on a clock wherein the clock is
shared by the secondary beacon and the remote computing system. For
example, a secondary beacon identifier can by encrypted with the
secondary beacon key to obtain the secondary beacon token and the
secondary beacon token can be advertised by the secondary beacon.
After a predetermined period (e.g., every 20 minutes, every hour,
etc.), a new secondary beacon identifier can be generated by a
random number generator, the new secondary beacon identifier can be
encrypted using the beacon key to obtain a new secondary beacon
token, and the new secondary beacon token can be advertised by the
secondary beacon. However, the new secondary beacon identifier need
not be encrypted, or can be otherwise encrypted.
[0036] However, the secondary beacon can additionally or
alternatively be otherwise configured.
[0037] The system 30 preferably includes one or more anchor beacons
320. In variants, the event models, programs (e.g., bytecode),
and/or any other suitable data or instruction set determined for a
given anchor beacon can be replicated (e.g., pushed to) other
anchor beacons 320 in a given population, associated with a
specific user account, and/or any other suitable set of anchor
beacons.
[0038] The anchor beacon preferably includes the components of the
secondary beacon, but can additionally or alternatively include any
other components.
[0039] The anchor beacon preferably includes one or more radios.
The radios can include one or more Bluetooth radios (e.g.,
Bluetooth classic, BLE, etc.), such as those discussed above for
the secondary beacon. The radios can include one or more cellular
radios (e.g., LTE), short range radios (e.g., NFC, RF), global
navigation system radios (e.g., GPS, GLONASS, Galileo, etc.),
and/or any other suitable set of radios. The radios can include or
share one or more chipsets. However, the radios can additionally or
alternatively include any other suitable radio.
[0040] In variants, the antennas of one or more radios can be
arranged on the same plane (and/or be mounted to a common board).
The antennas for the respective radios can be: aligned (e.g.,
arranged in parallel), overlap, be radially distributed (e.g.,
arcuately distributed about a central point, example shown in FIG.
8), or otherwise arranged.
[0041] The anchor beacon preferably includes one or more sensors.
The sensors preferably include one or more motion sensors (e.g.,
IMU, accelerometer, gyroscope), temperature sensors, light sensors,
accelerometers, and/or any other suitable sensor. The sensors can
share a chipset with the processing system and/or the radios, but
can additionally or alternatively have individual chipsets (e.g.,
separate and distinct from the radio chipset, from the processor,
etc.).
[0042] In a specific example, the IMU can have a separate,
low-power chipset that is operated independently of the main
processing system. The low-power chipset can execute one or more
models (e.g., event models, learned models, etc.) and/or programs
that are specific to the IMU.
[0043] The anchor beacon can include one or more processing
systems. The processing system can include one or more CPUs, GPUs,
co-processors, microprocessors, clocks, storage, and/or any other
suitable element. The anchor beacon can include a power source
(battery, RF, etc.), a connector (e.g., data and/or port such as
USB-c), memory, inputs (e.g., buttons, microphones, etc.), outputs
(e.g., lighting, audio), housing enclosing the components of the
anchor beacon, and/or any other suitable components. However the
anchor beacon can additionally or alternatively include any other
suitable components.
[0044] In one variation, the anchor beacon includes two or more
processors. The first processor (e.g., the main processor)
preferably processes bytecode, coordinate sensor operation,
coordinates radio operation, and/or performs any other suitable
function. The second processor preferably processes machine
learning features (e.g., running event model, logging training
data, etc.), but can additionally or alternatively process any
other suitable feature. The anchor beacon can additionally or
alternatively include a third processor (e.g., secure module). The
third processor can store security keys, generate security keys,
handle payload and/or beacon identifier encryption, and/or perform
any other suitable set of functionalities. The anchor beacon can
include a housing, computer readable media, battery, a connector
and/or any other suitable component.
[0045] In one example, as shown in FIG. 7, the anchor beacon
consists essentially of: one or more processors 324; one or more
co-processors 326, wherein the co-processor(s) can include an AES
encryption system, one or more random number generators (e.g., true
random number generator for full entropy, or for any other suitable
benefit), and/or an asymmetric/symmetric hashing cryptographic
system; computer readable media 328 (e.g., RAM, Flash); one or more
Bluetooth radios 330 (e.g., BLE, Bluetooth classic, UWB radio 342,
etc.); a global navigation system 334 (e.g., that receives signals
from one or more satellites 420); a cellular radio 332 (e.g.,
modem); a battery 336 (e.g., lithium-ion rechargeable battery);
connector 338 (e.g., USB standard, such as USB-C, USB-A, micro-USB,
etc.; for data transfer and/or power transfer), a NFC radio (e.g.,
NFC programmable tag 344); a 3-axis accelerometer 340 or IMU; an
optional programmable push button 348; programmable outputs, such
as RGB LEDs; temperature sensor; adhesive layer 346; and housing
322 (e.g., durable non-toxic silicon; encloses most or all of the
aforementioned components). However, the anchor beacon can be
otherwise configured.
[0046] The anchor beacon preferably functions to track an asset.
The anchor beacon can execute one or more programs stored on-board
the anchor beacon. The anchor beacon can transmit event data to a
remote computing system.
[0047] The anchor beacon preferably operates according to the
instructions from bytecode 410. The bytecode is preferably based on
code determined by the client, but can be otherwise determined. The
code is preferably processed into (e.g., compiled into) bytecode by
the remote computing system, but can additionally or alternatively
be processed by the client, by a programming device, or otherwise
processed. The anchor beacon is preferably user programmable,
wherein the user can specify a predetermined set of functions
and/or processes and the system (e.g., the remote computing system)
can convert the user-specified programs into machine-executable
code that is executable by the limited processing capabilities of
the anchor beacon, but the anchor beacon can be otherwise
programmed.
[0048] Similar to the secondary beacon, the anchor beacon can be
operable between one or more modes. The anchor beacon can operate
in each mode at a frequency and according to operation conditions
specified by the bytecode (e.g., advertising schedules or periods,
scanning schedules or periods, transmit schedules or periods, wake
schedules, sleep schedules, etc,), but can operate according to
predetermined instructions, according to instructions or trigger
events received from the remote computing system (e.g., wherein the
remote computing system or bytecode can control the set of beacon
functions), or according to any other suitable set of instructions.
Examples of anchor beacon operation modes include: a training mode
(e.g., wherein the anchor beacon collects training data while being
subjected to an event), a processing mode (e.g., operating
according to the bytecode and/or an event model 515, which can be
received from the remote computing system or other compiler), a
scanning mode, an advertising mode, a transmitting mode, an offline
mode, and/or any other suitable
[0049] The anchor beacon can also function to sample data from
on-board sensors, receive secondary beacon packets (e.g., in the
scanning mode), resolve individual beacon identifiers from the
secondary beacon packet(s), determine the secondary beacon's
location relative to the anchor beacon (e.g., based on the RSSI,
AOA, time of flight, etc.), determine the ego location (e.g.,
location of the anchor beacon) based on known locations of each of
a set of secondary beacons (e.g., that the packets are received
from) and the respective estimated separation distance (e.g.,
determined based on the RSSI), communicate with the remote
computing system via a cellular radio, communicate with the client
(e.g., via web Bluetooth, through the remote computing system,
etc.), but can additionally or alternatively provide any other
suitable set of functionalities.
[0050] The anchor beacon is preferably operable in a training mode
505, which functions to generate an event model based on training
data. The anchor beacon operates in the training mode in response
to a training mode command (e.g., received from the user, received
from a remote computing system, detected at the anchor beacon,
etc.). The training mode preferably includes logging event data
related to a predetermined event (e.g., user-specified event)
wherein the anchor beacon is subjected to the event (e.g., the user
or other manipulator actuates the anchor beacon). The log data can
be streamed or periodically transmitted to the remote computing
system (e.g., via the client, via an intermediary device, directly
using the cellular radio, etc.). An example is shown in FIG. 5.
Each successive instance of the event can be identified by the
anchor beacon (e.g., wherein the anchor beacon labels each instance
in response to receipt of a training mode command or other
trigger), identified by the user (e.g., before or after each
instance; after the data is uploaded to the remote computing
system, etc.), and/or otherwise identified.
[0051] The event model is preferably determined by the remote
computing system (example shown in FIG. 5), but can be determined
by the client, an intermediary device, or any other suitable
computing device. The event model is preferably determined based on
the training data from the training session, but can be determined
based on historic data, population data, and/or any other suitable
data. The event model is preferably determined based on a template
model (e.g., for a specific processor, for the IMU processor, for
the event, etc.), but can be determined based on a reference model
(e.g., for the event, a prior model, etc.), or otherwise
determined. The event model is preferably sent to the anchor beacon
(e.g., directly via the cellular connection, via the client, via an
intermediary device, etc.), but can be executed by the remote
computing system (e.g., wherein anchor beacon data is streamed to
the remote computing system) or otherwise stored and executed. In
variants, the event model can be addressed to a specific processor
for storage and/or execution (e.g., the IMU processor).
[0052] The anchor beacon is preferably operable in a processing
mode 530. The processing mode functions to detect one or more
events 520. The events are preferably detected based on
measurements sampled by sensors on-board the anchor beacon, but can
be detected based on any other suitable data. The events are
preferably detected based on the bytecode, but can additionally or
alternatively be detected based on an event model, or otherwise
detected. The anchor beacon can operate in the processing mode
continuously, when in a wake state, in response to occurrence of a
precursor event, or at any other suitable time.
[0053] The anchor beacon is preferably operable in a scanning mode.
The scanning mode preferably includes using one or more Bluetooth
radios to scan for secondary beacon packets, wherein the packets
include one or more beacon identifiers. The Bluetooth radio can
collect signal processing information (e.g., RSSI, TOF, etc.),
and/or any other suitable information. However, the scanning mode
can be otherwise executed.
[0054] The anchor beacon is preferably operable in an advertising
mode. The advertising mode preferably includes using one or more
Bluetooth radios to advertise anchor beacon identifier and
additionally or alternatively a payload 420, and/or any other
suitable information. However, the advertising mode can be
otherwise executed.
[0055] The anchor beacon is preferably operable in a transmitting
mode. The transmitting mode preferably includes using one or more
cellular radios (or other long-range radios) to transmit the
payload 420 to the remote computing system (example shown in FIG.
4), but can additionally or alternatively transmit any other
suitable information to any other suitable entity.
[0056] The anchor beacon is preferably operable in an offline
mode.
[0057] In one variation, the anchor beacon operates in the offline
mode based on an IMU event. An IMU event can be if the acceleration
is below a predetermined threshold, such as zero (e.g., anchor
beacon is not moving) for a predetermined period of time. After
determining that the acceleration is below the predetermined
threshold, the anchor beacon can instruct all sensors and/or radios
to operate in the offline mode, and/or a subset of the sensors
and/or radio to operate in the offline mode.
[0058] In a second variation, if the acceleration is above a
predetermined threshold (e.g., the same or different from the
offline threshold), such as not zero (e.g., the anchor beacon is
moving), the anchor beacon can instruct all sensors and/or radios
to wake (and operate according to the bytecode). Alternatively or
additionally, the anchor beacon can operate in the wake mode in
response to the motion satisfying an event model. For example, the
IMU can detect a predetermined motion pattern, and/or the event
model can detect event occurrence based on the anchor beacon's
sensor data, such as an airplane take off and landing. After
detecting the motion pattern or event occurrence, such as after the
airplane is in the air, the anchor beacon can switch all the
sensors and/or radios to the active mode, and/or operate according
to (the remainder of) the bytecode.
[0059] However, the anchor beacon can be operable in any other
suitable mode.
[0060] In a first example, the anchor beacon can advertise the
anchor beacon identifier. In a second example, the anchor beacon
can scan for beacon packets comprising associated beacon
identifiers. In a third example, the anchor beacon can perform
range finding by leveraging RSSI (e.g., BLE, Bluetooth, etc.)
and/or time of flight (UWB, classic, etc.). In this example, the
anchor beacon can determine the ego location on-board the anchor
beacon, transmit the requisite information (e.g., secondary beacon
identifier, RSSI, etc.) to the remote computing system, or
otherwise determine the ego location.
[0061] In a fourth example, the anchor beacon can determine its
outdoor position using the GPS system and transmit coordinates to
the remote computing system at a predetermined frequency. The
coordinates can be used to track the anchor beacon (e.g., at the
remote computing system), wherein the anchor beacon is associated
with an asset.
[0062] In a fifth example, the anchor beacon can determine its
outdoor position using the GPS system and refine the outdoor
position using relative positioning (e.g., to secondary beacons;
with odometry, using the IMU measurements, etc.).
[0063] In a sixth example, the anchor beacon can determine indoor
position using UWB radio (e.g, x, y, z coordinates; using time of
flight (TOF), etc.). Over time, the anchor beacon can optionally
use odometry associated with IMU to refine the indoor position.
[0064] In a seventh example, the anchor beacon can encrypt a
payload (sensor data, identifier, event model, and/or any other
suitable data). The anchor beacon can send the payload to the
remote computing system, a secondary beacon, the client, or any
other suitable entity. The anchor beacon can encrypt the payload
using a symmetric key protocol, an asymmetric key protocol, or any
other suitable encryption scheme. For example, the remote computing
system determines a public key and associated private key and sends
the public key to the anchor beacon. The anchor beacon receives the
public key, generates a session key using the random number
generator, encrypts session key using the public key, and transmits
ciphertext of session key to the remote computing system. At the
remote computing system, decrypt the ciphertext using the private
key to obtain the session key. At anchor beacon, encrypt payload
using the session key and remote computing system can receive and
decrypt the payload using the shared session key.
[0065] In an eighth example, the anchor beacon can enter a
hibernation mode as the battery level starts to decrease past an
operable level. The LED can be programmed to blink at a
predetermined period (e.g., every 30 seconds, 5 minutes, etc.).
During hibernation mode, the clock can continue to operate. The
sensors and/or radios can operate in the offline mode.
[0066] However the anchor beacon can additionally or alternatively
include any other suitable component, and/or operate in any other
suitable manner.
[0067] The one or more anchor beacons and the one or more secondary
beacons can interact. For example, the anchor beacon can be placed
on an asset in a facility and secondary beacons can be placed at
different locations in the facility. The secondary beacons can
advertise their beacon identifiers and the anchor beacon can scan
for the secondary beacon packets. Using the packets, the anchor
beacon can determine its position based on RSSI (or TOF) in the
facility. When the anchor beacon is loaded into a vehicle, the
anchor beacon can receive satellite information from the GPS system
and send the satellite information to the cloud (e.g., remote
computing system). Then at a second facility, wherein the second
facility includes secondary beacons, the anchor beacon can detect
its indoor position based on the secondary beacons.
[0068] In another example, the anchor beacon can be attached in a
vehicle (e.g., truck, van, car, airplane, pod, etc.), such as on
the ceiling or side, and secondary beacons can be placed on assets
wherein assets are loaded into the vehicle.
[0069] In another example, the anchor beacon can be attached to the
inside of a vehicle, and scooters or any other suitable asset can
be placed in vehicle. The asset can advertise identifiers to the
anchor beacon and anchor beacon can transmit the asset identifiers
to the remote computing system. The remote computing system can
communicate with the user device to determine the number of assets
and associated asset identifiers in vehicle and/or any other
suitable information (e.g., battery levels of scooters, battery
level of anchor beacon, etc.).
[0070] In another example, the anchor beacon attached to the
outside of a vehicle (e.g., bus, van, pod, etc.). A secondary
beacon can be attached to an asset (e.g., person, object, animal,
etc.).
[0071] In another example, a secondary beacon can be placed at an
entrance of a room, and the anchor beacon can be connected to an
entity (e.g., human such as a janitor).
[0072] However, the one or more beacons can otherwise interact.
[0073] The system preferably includes one or more clients 360. The
client preferably functions as an interface for a user to generate
and send abstract code 405 to the anchor beacon (e.g., directly,
indirectly via a remote processing system). The client can function
as a user interface for the user to generate programs responsive to
events generated by the anchor beacon. The client can receive
program characteristics (e.g., battery management estimation 415).
The client can provide features such as syntax highlighting,
auto-completion, pre-written snippets (e.g., functions, variables,
etc.), and/or any other suitable feature. The client can
additionally or alternatively provide any other suitable set of
functionalities.
[0074] The client is preferably connected to the remote computing
system. The client can be in the remote computing system, separate
from the remote computing system, or otherwise positioned. The
client can additionally or alternatively be connected (e.g.,
wirelessly connected, wired) to the beacons to be programmed
(example shown in FIG. 3). The client is preferably operable as an
interface for a user to enter code. The user-entered code can be
processed by the remote computing system into bytecode 410. In
variants, the remote computing system can optionally determine a
battery management estimation of the bytecode on a specific beacon
(e.g., the anchor beacon, secondary beacon, etc.). The power
estimation can be reported to the user via the client (e.g., while
the user is developing the code, after the user developed the code,
or at any other suitable time). The bytecode can be read by the
beacon (example shown in FIG. 4). However, the client can be
otherwise configured.
[0075] The client is preferably a browser application, but can
additionally or alternatively be a native application, desktop
application, or any other suitable application. In variants where
the client is a browser application, the browser can communicate
with the beacons using web Bluetooth or any other suitable
protocol.
[0076] In an example, the client includes pre-designed template
applications (e.g., GPS tracker, location to slack, alert button,
Button and LED, Beacon Info, cellular location, cell tower scanner,
BLE Scanner, etc.).
[0077] However, the client can additionally or alternatively
include any other suitable components.
[0078] The system preferably includes one or more programs 380. The
program is preferably bytecode compilations of user code, wherein
the user code is generated by a user (e.g., user-generated code).
The user's code is preferably received at the client. The user's
code is preferably abstract, but can be otherwise written. The
abstract code is preferably in any suitable language, including:
web-based programming languages (e.g., JavaScript, Node.js, Ruby,
PHP, Golang, HTML, java, python, etc.), native programming
languages (e.g., C, C++, etc.), and/or any other suitable
programming language.
[0079] The abstract code preferably contains one or more variables
associated with a beacon (e.g., secondary beacon and/or anchor
beacon) (e.g., surfaced by an API). The variables can include
scanning control (e.g., on, off, scanning frequency), advertising
control (e.g., on, off, scanning frequency), GPS control, reading
from on-board sensors (e.g., sampling frequency), input reading
(e.g., button press responses), output control, and/or any other
suitable readout or control parameter.
[0080] The abstract code can include beacon population parameters.
The beacon population parameters can include human-understandable
abstractions (e.g., representation that can be naturally read by
humans) such as abstract variables or references associated with
one or more beacons (e.g., secondary beacons and/or anchor
beacons). The abstract variables are preferably associated with the
disambiguated information (e.g., beacon identifier or string,
geolocation lat/long coordinates, etc.) by a user account
associated with the beacon (e.g., beacon owner), but can
additionally or alternatively be automatically associated, learned,
or otherwise associated. Examples of abstract variables associated
with the beacons include: a human-readable name for the beacon(s),
a human-readable identifier for a set of beacons, a human-readable
identifier for a geographic location associated with a set of
beacons, and/or any other suitable variable. Specific examples
include: a beacon name instead of using the specific beacon
identifier such as the identifier assigned at manufacturing,
determined at beacon, etc.; a geographic identifier or venue name
instead of listing all beacons associated with a given venue,
and/or any other suitable population parameter.
[0081] The abstract code is preferably compiled by the remote
computing system (e.g., wherein the client sends the abstract code
to the cloud, the cloud compiles the code into bytecode, and sends
the bytecode to the beacon), but can additionally or alternatively
be compiled at the client or otherwise compiled.
[0082] In one variation, the remote computing system can optionally
disambiguate the abstract variables into machine-level
representations, and/or compile the machine-level representations
into the bytecode (example shown in FIG. 6). In variants, this
hardcodes the beacon information (e.g., beacon identifiers,
locations, hidden identifier resolution algorithms, etc.) into the
bytecode. The remote computing system can disambiguate the abstract
variables based on a lookup table, using semantic learning, and/or
any other suitable disambiguation method. In one example, the
remote computing system can include a beacon registry (e.g. lookup
table, database, etc.) that associates the abstract variables with
beacon information, such as beacon identifiers (e.g., alphanumeric
string, manufacturer identifier, public identifier, UUID with major
and minor values, etc.) for beacons (e.g., for secondary beacons,
anchor beacons, static beacons, etc.). The beacon registry can
optionally associate the beacon(s) with: beacon groups, geographic
locations (e.g., latitude, longitude, geofence identifier,
geographic region, etc.), and/or any other suitable data. Examples
of the abstract variables include: a user-assigned name for the
beacon (e.g., "conference room), a geolocation identifier (e.g.,
"home," "SFO airport," etc.), a user-assigned name for a beacon
group (e.g., "shipping yards"), or any other suitable abstract
variable. In a second example, the remote computing system can
disambiguate an abstract geographic reference (e.g., "Denver") into
a set of geolocations or a geographic region (e.g., set of
latitude, longitude, and optionally altitude values). However, the
abstract variables (e.g., human-readable descriptors) can be
otherwise disambiguated into any other suitable machine-readable
representation (e.g., numeric code, references, numeric addresses,
etc.)
[0083] The abstract code is preferably compiled into bytecode
(e.g., microcode), machine code, or compiled into any other
suitable code.
[0084] In variants, the bytecode includes disambiguated beacon
identifiers (e.g., associated with a specific beacon name, set of
beacon identifiers associated with a predetermined geofence or
geographic identifier). In these variants, the beacon can
automatically respond (according to the bytecode) to receipt of
packets from the beacons identified in the bytecode. An example can
be seen in FIG. 6.
[0085] The abstract code can additionally or alternatively include
a cloud program. The cloud program preferably functions to respond
to events received from the anchor beacon, but can additionally or
alternatively respond to events received from any other suitable
device (e.g., user device). The cloud program is preferably stored
in the remote computing system, but can additionally or
alternatively be stored in the client or otherwise stored. The
cloud program can be: generated by the user, standard code, or
otherwise determined. The cloud program can be the same language as
that used to generate the beacon program, or any other suitable
language. The cloud program can include serverless architecture
features (e.g., lambda.TM. expressions), dedicated server
architecture, or be otherwise implemented. The cloud program can
include one or more beacon identifiers, one or more events and/or
event types, a response (e.g., a response to the event), and/or any
other suitable information. For example, a response can include
notifying a third party. Notifying a third party can include
sending a notification, using communication credentials (e.g., an
authentication token, an authentication identifier, etc.), to a
predetermined set of endpoints. In a specific example, a button
press event can be detected by the anchor beacon and reported to
the remote computing system. In response to the button press event,
the remote computing system sends a notification (e.g., message) to
a user's device using credentials associated with the Twilio API or
any other suitable API.
[0086] In an example, while the user is developing instructions in
the client, the reomote computing system can process the user code
and provide a resource estimation (e.g., power consumption
estimate, battery lifetime profiler) to the user (e.g., based on
the beacon components associated with different functions and/or
calls, and the estimated power consumption for each of the
identified beacon components). Additionally or alternatively, the
cloud can determine code refactoring and suggest the code
refactoring to the user through the client.
[0087] However, the abstract code can additionally or alternatively
include any other suitable components and/or be otherwise
configured.
[0088] The system can optionally include one or more remote
computing systems 400. The remote computing system can function to
maintain a global database (e.g., the beacon repository) of beacon
information (e.g., for the anchor beacon(s), the secondary beacons,
etc.). The remote computing system can function to process (e.g.,
compile) code from the client into bytecode and/or transmit
bytecode to one or more beacons. Processing the code received from
the client into bytecode can be based on the known knowledge of the
world (e.g., beacon identifiers and locations) and/or any other
suitable data.
[0089] In one variation, the remote computing system identifies
abstract variables in the abstract code; determines the machine
representation for the abstract variable based on: the abstract
variable value, the beacon population associated with the user
providing the code (e.g., the user's account), and/or any other
suitable information; and compiles the abstract code into bytecode
using the machine representations for the abstract variables.
[0090] The remote computing system can function to generate an
event model. The event model can be determined from a set of
training data (e.g., sampled by the anchor beacon, pre-determined
data from a second anchor beacon, pre-determined data from any
other suitable beacon, synthetic data, etc.), and a template model
(e.g., decision tree, neural network, regression, etc.), or
otherwise determined. Training data can be sampled by the beacon
while in the training mode, sampled during typical operation, or
otherwise sampled. The remote computing system can optionally
process the training data to determine positive and negative
samples associated with the event. The template model can be
received from a third party associated with a chipset (e.g., a
model specifically configured for the chipset), retrieved from a
database, and/or otherwise determined. The remote computing system
can determine a (trained) model based on the training data, and/or
any other suitable data (e.g., pre-determined data such as from
other beacons). The event model can be compiled into model
bytecode, or otherwise compiled. The model bytecode can be
transmitted to the beacon. The beacon can store the model in
computer readable media. The model can be stored by the main
processing system, at a sensor-specific processing system, or at
any other suitable system.
[0091] The remote computing system can function to manage beacon
default settings (e.g., advertising, transmit power, SSUID on/off,
toggle functionalities, control payload), manage user access to the
beacon (e.g., verify that the user pushing code to the beacon is
authorized and/or logged in with the correct credentials), and/or
otherwise manage the beacon(s).
[0092] The remote computing system can function to store beacon
keys (e.g., complimentary to beacon keys), store authentication
tokens (e.g., for third-party applications), such as communication
tokens used to send notifications to the user or another endpoint,
and/or any other suitable set of keys.
[0093] The remote computing system can function to determine a
scanning device's location based on one or more known locations for
the advertising beacons and a distance indicator (e.g., RSSI) of
the advertisement signal received at the scanning device from the
advertising beacon. For example, the remote computing system can
trilaterate a device's location (e.g., anchor beacon location, user
device location) based on: the beacon identifiers from packets
received by the device (e.g., secondary beacon identifiers, anchor
beacon identifiers, etc.), the known locations associated with the
beacon identifiers, and the distance indicators for each
packet.
[0094] The remote computing system can function to perform actions
based on (e.g., responsive to) events detected at the anchor beacon
(e.g., send a message to a user device, management entity, or any
other suitable message receiver). The actions are preferably
performed according to a cloud program provided by the user, but
can additionally or alternatively be performed in response to
satisfaction of a set of conditions (e.g., beacon event
occurrence), or at any other suitable time.
[0095] However, the remote computing system can additionally or
alternatively provide any other suitable set of
functionalities.
[0096] The remote computing system can be a remote server system, a
mobile device, a laptop, a smartphone, a distributed computing
system, and/or any other suitable system.
[0097] The remote computing system can store a global database of
beacon information. The beacon information can include: secondary
beacon identifiers, anchor beacon identifiers, the geographic
location (e.g., absolute or relative) associated with the beacon,
abstract variables associated with the beacon identifiers (e.g.,
for a given beacon management entity), anchor beacon state (e.g.,
battery level, etc.), anchor beacon operation parameters (e.g.,
advertising schedule, etc.), management entity and/or user account
associated with the beacon, and/or any other suitable
information.
[0098] In one variant, the beacon identifiers (e.g., secondary,
anchor) can be updated. For example, the secondary beacon can
generate a new secondary beacon identifier, advertise a packet
comprising the new identifier 615. The packet can be received at
the anchor beacon and forwarded to the remote computing system. The
remote computing system can update the global database with the new
generated secondary beacon identifier. An example can be seen in
FIG. 6.
[0099] The remote computing system can store an authentication
token. The authentication token can be used to send messages to
third party devices (e.g., the third party device could be
associated with the client) in association with the user account.
In one variation, the authentication token is a Twilio
authentication token.
[0100] However, the remote computing system can additionally or
alternatively be otherwise configured.
4. Method.
[0101] The method preferably functions to track an asset's location
and/or state. The method is preferably performed by the system
discussed above, but can additionally or alternatively be performed
by any other suitable system. The method is preferably performed
during an active session wherein the active session can be
determined by the client, remote computing system, or be otherwise
determined.
[0102] The method preferably includes operating the anchor beacon
according to instructions determined by the client S100. S100
preferably functions to enable the anchor beacon to operate
according to client specified instructions (e.g., user code). The
instructions can be determined for the anchor beacon: before the
anchor beacon is deployed (e.g., positioned on an asset), after the
beacon is deployed, or at any other suitable time, and/or
periodically updated based on bytecode wherein the period is
determined by the client.
[0103] S100 can include determining the instructions S120. S120 can
include: receiving abstract code at the compiling system (e.g.,
remote computing system) from the client, wherein the user enters
the instructions into the client. The compiling system can be: a
user device (e.g., laptop, desktop, etc.), browser, remote
computing system, and or be any other suitable system. The
instructions can be the program, wherein the program includes the
abstract code and additionally or alternatively includes the cloud
program. The abstract code can be compiled and/or disambiguated, as
discussed above, into bytecode. However the instructions can be
otherwise determined.
[0104] S100 can include transmitting the bytecode to the anchor
beacon S130. The one or more anchor beacons can be identified in
the abstract code, be the anchor beacons connected (e.g.,
wirelessly) to the client, be anchor beacons selected by the user,
be anchor beacons associated with the user (e.g., with the user
account), or be any other suitable set of anchor beacons.
[0105] Transmitting can include directly transmitting the bytecode
to the anchor beacon(s) (e.g., via a cellular connection, wherein a
signal can be sent to the anchor beacon to turn on the beacon's
onboard cellular radio, wherein the bytecode can be transmitted
during the next scheduled cellular radio operation period, etc.);
indirectly transmitting the bytecode to the anchor beacon(s) (e.g.,
via web Bluetooth, via the computing system running the client, via
a computing system wirelessly connected to the beacon, or any other
suitable connection etc.), and/or otherwise transmitted.
[0106] Determining the instructions can include storing the
bytecode at the one or more anchor beacons. The bytecode can be
stored in memory, and/or be otherwise stored. However, determining
the instructions can additionally or alternatively include any
other suitable elements.
[0107] S100 can include executing the bytecode on the anchor
beacon. The bytecode can be processed at the beacon by the anchor
beacon's first processor but can additionally or alternatively be
processed by any other suitable processor. In one example, the
bytecode can instruct the anchor beacon to use the Bluetooth radio
to advertise both iBeacon and Eddystone at the same time. In a
second example, the bytecode can instruct the anchor beacon to
detect a button press event and in response to the event, read the
GPS position and send the GPS position to the remote computing
system using the cellular radio.
[0108] In one example, the client determines instructions and the
remote computing system compiles the instructions into microcode
(e.g., bytecode), wherein the instructions specify detecting that
the button on the anchor beacon has been pressed. After the button
press event is detected at the anchor beacon, the information is
enqueued in the payload to be broadcast by the anchor beacon. The
payload is transmitted to the remote computing system, the cloud
program processes the payload to determine the button has been
pressed, and in response to the button press event, the cloud
program takes an action (e.g., send a message to the client, and/or
any other suitable device, using the authentication token).
[0109] However, S100 can additionally or alternatively include any
other suitable elements.
[0110] The method can additionally or alternatively include
operating the anchor beacon according to a learned model at S200.
S200 preferably functions to at the anchor beacon: gather training
data, and during operation, recognize an event associated with the
training data. S200 is preferably performed by the second
processor, but can additionally or alternatively be performed by
any other suitable processor. S200 is preferably performed in
parallel with S100, but can additionally or alternatively be
performed at any other suitable time (e.g., before and/or
after).
[0111] S200 preferably includes the training mode 505 and the
processing mode 530 as shown in FIG. 2. The beacon or event model
can be trained as discussed above, or be otherwise trained. S200
can additionally or alternatively include any other suitable
modes.
[0112] In one example of S200, while the anchor beacon is in
training mode to detect a drop event, the user can drop the beacon
10 times. The anchor beacon can record the data and stream the data
to the cloud. At the remote computing system, the data can be
processed and an event model can be determined. The event model can
be transmitted to the anchor beacon. At the anchor beacon, after
receiving the event model, the anchor beacon detects a drop event
and transmits the event label to the remote computing system.
[0113] Embodiments of the system and/or method can include every
combination and permutation of the various system components and
the various method processes, wherein one or more instances of the
method and/or processes described herein can be performed
asynchronously (e.g., sequentially), concurrently (e.g., in
parallel), or in any other suitable order by and/or using one or
more instances of the systems, elements, and/or entities described
herein.
[0114] As a person skilled in the art will recognize from the
previous detailed description and from the figures and claims,
modifications and changes can be made to the preferred embodiments
of the invention without departing from the scope of this invention
defined in the following claims.
* * * * *