Patent ID: 12219432

DETAILED DESCRIPTION

According to techniques of this disclosure, an asset tracking system includes a mobile platform for centralized management and organization of tracking devices backed by rules and output engines that support location or threshold-based rules for, e.g., actively configuring and/or re-configuring the tracking devices when a boundary is crossed, displaying location or sensor data from the tracking devices, and generating notifications based on the location or sensor data. The centralized platform allows for integrated and dynamic asset tracking without requiring complex or expensive infrastructure. The asset tracking system and corresponding methods disclosed herein will be described below with reference toFIGS.1A-9.

FIGS.1A-2will be discussed together.FIG.1Ais a schematic diagram of asset tracking system10.FIG.1Bis an enlarged schematic diagram of tracking device60.FIG.1Cis an enlarged schematic diagram of tracking device60′.FIG.2is a schematic diagram showing details of data flow within asset tracking system10. Asset tracking system10includes asset tracking network20, location data store30, centralized device management platform40, device configuration storage45, user interface50, and users52. As illustrated inFIG.2, location data store30includes location data32, and device configuration storage45includes device twins46. Asset tracking network20includes any number of tracking devices60and/or tracking devices60′ associated with any number of assets62. As illustrated inFIG.1B, tracking device60includes transmitter64, receiver65, onboard processor66, and onboard memory68. As illustrated inFIG.1C, tracking device60′ additionally includes sensor70. For ease of discussion, shared structure and function of tracking devices60and60′ will generally be described with reference to tracking device60. Centralized device management platform40includes processor72and memory74. Centralized device management platform40further includes rules engine76, which includes location evaluator module78and location-based rules module80, and output engine82.

Asset tracking network20is a positioning network for tracking devices60. Tracking devices60can receive positioning (location) information by any suitable positioning means. In some examples, the position of tracking devices60can be determined with triangulation, trilateration, or various other algorithms. For example, the position of tracking devices60can be determined using cellular towers for cellular devices or satellites for devices that use a global navigation satellite system (GNSS), such as global positioning system (GPS)-enabled devices. In other examples, the position of tracking devices60can be determined based on proximity to another device, such as by a Bluetooth or Bluetooth Low Energy (BLE) or other short-range wireless connection to a cellular or GPS-enabled device. In yet other examples, the position of tracking devices60can be determined based on a wireless internet connection (Wi-Fi) or a radio signal from a radio frequency identification (RFID) tag. Though asset tracking system10is not limited to these embodiments, some networks, such as Wi-Fi, Bluetooth, or RFID, may be more suitable for local or on-premises tracking or for more basic tracking (e.g., localizing an asset either inside or outside a building). On the other hand, cellular or GPS tracking may be more suitable for embodiments where a respective asset62is expected to travel a significant distance (e.g., miles). A combination of network types may be suitable to provide sufficient tracking resolution in a range of scenarios. In general, asset tracking system10can be implemented with any existing tracking or communications infrastructure to make up asset tracking network20. That is, an organization implementing asset tracking system10may already have Wi-Fi routers or wireless access points on its premises, and cellular towers and satellites are widely available.

Tracking devices60are location-aware devices or devices that can send and receive information signals (e.g., location data) and control signals. Tracking devices60can, in some examples, be considered Internet of Things (IoT) devices. For example, tracking devices60can be any commercially available IoT or “smart” devices capable of transmitting location data and receiving control signals. In some examples, tracking devices60are all the same type of tracking device. In other examples, tracking devices60include a combination of different types of tracking devices. Although three tracking devices60are illustrated inFIG.1A, it should be understood that other examples can include more or fewer tracking devices60. Asset tracking system10can include a large and scalable number of tracking devices60.

As illustrated inFIG.1B, tracking device60includes transmitter64and receiver65(or a transceiver rather than separate transmitter and receiver) for sending and receiving the information signals and control signals. In some examples, tracking devices60can include multiple transmitters64and receivers65(or multiple transceivers) for sending and receiving different types of signals. For example, tracking devices60can include separate transmitters64and receivers65for a cellular signal and a Wi-Fi signal (or any other combination or selection of signal types). Tracking devices60can also include other components or features, such as an antenna, an on/off button, a battery or other power supply, or a simple display, for example. In some examples, tracking devices60can take the form of relatively small tags that are readily attachable to various types of assets.

Tracking devices60also include onboard processor66and memory68. Onboard processor66is configured to implement functionality and/or process instructions for tracking device60. For example, processor66can be capable of processing instructions stored in memory68. Processor66can process control instructions or commands from central device management platform40. Examples of processor66can include one or more of a processor, a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other equivalent discrete or integrated logic circuitry.

Onboard memory68can be configured to store information before, during, and/or after operation of tracking device60. Memory68, in some examples, is described as computer-readable storage media. In some examples, a computer-readable storage medium can include a non-transitory medium. The term “non-transitory” can indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium can store data that can, over time, change (e.g., in RAM or cache). In some examples, memory68can be entirely or partly temporary memory, meaning that a primary purpose of memory68is not long-term storage. Memory68, in some examples, is described as volatile memory, meaning that memory68does not maintain stored contents when power to devices (e.g., tracking device60) is turned off. Examples of volatile memories can include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories. Memory68, in some examples, also includes one or more computer-readable storage media. Memory68can be configured to store larger amounts of information than volatile memory. Memory68can further be configured for long-term storage of information. In some examples, memory68includes non-volatile storage elements. Examples of such non-volatile storage elements can include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Onboard memory68is encoded with instructions that are executed by processor66. For example, memory68can be used to store program instructions for execution by programs running on processor66of tracking device60. Memory68can store configuration information for respective tracking devices60. In some examples, memory68is used by programs running on processor66to temporarily store information during program execution.

Tracking device60′, as illustrated inFIG.1C, is an alternative example of tracking device60. Tracking device60′ can generally include all the same structure and function as tracking device60, except tracking device60′ additionally includes sensor70for additional telemetry. Sensor70can be any type of sensor for measuring (sensing) a parameter associated with a corresponding asset62. For example, sensor70can be a temperature sensor, a pressure sensor, a thermal imaging device, or other sensor type. In some examples, sensor70can include more than one sensor. In further examples, sensor70can include multiple types of sensors. Moreover, although illustrated inFIG.1Cas a component of tracking device60′, sensor70can alternatively be communicatively connected (i.e., send signals/data) to tracking device60′ but not physically implemented as a part of the same device.

Assets62can be any mobile assets to be tracked. More specifically, assets62can include any assets that users52(or groups of users52as illustrated inFIG.2) select to track using tracking devices60. Each asset62is associated with or connected to respective ones of tracking devices60. In some examples, assets62can include shopping carts, wheelchairs, or other assets that individuals will frequently move around a building. In other examples, assets62can include fleet vehicles, cargo, or shipped packages that will travel relatively long distances. In some examples, assets62can be refrigerated cargo that must be maintained at a certain temperature. Assets62and corresponding tracking devices60may be distributed throughout a physical area, such as a warehouse, store, campus, hospital, airport, office, construction site, or other facility. In some examples, assets62may be distributed within a building and also outside of the building, such as in a parking lot. Assets62and corresponding tracking devices60may also be in vehicles that travel according to pre-defined routes.

Each of tracking devices60can transmit (e.g., by transmitter64) location data representative of a physical location of that tracking device60to location data store30. When one of tracking devices60is associated with a corresponding one of assets62, the location data is also representative of a physical location of the corresponding one of assets62. Tracking devices60′ can also transmit sensor data from sensor70to location data store30. Accordingly, each of tracking devices60has a respective location data reporting frequency that defines how often tracking devices60transmit location data (a rate). The respective location data reporting frequency can include any suitable time increment, such as every minute, every five minutes, every half-hour, hourly, twice daily, daily, etc. Each of tracking devices60can be configured with a same or different location data reporting frequency compared to other ones of tracking devices60. Moreover, in some embodiments, the respective location data reporting frequency for one of tracking devices60can be changed (updated). The location data reporting frequency can be set based on internal or external considerations, such as conserving battering life of the respective tracking device60, accurately recording as much of the movement of the corresponding asset62as possible, or other considerations.

Location data store30stores collective location data32from tracking devices60. Accordingly, location data store30is a collection of electronic data. Location data store30can be any suitable electronic data storage means, such as a database, data warehouse, data lake, flat file, or other data storage type. In some examples, location data store30can be an “on-premises” data store (e.g., within an organization's data centers). In other examples, location data store30can be a “cloud” data store that is available using cloud services from vendors such as Amazon, Microsoft, or Google. In some examples, location data store30can be a cloud service that is provided and maintained by a third-party vendor, such as a third-party vendor associated with tracking devices60. For example, location data store30as a third-party service can provide a level of abstraction between location data32and a request for the data, rather than permitting direct access to location data store30. Electronic data stored in location data store30is accessible by centralized device management platform40. In some examples, centralized device management platform40can access data from location data store30via an application programming interface (API), such as via an API provided by the third-party vendor in examples where location data store30is a third-party service, or some other communication interface.

Location data32(as shown inFIG.2) is a collection of location data transmitted by tracking devices60. In some embodiments, location data32can also include, or be associated with, sensor data from tracking devices60′. Location data32can be organized in any suitable data structure that preserves the relationship between the location data and the source (e.g., ones of tracking devices60). For example, location data32can be organized in rows or columns in a table, wherein each row (or column) corresponds to a location data transmission from one of tracking devices60. Individual records (e.g., a row) within location data32can include, or be associated with, identifying information for a respective tracking device60from which the recorded location data was received. For example, each tracking device60may be assigned a unique identifier or code that is then associated with each location data transmission from that tracking device60. Individual records within location data32can include, e.g., coordinate information (latitude and longitude), distance information with respect to a defined point, or more general location information, such as an indication of in-range or out-of-range. In general, location data32is updated based on the location data reporting frequency of each tracking device60. For example, when one of tracking devices60is configured with an hourly location data reporting frequency, location data32will be updated hourly with a new individual record corresponding to the location data transmission from the respective tracking device60. In some examples, tracking device60may transmit additional location data in a single update period for more granular tracking history. Each individual record within location data32can be associated with a time the location data was received from the respective tracking device60(i.e., time-stamped data). Each individual record within location data32can also be associated with a strength of the transmitted signal from the respective tracking device60. Location data32can also include historical data. That is, records within location data32may not be overwritten every time new location data is received.

Centralized device management platform40is a central platform for remotely managing tracking devices60. Centralized device management platform40includes processor72and memory74. Although processor72and memory74are illustrated inFIG.1Aas being separate components of a single computer device, it should be understood that in other examples, processor72and memory74can be distributed among multiple connected devices. In other examples, memory74can be a component of processor72. In some examples, centralized device management platform40is a wholly or partially cloud-based platform. In some examples, centralized device management platform40can include processing on edge devices. Centralized device management platform40can also include a web server, e.g., for running an API to connect to mobile applications. Moreover, although not shown inFIGS.1A and2, centralized device management platform40can include any suitable communication interface modules (software and/or hardware) for establishing communication with other components of asset tracking system10, such as location data store30, device configuration storage45, user interface50, and tracking devices60. For example, the communication interface modules can account for authorization or security requirements for accessing data located in location data store30or device configuration storage45or for communicating with user interface50and tracking devices60. In some examples, a communication interface module can allow centralized device management platform40to communicate with tracking devices60indirectly through a third-party system (e.g., via an API provided by the third-party vendor). In other examples, location data store30and device configuration storage45can be a part of centralized device management platform40.

Processor72is configured to implement functionality and/or process instructions within centralized device management platform40. For example, processor72can be capable of processing instructions stored in memory74. Examples of processor72can include one or more of a processor, a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other equivalent discrete or integrated logic circuitry.

Memory74can be configured to store information before, during, and/or after operation of centralized device management platform40. Memory74, in some examples, is described as computer-readable storage media. In some examples, a computer-readable storage medium can include a non-transitory medium. The term “non-transitory” can indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium can store data that can, over time, change (e.g., in RAM or cache). In some examples, memory74can be entirely or partly temporary memory, meaning that a primary purpose of memory74is not long-term storage. Memory74, in some examples, is described as volatile memory, meaning that memory74does not maintain stored contents when power to devices (e.g., hardware of centralized device management platform40) is turned off. Examples of volatile memories can include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories. Memory74, in some examples, also includes one or more computer-readable storage media. Memory74can be configured to store larger amounts of information than volatile memory. Memory74can further be configured for long-term storage of information. In some examples, memory74includes non-volatile storage elements. Examples of such non-volatile storage elements can include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Memory74is encoded with instructions that are executed by processor72. For example, memory74can be used to store program instructions for execution by rules engine76or output engine82on processor72. In some examples, memory74is used by software or applications running on processor72, e.g., rules engine76or output engine82, to temporarily store information during program execution.

Rules engine76is a first functional module of centralized device management platform40. Rules engine76is a collection of computer code in any suitable programming language. Rules engine76can be a computer program or a script that can also be, to some degree, configurable. In general, rules engine76accesses or receives and evaluates location data32to associate locations of tracking devices60with predefined location or threshold-based rules. Rules engine76is capable of running per-device rules. Activities of rules engine76can be further divided functionally into sub-modules, including location evaluator module78and location-based rules module80.

Location evaluator module78is a first functional sub-module of rules engine76. Location evaluator module78can be part of the rules engine computer program itself (i.e., written in code) and/or can be a functional representation of the rules engine computer program executing code based on a configuration. In general, location evaluator module78accesses or receives location data32and compares the location data indicating the position of ones of tracking devices60(e.g., individual records in location data32) to predefined geofence zones to identify a geofence zone (an identified zone) that includes the location of the respective tracking device60. In some examples, location evaluator module78can be configured or written to run whenever new location data is loaded from location data store30(e.g., based on the location data reporting frequency of tracking devices60).

Location evaluator module78can include methods in code for receiving and interpreting location data32and for establishing geofence zones (geofencing techniques). Geofence zones are representations of real-world geographic areas or physical regions that are bounded by a virtual perimeter. Geofencing techniques can include dynamically generating a geofence as a set radius around any point location or statically defining a set of boundaries. Methods for identifying a geofence zone that includes the location of the respective tracking device60can include, in some examples, evaluating geographic coordinates or, in other examples, can be a simpler in-range or out-of-range determination, depending on the signal type for the respective tracking device60. In some examples, evaluating geographic coordinates can further include performing an inside/outside check algorithm on polygons (triangles) of the geofence zone.

The actual geofence zones for a particular application of asset tracking system10can be configurations. Configurations for geofence zones can be input by developers or users52, e.g. via user interface50. In some examples, configurations for geofence zones can also be stored, e.g., in a database (not shown), and accessed by location evaluator module78. In other examples, configurations for geofence zones can be packaged with the code and updated periodically. Additionally, as will be described in greater detail below, configured geofence zones can be linked to device twins46and provisioned during device provisioning of tracking devices60.

The predefined geofence zones utilized in location evaluator module78can take a variety of forms. In some examples, the geofence zones can include zones that correspond to real-world boundaries or areas of interest to an organization, such as surrounding a parking lot, a construction site, a floor of a hospital, a region of a campus, etc. In some examples, one geofence zone can be predefined as a “home” zone or a zone associated with an area within which tracking devices60are expected to remain. In some examples, the geofence zones can include consecutive or adjacent regions. In other examples, one geofence zone may be entirely contained within another geofence zone. In some examples, the geofence zones can be polygonal, including regular or irregular polygonal zones formed by a two-dimensional polygonal (triangle, square, hexagon, etc.) mesh. In other examples, the geofence zones can be circular zones that extend a fixed radial distance around a central point. As will be described in greater detail below, geofence zones can be manually drawn with a display via user interface50.

Location evaluator module78can further include functionality for determining (e.g., counting) if or how many consecutive locations reported from a respective tracking device60are within the identified geofence zone that corresponds to the most recent location reported from the respective tracking device60. That is, location evaluator module78can determine if tracking device60has entered the identified zone in the time since the immediately previous location data report from that tracking device (i.e., the immediately previous location reported from that tracking device60was not within the identified zone/was in a different zone) or if one or more previous locations reported from that tracking device are also within the identified zone. In some examples, location evaluator module78can determine if a number of consecutive locations of tracking device60that are within the identified zone exceeds a threshold number, such as more than one consecutive location within the identified zone (i.e., at least two in a row). This determination can be based on the location data reporting frequency of the respective tracking device60such that the threshold number can be defined as a threshold duration (time tracking device60has spent in the identified zone). The threshold duration can be any desired amount of time, such as an hour, two hours, a day, etc. Additionally, or alternatively, location evaluator module78can include functionality for determining a distance that a respective tracking device60has traveled into the identified zone from a previous zone in which the respective tracking device60was located. In some examples, this distance may represent a distance outside of a home or expected zone for the respective tracking device60. In these ways, any brief excursions that tracking devices60make across geofence boundaries before quickly returning within the boundary may not exceed a threshold for proceeding with the process for updating tracking devices60. Duration or distance-based thresholds for quantifying the presence of tracking devices60in the identified zone and filtering the output can be used separately, in combination, or not at all, depending on the use case. Location evaluator module78may not evaluate for a threshold in use cases where a single location report from one of tracking devices60in the identified zone is sufficient to warrant a notification or change in device functionality. Such examples can include, tracking hazardous materials, baby location monitoring, etc. In these cases, asset tracking system10can be configured via location evaluator module78to prioritize alerts and updates over verifying the presence of tracking devices60in the identified zone.

Location-based rules module80is a second functional sub-module of rules engine76. Location-based rules module80can be part of the rules engine computer program itself (i.e., written in code) and/or can be a functional representation of the rules engine computer program executing code based on a configuration. In general, location-based rules module80compares the identified zone from location evaluator module78to a set of “rules” to identify a rule (an identified rule) that is associated with the identified zone. The set of predefined rules connect (or associate) one or more device configuration instructions to ones of the predefined geofence zones from location evaluator module78. As will be described in greater detail below with respect to output engine82andFIG.4, each predefined rule can also be associated with a target “audience” or group of users52for notifications.

Location-based rules module80can include methods in code for changing device configurations (i.e., device configuration instructions) for tracking devices60. The device configuration instructions can include methods for setting or changing device configurations for tracking devices60, such as, e.g., an asset type identification corresponding to a respective asset62that is associated with each tracking device60, a location data reporting frequency, a signal type for transmitting location data, and an enabled or disabled state of a sensor component (e.g., sensor70of tracking device60′ inFIG.1C), or other methods. The device configuration instructions can be modified by adding, removing, or changing the underlying code for location-based rules module80.

The device configuration instructions are also associated with location or threshold-based conditions to form the set of predefined rules. The conditions can be based on one or more geofence zones that are predefined from location evaluator module78. In other words, the device configuration instructions can be conditional actions for configuring or reconfiguring tracking devices60according to a state of the respective tracking device60, such as which geofence zone the respective tracking device60is located within. In some examples, the location-based condition can be that the respective tracking device60has crossed a boundary into one of the predefined geofence zones and has most recently reported its location within that geofence zone, e.g., as determined by location evaluator module78. In other examples, the location-based condition can be that the respective tracking device60has remained in one of the predefined geofence zones for at least a threshold amount of time, e.g., as determined by location evaluator module78. In alternative embodiments, the device configuration instructions can also be conditioned on thresholds for other types of data, such as temperature data or pressure data from sensors70(FIG.1C), for example.

The location or threshold-based conditions and the application of those conditions to device configuration instructions for a particular application of asset tracking system10can be configurations. Configurations for the location or threshold-based conditions and their application to particular device configuration instructions can be input by developers or users52, e.g., via user interface50. In some examples, these configurations can also be stored, e.g., in a database (not shown), and accessed by location-based rules module80. In other examples, the configurations can be packaged with the code and updated periodically.

Output engine82is a second functional module of centralized device management platform40. Output engine82is a collection of computer code in any suitable programming language. Output engine82can be a computer program or a script. In general, output engine82performs workflow management-type functions and causes updates and/or notifications to be communicated to user interface50and to device twins46in device configuration storage45(each of which will be described in greater detail below). The updates and/or notifications communicated by output engine82are based on the identified rule from location-based rules module80that is associated with the identified zone from location evaluator module78of rules engine76. In other words, output engine82takes the state of the system as determined by rules engine76and applies corresponding outputs.

Output engine82can include methods in code for communicating updates to device twins46and syncing changes to tracking devices60. More specifically, output engine82can include methods for updating the set of device configurations of the respective device twin46with the device configuration that is associated with the identified rule from location-based rules module80. That is, output engine82can update the respective device twin46when one of tracking devices60has moved to a different geofence zone, such as for a threshold amount of time. On the other hand, output engine82may not communicate any updates to device twins46when tracking devices60have not moved to a different geofence zone.

In some examples, output engine82can also include methods in code for comparing the device configuration instruction that is associated with the identified rule to a pre-existing device configuration that is defined in a respective device twin46for the one of tracking devices60from which location data was reported and evaluated in location evaluator module78to determine if the device configuration instruction that is associated with the identified rule is different from the pre-existing device configuration or if they match (e.g., are the same). In some examples, output engine82can communicate an update to the respective device twin46if the device configuration instruction that is associated with the identified rule and the pre-existing device configuration are different. In other examples, output engine82can always communicate an update to the respective device twin46, regardless of whether there has been a previous determination that the device configuration instruction that is associated with the identified rule is different from the pre-existing device configuration (though it would be expected that the configurations would be different if the corresponding tracking device60has moved into a different geofence zone).

Once the respective device twin46has been updated, output engine82can cause the updated set of device configurations to be synced (or synchronized) to the corresponding one of tracking devices60to reconfigure it based on the identified rule. That is, each tracking device60can receive an updated set of device configurations that matches (or is the same) as the updated set of device configurations that is represented in the respective device twin46. A sync service can evaluate changes to the set of device configurations in respective device twins46and make corresponding tracking devices60compliant with the respective device twins46. That is, the updated set of device configurations can be synced to tracking device60via a sync service or interface that, in some examples, is hosted by centralized device management platform40via output engine82, or that, in other examples, is part of a third-party system that is directed to sync with tracking devices60via a communication from centralized device management platform40. In some examples, centralized device management platform40communicates with a third-party system via an API, such as via an API provided by the third-party vendor.

Output engine82can also include methods in code for communicating updates and/or notifications to user interface50. For example, output engine82can include workflow methods for determining when the identified rule from location-based rules module78is associated with a notification for one or more groups of users52. Notifications can include, e.g., an indication that one of tracking devices60is in a different geofence zone, an indication that one of tracking devices60has been in a different geofence zone for a threshold amount of time, or other notifications. In some examples, notifications can include an indication of elevation in severity state as one of tracking devices60moves from one geofence zone to another. In some examples, the notifications are generated by output engine82and delivered to user interface50in the form of alerts. In other examples, the notifications can be associated with an email that users52can receive in an email client or with a message received via a messaging service such as SMS, etc. Output engine82can also include methods for communicating other updates to user interface50, such as updates to a graphical representation of locations of tracking devices60(e.g., adding a graphical indicator to ones of tracking devices60that are outside of a home zone).

Device configuration storage45stores configuration information for tracking devices60. Accordingly, device configuration storage45is a collection of electronic data. Device configuration storage45can be any suitable electronic data storage means, such as a database, data warehouse, data lake, flat file, or other data storage type. In some examples, device configuration storage45can be an “on-premises” data store (e.g., within an organization's data centers). In other examples, device configuration storage45can be a “cloud” data store that is available using cloud services from vendors such as Amazon, Microsoft, or Google. In some examples, device configuration storage45can be a cloud service that is provided and maintained by a third-party vendor, such as a third-party vendor associated with tracking devices60. For example, device configuration storage45as a third-party service can provide a level of abstraction between the configuration information for tracking devices60and a request for the data, rather than permitting direct access to device configuration storage45. In some examples, device configuration storage45and location data store30can be services provided by the same third-party vendor. Electronic data stored in device configuration storage45can be modified, either directly or indirectly, by centralized device management platform40. In some examples, centralized device management platform40can access data from device configuration storage45via an API, such as via an API provided by the third-party vendor in examples where device configuration storage45is a third-party service, or some other communication interface.

As illustrated inFIG.2, device configuration information stored in device configuration storage45can take the form of device twins46. Each device twin46corresponds to one of tracking devices60. Each device twin46is a “digital twin” or virtual representation that serves as the digital counterpart of the corresponding physical tracking device60. In general, each device twin46can include a digital representation of an asset type associated with the corresponding tracking device60, a class associated with the corresponding tracking device60and/or its components (e.g., sensor70of tracking device60′ inFIG.1C), base and current configurations of the corresponding tracking device60and/or its components, and a current state of the corresponding tracking device60and/or its components. Each device twin46can have a unique identifier that is associated with a unique identifier for the corresponding one of tracking devices60.

More specifically, each device twin46includes a set of device configurations to be deployed for a corresponding one of tracking devices60. As such, device twins46can be asset templates for configuring tracking devices60. That is, each tracking device60can be configured or provisioned from an initial state using a corresponding device twin46that defines all the configuration information for that tracking device60. Alternatively, an initial version of each device twin46can be filled out based on information from the respective tracking device60. Tracking devices60that have been configured from an initial state can be described as having pre-existing device configurations (that are defined in the set of device configurations of the corresponding device twin46) with respect to any subsequent updates based on identified rules from location-based rules module80. Device twins46include parameter definitions and values that are required for implementation and functionality of tracking devices60. For example, device configurations (i.e., a set of device configurations) defined in device twins46can include an asset type identification corresponding to a respective asset62that is associated with the one of tracking devices60, a location data reporting frequency, a signal type for transmitting location data, and an enabled or disabled state of a sensor component (e.g., sensor70of tracking device60′ inFIG.1C), or any other configurations for functionality of tracking devices60. The device configurations defined in device twins46can also include a home zone identification corresponding to a predefined geofence zone that is a home zone for a respective tracking device60. Device twins46can be updated by output engine82with new or changed device configurations based on identified rules from location-based rules module80.

User interface50can be communicatively coupled to centralized device management platform40to enable users52to interact with centralized device management platform40, such as for, e.g., accessing and viewing information associated with tracking devices60, receiving notifications generated by output engine82, configuring centralized device management platform40, etc. User interface50can include a display device and/or other user interface elements (e.g., keyboard, buttons, monitor, graphical control elements presented at a touch-sensitive display, or other user interface elements). In some examples, user interface50includes a graphical user interface (GUI) that includes graphical representations of information associated with tracking devices60and/or notifications generated by output engine82. For example, user interface50can include graphical representations of locations of tracking devices60presented on a map, times that location data was last received from each of tracking devices60, strength of the transmitted signal from each of tracking devices60, device configuration information, etc. Trend information about tracking devices60can also be derived from the collective location data and presented with visualizations for users52via user interface50. For example, user interface50can include a graphical representation of a percentage of assets62that are in an expected zone (e.g., on the organization's property) compared to a percentage of assets62that are outside of the expected zone. As will be described in greater detail below with respect toFIG.4, user interface50can have multiple display or accessibility configurations based on groups of users.

In some examples, user interface50can take the form of a mobile device (e.g., a smart phone, a tablet, etc.) with an application downloaded that is designed to connect to centralized device management platform40. In such examples, user52can load the application on the mobile device, and the device can communicate a request to centralized device management platform40(e.g., via an API running on a web server) to receive updated application data. Once updated data has been received at user interface50, users52can view any notifications and view updated locations of tracking devices60.

Users52can also configure aspects of centralized device management platform40via user interface50. For example, users52can select configurations for configuration-driven modules of rules engine76. In some examples, users52can set boundaries (geofences) to define zones for location evaluator module78of rules engine76. In some examples, setting boundaries to define the zones can include manually drawing boundaries using a GUI that displays a map. In some examples, users52can select conditional actions (e.g., device configuration changes) to associate with a location or zone for location-based rules module80of rules engine76. Any configurations set or selected by users52can then be communicated to centralized device management platform40(e.g., via an API running on a web server) so that rules engine76, including location evaluator module78and location-based rules module80, can execute code based on the configurations.

In general, each of location data store30, components of centralized device management platform40, device configuration storage45, and user(s)52(along with user interface50) can be remote from each other. In some examples, location data store30and/or device configuration storage is a cloud-based data store. Location data store30and device configuration storage can be available from a same or different cloud service in examples where both location data store30and device configuration storage45are cloud-based. Centralized device management platform40can also be wholly or partially cloud-based. Moreover, one or more processes of centralized device management platform40may not be executed in a fixed location, i.e., one or more processes of centralized device management platform40can be executed in different locations (e.g., on different processors).

In operation, assets62move or are moved, and corresponding tracking devices60periodically transmit location data to location data store30. Centralized device management platform40retrieves location data32from location data store30. Location data32is evaluated by location evaluator module78of rules engine76to identify geofence zones that include the location of each tracking device60. Location-based rules module80compares the identified zones to stored rules to identify rules that are associated with the identified zones. Centralized device management platform40communicates (or interfaces) with user interface50and/or device configuration storage45(and, subsequently, tracking devices60) based on instructions from output engine82that are, in turn, based on the identified rules from rules engine76. Notifications may be generated by output engine82and available to users52via user interface50or other means, such as email, SMS, etc. User interface50can also display updated information about tracking devices60and corresponding tracked assets62. One or more of device twins46in device configuration storage45are updated based on the instructions from output engine82, and updated ones of device twins46are synced to corresponding tracking devices60. Tracking devices60are thereby reconfigured to have changed functionality according to the device configurations in the corresponding ones of device twins46.

Asset tracking system10, according to techniques of this disclosure, allows for dynamic asset tracking without requiring the addition of extensive (and potentially expensive) infrastructure because asset tracking system10can be implemented using available tracking technologies. Asset tracking system10also simplifies system management because tracking device reconfiguration and generation of notifications happen centrally by centralized device management platform40. Moreover, the functional modules of centralized device management platform40(rules engine76and output engine82) work in tandem to allow tracking device reconfiguration and generation of notifications to occur dynamically (or essentially automatically) as tracking devices60move. Accordingly, asset tracking system10can require relatively less active upkeep to track assets62, i.e., can be more efficient and save time, compared to other asset tracking systems, as manual interaction with asset tracking system10by technicians is minimized. In some specific situations, remote reconfiguration of deployed tracking devices60allows tracking devices60to be reconfigured to have functionality that better matches the conditions each tracking device60is experiencing, such as to make more accurate measurements from a sensor (e.g., sensor70inFIG.1C) or to conserve battery life, for example. These reconfigurations may not otherwise be possible manually if tracking devices60have been moved off an organization's premises and/or are not readily recoverable or accessible.

Similarly, tracking devices60in asset tracking system10are readily reusable for different applications because device configuration is linked to device location and tracking devices60can be automatically reconfigured for a new purpose based entirely on their location. This reduces the number of manual steps that would otherwise be required for updating an organization's network of devices.

Asset tracking system10is also highly flexible and modifiable such that it can be implemented in a wide range of asset tracking scenarios. For example, rules engine76of centralized device management platform40can be readily updated to add more location-based rules and grow the system. Rules engine76can also be reconfigured to include, e.g., new geofence zones, different conditions for device configurations, etc., so that the location-based rules can apply to different scenarios. Asset tracking system10can also integrate sensor data from additional sensors with location data from tracking devices (e.g., tracking devices60′ inFIG.1C) for more complex asset tracking and device reconfiguration capabilities.

Further, information (e.g., location data32) about tracked assets (tracking devices60and associated assets62) is evaluated centrally and available to users52via user interface50in communication with centralized device management platform40. Location data32, including historical data, can be used at scale to track trends across all deployed tracking devices60for an organization. For example, an organization can track counts of tracked assets62that are in a corresponding home zone compared to those that are outside the home zone for one or more branches of the organization. With this trend information, an organization can derive business insights and take targeted corrective actions, e.g., to improve operational processes relating to asset management.

FIG.3is a schematic diagram of communication protocol100for tracking device60and centralized device management platform40. As illustrated inFIG.3, communication protocol100includes steps102-124. Communication protocol100represents one non-limiting example of a protocol or sequence of actions for centralized device management platform40and tracking device60to establish a connection and send or receive data and/or commands. For example, communication protocol100can utilize communication interface features of centralized device management platform40. It should be understood, however, that other communications protocols can also be used with centralized device management platform40and tracking device60.

Step102is a first step of communication protocol100. At step102, tracking device60sends a first request for a data upload to centralized device management platform40. At step104, centralized device management platform40receives the first request from tracking device60and, at step106, centralized device management platform40transmits a first acknowledgement to tracking device60. At step108, tracking device60receives the first acknowledgement from centralized device management platform40. At step110, tracking device60transmits data to centralized device management platform40, and centralized device management platform40receives the data at step112. For example, the data transmitted by tracking device60in step110and received by centralized device management platform40in step112can include location and/or sensor data (e.g., as described above with reference toFIGS.1A and2).

At step114, centralized device management platform40transmits a second acknowledgement (of receipt of the data) and also transmits a second request to send a command to tracking device60. At step116, tracking device receives the second acknowledgement and the second request, and, at step118, tracking device60transmits a third acknowledgement to centralized device management platform40. At step120, centralized device management platform40receives the third acknowledgement. At step122, centralized device management platform40transmits a command to tracking device60. Step124is a final or sequentially last step of communication protocol100. At step124, tracking device60receives the command from centralized device management platform40. For example, the command transmitted to and received by tracking device60in steps122and124, respectively, can include instructions for reconfiguring tracking device60based on a device configuration in an updated device twin46(e.g., as described above with reference toFIG.2). In other examples, the command can be that there are no commands (e.g., if the respective device twin46was not updated).

Communication protocol100can be implemented for an embodiment of asset tracking system10where centralized device management platform40communicates directly with tracking devices60, rather than indirectly through a third-party system. However, it should be understood that a similar communication sequence could occur in an alternative embodiment where a third-party system communicates directly with the tracking devices (and centralized device management platform40communicates with the third-party system). In an indirect communication embodiment, the third-party system would effectively serve as an intermediate between centralized device management platform40and tracking devices60, and steps in communication protocol100that are assigned to centralized device management platform40could instead be carried out by the third-party system.

Asset tracking system10ofFIGS.1A and2using communication protocol100allows communications from centralized device management platform40to remotely reconfigure tracking devices60. In this way, one or more tracking devices60can be dynamically reconfigured based on location-based rules from rules engine76. That is, tracking devices60can be reconfigured in response to a change that occurs after tracking devices60have been deployed and associated with assets62without requiring a technician to manually update the devices in the field. This is useful so that tracking devices can seamlessly transition between different configurations as the devices move between zones. Further, certain device configurations may be desired when an asset has been removed from an organization's premises (e.g., a lost or stolen asset), and it may not otherwise be feasible for the corresponding tracking device to be reconfigured until the asset was recovered.

FIG.4is a schematic diagram illustrating an example organization of groups202A-202nand corresponding sets of tracked assets210A-210n. As illustrated inFIG.4, organizational hierarchy200includes groups202A-202n(the character “n” is used herein as an arbitrary reference character to indicate any integer value), which include corresponding subset groups204A-204n,205A-205n, and206A-206n. Groups202A-202nare also organized under super group208. Each of groups202A-202nis associated with a corresponding set of tracked assets210A-210n, each of which includes corresponding tracking devices212and assets214.

Organizational hierarchy200represents an example organization of relationships between groups of users (e.g., users52shown inFIG.1A) of asset tracking system10. The illustrated embodiment is intended merely as a non-limiting example to show various relationships between groups of users that are possible within the scope of the present disclosure.

Groups202A-202ncan represent a primary category of users52. For example, groups202A-202ncan represent users in individual branches of an organization, such as individual stores. Group202A can represent a first branch, group202B can represent a second branch, and group202ncan represent a third branch. Although three groups202A-202nare illustrated inFIG.4, it should be understood that other examples can include more or fewer groups202A-202n.

Groups202A-202ncan be organized under super group208. Super group208is a parent group with respect to groups202A-202nin that it includes all groups202A-202nand any subset groups corresponding to those groups202A-202n. In examples where each of groups202A-202nrepresents a branch of an organization, super group208can represent users who manage the entire organization or a sector of the organization.

Each of groups202A-202ncan also include corresponding subset groups204A-204n,205A-205n, and206A-206n. As illustrated inFIG.4, group202A can include subset groups204A-204n, group202B can include subset groups205A-205n, and group202ncan include subset groups206A-206n. Although three subset groups204A-204n,205A-205n, and206A-206nare illustrated per each group202A-202n, it should be understood that other examples can include more of fewer subset groups per each group202A-202n. Moreover, each group202A-202ncan include the same or different number of corresponding subset groups204A-204n,205A-205n, and206A-206n. In other examples, ones of groups202A-202nmay not include any subset groups. For example, each of subset groups204A-204n,205A-205n, and206A-206ncan represent a category of personnel. In one example, subset group204A could represent operations employees, subset group204B could represent sales employees, and subset group204ncould represent security employees. In other examples, each of subset groups204A-204n,205A-205n, and206A-206ncan represent any category of users52that is a subset of the corresponding group202A-202n.

Each of groups202A-202nis associated with a corresponding set of tracked assets210A-210n. As illustrated inFIG.4, group202A is associated with set of tracked assets210A, group202B is associated with set of tracked assets210B, and group202nis associated with set of tracked assets210n. Each set of tracked assets210A-210ncan encompass any assets that the corresponding one of groups202A-202nselects to track.

Each set of tracked assets210A-210nincludes tracking devices212and assets214. Tracking devices212are examples of tracking devices60,60′ described above with reference toFIGS.1A-2. Assets214are examples of assets62described above with reference toFIG.1A. Each set of tracked assets210A-210ncan include any number of tracking devices212and assets214. In some examples, ones of groups202A-202nmay select to track assets that are all the same type of asset. For example, set210A corresponding to group202A includes assets214, which are carts, and set210B corresponding to group202B includes assets214, which are vehicles. In other examples, ones of groups202A-202nmay select to track assets that are different types of assets. For example, set210ncorresponding to group202nincludes assets214, which are packages and vehicles. In general, sets of tracked assets210A-210ncan include any combination of types of assets214.

Groups202A-202n, super group208, and subset groups204A-204n,205A-205n, and206A-206ncan be associated with different accessibility levels with respect to centralized device management platform40(FIGS.1A and2-3), which can be implemented via user interface50(FIGS.1A and2). In some examples, user interface50may only display information (e.g., location information on a map) about a respective one of sets of tracked assets210A-210nfor each of groups202A-202n. That is, group202A may have access to information about set of tracked assets210A but not set210B or set210n, group202B may have access to information about set of tracked assets210B but not set210A or set210n, and group202nmay have access to information about set of tracked assets210nbut not set210A or set210B. In some examples, user interface50can have a different overall display configuration for each of subset groups204A-204n,205A-205n, and206A-206n. The display configuration for each of subset groups204A-204n,205A-205n, and206A-206ncan, in some examples, limit visibility to only certain information about tracking devices212and assets214. In some examples, configuration settings for configuring centralized device management platform40may be locked so that only some subset groups204A-204n,205A-205n, and206A-206ncan change configurations. In comparison, super group208can have more comprehensive access to information about all sets of tracked assets210A-210nacross all groups202A-202n(i.e., all tracking devices212and all assets214). For example, super group208can have access to overall trend information about sets of tracked assets210A-210nto compare across and between groups202A-202n.

Groups202A-202n, super group208, and subset groups204A-204n,205A-205n, and206A-206ncan also each be associated with different notification types or frequencies via output engine82(FIGS.1A and2). For example, a workflow method of output engine82can direct notifications to be sent to groups202A-202nor particular ones of subset groups204A-204n,205A-205n, and206A-206nfor users in those groups to take more immediate action with respect to the corresponding set of tracked assets210A-201n. On the other hand, a workflow method of output engine82can direct notifications to super group208relatively infrequently.

Embodiments of organizational hierarchy200can be implemented with asset tracking system10so that relevant information about tracked assets is available to the appropriate users52. This can improve efficiency or ease-of-use and security of asset tracking system10with respect to user actions. In particular, users in groups202A-202nor ones of subset groups204A-204n,205A-205n, and206A-206nmay only be able to access information that is relevant to their role, such as information about assets associated with their respective branch of the organization. Configuring a user interface (e.g., user interface50inFIGS.1A and2) based on user roles can ensure that the appropriate personnel are alerted to take corrective action for rogue assets. In comparison, users in super group208may be able to access management-level information, such as trends across all branches/locations of the business. This is useful for developing overall business insights based on location data from all the organization's tracked assets, such as to determine which locations are experiencing more instances of rogue assets.

Various non-limiting implementations of asset tracking systems according to techniques of this disclosure (e.g., asset tracking system10inFIG.1A) will be described with reference toFIGS.5A-8B. Each asset tracking system embodiment shown inFIGS.5A-8Bincludes generally similar components, which are identified by shared reference numbers that are increased incrementally between each pair ofFIGS.5A-5B,6A-6B,7A-7B, and8A-8B(e.g.,FIGS.5A-5Binclude rules engine340,FIGS.6A-6Binclude rules engine440,FIGS.7A-7Binclude rules engine540, andFIGS.8A-8Binclude rules engine640). Further, each asset tracking system embodiment shown inFIGS.5A-8Bcan be an example of asset tracking system10ofFIG.1A, with similar components sharing the same name. Some components of the asset tracking system embodiments shown inFIGS.5A-8Bare omitted for ease of discussion, but it should be understood that the asset tracking system embodiments shown inFIGS.5A-8Bcan include all or any combination of the components and features described above with respect toFIGS.1A-4. Additionally, although depicted inFIGS.5A-8Bas separate examples, an asset tracking system according to techniques of this disclosure can include any combination of the following features.

FIGS.5A-5Bare schematic diagrams of asset tracking system300in which rules engine340includes location-based rules for configuring tracking devices with respect to geofence zone330. As illustrated inFIGS.5A-5B, asset tracking system300includes tracking devices310and312and corresponding assets320and322, respectively, geofence zone330, and map feature332. Asset tracking system300also includes rules engine340(including location evaluator module342and location-based rules module344), output engine350, and device twin360, which includes corresponding device configuration362.

In the example shown inFIGS.5A-5B, geofence zone330is an irregular polygonal shape that encompasses a parking lot. Map feature332is building, such as a store. Assets320and322are shopping carts, and device twins360can also be considered asset templates for a cart. InFIG.5A, both tracking device310and corresponding asset320and tracking device312and corresponding asset322are located within geofence zone330. In this example, tracking devices310and312are already configured based on geofence zone330and remain in geofence zone330. When location data from tracking device312is evaluated by location evaluator module342and location-based rules module344of rules engine340, a device configuration instruction associated with the rule that is associated with geofence zone330will match device configuration362in device twin360that is assigned to tracking device312. Accordingly, device twin360(and device configuration362) will not be updated by output engine350.

FIG.5Bshows a progression fromFIG.5Awhere tracking device312and corresponding asset322have moved outside geofence zone330. In some examples, tracking device312and corresponding asset322may have been outside geofence zone330for at least a threshold amount of time (e.g., a certain number of consecutive location reports). When location data from tracking device312is evaluated by location evaluator module342and location-based rules module344of rules engine340, a device configuration instruction associated with the rule that is associated with a zone representing an area outside geofence zone330will not match device configuration362in device twin360that is assigned to tracking device312. Accordingly, device twin360(and device configuration362) will be updated by output engine350. The update can include, e.g., changing an asset type identification for asset322, changing a location data reporting frequency for tracking device312, changing a signal type for transmitting the location data, and changing an enabled or disabled state of a sensor component of tracking device312, or other changes. For example, the location data reporting frequency of tracking device312may be increased to track the movement of asset322more continuously because asset322is now outside its home location (geofence zone330). In other examples, the location data reporting frequency of tracking device312may be decreased to conserve battery life of tracking device312, e.g., until asset322can be recovered.

FIGS.6A-6Bare schematic diagrams of asset tracking system400in which rules engine440includes location-based rules for configuring tracking devices with respect to an inside geofence zone and an outside geofence zone. As illustrated inFIGS.6A-6B, asset tracking system400includes tracking devices410and412and corresponding assets420and422, respectively, first geofence zone430A, second geofence zone430B, and map feature432. Asset tracking system400also includes rules engine440(including location evaluator module442and location-based rules module444), output engine450, and device twin460, which includes corresponding device configuration462.

In the example shown inFIGS.6A-6B, first geofence zone430A is an irregular polygonal shape that encompasses a parking lot, and second geofence zone430B is bounded by the walls of map feature432such that second geofence zone430B encompasses the interior of map feature432(an inside geofence zone). Second geofence zone430B is contained within first geofence zone430A, which is outside map feature432(an outside geofence zone). Map feature432is building, such as a store. Assets420and422are shopping carts, and device twins460can also be considered asset templates for a cart. InFIG.6A, both tracking device410and corresponding asset420and tracking device412and corresponding asset422are located within first geofence zone430A. In this example, tracking devices410and412are already configured based on first geofence zone430A and remain in first geofence zone430A. When location data from tracking device412is evaluated by location evaluator module442and location-based rules module444of rules engine440, a device configuration instruction associated with the rule that is associated with first geofence zone430will match device configuration462in device twin460that is assigned to tracking device412. Accordingly, device twin460(and device configuration462) will not be updated by output engine450.

FIG.6Bshows a progression fromFIG.6Awhere tracking device412and corresponding asset422have moved from first geofence zone430A to second geofence zone430B. In some examples, tracking device412and corresponding asset422may have been within second geofence zone430B for at least a threshold amount of time (e.g., a certain number of consecutive location reports). When location data from tracking device412is evaluated by location evaluator module442and location-based rules module444of rules engine440, a device configuration instruction associated with the rule that is associated with second geofence zone430B will not match device configuration462in device twin460that is assigned to tracking device412. Accordingly, device twin460(and device configuration462) will be updated by output engine450. The update can include, e.g., changing an asset type identification for asset422, changing a location data reporting frequency for tracking device412, changing a signal type for transmitting the location data, and changing an enabled or disabled state of a sensor component of tracking device412, or other changes. For example, the signal type for tracking device412may be changed from a cellular signal (based on a rule associated with first geofence zone430A) to a Wi-Fi signal because the Wi-Fi signal range may only extend approximately within the walls of building432.

FIGS.7A-7Bare schematic diagrams of asset tracking system500in which rules engine540includes location-based rules for configuring tracking devices with respect to adjacent geofence zones530A-530D. As illustrated inFIGS.7A-7B, asset tracking system500includes tracking devices510,512,514, and516and corresponding assets520,522,524, and526, respectively, first geofence zone530A, second geofence zone530B, third geofence zone530C, fourth geofence zone530D, and map feature532. Asset tracking system500also includes rules engine540(including location evaluator module542and location-based rules module544), output engine550, and device twin560, which includes corresponding device configuration562.

In the example shown inFIGS.7A-7B, first, second, third, and fourth geofence zones530A-530D are each a polygonal shape that encompasses adjacent first, second, third, and fourth areas, respectively, within the interior of map feature532. Map feature532is building or campus, such as a mall, college, or hospital. For example, each of geofence zones530A-530D can represent a separate region, department, floor, etc. of a building or a campus of connected buildings. Assets520,522,524, and526are wheelchairs, and each of assets520,522,524, and526(and corresponding tracking devices510,512,514, and516) can have a home zone where the asset is expected to be located. For example, the home zone for asset520can be first geofence zone530A (zone A), the home zone for asset522can be second geofence zone530B (zone B), the home zone for asset524can be third geofence zone530C (zone C), and the home zone for asset526can be fourth geofence zone530D (zone D). Accordingly, device twins560can also be considered asset templates for wheelchairs in zones A-D.

InFIG.7A, each of tracking devices510,512,514, and516and corresponding assets520,522,524, and526are located in their respective home zone. That is, tracking device510and asset520are in first geofence zone530A, tracking device512and asset522are in second geofence zone530B. tracking device514and asset524are in third geofence zone530C, and tracking device516and asset526are in fourth geofence zone530D. In this example, tracking devices510,512,514, and516are already configured based on the respective home zone and remain in the respective home zone. When location data from tracking device512is evaluated by location evaluator module542and location-based rules module544of rules engine540, a device configuration instruction associated with the rule that is associated with second geofence zone530B will match device configuration562in device twin560that is assigned to tracking device512. Accordingly, device twin560(and device configuration562) will not be updated by output engine550.

FIG.7Bshows a progression fromFIG.7Awhere tracking device512and corresponding asset522have moved from second geofence zone530B (the respective home zone) to first geofence zone530A. In some examples, tracking device512and corresponding asset522may have been within first geofence zone530A for at least a threshold amount of time (e.g., a certain number of consecutive location reports). When location data from tracking device512is evaluated by location evaluator module542and location-based rules module544of rules engine540, a device configuration instruction associated with the rule that is associated with first geofence zone530A (or a generic “not home zone”) will not match device configuration562in device twin560that is assigned to tracking device512. Accordingly, device twin560(and device configuration562) will be updated by output engine550. The update can include, e.g., changing an asset type identification for asset522, changing a location data reporting frequency for tracking device512, changing a signal type for transmitting the location data, and changing an enabled or disabled state of a sensor component of tracking device512, or other changes. For example, the location data reporting frequency of tracking device512may be increased to track the movement of asset522more continuously because asset522is now outside its home zone (second geofence zone530B).

FIGS.8A-8Bare schematic diagrams of asset tracking system600in which rules engine640includes location-based rules for configuring tracking devices with respect to a first asset type zone and a second asset type zone. In general,FIGS.8A-8Billustrate an example of repurposing or reassigning a tracking device according to techniques of this disclosure to track another asset or an asset of a different asset type altogether. As illustrated inFIGS.8A-8B, asset tracking system600includes tracking device610, assets620and622, first geofence zone630A, second geofence zone630B, first map feature632A, and second map feature632B. Asset tracking system600also includes rules engine640(including location evaluator module642and location-based rules module644), output engine650, and device twin660, which includes corresponding device configuration662.

In the example shown inFIGS.8A-8B, first geofence zone630A is a circular shape that generally encompasses a building (map feature632A), and second geofence zone630B is a circular shape that generally encompasses a different building (map feature632B). Map feature632A is a cold storage facility and map feature632B is a store. Asset620is a package or container, and a corresponding device twin660can be considered an asset template for cold storage. Asset622is a shopping cart, and a corresponding device twin660could be considered an asset template for a cart, which would be the result of a change caused by moving tracking device610from asset620to asset622. InFIG.8A, only asset620is associated with a tracking device (tracking device610). Tracking device610and asset620are located in first geofence zone630A, which can be considered a first asset type zone. Asset622is located in second geofence zone630B, which can be considered a second asset type zone because asset622is a different type of asset (shopping cart) than asset620(container). In this example, tracking device610is already configured based on first geofence zone630A and remains in first geofence zone630A. When location data from tracking device610is evaluated by location evaluator module642and location-based rules module644of rules engine640, a device configuration instruction associated with the rule that is associated with first geofence zone630A will match device configuration662in device twin660that is assigned to tracking device610. Accordingly, device twin660(and device configuration662) will not be updated by output engine650.

FIG.8Bshows a progression fromFIG.8Awhere tracking device610is removed from asset620in first geofence zone630A and associated with asset622in second geofence zone630B. In some examples, tracking device610and corresponding asset622may have been within second geofence zone630B for at least a threshold amount of time (e.g., a certain number of consecutive location reports). When location data from tracking device610is evaluated by location evaluator module642and location-based rules module644of rules engine640, a device configuration instruction associated with the rule that is associated with second geofence zone630B will not match device configuration662in device twin660that is assigned to tracking device610. Accordingly, device twin660(and device configuration662) will be updated by output engine650. The update can include, e.g., changing an asset type identification for asset622, changing a location data reporting frequency for tracking device612, changing a signal type for transmitting the location data, and changing an enabled or disabled state of a sensor component of tracking device612, or other changes. For example, the asset type identification can be changed to “shopping cart IDxxx” from “cold storage container IDxxx” now that tracking device610is no longer associated with container620. Additionally, a temperature sensor component of tracking device610can be disabled through the device twin660and device configuration662, as its functionality may not be necessary or desired for monitoring cart622.

FIGS.5A-8Billustrate various ways an asset tracking system can be implemented according to techniques of the present disclosure. As illustrated inFIGS.5A-8B, geofence zones for the asset tracking system described herein are widely configurable to capture various boundary-crossing events for tracking devices. This allows for location-based rules to be tailored to a particular organization's layout or conditions (e.g., whether there is a building that assets might be inside or outside of, whether there is a group of assets that should remain in a certain area whereas other groups are assigned to different areas, whether a tracking device has been relocated to a new site with different asset types, etc.). Additionally, having a robust rules engine as described herein allows any number of device configurations to be associated with location-based rules, such that individual aspects of a tracking device can be reconfigured based on a location change (e.g.,FIGS.5A-7B), or the entire tracking device functionality can be changed (e.g.,FIGS.8A-8B).

FIG.9is a process flowchart illustrating steps710-770of process700for updating tracking device configurations based on location data. Process700for updating tracking device configurations based on location data will be described with reference to components of asset tracking system10described above (FIGS.1A-4), though process700is also applicable to asset tracking systems300,400,500, and600(FIGS.5A-8B). That is, although depicted inFIGS.1A-8Bas separate examples, an asset tracking system according to techniques of this disclosure can include any combination of the foregoing features.

As illustrated inFIG.9, a first step of process700is to receive location data corresponding to a tracked asset (e.g., one of assets62and a corresponding tracking device60) (step710). At step720, the location data is evaluated to identify a zone that includes the location of the tracking device. For example, the location data can be retrieved from location data store30and evaluated at rules engine76(e.g., location evaluator module78) of centralized device management platform40.

At step730, a first decision is made within process700to determine if a threshold related to presence of the tracking device in the identified zone (identified at step720) has been exceeded. For example, location evaluator module78can include a function for counting consecutive location data reports from tracking devices60that are within the same zone. In other examples, location evaluator module78can include a function for determining a distance that tracking devices60have traveled into the identified zone. If there has been more than one consecutive location reported from the tracking device in the identified zone such that a threshold duration is exceeded or if the distance the tracking device has traveled exceeds a threshold distance (YES), then process700proceeds to step740. If there has not been more than one consecutive location reported from the tracking device in the identified zone of if the distance the tracking device has traveled is less than the threshold distance (NO), then process700returns to step710. In alternative examples, process700does not include step730, i.e., process700proceeds directly from step720to step740. At step740, the identified zone is compared with stored rules to identify a rule that is associated with the identified zone. For example, location-based rules module80of rules engine76can identify a rule associated with the identified zone.

At step750, a second decision is made within process700to determine if the identified rule matches a device configuration in a template that is assigned to the tracking device. For example, each of tracking devices60is implemented according to a corresponding device twin (or template)46that includes a device configuration for the respective tracking device60. The corresponding device twin46can be accessed by centralized device management platform40. If the identified rule from rules engine76is associated with a device configuration instruction that does not match the device configuration currently defined in the corresponding device twin46(NO), then process700proceeds to step760. If the identified rule from rules engine76is associated with a device configuration instruction that matches the device configuration currently defined in the corresponding device twin46(YES), then process700returns to step710because the corresponding device twin46does not need to be updated. In alternative examples, process700does not include step750, i.e., process700proceeds directly from step740to step760.

At step760, the device configuration is updated based on the identified rule that is associated with the identified zone, and, at step770, the updated device configuration is transmitted to the tracking device. For example, output engine82can cause the corresponding device twin46to be updated and sync the updated configuration to the respective tracking device60. Accordingly, the respective tracking device60will be updated and reconfigured based on the rule from rules engine76that is associated with zone that includes the most-recently reported location of the device.

As described above with respect toFIGS.1A-8B, an asset tracking system according to techniques of this disclosure allows for dynamic asset tracking that is both broadly applicable to various tracking scenarios and readily modifiable.

While the invention has been described with reference to an exemplary embodiment(s), it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment(s) disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.