Method and system for locating objects within a master space using machine learning on RF radiolocation
Summary by NHIP
RF Beacon Location System
The system locates objects within predefined subspaces using machine learning models trained on prior RF signal surveys. Distinctive elements include RF beacons transmitting signals to tags that send data packages containing signal identifications to a gateway and location engine, which accesses specific ML models associated with unique subspace identifiers and coordinates.
Claim Score by NHIP
Abstract
Location of objects within an identified subspace defined within a predefined master space. The system includes an RF beacon associated with an object, the RF beacon transmitting signals to one or more of RF tags transmitting to an object location system a tag data package including an identification of the signals received by the RF tags from the RF beacon. The system includes a gateway receiving and extracting, from the transmitted tag data package, the identification of signals. The system further includes the location engine accessing an ML model trained by performing a survey of RF signals received from a plurality of RF signal sources during a prior RF master space survey operation and determining a subspace identifier corresponding to a predicted subspace location for the object by comparing the identification of signals included in the received tag data package to a model plurality of signals accessed from the model.

Term
15.6 yearsleft in the term
Expires 18 April 2042, including 536 days of term adjustment.
- Priority
- Filed
- Granted
- Today
- Expires
20 claims: 2 independent, 18 dependent
- 1A system for location of objects within an identified subspace of a plurality of subspaces defined within a predefined master space, comprising:a Radio Frequency (RF) beacon associated with an object, the RF beacon transmitting signals to one or more RF tags, the one or more RF tags transmitting, to an object location system, a tag data package, the tag data package comprising an identification of the signals received by the one or more RF tags from the RF beacon;the object location system comprising a gateway and a location engine: the gateway receiving and extracting, from the transmitted tag data package, the identification of signals;the location engine: accessing a plurality of machine learning (ML) models, each of the plurality of ML models associated with one of a plurality of subspaces, each subspace associated with a subspace identifier, each one of the plurality of ML models trained by: generating a session identifier for a measurement session, retrieving a customer site number associated with a master space, identifying a zone label and coordinates for one of the plurality of subspaces within the master space based on customer site information, associating the zone label with a location number, storing the session identifier, zone label, coordinates, and location number in a location list, generating a scan identifier for a radio frequency (RF) signal sampling operation, collecting RF signal strength indicator (RSSI) values from a plurality of RF beacons within the one of the plurality of subspaces, associating the collected RSSI values with the location number, generating a measurement log comprising the session identifier, zone label, scan identifier, and collected RSSI values, and processing the measurement log to create the one of the plurality of machine-learning data models, the one of the plurality of machine-learning data models associated with the one of the plurality of subspaces;providing the identification of signals to each of the plurality of ML models;receiving, from each of the plurality of ML models, a correlation between the identification of signals and that machine-learning data model;determining a highest correlation of the received correlations;selecting, from the plurality of ML models, a candidate ML model from which the highest correlation was received;determining a subspace identifier corresponding to a predicted subspace location associated with the candidate ML.
- 11Broadest claimClaim Score 14, narrow(NHIP)A method for location of objects within an identified subspace of a plurality of subspaces defined within a predefined master space, comprising the steps of:providing a Radio Frequency (RF) beacon associated with an object, the RF beacon transmitting signals to one or more RF tags, the one or more RF tags transmitting, to an object location system, a tag data package, the tag data package comprising an identification of the signals received by the one or more RF tags from the RF beacon;receiving and extracting, from the transmitted tag data package, the identification of signals;accessing a plurality of machine learning (ML) models, each of the plurality of ML models associated with one of a plurality of subspaces, each subspace associated with a subspace identifier, each of the plurality of ML models trained by: generating a session identifier for a measurement session;retrieving a customer site number associated with a master space;identifying a zone label and coordinates for one of the plurality of subspaces within the master space based on customer site information;associating the zone label with a location number;storing the session identifier, zone label, coordinates, and location number in a location list;generating a scan identifier for a radio frequency (RF) signal sampling operation;collecting RF signal strength indicator (RSSI) values from a plurality of RF beacons within the one of the plurality of subspaces;associating the collected RSSI values with the location number;generating a measurement log comprising the session identifier, zone label, scan identifier, and collected RSSI values;and processing the measurement log to create the one of the plurality of machine-learning data models, the one of the plurality of machine-learning data models associated with the one of the plurality of subspaces;providing the identification of signals to each of the plurality of ML models;receiving, from each of the plurality of ML models, a correlation between the identification of signals and that machine-learning data model;determining a highest correlation of the received correlations;selecting, from the plurality of ML models, a candidate ML model from which the highest correlation was received;determining a subspace identifier corresponding to a predicted subspace location associated with the candidate ML model.
Independent claims2
466 paragraphs in 7 sections, as filed
CROSS-REFERENCE TO RELATED PATENT APPLICATION
0001This patent application is a continuation-in-part of U.S. patent application Ser. No. 17/083,981, filed on Oct. 29, 2020, the entire disclosure of which is hereby incorporated by reference herein.
TECHNICAL FIELD
0002The present disclosure and claimed inventions relate generally to radiolocation and relate more specifically to the location of objects in particular zones (rooms, subspaces, areas, etc.) of a master space such as a building, equipment lot, warehouse, etc. using the detected characteristics of radio signals such as beacons distributed within or near the master space.
BACKGROUND
0003Knowing the location of specific assets or object within a spatial environment is an important aspect of present-day logistics, healthcare, and other industries. For example, in a logistics environment such as a warehouse of products, a commercial organization needs to know the location of specific objects such as pallets or individual product packages for purposes of retrieval and shipment. As another example, a healthcare facility such as a hospital needs to know the location of specific assets such as respirators, gurneys, ECG machines, or other items for purposes of repositioning the assets where a need exists. As another example, a storage lot of movable vehicles or equipment (e.g., automobiles, construction equipment, military assets) may have multiple objects whose locations need to be tracked for sales, maintenance or service, deployment for missions or jobs, etc.
0004Certain types of objects are highly mobile and require real-time tracking. For example, tracking the location of people usually requires use of actively radio frequency (RF) radiating devices such as pagers, mobile telephones, active RFID tags, active transmitting tags, etc., with the necessary placement of significant and costly tracking infrastructure and networks. Various “active RF” object location systems are known in the art. Although perhaps not generally representative of real time “active RF” location system, U.S. Pat. No. 8,957,812 to Hill et al. describes a position tracking system using radio signals coupled with inertial sensing. This system involves a transmitter on each located asset and uses a plurality of receiver antennas to receive a device's radio signal at each antenna.
0005Active RF location systems (such as described in the Hill et al. patent in some respects) typically involve use of RF transmitters that activate frequently to provide position information frequently if not in real time, require costly infrastructure such as access points or locators that must be supplied with power and network connections, use less accurate techniques such as time difference of arrival (TDOA) of signals, are prone to multipath errors, use more accurate ultrawideband technologies that have limited range or significant power consumption, or have a number of other drawbacks,
0006Other objects such as product pallets and medical equipment, although mobile, tend to remain stationary for significant periods of time, and may be in an environment (such as a warehouse with multiple levels of racks or shelves, or a multi-roomed or multi-story building) where networking infrastructure and actively radiating tracking devices are costly to install and difficult to maintain. For example, an asset tracking device that is frequently turning on and off a radio frequency (RF) transmitter demands high energy usage and thus frequent battery charging and/or replacement. In addition, such systems require placement of receiving and transmitting equipment within the spatial environment with special attention to the frequency and bandwidth of the RF communication channels.
0007Furthermore, spatial environments can change over time, due to the addition of walls and doors, equipment failure, communication infrastructure changes, and/or placement of RF-blocking objects or “Faraday cage” type obstacles in the RF signal path of active RF transmitting object location. Changes in the spatial environment or infrastructure can impede the reliability of object location that uses active RF transmitting approaches.
0008It is known to use the Bluetooth Low Energy (BLE) radio technology embedded into radio beacons for purposes of indoor location applications. BLE technology is easy to deploy, relatively low cost, and enjoys wide support on consumer devices such as headphones, audio speakers, keyboards, home automation, and the like.
0009Some known location applications implement co-ordinate location estimated by radio “fingerprinting” techniques applied to Received Signal Strength Indicator (RSSI) data values received from BLE beacons. Fingerprinting techniques involve the determination of specific identifying properties about the BLE signals based solely on the strength of multiple signals received by a device (such as a consumer cellphone) that possesses a BLE receiver. Although fingerprinting techniques allow a crude triangulation type location of a device, fingerprinting techniques are susceptible to changes in the RF environment that affect the unique “signature” or fingerprint of a group of BLE beacons. In other words, if a BLE beacon used for radiolocation is moved, or fails, or is subjected to interference from external RF sources, or is obstructed by metallic objects or “Faraday cage” type obstacles in the signal path from a BLE beacon to a BLE receiver.
0010More recent radiolocation systems involve the use of artificial intelligence (AI), machine learning approaches to “learn” an environment and adapt to certain changes. For example, the paper by Wen et al., “Indoor localization algorithm based an artificial neural network and radio-frequency identification reference tags”, <i>Advances in Mechanical Engineering</i>, Vol. 10(12) 1-12 (2018), describes an indoor radio-frequency identification localization algorithm based on received signal strength indication (RSSI) technology from a plurality of reference tags containing RF transmitters; the coordinates of the reference tags are known. By comparing different RSSI values between tracking tags and reference tags, the coordinate values of tracking tags can be estimated. The Wen et al. paper proposes using the RSSI value of reference tags and the actual known coordinates of reference tags to train an artificial neural network (ANN) to determine tracking tag location, in particular involving “back propagation” (BP) characteristics of radio signals from the tags to adjust for changes in the RF environment.
0011However, the Wen et al. system involves placing a large number of RFID reference tags into an array in a space, e.g., shelves in a warehouse, placing similar RFID tracking tags on objects to be located in the space, and using multiple readers to interrogate the reference tags and tracking tags. The system involves detecting multi-path reflections (back propagation) of signals from the tags and using a neural network on data representing multi-path effects to obtain high location accuracy. Although a system described in this paper might be able to provide location to a significant degree of precision, such accuracy is unnecessary for many applications and leads to significant additional costs of infrastructure.
0012There is significant recent artificial intelligence (AI)/machine learning (ML) research on the use of “classification algorithms” for analyzing a set of data items for certain predetermined characteristics, training a database or “data model” to classify data items as having, or not having, those characteristics, and then processing a new data item based on the trained data model to decide whether the new data item has or does not have the identified characteristics. For example, there are known AI/ML systems that process data items consisting of photographs of cats or dogs, and then can, with a high degree of accuracy, classify a new photograph as containing, or not containing, a cat or dog. Such classification algorithms are typically somewhat binary in nature, i.e., they only decide if a data item does or does not have the characteristics, yes or no. The present inventors believe and have determined that such classification algorithms may be useful for radiolocation applications that do not require highly accurate coordinate location determination. For example, the present disclosure relates to determining whether a tracked object is, or is not, within a predefined space, which is believed to be sufficient for many real-world location applications.
0013Accordingly, there is a need for an asset or object location system that makes highly efficient use of battery power, is deployable in large multi-dimensional environments such as warehouses, hospitals, other multi-story buildings, etc. without requiring significant data communications equipment positioning, installation, and maintenance, or large numbers of reference tags, or the need for high accuracy in coordinate-based location. Furthermore, there is a need for an object location system that does not rely on RF fingerprinting for location determination and is adaptable to environmental changes such as beacon repositioning or failure, interference, or Faraday cage type obstacles.
BRIEF SUMMARY
0014Briefly and generally described, and according to one aspect, the present disclosure relates to a system and method for location of objects within an identified subspace within a predefined master space. The system and methods involve detecting radio frequency (RF) signals from identifiable RF signal sources within the master space, building one or more computer models of the subspaces based on RF signal characteristics of the RF signals, receiving RF signals, by, for example, one or more of RF tags, from a transmitting beacon associated with an object to be located, accessing the one or more data models of the subspaces, and providing a predicted location of the object as being in a particular identified subspace. The computer models are machine learning (ML) models.
0015The described system(s) and method(s) are useful for locating objects, such as inventory items in a multi-room, multi-story facility such as a warehouse, factories, storage lot, agricultural facility, medical faculties such as hospitals, and the like.
0016More particularly described, but without limitation except as expressed in the claims, the system and methods provide for location of objects within an identified subspace of a plurality of subspaces defined within a predefined master space. According to an aspect, any type of identifiable RF signal source (IRFSS) whose signal can be operatively detected within the master space may be used in constructing an RF model of the master space. According to one aspect, a plurality of radio frequency (RF) tags are positioned in a predetermined arrangement such that RF energy from one or more of the RF beacons is receivable (i.e. operatively detectable) within the predefined master space and one or more of the subspaces. The RF tag includes (i) an electronic tag identifier, (ii) a tag receiver operative to receive RF beacon signals from the one or more RF beacons as one of more the beacons assume a position within the predefined master space, (iii) a tag data package assembler, and (iv) a tag transmitter operative to transmit a tag data package assembled by the tag data package assembler. Each of the RF beacons transmits an RF beacon signal at a predetermined frequency or set of frequencies and has a beacon identifier.
0017According to a related aspect, existing sources of identifiable RF transmissions such as existing WiFi access points, Bluetooth beacons, nearby cellular base stations, or other RF sources whose signals can be operatively detected within the master space and subspaces may be used in constructing an RF model of the master space. For example, such other types of IRFSS may be identified by characteristics other than a predetermined beacon identifier, such as the frequency of the signal itself, the frequency of a carrier signal e.g., from an AM/FM/broadcast television station, the known characteristics of a cellular/mobile telephone communication tower or antenna, or other metadata (identifying data) that typically accompany RF transmissions from various known sources. In some implementations, for example, the RF signal sources may include a Bluetooth Low Energy (BLE) beacon, Wi-Fi (IEEE 802.11) access point, Zigbee access point, Bluetooth transmitter, cellular network transmitter (2G-5G and beyond), and/or a shortwave transmitter.
0018According to an aspect, an RF transmitting beacon is placed into proximate association with an object to be located in the master space. The RF beacon transmits an RF beacon signal at a predetermined frequency or set of frequencies and has a beacon identifier. The RF beacon includes (i) an electronic beacon identifier, (ii) a beacon receiver operative to receive RF signals from one or more of the RF signal sources, (iii) a beacon data package assembler, and (iv) a beacon transmitter operative to transmit a beacon data package assembled by the beacon data package assembler. According to an aspect, the RF beacon includes a motion sensor such that the RF tag transmits the tag data package in response to detection with the motion sensor that the RF beacon has stopped movement. In some implementations, the RF beacon includes a signaling component configured to be actuated by a user communication device so as to execute a “last ten feet” proximity operation to notify a user of proximity to the RF beacon with the signaling component when the user communication device approaches the RF beacon.
0019The RF signals employed to construct the computer models may be obtained from preplaced RF beacons, preplaced RF tags, or from other identifiable RF signal sources (IRFSS). According to some implementations, the location engine accesses the ML model trained by performing a survey of RF signals received from the plurality of RF signal sources during a prior RF master space survey operation. In some aspects, the location engine further determines a subspace identifier corresponding to a predicted subspace location for the object by comparing the identification of signals included in the received tag data package to a model plurality of signals accessed from the ML model. The ML models can be dynamically updated with additional RF data in response to physical changes in the environment, failure or changes to the RF signal sources, addition of new IRFSS, or other changes. For example, the ML model can be updated in response to at least one of (i) a user intervention to correct an erroneous prediction of the subspace location for the object, (ii) a successful object location operation, or (iii) receiving scanned data from other additional sources providing data different from data in the transmitted tag data package. According to one aspect, the computer models are created and maintained with a Support Vector Machine (SVM).
0020According to an aspect, an object location system includes a radio gateway comprising one or more radio receivers for receiving tag data packages transmitted by the RF transmitting and receiving tags. The system also includes a computer-implemented object location engine coupled to the radio gateway. The object location system is operative for various functions, including:
0021(a) For a predefined master space in which an object is to be located, in a master space survey operation, assigning a plurality of subspace identifiers to a plurality of subspaces having specific spatial boundaries within the master space and storing the subspace identifiers in a master space database for later association with RF signal data samples taken in a master space survey operation.
0022(b) Receiving data generated by a master space survey operation, represented by RF signal data samples collected within the master space, generating one or more subspace data models from the RF signal data samples for use in connection with an object location operation, and storing the one or more subspace data models in a models database.
0023(c) For an object location operation to locate an object associated with a particular RF beacon within a to-be-identified subspace within the master space, receiving RF signals at the tag receiver from one or more of the RF beacons within the to-be-identified subspace within the master space, to thereby obtain a beacon-specific RF tag signal reading data comprising data derived from one or more RF tag signals and their associated tag identifiers within the to-be-identified subspace.
0024(d) At the tag data package assembler associated with the particular RF tag, using the RF tag signal reading data, generating a tag data package comprising (i) a tag identifier of the particular RF tag, (ii) data associated with the RF beacon signals received from the RF beacon placed in proximate association with an object to be located in the master space, and (iii) the beacon identifier(s) associated with the RF beacons from which the tag receiver received RF beacon signals.
0025(e) At the particular RF tag, transmitting the tag data package from the tag data package assembler via the tag transmitter of the RF tag. According to one aspect, the tag data package is compressed prior to transmission.
0026(f) Receiving a transmitted tag data package from the tag transmitter of the particular RF tag at a gateway radio receiver located so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space. In some implementations, the identification of signals received by one or more of the RF tags from at least one of the RF beacon or the plurality of RF signal sources includes an RF signal source identifier and RF signal data samples in a form of Received Signal Strength Indicator (RSSI) data.
0027(g) Processing a tag data package received by a receiver associated with the radio gateway to extract the RF beacon signals (received by the tag receiver in the particular RF tag) corresponding to the RF beacon associated with the object to be located in the to-be-identified subspace, the beacon identifiers, and the tag identifiers associated therewith.
0028(h) Retrieving one or more stored subspace data models from the models database based on one or more beacon identifiers (contained in the tag data package received from the tag) corresponding to the beacon associated with the object to be located.
0029(i) Executing the retrieved one or more stored subspace data models using as input parameters the RF beacon signals (included in the tag data package received from the tag) corresponding to the beacon associated with the object to be located, to identify one or more prediction candidates of subspaces in which the object may be located, each prediction candidate comprising a subspace identifier produced by execution of each of the subspace data models.
0030(j) Processing the one or more prediction candidates with a selection operation to determine a particular one of the subspace identifiers as the selected subspace identifier in which the object is predicted by the system to be located and thereby generate a determined subspace identifier for the object. In some implementations, each of the plurality of subspaces is associated with a plurality of subspace data models, wherein the system is configured to generate a plurality of prediction candidates of subspaces, in which the object may be located from a plurality of data models for each object location operation. According to an aspect, the object location operation comprises determining the identified subspace for the object based on a voting algorithm executed on the plurality of prediction candidates.
0031(k) Based on the determined subspace identifier, providing a data output from the object location system as a data package identifying the particular beacon and the determined subspace identifier to an external system, as indicating the location of the object associated with the beacon.
0032According to an aspect, the identified subspace is a physical subspace defined by physical boundaries including but not limited to as walls, ceiling, floors, and the like. The identified subspace can also be virtual subspace defined by virtual boundaries within one or more physical rooms.
0033Advantageously, and according to one aspect, a system and methods as disclosed herein provides for subspace or “room-level” indoor object position location and tracking with high accuracy. Furthermore, such a system and methods minimize the infrastructure cost and deployment, as compared to active location systems.
0034Advantageously, and according to another aspect, a system and methods as disclosed herein minimizes maintenance cost by adapting to changes in the physical environment by using continuous or active reinforcement of position determination by machine learning (ML) from location data generated by each incident of location of an object.
0035Advantageously, and according to yet another aspect, a system and methods as disclosed herein facilitate improved object location by using continuous or active reinforcement of position determination by machine learning (ML) from location data generated from one or more stationary or “reference” objects (such as objects with RF beacons) or other transmitters whose positions do not change in spite of deliberate or inadvertent changes to the environment from room reconfiguration, Faraday obstacles, equipment failure (e.g. of one or more RF tags), or other changes that may affect the RF environment. In such other aspect, such reference objects and/or transmitters are used in conjunction with preplaced tags.
0036These and other aspects, features, and benefits of the claimed invention(s) will become apparent from the following detailed written description of the preferred embodiments and aspects taken in conjunction with the following drawings, although variations and modifications thereto may be effected without departing from the spirit and scope of the novel concepts of the disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
0037The accompanying drawings illustrate one or more embodiments and/or aspects of the disclosure and, together with the written description, serve to explain the principles of the disclosure. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like elements of an embodiment, and wherein:
0038<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates a simplified exemplary master space comprising multiple zones or “virtual rooms” or subspaces in which an object is to be located in accordance with aspects of this disclosure.
0039<figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>1</b></figref> in a perspective three-dimensional (3D) view to show multidimensional aspects.
0040<figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>1</b></figref> to show a scanning or survey operation to obtain RF data samples from beacons deployed in the master space.
0041<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>1</b></figref> to show how a stationary object and tag are used according to one aspect to improve or enhance an object location operation.
0042<figref idref="DRAWINGS">FIG. <b>5</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>1</b></figref> to show an altered RF environment and how such an altered RF environment might affect the location of an object.
0043<figref idref="DRAWINGS">FIG. <b>6</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>1</b></figref> to show the presence of multiple types of identifiable RF signal sources (IRFSS), including sources not limited to beacons, for use in object location operations.
0044<figref idref="DRAWINGS">FIG. <b>7</b></figref> is a block diagram of an object location system according to major aspects of the present disclosure.
0045<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates the components of a dual mode RF tag according to one aspect of the present disclosure.
0046<figref idref="DRAWINGS">FIG. <b>9</b></figref> illustrates the components of an alternative dual mode RF tag according to another aspect of the present disclosure, especially for use in “last ten feet” detection of an object.
0047<figref idref="DRAWINGS">FIG. <b>10</b></figref> illustrates the architecture of an object location engine and location services of an object location system according to the present disclosure.
0048<figref idref="DRAWINGS">FIG. <b>11</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>11</b>A-<b>11</b>C</figref>, illustrates exemplary training data of RF signal samples, object location prediction data, and object location data updating and model reinforcement used for training a machine learning (ML) aspect of the present disclosure.
0049<figref idref="DRAWINGS">FIG. <b>12</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>12</b>A-<b>12</b>D</figref>, illustrates another exemplary survey, training, and model construction data, used for training a machine learning (ML) aspect of the present disclosure.
0050<figref idref="DRAWINGS">FIG. <b>13</b></figref> is a high-level flow chart of a system and methods for master space modeling and object location prediction according to an aspect of the present disclosure.
0051<figref idref="DRAWINGS">FIG. <b>14</b></figref> is a flow chart of a computer-implemented master space survey process according to an aspect of the present disclosure.
0052<figref idref="DRAWINGS">FIG. <b>15</b></figref> is a flow chart of further aspects of a computer-implemented survey data pre-processing process according to an aspect of the present disclosure.
0053<figref idref="DRAWINGS">FIG. <b>16</b></figref> is a flow chart of a machine-learning (ML) model training process according to an aspect of the present disclosure.
0054<figref idref="DRAWINGS">FIG. <b>17</b></figref> is a flow chart of a computer-implemented object location process according to an aspect of the present disclosure.
0055<figref idref="DRAWINGS">FIG. <b>18</b></figref> illustrates a simplified exemplary master space comprising multiple zones or “virtual rooms” or subspaces in which an object is to be located in accordance with aspects of this disclosure.
0056<figref idref="DRAWINGS">FIG. <b>19</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>18</b></figref> in a perspective three-dimensional (3D) view to show multidimensional aspects.
0057<figref idref="DRAWINGS">FIG. <b>20</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>18</b></figref> to show a scanning or survey operation to obtain RF data samples from tags deployed in the master space.
0058<figref idref="DRAWINGS">FIG. <b>21</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>18</b></figref> to show how a stationary object and beacon are used according to one aspect to improve or enhance an object location operation.
0059<figref idref="DRAWINGS">FIG. <b>22</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>18</b></figref> to show an altered RF environment and how such an altered RF environment might affect the location of an object.
0060<figref idref="DRAWINGS">FIG. <b>23</b></figref> illustrates the exemplary master space of <figref idref="DRAWINGS">FIG. <b>18</b></figref> to show the presence of multiple types of identifiable RF signal sources (IRFSS), including sources not limited to tags, for use in object location operations.
0061<figref idref="DRAWINGS">FIG. <b>24</b></figref> is a block diagram of an object location system according to major aspects of the present disclosure.
0062<figref idref="DRAWINGS">FIG. <b>25</b></figref> illustrates the components of a dual mode RF tag according to one aspect of the present disclosure.
0063<figref idref="DRAWINGS">FIG. <b>26</b></figref> illustrates the components of an alternative dual mode RF tag according to another aspect of the present disclosure, especially for use in “last ten feet” detection of an object.
0064<figref idref="DRAWINGS">FIG. <b>27</b></figref> illustrates the architecture of an object location engine and location services of an object location system according to the present disclosure.
0065<figref idref="DRAWINGS">FIG. <b>28</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>28</b>A-<b>28</b>C</figref>, illustrates exemplary training data of RF signal samples, object location prediction data, and object location data updating and model reinforcement used for training a machine learning (ML) aspect of the present disclosure.
0066<figref idref="DRAWINGS">FIG. <b>29</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>29</b>A-<b>29</b>D</figref>, illustrates another exemplary survey, training, and model construction data, used for training a machine learning (ML) aspect of the present disclosure.
0067<figref idref="DRAWINGS">FIG. <b>30</b></figref> is a high-level flow chart of a system and methods for master space modeling and object location prediction according to an aspect of the present disclosure.
0068<figref idref="DRAWINGS">FIG. <b>31</b></figref> is a flow chart of a computer-implemented master space survey process according to an aspect of the present disclosure.
0069<figref idref="DRAWINGS">FIG. <b>32</b></figref> is a flow chart of further aspects of a computer-implemented survey data pre-processing process according to an aspect of the present disclosure.
0070<figref idref="DRAWINGS">FIG. <b>33</b></figref> is a flow chart of a machine-learning (ML) model training process according to an aspect of the present disclosure.
0071<figref idref="DRAWINGS">FIG. <b>34</b></figref> is a flow chart of a computer-implemented object location process according to an aspect of the present disclosure.
DETAILED DESCRIPTION
0072For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will, nevertheless, be understood that no limitation of the scope of the disclosure is thereby intended; any alterations and further modifications of the described or illustrated embodiments, and any further applications of the principles of the disclosure as illustrated therein are contemplated as would normally occur to one skilled in the art to which the disclosure relates. All limitations of scope should be determined in accordance with and as expressed in the claims.
0073Aspects of the present disclosure generally relate to systems and methods for location of objects within predefined zones (subspaces or rooms) within a larger master space, using radio frequency (RF) signals transmitted by prepositioned beacons that are received by tags that include RF beacon receivers and a transmitter that communicates with an object location system by transmitting an object location data package containing RF signal data corresponding to the RF beacons whose signals are detectable within the zone (area, room, subspace). These RF signal data are used to invoke a machine-learning (ML) zone prediction of a specific subspace or room within the master space that is likely, within predetermined parameters, to contain the object and its associated tag.
0074In other implementations, aspects of the present disclosure generally relate to systems and methods for location of objects within predefined zones (subspaces or rooms) within a larger master space, using radio frequency (RF) signals transmitted by prepositioned tags (the RF signals are transmitted by RF beacon transmitters) as well as a tag transmitter that communicates with an object location system by transmitting an object location data package containing RF signal data corresponding to the RF tags receiving beacon signals that are detectable within the zone (area, room, subspace). These RF signal data are used to invoke a machine-learning (ML) zone prediction of a specific subspace or room within the master space that is likely, within predetermined parameters, to contain the object and its associated beacon.
GLOSSARY
0075Prior to a detailed description of this disclosure, the following glossary of terms and definitions therefor are provided as an aid to understanding the subject matter and terminology of aspects of the present systems and methods, are exemplary, and not necessarily limiting of the aspects of the systems and methods, which are expressed in the claims. Whether or not a term is capitalized is not considered definitive or limiting of the meaning of a term. As used in this document, a capitalized term shall have the same meaning as an uncapitalized term, unless the context of the usage specifically indicates that a more restrictive meaning for the capitalized term is intended. However, the capitalization or lack thereof within the remainder of this document is not intended to be necessarily limiting unless the context clearly indicates that such limitation is intended.
0076Beacon: a device that transmits a RF signal containing identity and other information used in asset tracking, wayfinding and proximity marketing; synonymous with RF beacon; RF beacons are placed at various locations within a master space so as to illuminate the master space and its subspaces with detectable RF energy in accordance with this disclosure so as to facilitate object location; a plurality of beacons are utilized in accordance with this disclosure, with each of the plurality of beacons transmitting an RF beacon signal at a predetermined magnitude and frequency and having a unique beacon identifier. The RF beacon may include one processor or multiple processors.
0077Beacon in another implementation: a device that transmits a RF signal containing identity and other information used in asset tracking, wayfinding and proximity marketing; synonymous with RF beacon; RF beacons are placed on various objects disposed within a master space so as to illuminate the master space and its subspaces with detectable RF energy in accordance with this disclosure so as to facilitate object location; a plurality of beacons are utilized in accordance with this disclosure, with each of the plurality of beacons transmitting an RF beacon signal at a predetermined magnitude and frequency and having a unique beacon identifier.
0078Beacon identifier: a unique data item associated with each of a plurality of RF beacons; a beacon identifier is typically transmitted with the signal from the RF beacon in a predetermined modulation scheme so that a signal detected from an RF beacon can be distinguished from other RF beacons that may also illuminate the same subspace; a beacon identifier is considered a part of the RF data collected by receiving and processing signals from RF beacons during a sampling, surveying, or object location operation; may be implemented with a MAC address.
0079BLE: Bluetooth Low Energy, a data communication standard that employs multiple channels in a predetermined frequency band so as to facilitate RF communications protocols such as use of multiple devices in an area of coverage, uplink and downlink communications, frequency hopping, interference avoidance, and other technical features.
0080Data Model: a set of data items of predetermined types that represent a conceptual entity and are stored in a computer database; in accordance with this disclosure, a data model is a set of data items obtained from a surveying operation, a sampling operation, and/or execution of machine learning or similar artificial intelligence algorithms for the purpose of representing a master space, a set of subspaces, and objects that are located within a subspace, whose locations are provided to an external system in accordance with aspects of this disclosure; in particular, an SVM data model.
0081Dual mode beacon: a beacon that uses both a RF sensing and a RF communication system for asset location.
0082Dual mode tag: a tag that uses both a RF sensing and a RF communication system for asset location.
0083Gateway: Synonymous with “radio gateway” or “location receiver”; a device or system or interface that receives transmissions from tags and/or other source of RF signals, and relays the received signals and related information to an application; in accordance with an aspect of this disclosure, certain software-implemented elements of a gateway can be implemented on a remotely-located computing and signal processing platform, e.g. “in the cloud.”
0084Identifiable RF Signal Source (IRFSS): a device that transmits an RF signal of sufficient magnitude and frequency to penetrate a master space and can be detected for use in object location as described in this disclosure; an RF signal from an IRFSS is identifiable in the sense that a system as disclosed herein can distinguish characteristics of the signal, such as frequency, RSSI, identification information transmitted with the signal, measured time of flight, directionality, and the like, for use in a data model as described herein. A tag is one form of IRFSS; a beacon is another form of IRFSS; other types may include external RF sources such as Wi-Fi (IEEE 802.11) signals, cellular network signals, AM/FM/shortwave radio signals, global positioning satellites (GPS), and other types of RF signals which are of sufficient strength and identifiability to be used in connection with object location as described herein.
0085Location engine: synonymous with object location engine; a component of the disclosed object location system whose function is to run machine learning models in an object location operation.
0086Machine learning (ML): a computer-implemented data processing operation that processes data from a training database so as permit subsequent data processing operation to render a computational result that reflects predetermined and “learned” characteristics of the data forming the training database and improves the computational result with repeated iterations of the computations using additional sets of data; machine learning is a broad field of computer science that includes many different algorithms for processing the training database and arriving at computational results that reflect such learning; machine learning is generally considered a form or species of “artificial intelligence”, which is a broader type of data processing operation that is considered to emulate aspects of human intelligence; a support vector machine (SVM) is considered a species of machine learning.
0087Master space: a predefined region or area, preferably multi-dimensional such as three-dimensional (3D) in which an object is to be located; the master space is subdivided into smaller, predefined units or “subspaces” in accordance with aspects of this disclosure.
0088Master space survey operation: a process or operation, whether automated or manual, for exploring, physically or virtually, a master space so as to determine its spatial boundaries and determine a logical arrangement of rooms or subspaces, within which objects are to be located; a master space survey operation results in assignment of subspace identifiers; a master space survey operation may be conducted manually by workers (people) with measuring equipment for defining actual and/or virtual boundaries, or in an automated manner by mobile equipment such as drones, robots, etc. that inspect the master space, determine boundaries, and assign subspace identifiers based on characteristics within the master space such as doors, stairs, walls, windows, shelves, cabinets, or other types of physical barriers or delimiting features within the master space.
0089Master space database: a computer-implemented database for storing, processing, and retrieving data items associated with the master space including but not limited to a master space identifier or name, subspace identifiers, features about the master space and/or subspace, the values of RF signals detected within the master space and/or its subspaces, and any other data items deemed useful in locating objects within the master space.
0090Object: anything (thing, person, or other physical entity) whose location within a master space is to be identified and provided for some useful purpose, e.g. locating a package object with a warehouse, locating a fire engine object within a few city blocks, locating a person within a building, etc. An object must be able to carry an RF tag within a master space in accordance with this disclosure in order to be located. In another implementation, an object must be able to carry an RF beacon within a master space in accordance with this disclosure in order to be located.
0091Object location operation: a process of the object location system for locating an object within a master space by determining a prediction candidate comprising predicted location of an object associated with an RF tag as disclosed herein, typically by executing one or more machine learning data models on a received tag data package.
0092Object location operation in another implementation: a process of the object location system for locating an object within a master space by determining a prediction candidate comprising predicted location of an object associated with an RF beacon as disclosed herein, typically by executing one or more machine learning data models on a received tag data package.
0093Object location system (OLS): a computer-implemented system that includes one or more databases, in particular a sampling database, a master space database, one or more data models; one or more RF receivers configured to receive signals transmitted by RF tags; user interface to allow operators to configure and operate the system; an output that provides information about an object to be located and its characteristics; such an object location system is constructed in accordance with aspects of this disclosure; synonymous with object locator system.
0094Object location data package: a collection of information relating to a particular object located in accordance with aspects of this disclosure, typically comprising an object identifier, an RF tag identifier, a subspace or room identifier, and other possibly relevant information such as a time stamp, one or more beacon identifiers that were involved in locating the object.
0095Object location data package in another implementation: a collection of information relating to a particular object located in accordance with aspects of this disclosure, typically comprising an object identifier, an RF beacon identifier, a subspace or room identifier, and other possibly relevant information such as a time stamp, one or more tag identifiers that were involved in locating the object.
0096Prediction candidate: a set of one or more potential subspaces within which an object to be located may actually be located; prediction candidates are typically represented by subspace identifiers in accordance with some aspects of this disclosure.
0097RF tag: a device attached to an object or other asset that is used to determine its location. RF tag is an electronic device that transmits and receives RF signals for the purpose of locating an object to which the tag is affixed in some form or fashion. The RF tag may include one processor or multiple processors. RF tag is generally synonymous with a tag.
0098RF tag in an alternative embodiment: an electronic device that transmits and receives RF signals for the purpose of locating an object to which the beacon is affixed in some form or fashion. An RF tag typically possesses a power source, an RF tag transmitter for transmitting a tag data package, and RF tag receiver operative for detecting and receiving RF beacon signals from one or more RF beacons, and an electronic tag identifier that is provided as a part of a tag data package.
0099RF tag identifier: a unique data item associated with each of a plurality of RF tags; a tag identifier is typically transmitted with the signal from the RF tag in a predetermined modulation scheme so that a signal detected from an RF tag can be distinguished from other RF tags that may also communicate in the same subspace; a tag identifier is considered a part of the RF data collected by receiving and processing signals from RF tags during a sampling, surveying, or object location operation; may be implemented with a MAC address.
0100Room: generally synonymous with “subspace” (or zone, area); a room may be a predefined area or region within the master space having spatial boundaries; a room need not have actual physical boundaries; a room or subspace may have actual physical boundaries, virtual boundaries, or a combination of actual physical and virtual boundaries.
0101RSSI: “Received Signal Strength Indicator”—a measurement of the power of an RF signal into a receiver; may be reported in dBm or arbitrary units.
0102RTLS: “Real-Time Location Service”—denotes a system and/or service for location of object on a real-time basis, often indoors; real-time typically means virtually instantaneously, within a predetermined response time suitable for an application in which a user is desiring to make use of the location for some immediate purpose, e.g. to communicate with the object, retrieve the object, update a database of information relating to the object or its use, etc.
0103Sampling database: a computer-implemented database for storing, processing, and retrieving data items associated with a sampling operation, thereby generating a map of a master space and the specific values of data items obtained during a sampling operation including beacon identifiers, subspace identifiers, detected RF frequencies, signal strengths, etc.
0104Sampling database in another implementation: a computer-implemented database for storing, process, and retrieving data items associated with a sampling operation, thereby generating a map of a master space and the specific values of data items obtained during a sampling operation including tag identifiers, subspace identifiers, detected RF frequencies, signal strengths, etc.
0105Sampling operation: a process or operation, whether automated or manual, wherein one or more RF beacon signals and their accompanying RF data are detected by receivers so as to obtain a set of RF data samples at a particular subspace; a survey is conducted with a sampling operation.
0106Sampling operation in another implementation: a process or operation, whether automated or manual, wherein one or more RF tag signals and their accompanying RF data are detected by receivers so as to obtain a set of RF data samples at a particular subspace; a survey is conducted with a sampling operation.
0107Scan: a process of receiving RSSI and identifying data from RF sources like beacons; typically involves use of an RF receiving device that is transported throughout a master space collecting RSSI samples and/or frequency data and storing them in a sampling database for use in constructing a data model; a scan may also be considered an instance of data comprising a set of data samples, e.g. a set of RSSI values collected at a point in time; as context herein may suggest, the term “scan” may also reference the data received from an RF tag (tag data package) in connection with an object location operation.
0108Scan in another implementation: a process of receiving RSSI and identifying data from RF sources like tags; typically involves use of an RF receiving device that is transported throughout a master space collecting RSSI samples and/or frequency data and storing them in a sampling database for use in constructing a data model; a scan may also be considered an instance of data comprising a set of data samples, e.g. a set of RSSI values collected at a point in time; as context herein may suggest, the term “scan” may also reference the data received from an RF tag (tag data package) in connection with an object location operation.
0109SVM: “Support Vector Machine”; in machine learning, support-vector machines are supervised learning models with associated learning algorithms that analyze data used for classification and regression analysis; SVM is considered a species of artificial intelligence (AI); SVM is particularly useful for addressing data classification problems, e.g. by classifying a data item into a set based on characteristics of the data, especially as compared with a training data set of similar data.
0110Survey: generally synonymous with Scan, above; a sampling operation conducted for constructing a data model; in particular a sampling operation involving collecting a set of scans (data samples) from a plurality of RF beacons, within predefined subspaces or rooms within a master space; typically conducted for purposes of establishing and training a data model, e.g. an SVM data model.
0111Survey in another implementation: generally synonymous with Scan, above; a sampling operation conducted for constructing a data model; in particular a sampling operation involving collecting a set of scans (data samples) from a plurality of RF tags, within predefined subspaces or rooms within a master space; typically conducted for purposes of establishing and training a data model, e.g., an SVM data model.
0112Subspace: generally synonymous with “room” (or area or zone); a subspace may be a predefined area or region within the master space having spatial boundaries; a subspace need not have actual physical boundaries; a room or subspace may have actual physical boundaries, virtual boundaries, or a combination of actual physical and virtual boundaries.
0113Subspace identifier: a data item associated with a predefined subspace; a subspace identifier is used to uniquely identify a particular subspace and differentiate it from other subspaces within the master space.
0114Tag data package: a collection of data collected by an RF tag comprising one or more data items such as (i) a tag identifier of the particular RF tag, (ii) data (e.g. RSSI data, frequency data) associated with the RF beacon signals received from one or more RF beacons within a subspace that is to be identified, and/or (iii) the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals; may also include other identifying information from other identifiable RF signal sources (IRFSS), e.g. frequency, accompanying metadata, RSSI, etc.
0115Tag data package in another implementation: a collection of data collected by an RF tag comprising one or more data items such as (i) a tag identifier of the particular RF tag, (ii) data (e.g. RSSI data, frequency data) associated with the RF beacon signals received from one or more RF beacons placed in proximate association with one or more objects within one or more subspaces that are to be identified, and/or (iii) the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals; may also include other identifying information from other identifiable RF signal sources (IRFSS), e.g. frequency, accompanying metadata, RSSI, etc.
0116Virtual Room (VR): a subspace that does not have actual physical boundaries but has boundaries of a predetermined dimensions that may not coincide with any physical boundaries such as walls, floors, ceilings, etc.; a virtual room can encompass a space within a larger space or subspace, or may also encompass a space that subsumes or encapsulates one or more actual physical spaces.
0117Zone: synonymous with area, room, and subspace.
0000Object Location System—Environment Overview
0118<figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates aspects of deployment of an object location system <b>10</b> and associated methods, constructed and operated as described in this disclosure, for purposes of locating one or more exemplary objects <b>20</b> (e.g., <b>20</b><i>a</i>, <b>20</b><i>b</i>) that are each associated with an RF tag <b>25</b> (e.g., <b>25</b><i>a</i>, <b>25</b><i>b</i>), according to one initial aspect. <figref idref="DRAWINGS">FIG. <b>1</b></figref> shows an exemplary spatial environment such as a multi-story building <b>30</b> that is considered a “master space.” The building or master space <b>30</b> is typically three-dimensional (3D) and comprises a plurality of subspaces or rooms identified as Room A, Room B, Room C, and Room D. It will of course be appreciated that the number of rooms or subspaces is arbitrary and can vary. The subspaces or rooms can be actual physical rooms defined by physical barriers such as floors, walls, ceiling, or can be virtual rooms with virtual boundaries. A virtual room can encompass more than one physical room or can define a smaller subspace within a physical room. For example, Room A in <figref idref="DRAWINGS">FIG. <b>1</b></figref> is a virtual room that extends across two physical rooms, Room <b>1</b> (R<b>1</b>) and Room <b>2</b> (R<b>2</b>), which are separated by a wall (W). Room C is a virtual room within Room <b>2</b> and shares the physical space with Room A. Room B on the other hand is solely contained within physical Room <b>3</b> (R<b>3</b>), as is Room D is physically the same as Room <b>4</b> (R<b>4</b>).
0119In accordance with one aspect of this disclosure, the master space <b>30</b> is preconfigured with installation of a plurality of RF beacons identified as B<b>1</b>-B<b>5</b>, for example, dispersed throughout the master space so as to irradiate the space and contained subspaces or rooms with RF energy from the beacons. The RF beacons are constructed as described elsewhere herein. The RF beacons are preferably distributed so that each position within the master space receives at least one signal from at least one beacon, and preferably such that each position receives signals from multiple beacons.
0120In accordance with a preferred aspect, the beacons B employed in disclosed embodiments are Bluetooth Low Energy (BLE) radio beacons that are prepositioned within the master space at predetermined strategic locations, for purposes of transmitting BLE signals from a plurality of beacons into each room or subspace of the master space. One example of a beacon that may be used in accordance with aspects of this disclosure is the HO Indoor Beacon manufactured by Shenzhen Minew Technologies Co. Ltd., Shenzhen, China, also known as Minew Tech, details of which are available from the manufacturer. Other similar devices may also be used.
0121It is preferred that a plurality of beacons will be disposed throughout the master space, spaced apart such that each room or subspace will be irradiated/illuminated by RF energy of sufficient magnitude such that an RF tag, as described herein, will receive RF beacon signals from at least one beacon, and preferably from a plurality of beacons, and preferably at least two beacons. Signals from more than about 4-6 beacons may impact the performance and response time of a location operation, although some applications may require or prefer a larger number of beacons.
0122According to one aspect, the beacons B transmit their beacon signals on a predetermined basis, established by the system operator. The beacons may be configured to transmit on a regular basis, such as periodically or on a predetermined timing schedule, or to transmit on demand. In such a system, the beacons could be configured to transmit “on demand”, for example, only during a survey operation, or during an object location operation. An “on demand” configuration requires some type of communication and command structure at the beacon, so that the beacon could receive a signal from the system <b>10</b> containing a command to transmit. A timing schedule requires a time synchronization function at the beacon, so that tags can be in a receive mode at the time that the beacons are transmitting.
0123Although a set of preplaced beacons B are a preferred configuration for a system <b>10</b>, it will be understood that the system may also operate in conjunction with other identifiable RS signal sources (IRFSS). Considerations of using other IRFSS to provide RF samples include the availability of preexisting radio sources, the strength/magnitude of signals from such sources as seen within the master space, the ability of the tags to receive signals from other IRFSS, identifying information or characteristics of the other IRFSS signals that allow use in constructing data models, the stability of such other IRFSS as to movement and signal characteristics, the presence of obstructions to or interference for signals from the IRFSS, and the like. Suitable candidates for other IRFSS include Wi-Fi access points, AM/FM/shortwave/television transmitters in the vicinity of the master space, air navigation beacons, cellular network towers, etc. Other types of RF sources may occur to those skilled in the art.
0124In <figref idref="DRAWINGS">FIG. <b>1</b></figref>, note that tag <b>25</b><i>a </i>associated with object <b>20</b><i>a</i>, in virtual Room A, receives signals from four exemplary beacons: B<b>1</b> B<b>2</b> on the same floor of the master space <b>30</b>, and also from B<b>3</b>, B<b>4</b> on an adjacent but upper floor. Similarly, tag <b>25</b><i>b </i>on object <b>20</b><i>b </i>in Room D receives signals from beacons B<b>2</b>, B<b>4</b>, B<b>5</b>. In accordance with aspects of this disclosure, each tag <b>25</b><i>a</i>, <b>25</b><i>b </i>communicates with the object location system <b>10</b> by transmitting a tag data package, as described elsewhere herein, via a separate RF communication channel, also as described elsewhere, on a predetermined communication basis and protocol. The disclosed object location system then determines the location of the objects <b>20</b> within the master space <b>30</b>, typically by identifying a particular room or subspace that has been determined as containing the object. The object location system typically then provides an object location data package, as described elsewhere herein, via a data communications network <b>40</b>, e.g., the Internet, to customer applications <b>50</b>. Customer applications may vary widely, as determined by a user of the system <b>10</b> that desires to locate and/or track the movement of objects <b>20</b> within the master space.
0125Also shown in <figref idref="DRAWINGS">FIG. <b>1</b></figref> are a number of sample points identified as S<b>1</b>, S<b>2</b>, S<b>3</b>, . . . Sn. In accordance with an aspect of this disclosure, objects are located by use of and reference to a data model of the RF environment of the master space <b>30</b> developed by taking RF signal samples at sample locations S, as described elsewhere herein. The data model of the space is constructed by a survey process involving the collection of RF data samples at various locations within various subspaces within the master space, e.g., samples S<b>1</b>, S<b>2</b>, . . . Sn, typically with RSSI data. Those samples are stored in a sampling database, described elsewhere, and associated with specific identified subspaces. The collection of data samples and associated identified subspaces are processed with a machine learning (ML) algorithm so as to generate a data model that provides the basis for a later determination of an object location. As more fully described elsewhere, a tag data package from an RF tag associated with a particular object to be located is processed by reference to the data model, to generate a prediction candidate of a specific subspace or room in which the tag, and hence the associated object, is most likely to be located. Aspects of the data model, survey operation, etc. are described in more detail below.
0126<figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates the exemplary master space <b>30</b> in a three-dimensional (3D) view, so as to illustrate the multi-room, multi-dimensional aspects of object location, as compared to the more two-dimensional (flat) view in <figref idref="DRAWINGS">FIG. <b>1</b></figref>. <figref idref="DRAWINGS">FIG. <b>2</b></figref> shows the object <b>20</b> and associated RF tag <b>25</b>, located within Room A. The RF tag <b>25</b> receives BLE signals from multiple RF beacons, e.g., B<b>1</b>, B<b>2</b>, B<b>3</b>, B<b>4</b>, as in <figref idref="DRAWINGS">FIG. <b>1</b></figref>. This view illustrates that the beacons B are typically dispersed throughout the master space and need not be in the same room or subspaces as any particular object to be located. Likewise, the beacons may be dispersed on different levels within the master space, provided that, preferably, any location within a subspace in which an object is to be located receives signals from at least one beacon and preferably multiple beacons. Accordingly, and preferably, the signals from the beacons employed in aspects of this disclosure are of sufficient magnitude to cover multiple rooms or subspaces. This contrasts with approaches that use low power or passive RFID tags, which typically have a very limited range.
0127Also as shown in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, the master space <b>30</b> has been sampled by a prior sampling operation or process, as described elsewhere, so that a data model of the 3D space is constructed and utilized for object location, by reference to multiple RSSI samples S<b>1</b>, S<b>2</b>, . . . Sn of the RF environment of the master space and its associated subspaces or rooms.
0128<figref idref="DRAWINGS">FIG. <b>3</b></figref> illustrates a survey process or operation for purposes of collecting RSSI data samples at various sampling locations S<b>1</b>, S<b>2</b>, . . . Sn throughout the master space <b>30</b> and its associated subspaces e.g., Room A, Room B, Room C, Room D, in accordance with aspects of this disclosure. The survey process is typically conducted by a person or a mobile machine (e.g., a robot, drone, or other autonomous mobile machine) that carries an RF scanning or room survey device <b>60</b>. The survey device <b>60</b> comprises a BLE signal receiver (not shown) that receives beacon signals from a number of RF beacons, e.g. from B<b>1</b>, B<b>2</b>, B<b>4</b>, etc., allows entry of data identifying a physical or virtual subspace or room, e.g. Room B in the example of <figref idref="DRAWINGS">FIG. <b>3</b></figref>, and transmits a set of RF signal samples, beacon identifiers, and information used for subspace identification, via a radio transmitter associated with the survey device <b>60</b>, to the object location system. This data is then used for model construction and maintenance. According to another aspect, a survey tool comprising a plurality of RF tags as described herein may be deployed within the master space and subspaces as the survey device <b>60</b>; data obtained from the plurality of RF tags may be used as the survey data.
0129It will be appreciated that the survey device <b>60</b> may also include other RF receivers for purposes of using RF signals from other identifiable RF signal sources (IRFSS), which can also be used in model construction. For example, and as shown elsewhere, RF signals from IEEE 802.11 (Wi-Fi), cellular networks, GPS satellites, AM/FM/shortwave, television, or other known, and typically locationally and carrier-signal stable RF sources, can be used in alternative embodiments. To use such other IRFSS signals, the survey device will require a compatible receiver and associated components and/or software for determining appropriate RF signal characteristics (RSSI) and associating it with identification information about the IRFSS.
0130It will be appreciated that a survey operation typically involves taking RSSI samples at various locations, e.g., S<b>1</b>, S<b>2</b>, . . . Sn within a particular subspace, so as to “visit” and obtain RSSI samples within a variety of different locations, elevations, rooms, near and away from obstacles, etc., so as to create a thorough map of the RF environment illuminated by the plurality of beacons B or other IRFSS. It will also be appreciated that one or more surveys may be conducted to construct a data model, and subsequent surveys may be conducted to update or maintain the data model to compensate for changes in the environment that may result from things such as addition or removal of walls, doors, windows, shelving, roofs, RF shielding/Faraday barriers, stacks of objects, furniture, and any number of things that might affect the transmissibility and reception of RF signals from the beacons or other IRFSS by RF tags associated with objects.
0131<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates a master space <b>30</b> and use of a stationary object <b>20</b><i>b </i>with associated tag <b>25</b><i>b </i>for purposes of data model stabilization or calibration, in accordance with one aspect of the present disclosure. <figref idref="DRAWINGS">FIG. <b>4</b></figref> also illustrates aspects of movement of an object <b>20</b><i>a </i>in Room A to a second position in Room C at <b>20</b><i>a</i>′ for purposes of object tracking within the master space, in a particular application.
0132In accordance with one aspect, the master space may be provided with one or more stationary or “reference” objects and/or tags, positioned at various locations within the master space, within one or more subspaces, actual or virtual. For example, consider that the object <b>20</b><i>b </i>and its associated RF tag <b>25</b><i>b</i>, are positioned within Room D, in a position where it cannot be readily moved. For example, the object and/or tag could be fastened to a wall or floor, or placed in a position that is not readily accessible such as in a special space. The stationary RF tag <b>25</b><i>b </i>need not even be associated with an object, but could represent a “virtual” object, as the primary purpose of a stationary object or tag is to provide object data packages identifying the stationary object and/or tag at various times. This allows the system to monitor for changes in the RF environment that might result from changes to the physical space or placement of objects or Faraday cage type objects within the space that could affect the reception of beacon signals by objects that are to be located.
0133It should be understood that it is not necessary to use stationary objects and/or stationary tags in order to monitor for changes in the RF environment that might result from changes to the physical space or placement of objects or Faraday cage type objects or barriers within the space that could affect the reception of beacon signals by objects that are to be located. In accordance with one preferred aspect of operation, RF tags <b>25</b> as described herein transmit data representing the beacon signals received by such tags on a predetermined basis (e.g., periodically, on demand, etc.) to the object location system <b>10</b> for use in constructing and training data models for object location. Data scans collected from any tags within the master space, whether moving, stationary, or temporarily stationary, provide a corresponding flow of RSSI values that can be used to construct additional data models as described herein and/or update existing models for use in locating objects.
0134According to one aspect, a stationary object <b>20</b><i>b </i>(physical or virtual) and associated stationary tag <b>25</b><i>b </i>may transmit tag data packages at certain predetermined intervals or times to the object location system <b>10</b>. For example, the stationary object data packages may be transmitted at predetermined intervals, e.g., each hour, day, week, etc., or alternatively at particular times on a predetermined schedule, or if the tag is configured to receive a prompt or trigger signal, upon command from the object location system <b>10</b> or from a beacon B. For example, one or more beacons could be configured to transmit a prompt signal on some predetermined basis to one or more tags, and the tags configured to respond on a predetermined basis to transmit a data package, independently of a current location operation.
0135According to another aspect, <figref idref="DRAWINGS">FIG. <b>4</b></figref> also shows the optional use of an auxiliary object location system (OLS) receiver or gateway <b>65</b>, which may be deployed for purposes of collecting tag data packages at various other locations within the master space <b>30</b>. According to this alternative and optional aspect, it will be appreciated that one or more auxiliary OLS receivers <b>65</b> may be deployed within the master space (only one is shown in <figref idref="DRAWINGS">FIG. <b>4</b></figref>) so as to provide for redundancy in receiving signals from RF tags <b>25</b>, in case of failure of a receiver at the OLS system <b>10</b> or signal reception complications that might result from reconfiguration of the master space or its subspaces, or placement of obstacles such as Faraday barrier type obstacles that might affect transmission of signals from the tags to the object location system <b>10</b>.
0136In accordance with one aspect of the present disclosure, a tag <b>25</b><i>b </i>associated with a stationary object <b>20</b><i>b </i>should in most instances receive constant and/or consistent beacon signals from the various beacons which are proximate enough to the stationary object to be reliably received. In the event that the system detects changes in the RSSI of beacon signals received from a stationary tag such as <b>25</b><i>b</i>, the system can take action in compensation. For example, the system can generate an alert to changes in the RF environment. As another example, and preferably, the system can update a data model of the master space in the event of determination that a permanent or persistent change to the RF environment has occurred. This can obviate a further survey of the master space to adjust for environmental changes, beacon failures, etc., or at least allow temporary adjustment in a data model until such time as a re-survey may be desirable.
0137Still referring to <figref idref="DRAWINGS">FIG. <b>4</b></figref>, another aspect of the present disclosure involves the tracking of movement of an object, e.g., object <b>20</b><i>a </i>and its associated RF tag <b>25</b><i>a</i>, from one location to another within the master space. As shown in this figure, assume that the object <b>20</b><i>a </i>and tag <b>25</b><i>a </i>move within Room A (which is virtual in the example discussed) to another physical room on the other side of wall W, but still within Room A, to assume position <b>20</b><i>a</i>′, <b>25</b><i>a</i>′. In accordance with an aspect of this disclosure, movement of an object might trigger a transmission of a tag data package that contains a data item indicating object movement. For example, the preferred RF tag <b>25</b>, as shown in <figref idref="DRAWINGS">FIG. <b>8</b></figref>, includes a motion sensor that detects a predetermined degree of movement of an object. This motion sensor can be used to trigger transmission of a tag data package from the tag so that the object location system <b>10</b> can indicate object movement. Such object movement may be for purposes of following or tracking an object, warning of theft or tampering or handling of an object, etc. According to another aspect, if the object location system is associated with an object location database (not shown), or a customer maintains such an object location database, for the purpose of associating a present location of an object with a particular location, a movement indication could be used to update the database automatically. Such an object location database could be maintained by or in association with the disclosed object location system <b>10</b>, or maintained by a customer who receives object location information from the disclosed object location system for its own private purposes.
0138<figref idref="DRAWINGS">FIG. <b>5</b></figref> illustrates how a change in the RF environment of the master space <b>30</b> may be detected and adjusted for, in accordance with an aspect of this disclosure. <figref idref="DRAWINGS">FIG. <b>5</b></figref> differs from <figref idref="DRAWINGS">FIG. <b>1</b></figref> in that the master space <b>30</b> shows the object <b>20</b><i>a </i>and its associated RF tag <b>25</b> is in the same position in Room A as in <figref idref="DRAWINGS">FIG. <b>1</b></figref> but is partially shielded by a Faraday cage or barrier type object, e.g., an additional wall W<b>2</b> made of metal. Those skilled in the art will understand and appreciate that metal constructions such as walls, screens, boxes, shelving, etc. affect the transmissibility of radio signals of certain frequencies, amplitudes, and modulation schemes. In some instances, the addition or movement of such Faraday cage type object can affect the reception of beacon signals by RF tags, and/or RF signals from IRFSS, whether or not the objects have been moved or handled.
0139As seen in <figref idref="DRAWINGS">FIG. <b>5</b></figref>, compared to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, the RF beacon signals from beacons B<b>1</b> and B<b>3</b> are obstructed by the metal wall W<b>2</b>, which reduces the signal strength from these two beacons as they are received at the RF tag <b>25</b><i>a </i>associated with object <b>20</b><i>a</i>. In some cases, a metal wall or other Faraday cage type object may actually completely block signals at certain frequencies and amplitudes, thereby removing signals from some sources from use in object location, at least until adjustments can be made to a data model.
0140In accordance with one aspect, the disclosed object location system <b>10</b> adjusts to the addition of this and other RF-signal-affecting obstacles or barriers in several different ways. According to one aspect, the addition of the metal wall W<b>2</b> could be detected automatically, especially in cases where one or more stationary objects such as shown in <figref idref="DRAWINGS">FIG. <b>4</b></figref> are utilized, and the altered RF signals from the stationary object are discovered or detected as having changed from a previous transmission from the RF tag associated with the stationary object. The changed RSSI data values from a transmission occurring subsequent to the addition of the wall is added to the data model. In subsequent object location operations, the updated data model will then reflect the changed RF environment and the object can still be reliably located.
0141According to another aspect, the operator of the object location system <b>10</b> is notified of the addition of the obstruction of wall W<b>2</b>, and can re-survey the area affected, e.g., Rooms A and B can be re-surveyed and the data model updated. According to yet another aspect, assume that the object <b>20</b> and its associated RF tag <b>25</b> has previously communicated its location to the object location system, in a prior location operation. The fact of addition of the metal wall W<b>2</b>, or at least the occurrence of some change to the RF environment, is automatically detected by comparing the RSSI signals from a first object location operation (or other tag signal communication) to the signals from a second or subsequent object location operation (or other tag signal communication), and either automatically updating the data model or generating an alert to a system operator of a change in the RF environment that may require a re-survey operation or other remedial action.
0142According to yet another aspect, and also as shown in <figref idref="DRAWINGS">FIG. <b>5</b></figref>, in a similar manner a change in the RF environment may occur in the event of failure or faulty operation of a beacon. For example, note in <figref idref="DRAWINGS">FIG. <b>5</b></figref> that beacon B<b>2</b> in Room C has failed, such that it is not transmitting its RF beacon signal. In this example, object <b>20</b><i>b </i>and its associated RF tag <b>25</b><i>b </i>no longer receives beacon signals from beacon B<b>2</b>, but still receives beacon signals from beacons B<b>4</b> and B<b>5</b>. Likewise, object <b>20</b><i>a </i>and its associated RF tag <b>25</b><i>a </i>no longer receives beacon signals from beacon B<b>2</b>, but still receives beacon signals from beacons B<b>1</b>, B<b>3</b>, and B<b>4</b>. In a manner similar to that described above, the disclosed system adjusts for the loss of signal from beacon B<b>2</b> in various ways as described above, e.g., updating the data model, alerting of the failure of the beacon B<b>2</b>, etc. The detection of the altered RF environment takes place automatically or in response to an alert of the change and possible repair or replacement of the failed beacon B<b>2</b>.
0143In accordance with the above-described aspects of diminished signals from beacons or other IRFSS, or failed beacons, a process of updating and/or reinforcement of a data model can be executed, so that a change in the RF environment of a master space can be dynamically updated for subsequent object location operations. By way of example and not limitation, see the discussion below associated with <figref idref="DRAWINGS">FIG. <b>13</b></figref> as regards data obtained by additional or reinforcement scans.
0000Object Location System
0144Turn now to <figref idref="DRAWINGS">FIG. <b>7</b></figref> for a detailed description of the disclosed object location system <b>10</b>, constructed and operated in accordance with aspects of this disclosure. The disclosed object location system (OLS) <b>10</b> comprises four major components: an object location engine <b>700</b>, a location data gateway <b>710</b>, location services <b>720</b>, and customer services <b>770</b>. Details of these major components are described in more detail below.
0145According to one aspect, the location data gateway <b>710</b> comprises a UHF (ultra-high frequency) radio gateway <b>712</b> for communicating with the disclosed tag <b>25</b>, as well as other location data gateways <b>715</b> for receiving location information from other sources such as other identifiable RF signal sources (IRFSS). Although the RF signals from beacons and from other IRFSS may be different frequencies, bands, magnitudes, RSSI, etc., it will be appreciated that the principles of usage of such signals and their associated identifying data is the same. Thus, the remarks which follow as to operations of a UHF radio gateway <b>712</b> apply also to other location data sources <b>715</b>.
0146The UHF radio gateway <b>712</b> may be constructed using a RadioCloud® UHF radio gateway manufactured by Cognosos, Inc., Atlanta, GA. Details of this UHF radio gateway are available in the literature supplied by the manufacturer.
0147The UHF radio gateway <b>712</b> is configured and operative to receive UHF radio signals transmitted from time to time, or upon demand, from one or more RF tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, . . . <b>25</b><i>n </i>associated with one or more objects <b>20</b><i>a</i>, <b>20</b><i>b</i>, . . . <b>20</b><i>n </i>to be located within a particular subspace or room within a master space <b>30</b>, as shown in prior drawing figures. As discussed previously and elsewhere herein, each of the plurality of RF tags <b>25</b> is operative to receive RF beacon signals from one or more RF beacons B<b>1</b>, B<b>2</b> . . . Bn. Alternatively, or in addition, the RF tags may be configured to receive other RF signals from other IRFSS transmitters. In accordance with one aspect, the UHF radio signals from the tags contain tag data packages from tags associated with object, as described herein. In accordance with another aspect, the radio signals from other IRFSS transmitters are associated with identifying information such as frequency, initial RSSI, directionality, or information or content associated with the signal to allow its identification.
0148The UHF radio gateway <b>712</b> may be positioned within the master space, or alternatively may be configured to connect with remote or “gateway” receivers positioned within or near the master space, and communicate the data packages from the receiver(s) in the radio gateway for demodulation and data package disassembly.
0149According to one aspect, the preferred UHF radio gateway <b>712</b> is operative for receiving one or more transmitted tag data packages, transmitted in a predetermined modulation scheme, from the tag transmitters of one or more RF tags <b>25</b> at one or more gateway receivers (not separately shown) within operative proximity to the master space, so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space. Preferably, the received tag data packages are demodulated by the gateway receivers, either stand-alone receivers or receivers associated with the UHF radio gateway <b>712</b>, and disassembled into the discrete data items forming the data packages. Typically, a tag data package includes data items corresponding to (i) a tag identifier that identifies a particular RF tag, (ii) data representing the RSSI values of all RF beacons whose signals were received by the RF tag, (iii) beacon identifier data items representing the identification of the beacons whose signals were received by a tag, associated with the RSSI values of the signals from each distinct beacon.
0150Alternatively, or in addition, the frequency of the signal received from a beacon may be used as a data item included in the tag data package.
0151As a further alternative, or in addition, data associated with a signal received from one or more IRFSS transmitters may be included as a part of a tag data package or may form an independent tag data package independent of a tag data package from a beacon. For example, an independent tag data package may include, for an IRFSS transmitter signal of a given source, (i) the frequency of the signal, (ii) the RSSI value of the signal, (iii) content transmitted by the IRFSS transmitter that assists in identification of the signal source, (iv) phase, timing, or directionality information derived from the IRFSS relative to receipt of the same signal by other receivers in the system. Any or all of such additional information may be used in aspects of the disclosed system to form data in the data model and used for location of objects that can receive such beacon and/or other IRFSS signals.
0152The object location system <b>10</b> further comprises an object location engine <b>700</b> whose principal function is to generate and maintain one or more data models used in machine learning (ML) of the RF characteristics, among other things, of the master space, allow assignment of subspaces within the master space, and access the ML data models in locating objects. Primarily, and generally speaking, the object location engine <b>700</b> is the computer-implemented component that processes tag data packages received by gateway receiver(s) to extract the RF beacon signals received by the tag receivers in the plurality of RF tags associated with objects to be located in the to-be-identified subspaces, the beacon identifiers, and the tag identifiers associated therewith, so as to provide a specifically identified subspace or room (i.e. a location) for a specific RF tag and its associated object within the master space.
0153The object location engine <b>700</b> comprises several major software-implemented components, for example, an application programming interface (API) gateway for connection to the location data gateway <b>710</b>, a location integration module or service, a packet pre-processing module or service, a rules engine, a model training model or service, a model lookup and prediction module or service, and database storage module or services. Details of these primary components are described in greater detail in connection with other figures. The API gateway for the UHF radio gateway receives signals from the various RF tags during their operation, as well as signals from a surveying device as described above.
0154Still referring to <figref idref="DRAWINGS">FIG. <b>7</b></figref>, the object location engine <b>700</b> provides location information to location services <b>720</b>, primarily in the form of object identifier data, location data, and other associated data such as a timestamp, security information, customer identification information, and any other information that may be useful by customers in connection with object location. Location services <b>720</b> are computer-implemented and may reside within and implemented by the object location system <b>10</b>, or customers may construct their own location applications locally with use of the location data provided by the system <b>10</b>. Location services <b>720</b> can include an API so that a customer (not shown) can communicate via the network <b>40</b> with the object location system <b>10</b>, to provide data such as object identifiers for use by the system <b>10</b> in its location operations, on-demand signals to trigger an RF tag to illuminate an LED or other indicator, or provide an audible sound, to assist in “last ten feet” location or object presence verification.
0155In addition, the location services <b>720</b> provides an abstraction layer over the object location engine <b>700</b>, such that customer services <b>770</b> is decoupled from the specific implementation. For instance, the object location engine <b>700</b> can be further modified, replaced, or augmented by other systems and techniques comprising location services <b>720</b>, for providing alternative, confirming, or supplementary location information for the master space, associated subspaces, and/or objects to be located. Thus, as shown in <figref idref="DRAWINGS">FIG. <b>7</b></figref>, location services can be provided to the network <b>40</b> for use by customer applications <b>780</b> independently of the customer services functions <b>770</b>.
0156Those skilled in the art will understand and appreciate the wide variety of customer applications that can be constructed using the object location information provided in various aspects of this disclosure.
0157Typically, a customer or user of the system <b>10</b> will communicate with the system to conduct object location operations via computer-implemented customer services <b>770</b>. The customer services <b>770</b> comprises a number of communication functions accessed via an application programming interface (API) that allows customers or users to provide its information to the system <b>10</b> and receive outputs indicating object location. Details of customer services are discretionary with users of the system, and will not be further described herein, as aspects of such services will be apparent to those skilled in the art.
0158Also shown in <figref idref="DRAWINGS">FIG. <b>7</b></figref> are several primary databases used by the disclosed object location system <b>10</b> to implement its functions. For example, a survey database <b>730</b> is used to store data obtained during a survey operation, such as RSSI data provided by a survey device <b>60</b> (<figref idref="DRAWINGS">FIG. <b>3</b></figref>) in association with a subspace or room identifier. Data in the survey database is used to construct a data model showing expected RSSI values at various locations within the master space, within particular identified subspaces.
0159Another database is a training database <b>740</b>. This database stores data derived from the survey database in a format that is used to train a machine learning data model to represent the master space and its subspaces. The training database <b>740</b> is preferably constructed initially with the survey data, but once a data model is constructed using specific RSSI data values associated with their respective identified room, the training data is preferably held static (i.e., not changed) until a decision is made to update or maintain the data used for model construction and training.
0160Alternatively, or in addition, the training database <b>740</b> and the survey databases <b>730</b> can be the same database. It will be understood that one purpose of a maintaining a training database separately from a survey database is to preserve historical information as to a particular layout of a space. Once a model has been created and used for object location operations, and in the event of an embodiment wherein the data values from survey and object location operations are updated, the model is then dynamically updated as operations or changes to the environment occur. According to one aspect, there is no need to maintain a separate survey database and training database.
0161Yet another database is a model storage database <b>750</b>. The model storage database stores data representing one or more data models which are used for object location candidate prediction, as described elsewhere. In accordance with an aspect of this disclosure, object location is effected by receiving RSSI data values in a tag data package received from a particular RF tag associated with a particular object, and running the data model to obtain a prediction candidate that represents at least a threshold likelihood that the particular RF tag and associated object are in a particular identified room. Data models stored in the model storage database may be updated and/or maintained based on new data received from a subsequent survey, operations for object location, and indications of changes to the RF environment which might affect the beacon signals.
0162<figref idref="DRAWINGS">FIG. <b>7</b></figref> also shows a customer database <b>760</b> maintained in connection with the object location system <b>10</b>. Typically, the customer database <b>760</b> stores customer-specific information such as customer identification, object identifiers for objects associated with a particular customer that are to be located or have already been located in prior operations of the object location system <b>10</b>. The customer services component or module <b>770</b> accesses the customer data database <b>760</b> so as to receive customer information such as object identifiers. According to one aspect, the customer database <b>760</b> stores object identifiers associated with particular customers or users, in association with location information determined by object location operations as described herein. Customers or users typically will access the object location information remotely by use of their own customer applications <b>780</b> (not described herein), via the network <b>40</b>, invoking functions of the customer services module or component <b>770</b>. Details of such remote data access functions are within the ordinary capabilities of those skilled in the art.
0000Details of RF Tag
0163<figref idref="DRAWINGS">FIG. <b>8</b></figref> illustrates details of the components of an exemplary specific device used to implement an RF tag <b>25</b> in accordance with aspects of the present disclosure. As will be understood, an RF tag <b>25</b> is affixed or otherwise associated with a specific object <b>20</b> (not shown) which is to be located in accordance with this disclosure. The RF tag <b>25</b> receives Bluetooth Low Energy (BLE) signals from one or more beacons B<b>1</b>, B<b>2</b> Bn, generates a tag data package (not shown), and transmits this tag data package via a UHF transmitter to the object location system <b>10</b>. In addition, or alternatively, the RF tag receives other RF signals from other identifiable RF signal sources (IRFSS).
0164The preferred tag <b>25</b> is considered “dual mode” in that it contains a BLE receiver <b>810</b> for receiving BLE signals from beacons, as well as a UHF transmitter <b>820</b> for communicating with the object location system <b>10</b>.
0165In addition, or alternatively, an RF tag <b>25</b> may be configured to receive RF signals from other, non-beacon identifiable RF signal sources (IRFSS) and generate a tag data package containing information associated with such other signal sources, in particular RSSI data, frequency data, and identifying data. In such a configuration, the BLE receiver <b>810</b> will be a receiver configured to receive signals other than beacon signals, or in addition thereto.
0166The disclosed tag <b>25</b> further comprises and is controlled by a microprocessor <b>830</b>, which is coupled for data communication with the BLE receiver <b>810</b> and UHF transmitter <b>820</b>. The microprocessor is operative, as described in various places herein, for receiving signals from the beacon, in BLE format in the disclosed embodiment, extracting the RSSI data from each signal received from a beacon, and associating the RSSI values from one or more beacons with an object identifier, to generate a tag data package. Typically, an object identifier is input into the microprocessor and stored therein upon association of the tag with a particular object. Alternatively, a tag may be preconfigured to include object identifier information for an object associated with the tag, which is then stored in the on-board memory of the microprocessor and transmitted with the tag data package in association with other data. As a specific example, a stationary tag such as shown in <figref idref="DRAWINGS">FIG. <b>4</b></figref> may be preconfigured to include identifying information that the tag is stationary, for ready identification and usage for calibration, location accuracy refinement, etc.
0167The disclosed tag <b>25</b> preferably further includes a motion sensor <b>840</b>, which detects movement of the tag and/or its associated object, for example, if an object is tampered with, moved, and/or the tag is removed. The motion sensor <b>840</b> is preferably a solid-state accelerometer that provides a “wake up” or interrupt signal to the microprocessor <b>830</b> upon detection of motion greater than a preconfigured amount, thereby indicating motion (acceleration) of a nature to indicate a motion that may indicate tampering, movement, tag removal, etc. The motion sensor <b>840</b> is preferably self-powered (e.g., with a capacitive stored charge) so that the microprocessor can assume an idle (sleeping) state for long periods of time without significant battery drain, but sufficient to “wake” the microprocessor in the event the motion sensor is actuated by a movement of preconfigured threshold.
0168The disclosed tag <b>25</b> also may include data inputs coupled to the microprocessor <b>830</b> for optional external sensors or switches for various other purposes that may be desired by a customer. For example, and not shown, other devise or sensors may include and employ (a) a temperature sensing device or thermometer may be included and employed for temperature monitoring of an object, (b) a light sensors for detecting whether an object (such as a living plant or light-sensitive object) is illuminated, (c) a sound sensor or microphone for detecting whether an object is being subject to sound waves above a predetermined threshold or having particular aural properties that might indicate something such as opening of a package or a door or dropping of the object (perhaps coupled with a high G-force signal from the motion sensor) that may suggest damage to an object, (d) a pressure sensor for detecting atmospheric pressure of the environment of any object, (e) a pressure or touch sensor for detecting contact with or upon an object that may indicate tampering or other physical interference, (f) a tampering detector for detecting that an object has been touched, manipulated, opened, damaged, or otherwise interfered with, and/or (g) a data input (such as for a USB keyboard) for configuration such as inputting of object identification and/or customer identification data. Other types of sensors or inputs for other purpose will occur to those skilled in the art, for purposes independent of object location but in certain instances in cooperation with location determination.
0169The disclosed embodiment preferably employs a Cognosos model RT-300 RTLS Tag as the RF tag <b>25</b> in all applications. The Cognosos model RT-300 RTLS tags <b>25</b> are available from Cognosos, Inc., 1100 Spring Street NW, Suite 300A, Atlanta, GA 30309. Details of the preferred tag are available in the literature provided by the manufacturer.
0170The RT-300 RF tag is a battery powered device that integrates a motion sensor <b>840</b> that senses when an associated asset (object) is moved and transmits its location to the UHF radio gateway <b>712</b> (<figref idref="DRAWINGS">FIG. <b>7</b></figref>). Preferably, each tag <b>25</b> is configured to transmit a unique tag identifier (ID) and location information only when an asset has ceased movement to conserve battery power. By using the disclosed and preferred RF tag, transmissions require very little power but can be accurately received up to hundreds of feet away by the radio gateway <b>712</b>. The disclosed radio gateway <b>712</b> can cover up to 100,000 square feet indoors.
0171For association and attachment to an object to be located or tracked, the disclosed RF tag <b>25</b> is provided with an easy to install cradle (not shown) that can be attached to most flat plastic or metal surfaces with double-sided tape or cable ties. Each RF tag <b>25</b> is provided with an internal coin lithium (Li—MnO2) CR2450 cell battery that can be easily replaced by simply removing the tag from the cradle with a supplied security tool and removing a single screw to access the battery.
0172The disclosed and preferred RF tags operate in the BLE frequency band 2400-2800 MHz and in the 900 MHz ISM band and dissipate power less than 1 uW for both functional operations of receiving signals from RF beacons as well as communicating with the UHF gateway. However, it will be understood that the choice of frequency is a matter for those skilled in art, taking into consideration other design choice issues as to radio frequency, modulation type, broadcast amplitude, antenna configuration, etc. In this regard, it will also be understood that although BLE may be preferred for many applications, the invention is not limited to any particular RF signals sources or characteristics.
0173In a preferred aspect of the disclosure, the microprocessor <b>830</b> on the preferred tag <b>25</b> assembles and transmits a tag data package in response to detection at a tag that was previously detected as moving, is determined to be at rest for a predetermined length of time. In accordance with this aspect, the microprocessor on the tag is “awakened” in response to movement of the tag, e.g., by a controller interrupt from the motion sensor, and thereafter monitors the motion sensor at periodic (short) intervals until it is detected that the motion has stopped and has remained stopped for a predetermined “at rest” period of time. Once the predetermined “at rest” time has elapsed, the tag takes readings of the beacon signals and/or other IRFSS, assembles a tag data package, and transmits the tag data package to the object location system.
0174Once the tag data package arrives at the object location system <b>10</b>, the system can predict the object's location by constructing and using appropriate data models based on the tag data package, and/or retrieving preexisting data models and making an object location prediction. This object location prediction can be stored for subsequent retrieval by a customer, and/or provided in real time, in accordance with a particular customer's configuration for notification as to location of the particular object.
0175<figref idref="DRAWINGS">FIG. <b>9</b></figref> illustrates an alternative configuration of a dual mode RF tag <b>25</b>′ according to another aspect of this disclosure, in particular relating to detection of proximity of a device within a predetermined distance, e.g., ten feet, which is arbitrary, in connection with an object location operation. The embodiment of RF tag <b>25</b>′ is predominantly the same as for the tag <b>25</b> described in connection with <figref idref="DRAWINGS">FIG. <b>8</b></figref>, except that it is configured for other functions in addition to receiving signals from beacons and/or other IRFSS. According to one aspect, the tag <b>25</b> is configured to receive information via the BLE communication band from a transmitter (not shown) operated by the system operator for effecting additional location or other functions.
0176According to an aspect, the BLE receiver <b>910</b> is configured to receive signals from the object location system, for examples from transmitters other than stand-alone independent location beacons, to effect certain actions in tag, for example and not limitation: (a) remote configuration of a tag <b>25</b> to provide it with object identification and/or customer identification data, (b) actuate a visual indicator, (c) actuate a sound generating device such as a buzzer or speaker, and/or (d) transmit “on demand” any stored information contained in the on-board memory such as RF beacon signals (and/or a history of beacon signal reception over a predetermined time period), prestored customer ID or object ID information.
0177In this regard, the disclosed alternative RF tag <b>25</b>′ is preferably also provided with an output from the microprocessor <b>930</b> (which typically includes one or more on-board driver circuits which may be configured for driving LEDs or sound-generating devices or electronic switches) for coupling to an LED visual indicator <b>960</b>, and/or a buzzer or speaker <b>970</b> for generating a sound on demand by signal from the microprocessor. A particular useful function of the dual mode tag <b>25</b>′ in <figref idref="DRAWINGS">FIG. <b>9</b></figref> is that for “last ten feet” detection, as will be described next.
0000Last Ten Feet Detection (a/k/a Object Proximity Detection)
0178Still referring to <figref idref="DRAWINGS">FIG. <b>9</b></figref>, and according to another aspect, a dual mode tag such as the tag <b>25</b>′ includes one or more indicators, e.g., <b>960</b>, <b>970</b>, that can be activated in response to a prompting or trigger signal provided by a user with a survey device or smartphone <b>60</b> having Bluetooth capability or a portable object location device <b>950</b>. In accordance with this aspect, the indicator(s) is actuated by prompting from such device with a Bluetooth signal containing a command to actuate. Such a configuration allows physical location of a particular object and its tag <b>25</b>′ within the “last ten feet”, it being understood that the actual distance is arbitrary and depends on other factors such as battery conservation and aspects of the RF environment. It will also be understood that such a “last ten feet” location function is typically conducted once a particular subspace or room has been previously identified by operation of the object location system <b>10</b>, and a user is dispatched to the identified subspace with a portable object location device <b>950</b> or other device for purposes of physically finding the object, perhaps among a number of other similar objects, or similar packages for objects, or in a cluttered environment.
0179In this regard, an RF tag <b>25</b>′ is provided with some type of indicator or signaling device that is capable of alerting a user of proximity to the located tag and device. Examples of suitable indicators or signaling devices include but are not limited to a light or LED <b>960</b> or sound-generating device <b>970</b> as shown in <figref idref="DRAWINGS">FIG. <b>9</b></figref>. Signaling devices can include other types of devices such as haptic feedback devices (buzzers/vibrators), a smartphone display notification, or any other device that can be actuated to alert a user when he or she (or an autonomous device such as a robot) is sent to physically locate and perhaps retrieve an object.
0180Such a portable object location device <b>950</b> may also be a mobile telephone with a Bluetooth radio circuit, as the preferred tag <b>25</b>′ is capable of receiving Bluetooth transmissions from sources other than BLE beacons.
0181Alternatively, the portable location device <b>950</b> may be the same as the survey device <b>60</b> used to receive signals from beacons for survey purposes, but also configured to transmit BLE signals back to the tag. According to this aspect, the survey device <b>60</b> or other portable location device <b>950</b> transmits a trigger signal, preferably limited to the object that is to be located, upon entering the pre-identified room in which the object is predicted to be located. In accordance with an aspect, the portable location device is supplied with an identifier of the object to be located, the transmitted trigger signal contains the identifier, and each tag is configured to respond only to a trigger signal that includes the identifier that is specific to that tag and object.
0182According to these and related aspects, when a user having such a portable object location device <b>950</b> approaches the identified object whose location is to be determined physically by the user, after having been previously informed of a particular room or subspace in which the object is predicted to be located, the object location device transmits a predetermined trigger signal via BLE to the tag <b>25</b>′, which in response to the trigger signal actuates the indicator (tag-local beacon, light, sound generator, haptic, etc.) to signal of its nearby proximity. According to a related aspect, the portable object location device <b>950</b> such as a mobile telephone may be provided with an application that sends a command to the tag <b>25</b>′ that causes it to flash the LED or sound the audible alarm, thereby enabling the user to find the object rapidly even when it may be located in an area with other nearby identical objects or packages.
0000Object Location System Architecture
0183<figref idref="DRAWINGS">FIG. <b>10</b></figref> illustrates the hardware architecture of aspects of the objection location system <b>10</b>, in particular details of the object location engine <b>700</b> and location services <b>720</b> in <figref idref="DRAWINGS">FIG. <b>7</b></figref>, and customer services module <b>770</b>. In particular, the disclosed object location engine <b>700</b> comprises an API gateway <b>1010</b>, location integration service <b>1020</b>, packet pre-processing <b>1030</b>, and a rules engine <b>1040</b>. The API gateway <b>1010</b> provides a connection portal to the UHF radio gateway <b>710</b> so as to receive information transmitted by tags <b>25</b> associated with objects <b>20</b> in the master space. A principal component of the gateway <b>710</b> is a UHF radio gateway <b>712</b>, which includes one or more gateway receivers, or is coupled with a network of distributed gateway receivers, that receive the tag signals. According to one aspect, the gateway <b>710</b> may also include comprises other location data APIs or inputs (not shown), for example, location information can be received from third-party location service partners that may provide cellular radio type tags that can be deployed in connection with the system <b>10</b>.
0184It will be understood from the discussion in connection with <figref idref="DRAWINGS">FIG. <b>3</b></figref> that a mobile device such as RF scanning device <b>60</b> or collection of one or more tags is used for scanning a master space in a survey operation for purposes of building and/or maintaining one or more data models, as described elsewhere herein. The gateway receivers <b>712</b> may include specific interfaces or protocols for communicating with devices such as a survey device, or a portable object location device <b>950</b> as discussed in connection with <figref idref="DRAWINGS">FIG. <b>9</b></figref>.
0185The API gateway <b>1010</b> is preferably implemented by a computer service such as Amazon Web Services (AWS), a cloud-based computing service provided by Amazon Web Services, Inc., Seattle WA USA, which allows deployment of a readily scalable system that can handle a large variety of users and master spaces for use by a number of different entities. Details of use of the AWS for data input services is available from the service provider.
0186The API gateway <b>1010</b> provides location data inputs to other components of the object location engine <b>700</b>, namely, raw RF packet data <b>1014</b> received from the disclosed UHF radio gateway <b>712</b>.
0187The location integration service <b>1020</b> of the object location engine <b>700</b> collects location information received from the location services <b>720</b>, as described elsewhere. The location integration service <b>1020</b> provides location data from a prior object location operation that can be combined with current location data derived from the RF tags <b>25</b>, so as to provide an “integrated” or combination location data for use in locating objects, and/or refining the training data.
0188Still referring to <figref idref="DRAWINGS">FIG. <b>10</b></figref>, the raw RF data packets <b>1014</b> comprise data obtained from transmissions from RF tags <b>25</b>, received via the API gateway <b>1010</b>, to a packet pre-processing service or component <b>1030</b>, which disassembles the raw RF packets and obtains the information contained in the tag data packages such as RSSI indicators, tag ID information, and object ID information. This data is thus prepared for storage into databases, as discussed elsewhere, and also for backup to a data backup system.
0189According to an aspect, both the location integration service <b>1020</b> and packet pre-processing service <b>1030</b> are implemented in the cloud with AWS Autoscaling EC2/JVM cloud-based data processing services provided by Amazon Web Services, Inc., Seattle WA, USA.
0190Outputs in the form of messages, identified as SensorMsg <b>1035</b>, from the location integration service <b>1020</b> and packet-preprocessing service <b>1030</b> are provided to a collection of functions shown in <figref idref="DRAWINGS">FIG. <b>10</b></figref> as a rules engine <b>1040</b>, which is also preferably implemented in the cloud, e.g. via AWS Autoscaling EC2/JVM services. The rules engine <b>1040</b> provides services including but not limited to a real-time location service (RTLS) <b>1042</b>, a geofencing service <b>1044</b>, a sensor threshold service <b>1046</b>, and a custom rules service <b>1048</b>.
0191According to one aspect, the RTLS (real time location system) service <b>1042</b> is operative for the primary function of accessing one or more data models stored in the system <b>10</b> and maintaining by the location services <b>720</b> and generating specific location information (e.g., a particular room or subspace) of a particular object associated with a particular tag, on demand by a user or customer of the system. Thus, the RTLS service <b>1042</b> provides one of the primary functions of the disclosed system and its advantages. The RTLS service <b>1042</b> is coupled to the location services component or services <b>720</b> for accessing the one or more data models.
0192The geofencing service <b>1044</b> is a specialized function according to a complementary aspect of this disclosure. In particular, a “geofence” will be understood by those skilled in the art to be a virtual “fence” for confining an object within a particular predefined space. In particular, a geofence is useful for detecting whether a particular object might be moved from one particular location or subspace or room to another location or subspace or room. Such a geofence is useful for detecting unauthorized movement of an object (such as theft, deliberate mislocation, or inadvertent mislocation. A geofence is constructed by a user that inputs one or more rooms or subspaces within which particular objects are permitted to reside, in association with object ID and customer ID, and maintains the list of permitted rooms in a database, and access the database to determine room location in response to the movement actuation of a tag <b>25</b> associated with a particular object that is subject to geofencing.
0193According to one aspect, the sensor threshold service <b>1046</b> provides a function that permits limited movement of an object within one or more rooms or subspaces, before triggering an alarm of other indicator of movement of the object. This function can be implemented in conjunction with geofencing. In accordance with a sensor threshold service, the system maintains a predetermined distance movement threshold value, or alternatively an RSSI signal threshold value, for a particular object, in association with object ID and customer ID. In response to a signal of a tag <b>25</b> indicating movement of a particular identified object, a new location of the object is compared to the threshold value (distance and/or RSSI value), so as to determine whether the object has moved a sufficient amount, as indicated by a change in the distance (or RSSI) values from an initial value when the object was last located, to different values. In the event that the determined movement of the object exceeds the predetermined change threshold, there is an indication that the object has moved sufficiently to note the change in position, and perhaps trigger an alarm of movement. Such a sensor threshold service is useful for allowing limited movement of objects within an approved subspace, without necessarily triggering an alarm.
0194A custom rules service <b>1048</b> is also provided so as to store custom rules provided by users or customers, as may be determined from time to time.
0195Still referring to <figref idref="DRAWINGS">FIG. <b>10</b></figref>, the location services <b>720</b> provides two major functions in the disclosed object location system <b>10</b>: a model training function <b>1070</b> and a model lookup and prediction function <b>1080</b>. Both the model training function <b>1070</b> and model lookup and prediction function <b>1080</b> are implemented in the disclosed embodiment by AWS SageMaker service provided by Amazon Web Services, Inc., Seattle WA, USA, or alternatively by a TensorFlow open-source ML platform. As known to those skilled in the art, AWS SageMaker is a fully managed cloud-based service that provides services for building, training, and deploying machine learning (ML) models quickly. TensorFlow is an open-source machine learning model building and deployment platform, details of which are available at http://www.tensorflow.org. As will be appreciated, the TensorFlow ML environment may be implemented within services provided by AWS.
0196According to one aspect, the model training function <b>1070</b> is implemented with a machine learning (ML) function, which is species of artificial intelligence (AI) technology. In the disclosed embodiment, the preferred ML function is a Support Vector Machine (SVM) algorithm, the general operations of which are known to those skilled in the art. The SVM accesses data in the survey database and/or training database <b>730</b> and creates one or more SVM data models that are used for object location prediction, based on RSSI values provided by a tag <b>25</b> that are activated to transmit its tag data package containing such RSSI values. Further details of the preferred SVM algorithm are described below. A data model formed from processing the survey data and/or training data in the respective databases is then stored in the model storage database <b>750</b>, shown in other figures.
0197According to one aspect, the model lookup and prediction function <b>1080</b> is an application algorithm that accesses models constructed by the preferred SVM stored in the model storage database <b>750</b> and provides a prediction output comprising a location prediction (identification) of a particular subspace in which a particular, pre-identified object <b>20</b>, as associated with an identified tag <b>25</b>, may be located. According to a related aspect, the model lookup and prediction function <b>1080</b> accesses one or more data models, e.g., as discussed in detail below, and processes the received RSSI values from a tag data package against the one or more data models to arrive at a prediction candidate, which is provided as the location prediction output.
0198According to one aspect, a location prediction output for a particular object from the model lookup and prediction function <b>1080</b> is provided to a location fixes service <b>1012</b> for use in a location integration service <b>1020</b>. The location integration service <b>1020</b> combines the predicted location for the tag and associated object with data corresponding to the tag data package that triggered the location operation, to form “scan” associating the RF values of the tag data package with the predicted location of the tag and object. The location integration service <b>1020</b> and the packet pre-processing function <b>1030</b> generate data messages SensorMsg, as described elsewhere, which are further handled by the rules engine <b>1040</b>, according to the particular function invoked, e.g. geofencing, sensor threshold, any custom rules, or in case of a new incoming tag data package, an RTLS lookup function and location prediction.
0199The location services <b>720</b> accesses data in the survey database <b>730</b>, the model training database <b>740</b>, and the model storage database <b>750</b> (not shown in <figref idref="DRAWINGS">FIG. <b>10</b></figref>) for purposes of constructing one or more data models for machine learning of a master space and its associated subspaces, maintaining those models with additional data and “machine learning” (i.e. updating of the data models) resulting from object location operations, and also for conducting the primary function of object location by invoking and running one or more data models in response to an object location operation. Typically, an object location operation is triggered by a “command” from the RTLS lookup service <b>1042</b>, which provides data received from an RF tag <b>25</b> indicating its set of RSSI values, object ID, and customer ID, among other potential data items, and uses that data to run a data model to obtain a prediction candidate for a likely location of the particular object associated with the tag that provided the data. As previously described, a tag typically provides its tag data package in response to detection that a tag (and its associated object) has stopped moving, after of course beginning to move.
0200As indicated above, the various functions of the rules engine <b>1040</b> provide several outputs for utilization by various functions associated with the system <b>10</b>. For example, and further to that as described above, the RTLS lookup function <b>1042</b> provides location information as to a predicted location for a particular object from an object location operation to customer services function <b>770</b>. And although not shown, information from an object location operation is also provided to the training data base <b>740</b>. It will be understood that location data from a located object may be added to the training database <b>740</b>, in which case the database may more properly be considered a “location data storage database,” as it contains data used for initial training of the model, plus updates from changes to the RF environment as detected by other functions, as well as location data from actual object location operations. All of such data forms a part of the machine learning database and used to refine the model subsequent to initial training. By updating the training database to include location data from actual object location operations, as well as from detected changes in the environment due to beacon failure, new beacon additions, moved beacons, changes in the physical infrastructure such as changes to shelving, doors, walls, etc., the data models used for object location prediction are dynamically updated for subsequent object location operations.
0201In the disclosed embodiment, the survey database <b>730</b>, the training database <b>740</b>, and the model storage database <b>750</b> are all implemented in cloud-based data storage services provided by Amazon Web Services, Inc., Seattle WA USA, such as AWS S3, AWS SQL, and/or AWS ElasticSearch, details of which are available from the service provider. It will of course be understood and appreciated that databases can be maintained in other known manners such as with local storage or by use of other cloud-based data storage services, as determined by one who builds and operates an object location system <b>10</b> as described herein.
0202<figref idref="DRAWINGS">FIG. <b>10</b></figref> also illustrates aspects of customer services function <b>770</b>, as introduced in <figref idref="DRAWINGS">FIG. <b>7</b></figref>. Customer services <b>770</b> provides application programming interfaces (APIs) into the disclosed object location system <b>10</b> (not shown in <figref idref="DRAWINGS">FIG. <b>10</b></figref>) for the purpose of allowing users such as customers of a provider of the system <b>10</b> to input their information as to objects to be located and/or tracked, aspects of the master space and its associated subspaces including the surveying thereof, and conducting object location operations to locate specific objects within the user's respective master space(s).
0203In the disclosed embodiment, the customer services functions <b>770</b> are implemented with various AWS services and storage facilities, as for other functions in the system <b>10</b>. An API service (not shown) provides an interface to the Internet <b>40</b> or other data communication network so that particular customers or users can employ mobile devices such as networked computers, data tablets, cellphones, or other devices to conduct survey operations and object location operations using applications that execute on such devices. These operations generate API queries, for example, to access and invoke functions of the system <b>10</b>. The API services include functions such as a load balancer for handling and balancing a number of simultaneous/high volume of operations in the system, a monitoring and observability service for providing metrics as to operations and performance of the system, an API endpoints service for providing web-based access to the system by users, and an event notification service for generating real-time information to users including automatically updated object location information, violations of geofence rules, and/or movement threshold indications. In the disclosed embodiment, these aspects are implemented respectively by AWS Elastic Load Balancer, AWS Cloudwatch service, API Endpoints service, and AWS SNS event notification service, all provided by Amazon Web Services, Inc., Seattle WA. Details of these cloud-based services are available from the service provider. These services store and retrieve data in the customer database <b>760</b>, also provided in the disclosed embodiment by Amazon Web Services, but of course may be implemented locally in a user's facility or via other cloud-based storage and web-accessible service providers.
0000Exemplary Training Data, Object Location Prediction, and Model Update
0204Turn now to <figref idref="DRAWINGS">FIGS. <b>11</b> and <b>12</b></figref> for a discussion of exemplary data used in constructing a data model of a master space and associated subspaces, based on use of pre-collected survey data, of exemplary data in use of a data model to generate a prediction candidate for the location of a particular object, and of updating a data model based on subsequently-acquired data from object location operations or changes to the RF environment, respectively. <figref idref="DRAWINGS">FIG. <b>11</b></figref> provides one example of exemplary data, and <figref idref="DRAWINGS">FIG. <b>12</b></figref> provides another example of exemplary data.
0205<figref idref="DRAWINGS">FIG. <b>11</b>A</figref> illustrates an exemplary data table of RSSI data values, expressed in dBm, that represent the results of a survey operation by a user of the disclosed object location system <b>10</b>. Each row in the table in this figure represents a single “scan”, comprising a collection of RSSI data values. The data values represent a plurality of data values obtained by use of a survey device <b>60</b>, after a user has obtained RF data samples within a plurality of exemplary subspaces or rooms Room A, Room B, and Room C in a survey operation. Each data value in the table represents RSSI value measured by a survey device, for example at sample locations S<b>1</b>, S<b>2</b>, . . . Sn, taken within a predefined subspace of a master space. Preferably each sample—e.g., S<b>1</b> in <figref idref="DRAWINGS">FIG. <b>11</b>A</figref>—will include the RSSI values measured from one or more RF channels of an RF beacon, assuming that each RF beacon provides one or more discrete RF channels. For example, note in <figref idref="DRAWINGS">FIG. <b>11</b>A</figref>, on the first row of the table, that a beacon identified as Beaconl has three channels, Ch. 1, Ch. 2, and Ch. 3, each transmitting at a different frequency within the specified RF band for the beacons deployed in the master space. Sample S<b>1</b> has RSSI values of −70 dbM, −68 dbM, and −69 dBm, as measured within Room A. Similar samples, e.g., S<b>2</b>, are taken of RF signals from other beacons with multiple channels, e.g., Beacon 2 and Beacon 3, in the example shown. Assume further that another set of data samples is taken within Room A, preferably at another physical location within Room A as represented in the second row of data values in the table. Preferably, each set of data samples is taken at a different location within the subspace being surveyed.
0206In a similar manner, other data samples are taken within the subspaces Room B and Room C, capturing RSSI data from various locations within each subspace from signals as received from beacons whose signals are detectable within that subspace, to build out a data table such as that shown in <figref idref="DRAWINGS">FIG. <b>11</b>A</figref>. Such a table of data values is then used to train and deploy a machine-learning model. In <figref idref="DRAWINGS">FIG. <b>11</b>A</figref>, the data values for the first two rows represents a first data model A. In like fashion, the data values for the next two rows represent a second data model B, and the last three rows represent a third data model C. These data values and their respective identifiers for data Models A, B, and C are then stored in the survey database <b>730</b>, and once the models are identified, the constructed data models are stored in the Training Database <b>740</b>, for access by the model training function <b>1070</b> (<figref idref="DRAWINGS">FIG. <b>10</b></figref>). Once a set of data from a survey is used in building a data model, that data is transferred into the model storage database <b>750</b>.
0207<figref idref="DRAWINGS">FIG. <b>11</b>B</figref> illustrates an exemplary data table of RSSI data values, expressed in dBm, that represent the results of an object location operation by a user of the disclosed object location system <b>10</b>. In the example, a plurality of data samples provided in tag data packages from an RF tag <b>25</b> are provided by a set of scans or data acquisition samples of beacon signals received by RF tag and transmitted to the object location system for an object location operation. The example shown has four (4) scans or sets of data samples, as represented by the four rows in the table, taken from signals received from three beacons Beacon 1, Beacon 2, and Beacon 3, whose signals are detectable by the RF tag <b>25</b>. As shown, each beacon has three RF channels, Ch. 1, Ch. 2, Ch. 3. It is believed that at least three sets of data samples from a tag provide acceptably reliable location operations, although predictions may be made with more or fewer data samples.
0208In the example shown, each set (row) of data samples from a tag <b>25</b> that receives the RF beacon signals from the three beacons is run against a location prediction algorithm that accesses one or more data models built from a prior survey and data model training operation. Note that three of the four sets of scans have resulted in the prediction of Room A as the likeliest location for the object <b>20</b> whose tag <b>25</b> obtained the RF beacon signals and transmitted them to the system for the location operation. Note that one of the sets of data (the third row), resulted in the prediction of Room B. In accordance with one aspect of the present disclosure, a weighting or “voting” algorithm is used to determine that the three predictions of Room A outweigh (outvote) the single prediction of Room B, such that a location prediction of Room A is output by the system as the determined location of the object associated with the tag that provided the data.
0209<figref idref="DRAWINGS">FIG. <b>11</b>C</figref> illustrates an exemplary data table or schema of RSSI data values, expressed in dBm, that represent the results of an object location data update and/or model maintenance operation resulting from additional data obtained by use of the disclosed object location system <b>10</b>. In the example shown, assume that the first four rows of data (RSSI value) from an initial set of scans of values from a tag.
0210Assume further that the data items used in model construction and maintenance now include additional data items from any one of a number of additional sources, e.g., known static objects or tags, newly added beacons, confirmed object tag location operations, triggered environment changes, follow up surveys, beacon failures, diminished RF signals, moved or replaced beacons, added or removed external IRFSS, etc. Such additional data items are shown in <figref idref="DRAWINGS">FIG. <b>11</b>C</figref> as “additional scan data”, and are used to update, reinforce, and/or maintain the data model constructed in initials scans from an initial survey. In the figure, two (2) additional data items are shown, reflecting in this particular example the receipt of signals from beacons Beacon 1, Beacon 2, and Beacon 3, and from different RF channels of such beacons. Although this exemplary schema shows signals from beacons, it will be understood that such additional scan data can be obtained from other identifiable RF signal sources (IRFSS).
0211It will be understood in connection with <figref idref="DRAWINGS">FIG. <b>11</b>C</figref> that the additional scan data is used to run the data model and determine (or verify) that a particular room, e.g., Room A, Room B, is predicted to be the location of the receiver that generated the additional scan data. Upon updating the data model using the additional data continuously in response to triggered circumstances such as beacon failure, or object location operations, or in response to follow up surveys.
0212According to a related aspect of <figref idref="DRAWINGS">FIG. <b>11</b>C</figref>, it will be understood that the disclosed system and methods contemplated at least three different ways or methods for reinforcement of data models constructed as described herein. Examples of such situations are described above in connection with <figref idref="DRAWINGS">FIGS. <b>4</b>, <b>5</b>, and <b>6</b></figref>. Such methods involve use of data from circumstances or conditions detected in the RF environment, stationary or static tags, additional or removed beacons, and providing additional data scans such as those shown in <figref idref="DRAWINGS">FIG. <b>11</b>C</figref> for use in subsequent model construction and usage or subsequent object location predictions. For example, a first reinforcement or updating method involves user intervention for correction of an erroneous subspace prediction. In this method, the system provides for user entry of a corrected room or subspace identifier in the training database, in response to a user determination that the system has erroneously predicted an object location. In such a method, the system may provide for user override of the incorrect prediction, and/or provision of a corrected subspace identifier for the tag data that prompted the erroneous subspace prediction.
0213A second reinforcement or updating method involves the inclusion of additional scans into the training database in response to a determination that the RF environment may have changed, or by the inclusion of additional beacons or RF sources, or the utilization of static of stationary tags such as shown in <figref idref="DRAWINGS">FIG. <b>4</b></figref>. This may be determined by the occurrence of mispredicted locations, as well as the identification of initial survey scans that included signals from beacons or other IRFSS that are no longer present or are significantly attenuated, and replacement and/or updating of scans forming the data models.
0214A third method involves automatic reinforcement based on each successful object location operation. In this method, the data from each successful object location prediction, as represented by the tag data package with the scan at prediction time, is provided to the training database for use in subsequent model construction and usage.
0215<figref idref="DRAWINGS">FIG. <b>12</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>12</b>A-<b>12</b>D</figref>, is another example of exemplary data derived and used in aspects of the present invention(s), in connection with, respectively, a survey operation, training of a ML database, adjustment of data used in construction of models used for object location prediction, and model construction by assigning rooms (subspaces) to particular sets of adjusted data values.
0216<figref idref="DRAWINGS">FIG. <b>12</b>A</figref> illustrates exemplary data derived in an initial survey operation or process, as described in this disclosure. As indicated in the figure, a survey operation or process provides data, exemplary data of which is illustrated, collected in scans Sn collected from beacons Bn in indicated rooms identified by Room Label Rn as a result of survey scan within the identified room. During the survey process, a room or subspace label is associated with each scan, as represented by a Scan ID data value. The data in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref> is considered an initial survey scan.
0217It may be noted in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref> that certain scans, e.g. scans S<b>1</b>, S<b>2</b>, S<b>3</b> provided no data from beacons B<b>4</b>, B<b>5</b>, and B<b>6</b>, for room R<b>1</b>, and scan S<b>1</b> provided no data from beacon B<b>3</b> for R<b>1</b>. Likewise, scans S<b>7</b>, S<b>8</b>, and S<b>9</b> provided no data from beacons B<b>3</b>, B<b>4</b>, B<b>5</b>, B<b>6</b>, and scan S<b>8</b> provided no data from beacon B<b>7</b>, for room R<b>3</b>. “No data” in this example means that the signals received from those respective beacons were either totally missing or alternatively below some predetermined threshold, e.g., less than −120 dBm.
0218Also, in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref>, note that the scans from the survey labeled with room R<b>2</b> has a distinctively different set of values. This survey data indicates that the rooms R<b>1</b> and R<b>3</b> have signals from a set of beacons that have a number of the same beacon identifiers, i.e. beacon B<b>1</b>, B<b>2</b>, B<b>7</b>, B<b>8</b>, and B<b>9</b>. In order to conduct an object location operation, a plurality of data models are constructed using this survey data, and allow selection of which room a particular object is located, based on a scan taken at the time of object location prediction.
0219<figref idref="DRAWINGS">FIG. <b>12</b>B</figref> illustrates both an exemplary scan from a tag associated with an object to be located at prediction time, as well as the result of a selection or determination of a set of survey scans from the data in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref> from the initial survey database to use for model construction. The selection of scans Sn for use in model constructing and training is based on scan data from a tag at prediction time. An exemplary process for constructing a set of training data for the ML SVM classification algorithm thus involves, at Step 1, selection of a set of survey scans Sn for model construction based on the RSSI values from a scan from a tag that is to be located. In this case, because the tag to be located has received signals from beacons B<b>1</b>, B<b>2</b>, B<b>7</b>, B<b>8</b>, and B<b>9</b>, and because scans S<b>1</b>, S<b>2</b>, S<b>3</b>, S<b>7</b>, S<b>8</b>, and S<b>9</b> in the initial survey data show significant signals from the same beacons B<b>1</b>, B<b>2</b>, B<b>7</b>, B<b>8</b>, and B<b>9</b>, the data from these initial survey scans are selected for model construction. In accordance with an aspect of this disclosure, provided that a predetermined percentage of the beacons, for example 75%, in an initial survey data item Sn have values from beacons (represented by beacon identifiers) that match the beacon identifiers received by the tag to be located, such initial survey scans are used in training. For example, and in other words, if a particular initial survey scan Sn has data values for at least 75% of the same beacons in the tag data, then that scan value may be selected as training data for model construction.
0220Note in <figref idref="DRAWINGS">FIG. <b>12</b>B</figref> that two of the initial scans S<b>2</b> and S<b>8</b> show zero values from beacons B<b>8</b> and B<b>7</b>, respectively. Still, in this example, 80% of the beacon identifiers (4 out of the 5 in the prediction time scan data) in the scans S<b>2</b> and S<b>8</b> are the same as in the prediction time scan data. Thus, scans S<b>2</b> and S<b>8</b> are still eligible for use in training, according to this particular aspect of scan selection for model construction. Note also, and as discussed next, the presence of the zero values creates a certain complication in model construction.
0221<figref idref="DRAWINGS">FIG. <b>12</b>C</figref> illustrates the exemplary training data of <figref idref="DRAWINGS">FIG. <b>12</b>B</figref>, below the scan data from the tag at prediction time for comparison, showing the adjustment of certain training data by insertion or inclusion of data for certain beacons, for completion of model construction in accordance with a particular aspect of the present disclosure. Note that at Step 2, the initial survey scans for S<b>2</b> and S<b>8</b> in <figref idref="DRAWINGS">FIG. <b>12</b>B</figref> had zero values for one particular beacon of the five indicated (B<b>8</b> and B<b>7</b>, respectively) but otherwise had values for four other beacons. In accordance with this aspect, the zero values are replaced with values that represent an interpolation of values from adjacent scans, it being understood that that scans S<b>1</b>, S<b>2</b>, and S<b>3</b> were all associated with room R<b>1</b>, and scans S<b>7</b>, S<b>8</b>, S<b>9</b> were all associated with room R<b>3</b>. Having a zero value for scans where most of the values are reasonable is perhaps anomalous, and according to this aspect of the disclosure, will be replaced by a value determined by a predetermined statistical computation or pure interpolation so as to provide a meaningful value for use in object location prediction. In the example shown for scan S<b>2</b> in the training data, the value of −117 dB is inserted, as average of the adjacent values from S<b>1</b> and S<b>3</b> from beacon B<b>8</b>. Similarly for scan S<b>8</b>, the value of −97 dB is inserted, as an average of the values from S<b>7</b> and S<b>9</b>. Although a statistical average is used in this example, it will be understood that other statistical computations may be employed to fill in for missing and/or anomalous values, such as pure interpolation, median, mode, or other types of statistical values.
0222In <figref idref="DRAWINGS">FIG. <b>12</b>C</figref>, once any anomalous or missing values are filled in, the training data may be considered completed and ready for use in model construction and object location prediction.
0223<figref idref="DRAWINGS">FIG. <b>12</b>D</figref> illustrates two particular data models in accordance with an aspect of this disclosure. This figure illustrates the assignment of a first data model R<b>1</b> associated with room R<b>1</b>, and a second data model R<b>3</b> associated with room R<b>3</b>, based on the collection of a set of initial survey scans (survey data) as shown in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref>, training of a ML algorithm by selection of a predetermined set of survey scans from the initial survey scans based on the RSSI values of a tag data scan at prediction time for a tag associated with an object to be located as shown in <figref idref="DRAWINGS">FIG. <b>12</b>B</figref>, as such a set of selected survey scans may be adjusted to compensate for anomalies and/or missing values as in <figref idref="DRAWINGS">FIG. <b>12</b>C</figref>.
0224<figref idref="DRAWINGS">FIG. <b>12</b>D</figref> illustrates the data resulting from construction of a data model for room R<b>1</b> and R<b>3</b>. At Step 3a, model identifier Model R<b>1</b>, comprising scans S<b>1</b>, S<b>2</b>, and S<b>3</b>, as adjusted in a manner as previously described, is assigned to these scans. At Step 3b, a model identifier Model R<b>3</b>, comprising scans S<b>7</b>, S<b>8</b>, and S<b>9</b>, as similarly adjusted, is assigned to these scans. At Step 3c, a binary version of these data models is stored in the model storage database <b>750</b> (<figref idref="DRAWINGS">FIG. <b>7</b></figref>).
0225Still referring to <figref idref="DRAWINGS">FIG. <b>12</b>D</figref>, in accordance with aspects of this disclosure, an object location prediction is conducted upon construction and/or retrieval of the constructed training data models. As described elsewhere herein, an object location operation involves prediction of the room in which the object to be located is most likely found, based on the tag data from the scan from a tag associated with the object to be located at prediction time. In accordance with aspects of this disclosure, a ML algorithm, a SVM in the disclosed preferred aspects, is applied to the data in the constructed models (Model R<b>1</b> and Model R<b>3</b> in the example shown). In this example, a typical classification algorithm, such as SVM, will return room (subspace) R<b>1</b> as the room in which the tag and its associated object is most likely to be found.
0000Flow Charts of Processes for Survey, Survey Pre-Processing, Model Training, Model Serving
0226Turn next to <figref idref="DRAWINGS">FIGS. <b>13</b>-<b>17</b></figref> for a discussion of flow charts of various computer-implemented processes that are executed by the object location system <b>10</b> constructed in accordance with aspects of this disclosure. These flow charts are examples of steps that can be used to implement various functions of the disclosed object location system in a networked computer system, having a location gateway <b>710</b> for receiving RF signals from RF tags <b>25</b> associated with an object <b>20</b> to be located, which is coupled to an object location engine <b>700</b> that carries out survey operations, model building and training, object location, in conjunction with user-provided information relating to the defining of subspaces or rooms within a master space, object ID, customer ID, and other data items used in carrying out the functions described herein. According to one aspect, it will be appreciated that the steps described in the flowcharts described are carried out in computer code executed on the various cloud-based computing and communicating components described above, in particular in <figref idref="DRAWINGS">FIG. <b>10</b></figref>.
0227<figref idref="DRAWINGS">FIG. <b>13</b></figref> is a high-level flow chart that illustrate primary computational data collection, model training, and object location operations that are conducted in order to carry out the functions required for object location in accordance with this disclosure. Each of the major steps shown in <figref idref="DRAWINGS">FIG. <b>13</b></figref> are effected by a computer program process that is executed in the object location system <b>10</b>, constructed as described herein. First, at process <b>1400</b>, the master space in which objects to be located may be found is surveyed, to obtain RF data samples of the RF environment of the master space and assigned appropriate subspaces or room identifiers. At process <b>1500</b>, the survey data from a survey operation is pre-processed to build a training database. At process <b>1600</b>, one or more data models are constructed by selection of a set of scans from the initial survey database based on values received from a tag associated with an object to be located. At process <b>1700</b>, an object location process is conducted by executing selected data models and predicting a room in which the object is likely to be located. As shown, data from an object location operation <b>1700</b> are fed back to the model training process <b>1600</b>, as in certain aspects of this disclosure the data models used for object location prediction are continuously updated with data from successful object location predictions. Details are these major processes are described below.
0228<figref idref="DRAWINGS">FIG. <b>14</b></figref> illustrates steps that can be used to implement a survey function or process <b>1400</b>, identified in <figref idref="DRAWINGS">FIG. <b>14</b></figref> as a field survey application (app). Starting at step <b>1405</b>, a survey function begins upon a command, for example from a survey device <b>60</b> as shown generally in <figref idref="DRAWINGS">FIG. <b>3</b></figref>, which contains an application for collecting RF data samples from beacons in a master space, from a receiver associated with or built into the survey device <b>60</b>. Such a begin survey command is shown as “Start Measurement Session.” In a measurement session, the survey device is activated and deployed within one or more subspaces or rooms within this master space, and the associated receiver receives beacon signals, preferably multi-channel, from one or more beacons whose signals propagate into the subspace being surveyed.
0229At step <b>1408</b>, a session ID is generated to identify the particular survey session being conducted. At step <b>1410</b>, a customer site number for the master space is retrieved from the customer database <b>760</b>. The customer site number is used to associate a particular master space and its identified subspaces with a particular user or customer. The customer site number may include a subspace or room identifier for association with RF data samples obtained within the room being surveyed. At step <b>1413</b>, the survey device begins collecting RF data samples within an identified subspace.
0230At step <b>1415</b>, a “zone label”, also known here as a subspace identifier, and its coordinates within the master space, are identified based on customer site information, and written at step <b>1418</b> to a Location List, as shown in the accompanying table. According to one aspect, a Location List comprises data items including but not limited to the session identifier (SessionID), a start time for the session (SessionStartTime), a customer identifier (CustomerLabel), one or more master and/or subspace identifiers (ZoneLabel), and one or more location identifiers (LocationNumber) associated with the master space and/or associate subspaces, coordinates of the master space and/or associated subspaces as may be required (X Coord, Y Coord, Z Coord) for a three dimensional master space, and, if desired, a reference to a predetermined map of the space and subspace maintained by the user (Map Point Ref). These data items are associated with a customer or user LocationNumber at step <b>1420</b>. The LocationNumber data item is a customer-supplied data item that distinguishes one particular location associated with a customer or user, within a plurality of locations. The data items, as listed above and as shown in the accompanying Location List table, are then stored (uploaded) in the survey database <b>730</b> at step <b>1422</b>.
0231After step <b>1415</b>, a scan identifier (Scan ID) is generated at step <b>1425</b> to identify the particular scan or data acquisition operation for obtaining RF beacon signal samples, and the survey device <b>60</b> begins to collect the RF beacon signal samples, or signal sample from any other RF sources that are used as IRFSS. At step <b>1430</b>, the RSSI values of multi-channel beacons are collected and stored, in association with a particular location in the master space and subspace, and associated with Location N, where N will increment for each sample location S<b>1</b>, S<b>2</b>, . . . Sn. At step <b>1432</b>, the scan is completed for that sample location S<b>1</b>, and the data values are recorded or written at step <b>1435</b> to a measurement log, as shown in the accompanying table. According to an aspect, the Measurement Log comprises data items including but not limited to SessionID, SessionStartTime, CustomerLabel, SiteLabel (identifying a particular master space), ZoneLabel (identifying a particular subspace or room), a scan identifier (ScanID), a scan start time and duration (ScanStartTime, ScanDuration), a time at which a beacon signal is received (PacketReceiveTime), a beacon identifier (BeaconMAC), and the signal strength measurement itself (RSSI) of the particular data value of a particular channel of a particular beacon.
0232In addition, and although not shown in <figref idref="DRAWINGS">FIG. <b>14</b></figref>, a data item for the Measurement Log may include a channel identifier (Channel ID) for configurations that involve multi-channel beacons or other multi-channel RF sources as IRFSS, as well as value or data item representing the frequency or frequencies of a beacon or other RF source.
0233The Measurement Log written at step <b>1435</b> is then associated with a user Location Number established at step <b>1420</b> and uploaded at step <b>1422</b> to the survey database <b>730</b>.
0234After writing a Measurement Log at step <b>1435</b>, the inquiry is made at step <b>1440</b> whether additional scans at additional sample locations are to be made, and if so, the process returns to step <b>1425</b> and another scan is initiated. If at step <b>1440</b> the user conducting the survey has completed his or her survey of the master space and associated subspaces, the process passes to step <b>1450</b> and the survey process is complete.
0235<figref idref="DRAWINGS">FIG. <b>15</b></figref> illustrates steps that can be used to implement a survey data pre-processing function or process <b>1500</b>, identified as a Survey Pre-Processing application (app). According to one aspect, a survey pre-processing process is carried out so as to transform survey data as stored in the survey database <b>730</b> into data that is used to construct (i.e., train a machine with “machine learning”) one or more data models that are used for location of objects. The output or result of the pre-processing function or process <b>1400</b> is stored in the Training Database <b>740</b>.
0236Another purpose of the Pre-Processing app <b>1500</b> is to normalize the RSSI values obtained during a survey of a master space so as to compensate for variations that might occur as a result of use of different RF beacons having somewhat different characteristics, e.g. from different manufacturers, calculate mean values of RSSI values for a various locations within an identified subspace so as to identify aberrations that might occur due to beacon malfunction, additional beacon placement, beacon movement, and other issues.
0237Starting at step <b>1505</b>, a survey pre-processing function <b>1500</b> accesses data in the survey database <b>730</b> collected during a prior survey operation, and first counts the number of distinct beacons detected during the survey. Such a count is effected by a pass through all data samples in the survey for a specific master space and identifying all unique MAC (media access control) addresses for beacons. It is understood at this juncture that each beacon has a unique identifier so as to distinguish signals from different beacons; all beacons deployed in a master space should have a unique identifier that is provided as a part of the beacon's signal. A MAC address is a convenient identifier for this purpose. Upon counting all unique MAC addresses in the survey data of the specified master space that was surveyed, at step <b>1508</b> data corresponding to this count is written to a beacon metadata file, as shown in the accompanying table, and stored in the training database <b>740</b>. The data items in the beacon metadata file include but are not limited to the following: a user or customer identifier (CustomerLabel), an identifier of the specific master space associated with the particular survey data being pre-processed (SiteLabel), and a list of all beacons detected in the survey by beacon identifier (BeaconMAC).
0238After the counting of the unique number of beacons detected in the survey, after step <b>1505</b>, the RSSI data values for each unique beacon from the survey device <b>60</b> are normalized at step <b>1510</b>. The normalization of RSSI values is for the purpose of determining the variation in a RSSI values that were detected in the survey. In other words, it is expected that the RSSI values for all RF beacon signals will vary according to some function, and that there will be a maximum value seen and a minimum value seen, a mean value of all the values of a particular beacon, and a standard deviation of those values. This normalization assists in later object identification error detection using data from a particular RF tag, if for example a value significantly above or below the mean is seen, e.g., more than 2 standard deviations from the mean, which may indicate an anomalous RSSI value read from a tag. After the normalization calculations are completed for the data associated with each individual beacon are completed, a Preprocessed Beacon File for the beacons is created at step <b>1515</b>. Data items in the Preprocessed Beacon File, as shown in the accompanying table, include but are not limited to: a customer or user identifier (CustomerLabel), an identifier of the particular master space of the survey (SiteLabel), a time stamp associated with the survey (SessionStartTime), and a list that associates beacons with particular zones (rooms or subspaces), namely: a zone identifier (room or subspace identifier (ZoneLabel), the mean value and standard deviation of the RSSI values seen in that zone for each beacon (e.g. MAC 1 RSSI Mean, MAC 1 RSSI StdDev . . . MAN N RSSI Mean, MAC N RSSI StdDev).
0239Also after step <b>1505</b>, the RSSI data from the survey is associated with each particular zone (area, room, subspace) at step <b>1520</b>, in a Per-Zone Data collection. The data items in the Per-Zone Data collection, as shown in the accompanying table, include but are not limited to a user or customer identifier (CustomerLabel), an identifier of the master space associated with this survey data (SiteLabel), a time stamp of the survey (SessionStartTime), a zone identifier (area, room, subspace), and data of the survey samples S in the form of Category (−1/1) identifying a channel and RSSI value, and the sample data in the form of MAC 1 Mean, MAC 1 StdDev . . . MAC N Mean, MAC N StdDev. The Per-Zone Data is then written to the training database <b>740</b>.
0240<figref idref="DRAWINGS">FIG. <b>16</b></figref> illustrates steps that used to implement a ML model training function or process <b>1600</b>, identified as a Model Training application (app), according to one aspect of the disclosed invention. According to one aspect, the Model Training app <b>1600</b> is run against each specific zone (area, room, subspace) so as to generate a data model using the training data in the training database <b>740</b>, and the resultant data model(s) are stored in the model storage database <b>750</b>. According to one aspect, the machine learning model construction involves construction of a Support Vector Machine (SVM), which is known to those skilled in the art as a supervised machine learning model that uses classification algorithms for a two-group classification problem: whether a particular object, as indicated by data provided by an associated tag <b>25</b>, is or is not, predicted to be in a particular room or subspace, identified as a zone (ZoneLabel).
0241The Model Training app <b>1600</b> has two nested routines or procedures: a Parallelize per Zone process <b>1605</b> and a Parallelize per parameter choice process <b>1610</b>. Those skilled in the art will understand that when training an SVM, the user needs to make a number of decisions: how to preprocess the data, what type of kernel to use, and finally, setting the parameters and hyperparameters of the SVM and the kernel. Kernels in an SVM will be understood by those skilled in the art to be algorithms implementing certain mathematical functions that are defined as the kernel. The function of a kernel is to take data as input and transform it into the required form. Different SVM algorithms use different types of kernel functions, for example linear, nonlinear, polynomial, radial basis function (RBF), and sigmoid. Each of these different types of kernels have an associated set of parameters that are used in constructing a model.
0242In the disclosed embodiment, a linear kernel has been employed, as the classification function is a simple yes/no decision—a data model for a particular room or subspace will indicate either that a particular object, as represented by a set of RSSI data samples provided by an associated tag, are predicted to be either “yes—in the room associated with the model” or “no—not in this room.”
0243Those skilled in the art will also understand that certain SVM kernels also have another set of parameters called hyperparameters, for example the “soft margin constant” and other parameters of the chosen kernel function such as the width of a Gaussian ken or degrees of a polynomial kernel. Those skilled in the art of implementing SVM functions will understand how to select and optimize parameters and hyperparameters for a chosen SVM kernel, as well as choosing an appropriate kernel (or other classification algorithm) for a specific application of the present invention.
0244The Parallelize per parameter choice process starts at step <b>1620</b>, where the data in the training database (or survey database, original or as updated/reinforced) is processed on a partitioned basis, for example, all the data associated with a particular beacon are found and processed, or all the data associated with a particular zone or room are processed.
0245At step <b>1622</b>, any required hyperparameters for the selected parameter are chosen and applied. At step <b>1625</b>, a SVM data model is generated, i.e., by application of the selected kernel, to assess the closeness of the “fit” of the data to an expected minimized “distance” of the particular data of a sample to the associated line, plane, hyperplane, or other reference geometry. Stated in other words, the fit of an SVM is a determination of the acceptable error margin of the soft margin parameter. It will be understood that an SVM with a linear kernel (or classifier) may be easier to determine a suitable fit, since the only parameter that affects performance is the soft margin constant. Of course, other kernels and degrees of fit may be employed, e.g., Gaussian, polynomial, and others.
0246After determining an acceptable fit of the data used for training, the SVM model is validated at step <b>1628</b>. Validation of an SVM model may be effected by running the same training data, and/or additional data, through the model again, and assessing the error.
0247The result of each Parallelize per parameter choice process <b>1610</b> is provided to a Choose Best Fit step <b>1630</b>, a part of the Parallelize per Zone process <b>1505</b>. This step entails assessing the results of different kernels, parameters, and hyperparameters, and determining a particular model with kernel, parameter and hyperparameters, for use with the training data set, that represents a chosen “best fit” of the training data to provide acceptable results in location prediction. It will be understood that various different types of kernels may be employed in embodiments of the invention, and that different kernels may be used for the same training data, as a matter of selected performance and accuracy.
0248The result of the Parallelize per Zone process <b>1605</b> is a Data Model export file provided at step <b>1640</b>, one or more depending upon the choice of SVM kernels, parameters, and hyperparameters used to construct the data model. The Data Model export file, as illustrated in the accompanying table, is written to the model storage database <b>750</b>. The data items of the Data Model export file <b>1640</b> include but are not limited to the following: a user or customer identifier (CustomerLabel), a master space identifier (SiteLabel), a time stamp of the data of the survey used to construct the model (SessionStartTime), one or more zone identifiers (area, room, subspace), and model delimiters (<Model> . . . </Model>) encapsulating the data corresponding to the data model.
0249According to one aspect of this disclosure, the Data Model export file is stored in the model storage database <b>750</b> indexed and/or searchable by a parameter corresponding to identification of the “beacons heard”, that is, by a parameter that represents the particular beacons whose signal values from the initial survey scan are present. Data models are preferably retrieved for use in an object location operation by using a set of beacons, based on their identifiers, from the tag data package from the tag associated with the object to be found, to search in the model storage database for models that have a matching set of beacons. For example, and referring back to <figref idref="DRAWINGS">FIG. <b>12</b>D</figref>, note that the scan from the tag at prediction time included signals received from beacons B<b>1</b>, B<b>2</b>, B<b>7</b>, B<b>8</b>, and B<b>9</b>. These are the “beacons heard” by the tag. The data models Model R<b>1</b> and Model R<b>3</b> also have the same set of “beacons heard”. Thus, these particular data models are retrieved from the model storage database <b>750</b> for use in the object location operation, as will be described. Those skilled in the art will understand how to construct an efficient retrieval algorithm for data model retrieval.
0250<figref idref="DRAWINGS">FIG. <b>17</b></figref> illustrates a process <b>1700</b> used to implement an Object Location function or process. According to one aspect, a specific object <b>20</b> associated with a particular RF tag <b>25</b> located in a particular zone (area, room, subspace) is located in response to receipt at the disclosed object location system <b>10</b> of tag data package transmitted from an RF tag, and a room prediction data item (also known as a Zone Prediction) is returned by the process, which is then provided for use by the customer or user of the system <b>10</b> for its own purposes and applications. In accordance with one aspect, one or more ML data models are employed to conduct the room prediction, based on data accumulated during one or more surveys of the beacon signals that are receivable in the master space, as described above.
0251In one aspect, the Object Location process <b>1700</b> comprises several nested subroutines or subprocesses including a Parallelize for all inbound requests process <b>1710</b>, which is executed for each object location operation however invoked, and a Parallelize per sample process <b>1720</b>, which is executed for each collection of RF data samples in a tag data packaged received from the tag associated with the object to be located.
0252The Parallelize for all inbound requests process <b>1720</b> begins at step <b>1712</b>, where the system <b>10</b> has received a tag data package from a tag <b>25</b> associated with an object <b>20</b> to be located. The step <b>1712</b> is identified as Submit BLE scan with Cust/Site ID, indicating that the object location operation is invoked by providing an object location request data package <b>1714</b> that includes particular customer identifier (CustID), an identifier of the master space involved (SiteID), and a collection of RF data (RSSI values) associated with the RF beacon signals received by the tag from the one or more RF beacons within the to-be-identified subspace, and, the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals. As shown in <figref idref="DRAWINGS">FIG. <b>17</b></figref>, the data items associated with an object location request data package command or request to identify an object location include but are not limited to: a customer identifier (CustID), a master space identifier (SiteID), and one or more sets of “scans” comprising a beacon identifier and the RSSI values detected from that beacon and its one or more channels by the tag. Here is an exemplary format for an object location request data package as seen in <figref idref="DRAWINGS">FIG. <b>17</b></figref>:
0253<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>CustID: Acmelnc</entry></row><row><entry>SiteID: BeepBeep190</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="63pt" align="center" /><tbody valign="top"><row><entry>MAC address</entry><entry>Channel ID</entry><entry>RSSI</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="42pt" align="center" /><tbody valign="top"><row><entry>dcl8bdfl0</entry><entry>ch37</entry><entry>−45</entry><entry>−45</entry><entry>−50</entry></row><row><entry /><entry>ch38</entry><entry>−60</entry></row><row><entry>9381c8043</entry><entry>ch36</entry><entry>−45</entry><entry>−45</entry><entry>−50</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0254Upon receipt of this object location request data package <b>1714</b>, at step <b>1716</b> the model storage database <b>750</b> is accessed to obtain one or more prestored data models for the particular SiteID of the particular user of customer, as well as any required supplementary data (e.g., metadata further identifying locations, rooms, master spaces, street addresses, etc.) from the Customer Database <b>760</b>. Upon fetching of any data models (also known as Zone Models), a Parallelize Per Sample process <b>1720</b> is invoked.
0255At step <b>1725</b>, an array is filled with the RSSI data values/samples in the object location request data package (Fill X Array), and at step <b>1730</b>, a Parallelize Per Zone process <b>1730</b> is executed to obtain a prediction of whether the tag and associated object are predicted to be in or out of a particular zone (room, subspace.
0256The result of the Parallelize Per Zone process <b>1730</b> is one or more predictions of a particular zone (room, subspace) in which the tag <b>25</b> that provided the RSSI values received from the beacon(s) in the subspace. Typically, a plurality of predictions of rooms will be generated, as multiple data models will be employed for a room prediction. At step <b>1735</b>, these multiple room predictions are preferably sorted by “strength” i.e., which according to one aspect facilitates a calculation of a probability and/or use of a “weighted voting” scheme that the object is located in that particular room. Reference is made in this regard to <figref idref="DRAWINGS">FIG. <b>12</b></figref>, which is an exemplary table of RSSI values and room predictions. By sorting a table of this nature populated with RSSI values from the detected beacons in the columns by RSSI value, it will be seen that the predictions of Room A are more frequent than those of Room B.
0257A list or table of sorted room predictions such as shown in the example of <figref idref="DRAWINGS">FIG. <b>12</b></figref> is then inspected at step <b>1740</b> to consolidate, i.e., identify, any contradictory samples. For example, as in the example table in <figref idref="DRAWINGS">FIG. <b>11</b></figref>, the prediction of Room B may be in error, as three of four data models predicted Room A; Room B is therefore contradictory according to a voting scheme, as employed in one aspect, and may be eliminated as a room prediction, or used in a probability calculation. At step <b>1745</b> a response (a zone or subspace prediction) is formatted, and at step <b>1750</b> a zone (or room, subspace) prediction of location is provided as an output. A typical format of a zone prediction data package returned is shown at <b>1755</b>, and includes data items including but not limited to: customer or user identifier (CustID), a master space identifier (SiteID), and a result comprising a confidence level e.g. <b>0</b>.<b>983</b> representing a probably calculation, a zone or subspace or room identifier (Room A), and optionally, accompanying metadata such as a name of the zone or subspace obtained by reference to customer information e.g. “Storeroom SE Corner.”
0000Use of Static Object for Calibration and Object Location Determination Resolution
0258According to another aspect, a static or reference object is used for calibration of the disclosed object location system, as providing additional, static, stable reference data for use in a data model.
0259Referring back to <figref idref="DRAWINGS">FIG. <b>4</b></figref>, a stationary object <b>20</b><i>b </i>with associated tag <b>25</b><i>b </i>is shown positioned in Room D. The tag <b>25</b><i>b </i>need not be associated with an object but may provide a suitable indicator to the system that it is stationary. According to this aspect, the tag <b>25</b><i>b </i>is queried on some predetermined basis (e.g., periodically, on a set schedule, randomly, etc.) to provide a tag data package that comprises readings from a predetermined set of beacons whose signals are received by the tag <b>25</b><i>b</i>. For example, in <figref idref="DRAWINGS">FIG. <b>4</b></figref>, the tag <b>25</b><i>b </i>is shown receiving signals from beacons B<b>2</b>, B<b>4</b>, and B<b>5</b>. Signals from these beacons B<b>2</b>, B<b>4</b>, and B<b>5</b> were previously detected and used in generating one or more data models for Room D in a prior survey operation. Generally, it is expected that the signals from these beacons will remain consistent over time and that the RSSI values received by tags within Room D will only vary by a small, acceptable error, perhaps due to component drift, deterioration, temperature, or other factors. However, those skilled in the art will recognize that radio signals will change over time due to those factors. Furthermore, the radio signals received by the exemplary stationary tag <b>25</b><i>b</i>, as well as received by any tags and objects in a location operation, may be altered or affected by other changes in the environment. For example, the introduction of Faraday barriers or cages, removal or addition of structural features such as windows, doors, roof or ceiling materials, flooring, obstacles, items on a shelf, etc. may significantly alter the RF environment and change the signals received by the stationary tag <b>25</b><i>b. </i>
0260If the change is sufficiently nominal, there is no need to take any action. However, there may be an error margin that suggests, or mandates, that adjustments be made in the data model(s) to compensate for changes. According to an aspect, the system <b>10</b> is operative to access the stationary tag <b>25</b><i>b </i>from time to time, and log the beacon signals received by the tag, and process the log for a deviation of the RSSI values that are indicative of a change in the environment. Steps for accessing the tag <b>25</b><i>b </i>and monitoring for changes in the RF environment may include, but are not limited to: (a) transmit a trigger signal to the tag <b>25</b><i>b </i>to cause a sampling operation, (b) the tag <b>25</b><i>b </i>collects a set of data values for the beacons whose signals it detects, (c) the tag <b>25</b><i>b </i>transmits a tag data package to the object location system, (d) the object location system receives the transmitted data from the tag and stores it in a local database in association with data from this particular stationary tag (as well as any other stationary tags), (e) the system processes the data from the stationary tag to compare the readings with a calculated standard, (f) in the event that an error or deviation of the stationary tag data exceeds a predetermined threshold, an “action condition” is indicated and provided to a system operator. It will be understood that data from prior operations that has accumulated over a certain predetermined time period may be used to determine the predetermined threshold, e.g., a mean of RSSI values of the various detected beacons over a predetermined time period, a sliding/moving set of values, etc.
0261According to one aspect, in the event of an error of a predetermined magnitude, but less than a second predetermined magnitude that amounts to an error condition that needs attention, may be used for a calibration operation. In such an operation, the system operator may conclude that the beacons or other components are experiencing a drift of an acceptable degree over time, but not sufficient to indicate failure or unusability. In this exemplary case, the deviation amount may be used as the basis for a calibration adjustment of data values that were used to make up the data model(s). Therefore, the training data (and/or associated model) may be adjusted by adding a calibration value or offset to each prestored survey data item to compensate for the acceptable error or drift. From the foregoing, those skilled in the art will be enabled to provide computer program code to effect such calibration or error condition alerts.
0262Accordingly, it will now be understood that a monitored static object in a subspace provides for calibration and/or some degree of error compensation. In the event that the RF environment, shielding by other objects or structures, or other RF-affecting issues occur, a user of the system can continue to improve its model in ML iterations by knowing that the static object is still at its location but with alerts that the RF environment may have changed.
0263From the foregoing, it will now be appreciated that there is disclosed a system for location of objects within an identified subspace of a plurality of subspaces defined within a predefined master space. The disclosed system comprises a plurality of radio frequency (RF) emitting beacons positioned in a predetermined arrangement such that the RF energy from the RF beacons illuminates at least a portion of the predefined master space and one or more of the subspaces, each of the RF beacons located in a position spaced apart from other RF beacons, each of the RF beacons transmitting an RF beacon signal at a predetermined frequency and having a beacon identifier.
0264The system further comprises one or more RF transmitting and receiving tags in proximate association with objects to be located in the master space, the RF tag including (i) an electronic tag identifier, (ii) a tag receiver operative to receive RF beacon signals from one or more of the RF beacons as the tag assumes a position within the predefined master space, (iii) a tag data package assembler, and (iv) a tag transmitter operative to transmit a tag data package assembled by the tag data package assembler.
0265The system further comprises a models database for storing machine learning (ML) models.
0266The system further comprises an object location system including a radio gateway for receiving tag data packages transmitted by the RF transmitting and receiving tag, and a computer-implemented object location engine coupled to the radio gateway. In accordance with disclosed aspects of the system, the object location system is operative for: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0267">(a) for a predefined master space in which an object is to be located, in a master space survey operation, assigning a plurality of subspace identifiers to a plurality of subspaces having specific spatial boundaries within the master space and storing the subspace identifiers in a master space database for later association with RF signal data samples taken in a master space survey operation;</li><li id="ul0002-0002" num="0268">(b) conducting a master space survey operation by collecting data comprising RF signal data samples within the master space, generating one or more subspace data models from the RF signal data samples for use in connection with an object location operation, and storing the one or more subspace data models in the models database;</li><li id="ul0002-0003" num="0269">(c) for an object location operation to locate an object associated with a particular RF tag associated within a to-be-identified subspace within the master space, receiving RF beacon signals at the tag receiver from one or more of the RF beacons within the to-be-identified subspace within the master space, to thereby obtain a tag-specific RF beacon signal reading data comprising data derived from one or more RF beacon signals and their associated beacon identifiers within the to-be-identified subspace;</li><li id="ul0002-0004" num="0270">(d) at the tag data package assembler associated with the particular RF tag, using the RF beacon signal reading data, generating a tag data package comprising (i) a tag identifier of the particular RF tag, (ii) data associated with the RF beacon signals received from the one or more RF beacons within the to-be-identified subspace, and (iii) the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals;</li><li id="ul0002-0005" num="0271">(e) at the particular RF tag, transmitting the tag data package from the tag data package assembler via the tag transmitter of the RF tag;</li><li id="ul0002-0006" num="0272">(f) receiving a transmitted tag data package from the tag transmitter of the particular RF tag at the receiver associated with the radio gateway so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space;</li><li id="ul0002-0007" num="0273">(g) processing a tag data package received by the radio gateway receiver to extract the RF beacon signals received by the tag receiver in the particular RF tag associated with the object to be located in the to-be-identified subspace, the beacon identifiers, and the tag identifiers associated therewith;</li><li id="ul0002-0008" num="0274">(h) retrieving one or more stored subspace data models from the models database based on one or more beacon identifiers contained in the tag data package received from the tag associated with the object to be located;</li><li id="ul0002-0009" num="0275">(i) executing the retrieved one or more stored subspace data models using as input parameters the RF beacon signals extracted from the tag data package received from the tag associated with the object to be located, to identify one or more prediction candidates of subspaces in which the object may be located, each prediction candidate comprising a subspace identifier produced by execution of each of the subspace data models;</li><li id="ul0002-0010" num="0276">(j) processing the one or more prediction candidates with a selection operation to determine a particular one of the subspace identifiers as the selected subspace identifier in which the object is predicted by the system to be located and thereby generate a determined subspace identifier for the object; and</li><li id="ul0002-0011" num="0277">(k) based on the determined subspace identifier, providing a data output from the object location system as a data package identifying the particular tag and the determined subspace identifier to an external system, as indicating the location of the object associated with the tag.</li></ul></li></ul>
0278It also be appreciated that the identified subspace may be a physical subspace defined by physical boundaries including but not limited to as walls, ceiling, floors, and the like. The identified subspace may also be a virtual subspace defined by virtual boundaries within one or more physical rooms. The master space may be a building and the subspace may be a room in the building.
0279According to one aspect, the above-mentioned master space survey is conducted by the steps of: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0280">(1) receiving data from a sampling operation with a sampling RF receiver in a survey device, by collecting RF data in the plurality of subspaces within the predefined master space by collecting RF signal samples from one or more RF beacons at a plurality of sampling locations within each of the one or more of the subspaces in the predefined master space;</li><li id="ul0004-0002" num="0281">(2) for each of the subspaces, storing sampling data corresponding to said RF signal samples and beacon identifiers associated with the RF signal samples from the sampling receiver in a sampling database correlated with a sampling location corresponding to a particular one of the subspaces as indicated by a corresponding subspace identifier;</li><li id="ul0004-0003" num="0282">(3) generating one or more subspace data models of the subspaces by applying a machine learning (ML) algorithm to the sampling data in the sampling database; and</li><li id="ul0004-0004" num="0283">(4) storing the one or more subspace data models in an ML model database for later access in connection with an object location operation.</li></ul></li></ul>
0284In accordance with an aspect, the master space survey operation collects RF signal data from one or more identifiable RF signal sources (IRFSS) in addition to signal data from RF beacons, and wherein the one or more subspace data models are generated using data from said one or more IRFSS. The one or more IRFSS may include but are not limited to: Wi-Fi (IEEE 802.11) access points, Zigbee access points, Bluetooth transmitters, cellular network transmitters (2G-5G and beyond), AM/FM/shortwave/television transmitters.
0285According to one aspect, the RF signal data samples are in the form of received signal strength indicator (RSSI) data.
0286According to another aspect, the subspace data models are generated using a machine learning (ML) classification algorithm. The preferred ML classification algorithm is a support vector machine (SVM).
0287According to another aspect, a subspace data model comprises a collection of RF signal samples associated with each subspace identifier, associated beacon identifiers, and RSSI values taken in the master space survey operation, each of said data models predicting a particular subspace identifier. The subspace data models are preferably derived from multiple sampling operations conducted at different locations within each subspace of the master space.
0288According to a further aspect, each subspace is associated with a plurality of subspace data models, wherein the system is operative to generate a plurality of prediction candidates of subspaces in which the object may be located from a plurality of data models for each object location operation, and wherein the selection operation comprises determining an identified subspace for the object based on a voting algorithm executed on the plurality of prediction candidates. Preferably, the selection operation comprises a voting process based on the greatest number of instances of determination of a particular subspace identifier by one of a plurality of different stored subspace data models.
0289According to another aspect, the system further conducts steps whereby the data values derived from an object location operation are added to a database together with the data from the master space survey operation and used to dynamically update the subspace data models.
0290According to another aspect, the RF receiving and transmitting tag includes a signaling component, wherein a user is provided with a communication device for communicating to the system indicating proximity to a subspace identified as containing the tag, and wherein the system executes a “last ten feet” proximity operation to notify a user of proximity to the RF tag upon approach by the user having possession of the communication device, by actuating the signaling component. As disclosed, the signaling device may include one or more of a light, an audible sound generating device, a haptic signaling component.
0291According to one preferred aspect, the RF receiving and transmitting tag includes a motion sensor that is operative to trigger transmission of a tag data package in response to detection of movement of the tag.
0292According to another aspect, the system is further operative to automatically detect changes in the RF environment of the master space resulting from physical changes to the environment by detecting a change in RF signals from one or more beacons or other IFRSS during an object location operation, and update one or more subspace data models to compensate for the changed environment. In this regard, the system may be configured to automatically detect changes in the RF environment of the master space resulting from failure or degradation of one or more beacons by detecting a change in or absence of RF signals from one or more beacons during an object location operation, and update one or more subspace data models to compensate for the changed environment.
0293It will also now be appreciated that the present disclosure described a method for location of objects within an identified subspace defined within a predefined master space. The disclosed method comprises steps including: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0294">(a) for a predefined master space in which an object is to be located, in a master space survey operation, assigning a plurality of subspace identifiers to a plurality of subspaces having specific spatial boundaries within the master space and storing the subspace identifiers in a master space database for later association with RF signal data samples taken in a sampling operation;</li><li id="ul0006-0002" num="0295">(b) placing a plurality of radio frequency (RF) emitting beacons in a predetermined arrangement such that the RF energy from the RF beacons illuminates at least a portion of the predefined master space and one or more of the subspaces, each of the RF beacons located in a position spaced apart from other RF beacons, each of the RF beacons transmitting an RF beacon signal at a predetermined frequency and having a beacon identifier;</li><li id="ul0006-0003" num="0296">(c) conducting a master space survey operation by collecting data comprising RF signal data samples within the master space, generating one or more subspace data models from the RF signal data samples for use in connection with an object location operation, and storing the one or more subspace data models in the models database;</li><li id="ul0006-0004" num="0297">(d) for an object to be located within a particular subspace within the master space via an object location operation via an object location system, associating a RF transmitting and receiving tag with the object, the RF tag including (i) an electronic tag identifier, (ii) a tag receiver operative to receive RF beacon signals from one or more of the RF beacons as the tag assumes a position within the predefined master space, (iii) a tag data package assembler, and (iv) a tag transmitter operative to transmit a tag data package assembled by the tag data package assembler;</li><li id="ul0006-0005" num="0298">(e) for an object location operation, at particular RF tag associated with an object to be located within a to-be-identified subspace via the object location operation within the master space, receiving RF beacon signals at the tag receiver from one or more of the RF beacons as the object assumes a position within the to-be-identified subspace within the master space, to thereby obtain a tag-specific RF beacon signal reading data comprising data derived from one or more RF beacon signals and their associated beacon identifiers within the to-be-identified subspace;</li><li id="ul0006-0006" num="0299">(f) at the tag data package assembler associated with the particular RF tag, using the RF beacon signal reading data, generating a tag data package comprising (i) a tag identifier of the particular RF tag, (ii) data associated with the RF beacon signals received from the one or more RF beacons within the to-be-identified subspace, and (iii) the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals;</li><li id="ul0006-0007" num="0300">(g) at the particular RF tag, transmitting the tag data package from the tag data package assembler via the tag transmitter of the RF tag;</li><li id="ul0006-0008" num="0301">(h) at an object location system, receiving a transmitted tag data package from the tag transmitter of the particular RF tag at receiver associated with a radio gateway so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space;</li><li id="ul0006-0009" num="0302">(i) at the object location system, processing a tag data package received by the radio gateway receiver to extract the RF beacon signals received by the tag receiver in the particular RF tag associated with the object to be located in the to-be-identified subspace, the beacon identifiers, and the tag identifiers associated therewith;</li><li id="ul0006-0010" num="0303">(j) with the object location system, retrieving one or more stored subspace data models from the ML database based on one or more beacon identifiers contained in the tag data package received from the tag associated with the object to be located;</li><li id="ul0006-0011" num="0304">(k) with the object location system, executing the retrieved one or more stored subspace data models using as input parameters the RF beacon signals extracted from the tag data package received from the tag associated with the object to be located, to identify one or more prediction candidates of subspaces in which the object may be located, each prediction candidate comprising a subspace identifier produced by execution of each of the subspace data models;</li><li id="ul0006-0012" num="0305">(l) processing the one or more prediction candidate with a selection operation to determine a particular one of the subspace identifiers as the selected subspace identifier in which the object is predicted by the system to be located and thereby generate a determined subspace identifier for the object;</li><li id="ul0006-0013" num="0306">(m) based on the determined subspace identifier, providing a data output from the object location system as a data package identifying the particular tag and the determined subspace identifier to an external system, as indicating the location of the object associated with the tag.</li></ul></li></ul>
0307<figref idref="DRAWINGS">FIG. <b>18</b></figref> illustrates aspects of deployment of an object location system <b>10</b> and associated methods, constructed and operated as described in this disclosure, for purposes of locating one or more exemplary objects <b>20</b> (e.g., <b>20</b><i>a</i>, <b>20</b><i>b</i>) that are each associated with an RF beacon B (e.g., B<b>1</b>, B<b>2</b>), according to one initial aspect. <figref idref="DRAWINGS">FIG. <b>18</b></figref> shows an exemplary spatial environment such as a multi-story building <b>30</b> that is considered a “master space.” The building or master space <b>30</b> is typically three-dimensional (3D) and comprises a plurality of subspaces or rooms identified as Room A, Room B, Room C, and Room D. It will of course be appreciated that the number of rooms or subspaces is arbitrary and can vary. The subspaces or rooms can be actual physical rooms defined by physical barriers such as floors, walls, ceiling, or can be virtual rooms with virtual boundaries. A virtual room can encompass more than one physical room or can define a smaller subspace within a physical room. For example, Room A in <figref idref="DRAWINGS">FIG. <b>18</b></figref> is a virtual room that extends across two physical rooms, Room <b>1</b> (R<b>1</b>) and Room <b>2</b> (R<b>2</b>), which are separated by a wall (W). Room C is a virtual room within Room <b>2</b> and shares the physical space with Room A. Room B on the other hand is solely contained within physical Room <b>3</b> (R<b>3</b>), as is Room D is physically the same as Room <b>4</b> (R<b>4</b>).
0308In accordance with one aspect of this disclosure, the master space <b>30</b> is preconfigured with installation of a plurality of RF tags identified as <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>c</i>, etc., for example, dispersed throughout the master space so as to receive RF energy from the beacons irradiating the space and contained subspaces or rooms. The RF tags and beacons are constructed as described elsewhere herein. The RF tags are preferably distributed so that each position of the beacon within the master space may communicate at least one signal with at least one tag, and preferably such that each position of the beacon may communicate signals with multiple tags.
0309In accordance with a preferred aspect, the beacons B employed in disclosed embodiments are Bluetooth Low Energy (BLE) radio beacons that are disposed on and associated with objects <b>20</b>. One example of a beacon that may be used in accordance with aspects of this disclosure is the i10 Indoor Beacon manufactured by Shenzhen Minew Technologies Co. Ltd., Shenzhen, China, also known as Minew Tech, details of which are available from the manufacturer. Other similar devices may also be used.
0310It is preferred that a plurality of tags will be disposed throughout the master space, spaced apart such that each room or subspace will be irradiated/illuminated by RF energy of sufficient magnitude such that an RF tag, as described herein, will receive RF beacon signals from at least one beacon, and preferably from a plurality of beacons, and preferably at least two beacons. Signals from more than about 4-6 beacons may impact the performance and response time of a location operation, although some applications may require or prefer a larger number of beacons. In some implementations, the latency is improved since the one or more beacons transmit the signals to the one or more tags in such a manner that the tags start receiving the signals from the beacons at the time when the beacon is located within a predetermined distance from the one or more tags. Therefore, in comparison to other embodiments (for example, wherein the beacons are disposed in the subspaces and the tags are associated with the objects), the beacons that are associated with the tracked objects and that radiate in search of the tags facilitate the lower latency because the beacon may communicate to the tags the presence of the object associated with the beacon at the time when the beacon and the object associated with the beacon located within the subspace. Thus, the energy can also be saved in such implementation since the tags disposed within the subspace start receiving beacon signal when the beacon and the object associated with the beacon is located within the predetermined distance from the tags in that particular subspace.
0311According to one aspect, the beacons B transmit their beacon signals on a predetermined basis, established by the system operator. The beacons may be configured to transmit on a regular basis, such as periodically or on a predetermined timing schedule, or to transmit on demand. Also, the tags could be configured to receive “on demand”, for example, only during a survey operation, or during an object location operation. An “on demand” configuration requires some type of communication and command structure at the tag, so that the tag could receive a signal from the system <b>10</b> containing a command to receive. A timing schedule requires a time synchronization function at the tag, so that tags can be in a receive mode at the time that the beacons are transmitting.
0312Although a set of preplaced tags <b>25</b> is a preferred configuration for a system <b>10</b>, it will be understood that the system may also operate in conjunction with other identifiable RS signal sources (IRFSS). Considerations of using other IRFSS to provide RF samples include the availability of preexisting radio sources, the strength/magnitude of signals from such sources as seen within the master space, the ability of the tags to receive signals from other IRFSS, identifying information or characteristics of the other IRFSS signals that allow use in constructing data models, the stability of such other IRFSS as to movement and signal characteristics, the presence of obstructions to or interference for signals from the IRFSS, and the like. Suitable candidates for other IRFSS include Wi-Fi access points, Bluetooth transceivers, AM/FM/shortwave/television transmitters in the vicinity of the master space, air navigation beacons, cellular network towers, etc. Other types of RF sources may occur to those skilled in the art. Thus, in some embodiments, the object location system <b>10</b> may utilize the tags <b>25</b> that are typically already disposed in the master space <b>30</b>, such as the Wi-Fi access points, Bluetooth transceivers, etc. Also, in such configuration where the beacons B are associated with the objects <b>20</b>, the latency may be improved since the tags <b>25</b> may communicate with each other and a fewer number of the tags <b>25</b> that previously gathered the respective tag data packages from other tags <b>25</b> may transmit the assembled tag data packages to the object location system <b>10</b>.
0313In <figref idref="DRAWINGS">FIG. <b>18</b></figref>, the tags <b>25</b> are prepositioned within the master space at predetermined strategic locations, for purposes of receiving signals from a plurality of beacons B in one or more rooms or subspaces of the master space <b>30</b>. Having the beacon B disposed on the object <b>20</b> provides an additional benefit of reducing the cost of the object location system <b>10</b>. In such configuration, the object location system <b>10</b> has a smaller number of beacons B associated with the objects <b>20</b>. Because typically the cost of the beacon B is higher than the cost of the tag <b>25</b>, utilizing the smaller number of beacons B, reduces the overall cost of the object location system <b>10</b> even if the number of the tags <b>25</b> may be greater than in the other object location system <b>10</b>.
0314In some embodiments, the beacon B<b>1</b> associated with object <b>20</b><i>a</i>, in virtual Room A, transmits signals to four exemplary tags: <b>25</b><i>a</i>, <b>25</b><i>b </i>on the same floor of the master space <b>30</b>, and also to <b>25</b><i>c</i>, <b>25</b><i>d </i>on an adjacent but upper floor. Similarly, beacon B<b>2</b> on object <b>20</b><i>b </i>in Room D transmits signals to tags <b>25</b><i>b</i>, <b>25</b><i>d</i>, <b>25</b><i>e</i>. In accordance with aspects of this disclosure, each tag <b>25</b><i>a</i>, <b>25</b><i>b </i>communicates with the object location system <b>10</b> by transmitting a tag data package, as described elsewhere herein, via a separate RF communication channel, also as described elsewhere, on a predetermined communication basis and protocol. The disclosed object location system <b>10</b> then determines the location of the objects <b>20</b> within the master space <b>30</b>, typically by identifying a particular room or subspace that has been determined as containing the object <b>20</b>. The object location system <b>10</b> typically then provides an object location data package, as described elsewhere herein, via a data communications network <b>40</b>, e.g., the Internet, to customer applications <b>50</b>. Customer applications <b>50</b> may vary widely, as determined by a user of the system <b>10</b> that desires to locate and/or track the movement of objects <b>20</b> within the master space.
0315Also shown in <figref idref="DRAWINGS">FIG. <b>18</b></figref> are a number of sample points identified as S<b>1</b>, S<b>2</b>, S<b>3</b>, . . . Sn. In accordance with an aspect of this disclosure, objects are located by use of and reference to a data model of the RF environment of the master space <b>30</b> developed by taking RF signal samples at sample locations S, as described elsewhere herein. The data model of the space is constructed by a survey process involving the collection of RF data samples at various locations within various subspaces within the master space, e.g., samples S<b>1</b>, S<b>2</b>, . . . Sn, typically with RSSI data. Those samples are stored in a sampling database, described elsewhere, and associated with specific identified subspaces. The collection of data samples and associated identified subspaces are processed with a machine learning (ML) algorithm so as to generate a data model that provides the basis for a later determination of an object location. As more fully described elsewhere, a tag data package that includes data received from an RF beacon B associated with a particular object <b>20</b> to be located is processed by reference to the data model, to generate a prediction candidate of a specific subspace or room in which the beacon B, and hence the associated object <b>20</b>, is most likely to be located. Aspects of the data model, survey operation, etc. are described in more detail below.
0316<figref idref="DRAWINGS">FIG. <b>19</b></figref> illustrates the exemplary master space <b>30</b> in a three-dimensional (3D) view, so as to illustrate the multi-room, multi-dimensional aspects of object location, as compared to the more two-dimensional (flat) view in <figref idref="DRAWINGS">FIG. <b>18</b></figref>. <figref idref="DRAWINGS">FIG. <b>19</b></figref> shows the object <b>20</b> and associated RF beacon B, located within Room A. The RF beacon B transmits BLE signals to multiple RF tags, e.g., <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>c</i>, <b>25</b><i>d</i>, as in <figref idref="DRAWINGS">FIG. <b>18</b></figref>. This view illustrates that the tags <b>25</b> are typically dispersed throughout the master space and need not be in the same room or subspaces as any particular object to be located. Likewise, the tags may be dispersed on different levels within the master space, provided that, preferably, the beacon B in any location within a subspace in which an object associated with the beacon B is to be located transmits signals to at least one tag and preferably multiple tags. Accordingly, the signals transmitted by beacons B and received by the tags employed in aspects of this disclosure are of sufficient magnitude to cover multiple rooms or subspaces. This contrasts with approaches that use low power or passive RFID tags, which typically have a very limited range.
0317Also as shown in <figref idref="DRAWINGS">FIG. <b>18</b></figref>, the master space <b>30</b> has been sampled by a prior sampling operation or process, as described elsewhere, so that a data model of the 3D space is constructed and utilized for object location, by reference to multiple RSSI samples S<b>1</b>, S<b>2</b>, . . . Sn of the RF environment of the master space and its associated subspaces or rooms.
0318<figref idref="DRAWINGS">FIG. <b>20</b></figref> illustrates a survey process or operation for purposes of collecting RSSI data samples at various sampling locations S<b>1</b>, S<b>2</b>, . . . Sn throughout the master space <b>30</b> and its associated subspaces, e.g., Room A, Room B, Room C, Room D, in accordance with aspects of this disclosure. The survey process is typically conducted by a person or a mobile machine (e.g., a robot, drone, or other autonomous mobile machine) that carries an RF scanning or room survey device <b>60</b>. The survey device <b>60</b> comprises a BLE signal transmitter (not shown) that transmits signals to a number of RF tags, e.g. to <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>d</i>, etc., allows entry of data identifying a physical or virtual subspace or room, e.g. Room B in the example of <figref idref="DRAWINGS">FIG. <b>20</b></figref>, receives data from the RF tags, and transmits a set of RF signal samples, tag identifiers, and information used for subspace identification, via a radio transmitter associated with the survey device <b>60</b>, to the object location system. This data is then used for model construction and maintenance. According to another aspect, a survey tool comprising a plurality of RF beacons B as described herein may be deployed within the master space and subspaces as the survey device <b>60</b>; data obtained from the plurality of RF beacons B may be used as the survey data.
0319It will be appreciated that the survey device <b>60</b> may also include other RF receivers for purposes of using RF signals from other identifiable RF signal sources (IRFSS), which can also be used in model construction. For example, and as shown elsewhere, RF signals from IEEE 802.11 (Wi-Fi), cellular networks, GPS satellites, AM/FM/shortwave, television, or other known, and typically locationally and carrier-signal stable RF sources, can be used in alternative embodiments. To use such other IRFSS signals, the survey device will require a compatible receiver and associated components and/or software for determining appropriate RF signal characteristics (RSSI) and associating it with identification information about the IRFSS.
0320It will be appreciated that a survey operation typically involves taking RSSI samples at various locations, e.g., S<b>1</b>, S<b>2</b>, . . . Sn within a particular subspace, so as to “visit” and obtain RSSI samples within a variety of different locations, elevations, rooms, near and away from obstacles, etc., so as to create a thorough map of the RF environment illuminating the plurality of tags <b>25</b> or other IRFSS. It will also be appreciated that one or more surveys may be conducted to construct a data model, and subsequent surveys may be conducted to update or maintain the data model to compensate for changes in the environment that may result from things such as addition or removal of walls, doors, windows, shelving, roofs, RF shielding/Faraday barriers, stacks of objects, furniture, and any number of things that might affect the transmissibility and reception of RF signals by the tags <b>25</b> or other IRFSS from RF beacons B associated with objects.
0321<figref idref="DRAWINGS">FIG. <b>21</b></figref> illustrates a master space <b>30</b> and use of a stationary object <b>20</b><i>b </i>with associated beacon B<b>2</b> for purposes of data model stabilization or calibration, in accordance with one aspect of the present disclosure. <figref idref="DRAWINGS">FIG. <b>21</b></figref> also illustrates aspects of movement of an object <b>20</b><i>a </i>in Room A to a second position in Room C at <b>20</b><i>a</i>′ for purposes of object tracking within the master space, in a particular application.
0322In accordance with one aspect, the master space may be provided with one or more stationary or “reference” objects <b>20</b> and/or beacons B, positioned at various locations within the master space, within one or more subspaces, actual or virtual. For example, consider that the object <b>20</b><i>b </i>and its associated RF beacon B<b>2</b>, are positioned within Room D, in a position where it cannot be readily moved. For example, the object <b>20</b> and/or beacon B could be fastened to a wall or floor, or placed in a position that is not readily accessible such as in a special space. The stationary RF beacon B<b>2</b> need not even be associated with an object, but could represent a “virtual” object, as the primary purpose of a stationary object or beacon is to provide object data packages identifying the stationary object and/or beacon at various times. This allows the system to monitor for changes in the RF environment that might result from changes to the physical space or placement of objects or Faraday cage type objects within the space that could affect the reception by the tags of the signals transmitted by the beacons associated with the objects that are to be located.
0323It should be understood that it is not necessary to use stationary objects and/or stationary beacons B in order to monitor for changes in the RF environment that might result from changes to the physical space or placement of objects or Faraday cage type objects or barriers within the space that could affect the reception by the tags of the signals transmitted by the beacons associated with the objects that are to be located. In accordance with one preferred aspect of operation, RF tags <b>25</b> as described herein transmit data (representing the beacon signals received by such tags) on a predetermined basis (e.g., periodically, on demand, etc.) to the object location system <b>10</b> for use in constructing and training data models for object location. Data scans collected from any tags within the master space, including signals from whether moving, stationary, or temporarily stationary beacons, provide a corresponding flow of RSSI values that can be used to construct additional data models as described herein and/or update existing models for use in locating objects.
0324According to one aspect, a stationary object <b>20</b><i>b </i>(physical or virtual) and associated stationary beacon B<b>2</b> may transmit signals to the tags <b>25</b> that in turn transmit tag data packages at certain predetermined intervals or times to the object location system <b>10</b>. For example, the stationary object data packages may be transmitted at predetermined intervals, e.g., each hour, day, week, etc., or alternatively at particular times on a predetermined schedule, or if the beacon B is configured to receive a prompt or trigger signal, upon command from the object location system <b>10</b> or from a tag <b>25</b>. For example, one or more tags <b>25</b> could be configured to transmit a prompt signal on some predetermined basis to one or more beacons B, and the beacons B configured to respond on a predetermined basis to transmit a data package, independently of a current location operation.
0325According to another aspect, <figref idref="DRAWINGS">FIG. <b>21</b></figref> also shows the optional use of an auxiliary object location system (OLS) receiver or gateway <b>65</b>, which may be deployed for purposes of collecting tag data packages at various other locations within the master space <b>30</b>. According to this alternative and optional aspect, it will be appreciated that one or more auxiliary OLS receivers <b>65</b> may be deployed within the master space (only one is shown in <figref idref="DRAWINGS">FIG. <b>21</b></figref>) so as to provide for redundancy in receiving signals from RF tags <b>25</b>, in case of failure of a receiver at the OLS system <b>10</b> or signal reception complications that might result from reconfiguration of the master space or its subspaces, or placement of obstacles such as Faraday barrier type obstacles that might affect transmission of signals from the tags to the object location system <b>10</b>.
0326In accordance with one aspect of the present disclosure, the beacon B<b>2</b> associated with a stationary object <b>20</b><i>b </i>should in most instances transmit constant and/or consistent beacon signals to the various tags which are proximate enough to the stationary object to be reliably received by the tags. In the event that the system detects changes in the RSSI of beacon signals received from a stationary beacon such as B<b>2</b>, the system can take action in compensation. For example, the system can generate an alert to changes in the RF environment. As another example, and preferably, the system can update a data model of the master space in the event of determination that a permanent or persistent change to the RF environment has occurred. This can obviate a further survey of the master space to adjust for environmental changes, tag failures, etc., or at least allow temporary adjustment in a data model until such time as a re-survey may be desirable.
0327Still referring to <figref idref="DRAWINGS">FIG. <b>21</b></figref>, another aspect of the present disclosure involves the tracking of movement of an object, e.g., object <b>20</b><i>a </i>and its associated RF beacon B<b>1</b>, from one location to another within the master space. As shown in this figure, assume that the object <b>20</b><i>a </i>and beacon B<b>1</b> move within Room A (which is virtual in the example discussed) to another physical room on the other side of wall W, but still within Room A, to assume position <b>20</b><i>a</i>′, B<b>1</b>′. In accordance with an aspect of this disclosure, movement of an object might trigger a transmission of a beacon data package that contains a data item indicating object movement. For example, the RF beacon B may include a motion sensor that detects a predetermined degree of movement of an object. This motion sensor can be used to trigger transmission of a beacon data package from the beacon. The beacon data package is transmitted to the one or more tags that further transmit to the object location system <b>10</b> the tag data package(s) including this beacon data package. Thus, the object location system <b>10</b> can indicate object movement. Such object movement may be for purposes of following or tracking an object, warning of theft or tampering or handling of an object, etc. According to another aspect, if the object location system is associated with an object location database (not shown), or a customer maintains such an object location database, for the purpose of associating a present location of an object with a particular location, a movement indication could be used to update the database automatically. Such an object location database could be maintained by or in association with the disclosed object location system <b>10</b>, or maintained by a customer who receives object location information from the disclosed object location system for its own private purposes.
0328<figref idref="DRAWINGS">FIG. <b>22</b></figref> illustrates how a change in the RF environment of the master space <b>30</b> may be detected and adjusted for, in accordance with an aspect of this disclosure. <figref idref="DRAWINGS">FIG. <b>22</b></figref> differs from <figref idref="DRAWINGS">FIG. <b>18</b></figref> in that the master space <b>30</b> shows the object <b>20</b><i>a </i>and its associated RF beacon B<b>1</b> is in the same position in Room A as in <figref idref="DRAWINGS">FIG. <b>18</b></figref>, but is partially shielded by a Faraday cage or barrier type object, e.g., an additional wall W<b>2</b> made of metal. Those skilled in the art will understand and appreciate that metal constructions such as walls, screens, boxes, shelving, etc. affect the transmissibility of radio signals of certain frequencies, amplitudes, and modulation schemes. In some instances, the addition or movement of such Faraday cage type object can affect the reception of beacon signals by RF tags, and/or RF signals from IRFSS, whether or not the objects have been moved or handled.
0329As seen in <figref idref="DRAWINGS">FIG. <b>22</b></figref>, compared to <figref idref="DRAWINGS">FIG. <b>18</b></figref>, the RF beacon signals received by tags <b>25</b><i>a </i>and <b>25</b> care obstructed by the metal wall W<b>2</b>, which reduces the signal strength received by these two tags as they are transmitted by the RF beacon B<b>1</b> associated with object <b>20</b><i>a</i>. In some cases, a metal wall or other Faraday cage type object may actual completely block signals at certain frequencies and amplitudes, thereby removing signals from some sources from use in object location, at least until adjustments can be made to a data model.
0330In accordance with one aspect, the disclosed object location system <b>10</b> adjusts to the addition of this and other RF-signal-affecting obstacles or barriers in several different ways. According to one aspect, the addition of the metal wall W<b>2</b> could be detected automatically, especially in cases where one or more stationary objects such as shown in <figref idref="DRAWINGS">FIG. <b>21</b></figref> are utilized, and the altered RF signals from the stationary object are discovered or detected as having changed from a previous transmission from the RF beacon B associated with the stationary object <b>20</b>. The changed RSSI data values from a transmission occurring subsequent to the addition of the wall is added to the data model. In subsequent object location operations, the updated data model will then reflect the changed RF environment and the object can still be reliably located.
0331According to another aspect, the operator of the object location system <b>10</b> is notified of the addition of the obstruction of wall W<b>2</b>, and can re-survey the area affected, e.g., Rooms A and B can be re-surveyed and the data model updated. According to yet another aspect, assume that the object <b>20</b> and its associated RF beacon B has previously communicated its location to the object location system, in a prior location operation. The fact of addition of the metal wall W<b>2</b>, or at least the occurrence of some change to the RF environment, is automatically detected by comparing the RSSI signals from a first object location operation (or other beacon signal communication) to the signals from a second or subsequent object location operation (or other beacon signal communication), and either automatically updating the data model or generating an alert to a system operator of a change in the RF environment that may require a re-survey operation or other remedial action.
0332According to yet another aspect, and also as shown in <figref idref="DRAWINGS">FIG. <b>22</b></figref>, in a similar manner a change in the RF environment may occur in the event of failure or faulty operation of a tag. For example, note in <figref idref="DRAWINGS">FIG. <b>22</b></figref> that tag <b>25</b><i>b </i>in Room C has failed, such that it is not transmitting its RF tag signal. In this example, object <b>20</b><i>b </i>and its associated RF beacon B<b>2</b> no longer communicates beacon signals to tag <b>25</b><i>b</i>, but still communicates beacon signals to tags <b>25</b><i>d </i>and <b>25</b><i>e</i>. Likewise, object <b>20</b><i>a </i>and its associated RF beacon B<b>1</b> no longer communicates beacon signals to the tag <b>25</b><i>b</i>, but still communicates beacon signals to tags <b>25</b><i>a</i>, <b>25</b><i>c</i>, and <b>25</b><i>d</i>. In a manner similar to that described above, the disclosed system adjusts for the loss of signal not received by tag <b>25</b><i>b </i>in various ways as described above, e.g., by updating the data model, alerting of the failure of the tag <b>25</b><i>b</i>, etc. The detection of the altered RF environment takes place automatically or in response to an alert of the change and possible repair or replacement of the failed tag <b>25</b><i>b. </i>
0333In accordance with the above-described aspects of diminished signals received by tags <b>25</b> or other IRFSS, or failed tags <b>25</b>, a process of updating and/or reinforcement of a data model can be executed, so that a change in the RF environment of a master space can be dynamically updated for subsequent object location operations. By way of example and not limitation, see the discussion below associated with <figref idref="DRAWINGS">FIG. <b>30</b></figref> as regards data obtained by additional or reinforcement scans.
0000Object Location System
0334Turn now to <figref idref="DRAWINGS">FIG. <b>24</b></figref> for a detailed description of the disclosed object location system <b>10</b>, constructed and operated in accordance with aspects of this disclosure. The disclosed object location system (OLS) <b>10</b> comprises four major components: an object location engine <b>700</b>, a location data gateway <b>710</b>, location services <b>720</b>, and customer services <b>770</b>. Details of these major components are described in more detail below.
0335According to one aspect, the location data gateway <b>710</b> comprises a UHF (ultra-high frequency) radio gateway <b>712</b> for communicating with the disclosed tag <b>25</b>, as well as other location data gateways <b>715</b> for receiving location information from other sources such as other identifiable RF signal sources (IRFSS). Although the RF signals from tags <b>25</b> and from other IRFSS may be different frequencies, bands, magnitudes, RSSI, etc., it will be appreciated that the principles of usage of such signals and their associated identifying data is the same. Thus, the remarks which follow as to operations of a UHF radio gateway <b>712</b> apply also to other location data sources <b>715</b>.
0336The UHF radio gateway <b>712</b> may be constructed using a RadioCloud® UHF radio gateway manufactured by Cognosos, Inc., Atlanta, GA. Details of this UHF radio gateway are available in the literature supplied by the manufacturer.
0337The UHF radio gateway <b>712</b> is configured and operative to receive UHF radio signals transmitted from time to time, or upon demand, from one or more RF tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, . . . <b>25</b><i>n</i>, that transmit tag data packages that include beacon data packages received from one or more RF beacons B<b>1</b>, B<b>2</b>, Bn associated with one or more objects <b>20</b><i>a</i>, <b>20</b><i>b</i>, . . . <b>20</b><i>n </i>to be located within a particular subspace or room within a master space <b>30</b>, as shown in prior drawing figures. As discussed previously and elsewhere herein, each of the plurality of RF tags <b>25</b> is operative to receive RF beacon signals from one or more RF beacons B<b>1</b>, B<b>2</b> . . . Bn. Alternatively, or in addition, the RF tags may be configured to receive other RF signals from other IRFSS transmitters. In accordance with one aspect, the UHF radio signals from the tags contain tag data packages from the tags that receive the beacon signals from the beacon that is associated with the object, as described herein. In accordance with another aspect, the radio signals from other IRFSS transmitters are associated with identifying information such as frequency, initial RSSI, directionality, or information or content associated with the signal to allow its identification.
0338The UHF radio gateway <b>712</b> may be positioned within the master space, or alternatively may be configured to connect with remote or “gateway” receivers positioned within or near the master space and communicate the data packages from the receiver(s) in the radio gateway for demodulation and data package disassembly.
0339According to one aspect, the preferred UHF radio gateway <b>712</b> is operative for receiving one or more transmitted tag data packages, transmitted in a predetermined modulation scheme, from the tag transmitters of one or more RF tags <b>25</b> at one or more gateway receivers (not separately shown) within operative proximity to the master space, so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space. Preferably, the received tag data packages are demodulated by the gateway receivers, either stand-alone receivers or receivers associated with the UHF radio gateway <b>712</b>, and disassembled into the discrete data items forming the data packages. Typically, a tag data package includes data items corresponding to (i) a tag identifier that identifies a particular RF tag, (ii) data representing the RSSI values of all RF beacons whose signals were received by the RF tag, (iii) beacon identifier data items representing the identification of the beacons whose signals were received by a tag, associated with the RSSI values of the signals from each distinct beacon.
0340Alternatively, or in addition, the frequency of the signal received from a beacon may be used as a data item included in the tag data package.
0341As a further alternative, or in addition, data associated with a signal received from one or more IRFSS transmitters may be included as a part of a tag data package or may form an independent tag data package independent of a tag data package from a beacon. For example, an independent tag data package may include, for an IRFSS transmitter signal of a given source, (i) the frequency of the signal, (ii) the RSSI value of the signal, (iii) content transmitted by the IRFSS transmitter that assists in identification of the signal source, (iv) phase, timing, or directionality information derived from the IRFSS relative to receipt of the same signal by other receivers in the system. Any or all of such additional information may be used in aspects of the disclosed system to form data in the data model and used for location of objects that can receive such beacon and/or other IRFSS signals.
0342The object location system <b>10</b> further comprises an object location engine <b>700</b> whose principal function is to generate and maintain one or more data models used in machine learning (ML) of the RF characteristics, among other things, of the master space, allow assignment of subspaces within the master space, and access the ML data models in locating objects. Primarily, and generally speaking, the object location engine <b>700</b> is the computer-implemented component that processes tag data packages received by gateway receiver(s) to extract the RF beacon signals received by the tag receivers in the plurality of RF tags <b>25</b>, wherein the beacon signals are transmitted by the RF beacons B associated with objects <b>20</b> to be located in the to-be-identified subspaces, the tag identifiers, and, the beacon identifiers associated therewith, so as to provide a specifically identified subspace or room (i.e. a location) for a specific RF beacon B and its associated object <b>20</b> within the master space.
0343The object location engine <b>700</b> comprises several major software-implemented components, for example, an application programming interface (API) gateway for connection to the location data gateway <b>710</b>, a location integration module or service, a packet pre-processing module or service, a rules engine, a model training model or service, a model lookup and prediction module or service, and database storage module or services. Details of these primary components are described in greater detail in connection with other figures. The API gateway for the UHF radio gateway receives signals from the various RF tags during their operation, as well as signals from a surveying device as described above.
0344Still referring to <figref idref="DRAWINGS">FIG. <b>24</b></figref>, the object location engine <b>700</b> provides location information to location services <b>720</b>, primarily in the form of object identifier data, location data, and other associated data such as a timestamp, security information, customer identification information, and any other information that may be useful by customers in connection with object location. Location services <b>720</b> are computer-implemented and may reside within and implemented by the object location system <b>10</b>, or customers may construct their own location applications locally with use of the location data provided by the system <b>10</b>. Location services <b>720</b> can include an API so that a customer (not shown) can communicate via the network <b>40</b> with the object location system <b>10</b>, to provide data such as object identifiers for use by the system <b>10</b> in its location operations, on-demand signals to trigger an RF beacon B to illuminate an LED or other indicator, or provide an audible sound, to assist in “last ten feet” location or object presence verification.
0345In addition, the location services <b>720</b> provides an abstraction layer over the object location engine <b>700</b>, such that customer services <b>770</b> is decoupled from the specific implementation. For instance, the object location engine <b>700</b> can be further modified, replaced, or augmented by other systems and techniques comprising location services <b>720</b>, for providing alternative, confirming, or supplementary location information for the master space, associated subspaces, and/or objects to be located. Thus, as shown in <figref idref="DRAWINGS">FIG. <b>24</b></figref>, location services can be provided to the network <b>40</b> for use by customer applications <b>780</b> independently of the customer services functions <b>770</b>.
0346Those skilled in the art will understand and appreciate the wide variety of customer applications that can be constructed using the object location information provided in various aspects of this disclosure.
0347Typically, a customer or user of the system <b>10</b> will communicate with the system to conduct object location operations via computer-implemented customer services <b>770</b>. The customer services <b>770</b> comprises a number of communication functions accessed via an application programming interface (API) that allows customers or users to provide its information to the system <b>10</b> and receive outputs indicating object location. Details of customer services are discretionary with users of the system, and will not be further described herein, as aspects of such services will be apparent to those skilled in the art.
0348Also shown in <figref idref="DRAWINGS">FIG. <b>24</b></figref> are several primary databases used by the disclosed object location system <b>10</b> to implement its functions. For example, a survey database <b>730</b> is used to store data obtained during a survey operation, such as RSSI data provided by a survey device <b>60</b> (<figref idref="DRAWINGS">FIG. <b>20</b></figref>) in association with a subspace or room identifier. Data in the survey database is used to construct a data model showing expected RSSI values at various locations within the master space, within particular identified subspaces.
0349Another database is a training database <b>740</b>. This database stores data derived from the survey database in a format that is used to train a machine learning data model to represent the master space and its subspaces. The training database <b>740</b> is preferably constructed initially with the survey data, but once a data model is constructed using specific RSSI data values associated with their respective identified room, the training data is preferably held static (i.e., not changed) until a decision is made to update or maintain the data used for model construction and training.
0350Alternatively, or in addition, the training database <b>740</b> and the survey databases <b>730</b> can be the same database. It will be understood that one purpose of a maintaining a training database separately from a survey database is to preserve historical information as to a particular layout of a space. Once a model has been created and used for object location operations, and in the event of an embodiment wherein the data values from survey and object location operations are updated, the model is then dynamically updated as operations or changes to the environment occur. According to one aspect, there is no need to maintain a separate survey database and training database.
0351Yet another database is a model storage database <b>750</b>. The model storage database stores data representing one or more data models which are used for object location candidate prediction, as described elsewhere. In accordance with an aspect of this disclosure, object location is effected by receiving RSSI data values in a tag data package received from RF tags that contain data received from a particular RF beacon B associated with a particular object <b>20</b>, and running the data model to obtain a prediction candidate that represents at least a threshold likelihood that the particular RF beacon B and associated object <b>20</b> are in a particular identified room. Data models stored in the model storage database may be updated and/or maintained based on new data received from a subsequent survey, operations for object location, and indications of changes to the RF environment which might affect the tag signals.
0352<figref idref="DRAWINGS">FIG. <b>24</b></figref> also shows a customer database <b>760</b> maintained in connection with the object location system <b>10</b>. Typically, the customer database <b>760</b> stores customer-specific information such as customer identification, object identifiers for objects associated with a particular customer that are to be located or have already been located in prior operations of the object location system <b>10</b>. The customer services component or module <b>770</b> accesses the customer data database <b>760</b> so as to receive customer information such as object identifiers. According to one aspect, the customer database <b>760</b> stores object identifiers associated with particular customers or users, in association with location information determined by object location operations as described herein. Customers or users typically will access the object location information remotely by use of their own customer applications <b>780</b> (not described herein), via the network <b>40</b>, invoking functions of the customer services module or component <b>770</b>. Details of such remote data access functions are within the ordinary capabilities of those skilled in the art.
0000Details of RF Tag and Beacon
0353<figref idref="DRAWINGS">FIG. <b>25</b></figref> illustrates details of the components of an exemplary specific device used to implement an RF tag <b>25</b> in accordance with aspects of the present disclosure. As will be understood, an RF beacon B is affixed or otherwise associated with a specific object <b>20</b> (not shown) which is to be located in accordance with this disclosure. The RF tag <b>25</b> receives Bluetooth Low Energy (BLE) signals from one or more beacons B<b>1</b>, B<b>2</b>, Bn, generates a tag data package (not shown), and transmits this tag data package via a UHF transmitter to the object location system <b>10</b>. In addition, or alternatively, the RF tag receives other RF signals from other identifiable RF signal sources (IRFSS).
0354The preferred tag <b>25</b> is considered “dual mode” in that it contains a BLE receiver <b>810</b> for receiving BLE signals from beacons, as well as a UHF transmitter <b>820</b> for communicating with the object location system <b>10</b>.
0355In addition, or alternatively, an RF tag <b>25</b> may be configured to receive RF signals from other, non-beacon identifiable RF signal sources (IRFSS) and generate a tag data package containing information associated with such other signal sources, in particular RSSI data, frequency data, and identifying data. In such a configuration, the BLE receiver <b>810</b> will be a receiver configured to receive signals other than beacon signals, or in addition thereto.
0356The disclosed tag <b>25</b> further comprises and is controlled by a microprocessor <b>830</b>, which is coupled for data communication with the BLE receiver <b>810</b> and UHF transmitter <b>820</b>. The microprocessor is operative, as described in various places herein, for receiving signals from the beacon, in BLE format in the disclosed embodiment, extracting the RSSI data from each signal received from a beacon, and associating the RSSI values from one or more beacons with an object identifier, to generate a tag data package. In some embodiments the beacon B may have a microprocessor (not shown). Typically, an object identifier is input into the microprocessor of the beacon B and stored therein upon association of the beacon B with a particular object <b>20</b>. Alternatively or optionally, the beacon B may be preconfigured to include object identifier information for an object associated with the beacon B, which is then stored in the on-board memory of the microprocessor of the beacon B and transmitted to the tag <b>25</b> that further transmits the object identifier information with the tag data package in association with other data. As a specific example, a stationary beacon B such as shown in <figref idref="DRAWINGS">FIG. <b>21</b></figref> may be preconfigured to include identifying information that the beacon B is stationary, for ready identification and usage for calibration, location accuracy refinement, etc.
0357The disclosed tag <b>25</b> may further include a motion sensor <b>840</b>; also, the beacon B may include a motion sensor (not shown). The motion sensor of the beacon B may detect movement of the beacon B and/or its associated object, for example, if an object is tampered with, moved, and/or the beacon B is removed. The motion sensor <b>840</b> and/or the motion sensor of the beacon B is preferably a solid-state accelerometer that provides a “wake up” or interrupt signal to the microprocessor <b>830</b> or the microprocessor of the beacon B, respectively, upon detection of motion greater than a preconfigured amount, thereby indicating motion (acceleration) of a nature to indicate a motion that may indicate tampering, movement, beacon removal, etc. The motion sensor <b>840</b> and/or the motion sensor of the beacon B is preferably self-powered (e.g., with a capacitive stored charge) so that the respective microprocessor can assume an idle (sleeping) state for long periods of time without significant battery drain, but sufficient to “wake” the respective microprocessor in the event the motion sensor corresponding to the microprocessor is actuated by a movement of preconfigured threshold.
0358The disclosed beacon B also may include data inputs coupled to the microprocessor of beacon B for optional external sensors or switches for various other purposes that may be desired by a customer. For example, and not shown, other devise or sensors may include and employ (a) a temperature sensing device or thermometer may be included and employed for temperature monitoring of an object, (b) a light sensors for detecting whether an object (such as a living plant or light-sensitive object) is illuminated, (c) a sound sensor or microphone for detecting whether an object is being subject to sound waves above a predetermined threshold or having particular aural properties that might indicate something such as opening of a package or a door or dropping of the object (perhaps coupled with a high G-force signal from the motion sensor) that may suggest damage to an object, (d) a pressure sensor for detecting atmospheric pressure of the environment of any object, (e) a pressure or touch sensor for detecting contact with or upon an object that may indicate tampering or other physical interference, (f) a tampering detector for detecting that an object has been touched, manipulated, opened, damaged, or otherwise interfered with, and/or (g) a data input (such as for a USB keyboard) for configuration such as inputting of object identification and/or customer identification data. Other types of sensors or inputs for other purpose will occur to those skilled in the art, for purposes independent of object location but in certain instances in cooperation with location determination.
0359The disclosed embodiment may employ a Cognosos model RT-300 RTLS Tag as the RF tag <b>25</b> in all applications. The Cognosos model RT-300 RTLS tags <b>25</b> are available from Cognosos, Inc., 1100 Spring Street NW, Suite 300A, Atlanta, GA 30309. Details of the preferred tag are available in the literature provided by the manufacturer.
0360The beacon B and RF tags may be battery powered devices. The beacon B integrates a motion sensor (not shown) that senses when an associated asset (object) is moved and transmits its location to the tags <b>25</b> that further transmits this location information to the UHF radio gateway <b>712</b> (<figref idref="DRAWINGS">FIG. <b>24</b></figref>). Preferably, each beacon B and tag <b>25</b> are configured to transmit a unique beacon identifier (ID) and location information only when an asset has ceased movement to conserve battery power. By using the disclosed beacons B and RF tags <b>25</b>, transmissions require considerably less power than typical devices but transmissions from the tags <b>25</b> can still be accurately received up to hundreds of feet away by the radio gateway <b>712</b>. The disclosed radio gateway <b>712</b> can cover up to 100,000 square feet indoors.
0361For association and attachment to an object to be located or tracked, the disclosed RF beacon B is provided with an easy to install cradle (not shown) that can be attached to most flat plastic or metal surfaces with double-sided tape or cable ties. Each RF beacon B is provided with a battery that can be easily replaced by simply removing the beacon B from the cradle with a supplied security tool and removing one or more screws to access the battery.
0362The disclosed RF tags operate in the BLE frequency band 2400-2800 MHz and in the 900 MHz ISM band and dissipate power less than 1 uW for both functional operations of receiving signals from RF beacons as well as communicating with the UHF gateway. However, it will be understood that the choice of frequency is a matter for those skilled in art, taking into consideration other design choice issues as to radio frequency, modulation type, broadcast amplitude, antenna configuration, etc. In this regard, it will also be understood that although BLE may be used in many applications, the invention is not limited to any particular RF signals sources or characteristics.
0363In a preferred aspect of the disclosure, the microprocessor <b>830</b> on the preferred tag <b>25</b> assembles and transmits a tag data package in response to detection at a beacon B that was previously detected as moving, is determined to be at rest for a predetermined length of time. In accordance with this aspect, the microprocessor on the beacon B is “awakened” in response to movement of the beacon B, e.g., by a controller interruption from the motion sensor, and thereafter monitors the motion sensor at periodic (short) intervals until it is detected that the motion has stopped and has remained stopped for a predetermined “at rest” period of time. Once the predetermined “at rest” time has elapsed, the tag takes readings of the beacon signals and/or other IRFSS, assembles a tag data package, and transmits the tag data package to the object location system.
0364Once the tag data package arrives at the object location system <b>10</b>, the system can predict the object's location by constructing and using appropriate data models based on the tag data package, and/or retrieving preexisting data models and making an object location prediction. This object location prediction can be stored for subsequent retrieval by a customer, and/or provided in real time, in accordance with a particular customer's configuration for notification as to location of the particular object.
0365<figref idref="DRAWINGS">FIG. <b>26</b></figref> illustrates an alternative configuration of a dual mode RF tag <b>25</b>′ according to another aspect of this disclosure, in particular relating to detection of proximity of a device within a predetermined distance, e.g., ten feet, which is arbitrary, in connection with an object location operation. The embodiment of RF tag <b>25</b>′ is predominantly the same as for the tag <b>25</b> described in connection with <figref idref="DRAWINGS">FIG. <b>25</b></figref>, except that it is configured for other functions in addition to receiving signals from beacons and/or other IRFSS. According to one aspect, the tag <b>25</b> is configured to receive information via the BLE communication band from a transmitter (not shown) operated by the system operator for effecting additional location or other functions.
0366According to an aspect, the BLE receiver <b>910</b> is configured to receive signals from the object location system, for examples from transmitters other than independent beacons, to effect certain actions in the tag or beacon. A BLE transceiver (not shown) may be disposed in the disclosed alternative beacon B′, such BLE transceiver may be configured to perform similar functions of the BLE receiver <b>910</b>, for example and not limitation: (a) remote configuration of the beacon B′ to provide it with object identification and/or customer identification data, (b) actuate a visual indicator, (c) actuate a sound generating device such as a buzzer or speaker, and/or (d) transmit “on demand” any stored information contained in the on-board memory such as RF tag signals (and/or a history of tag signal reception over a predetermined time period), prestored customer ID or object ID information.
0367In this regard, the disclosed alternative RF tag <b>25</b>′ is also provided with an output from the microprocessor <b>930</b>. The disclosed alternative RF beacon B′ may be provided with an output from the microprocessor of the RF beacon B′. Each of the outputs of the RF tag <b>25</b>′ and the RF beacon B′ typically include one or more on-board driver circuits which may be configured for driving LEDs or sound-generating devices or electronic switches. The outputs of the RF tag <b>25</b>′ and the RF beacon B′ are used for coupling to an LED visual indicator, and/or a buzzer or speaker for generating a sound on demand by signal from the microprocessors of the RF tag <b>25</b>′ and the RF beacon B′. The LED visual indicator and the buzzer/speaker of the RF tag <b>25</b>′ are generally denoted as <b>960</b> and <b>970</b>, respectively. The LED visual indicator and the buzzer/speaker of the RF beacon B′ are not shown in <figref idref="DRAWINGS">FIG. <b>26</b></figref>. A particular useful function of the dual mode tag <b>25</b>′ in <figref idref="DRAWINGS">FIG. <b>26</b></figref> or the disclosed alternative RF beacon B′ is for “last ten feet” detection, as will be described next.
0000Last Ten Feet Detection (a/k/a Object Proximity Detection)
0368Still referring to <figref idref="DRAWINGS">FIG. <b>26</b></figref>, and according to another aspect, a dual mode tag such as the tag <b>25</b>′ includes one or more indicators, e.g., <b>960</b>, <b>970</b>. The beacons B<b>1</b>′, B<b>2</b>′ . . . Bn′ may also include one or more indicators (not shown). The indicators of the beacons B<b>1</b>′, B<b>2</b>′ . . . Bn′ and/or indicators of the tag <b>25</b>′, e.g., <b>960</b>, <b>970</b>, can be activated in response to a prompting or trigger signal provided by a user with a survey device or smartphone <b>60</b> having Bluetooth capability or a portable object location device <b>950</b>. In accordance with this aspect, the indicator(s) is actuated by prompting from such device with a Bluetooth signal containing a command to actuate. Such a configuration allows physical location of a particular object and its beacon B′ (e.g., one or more of beacons B<b>1</b>′, B<b>2</b>′ . . . Bn′ that is/are specifically associated with the particular object) within the “last ten feet”, it is understood that the actual distance is arbitrary and depends on other factors such as battery conservation and aspects of the RF environment. It will also be understood that such a “last ten feet” location function is typically conducted once a particular subspace or room has been previously identified by operation of the object location system <b>10</b>, and a user is dispatched to the identified subspace with a portable object location device <b>950</b> or other device for purposes of physically finding the object, perhaps among a number of other similar objects, or similar packages for objects, or in a cluttered environment.
0369In this regard, an RF tag <b>25</b>′ and/or the beacon B′ are provided with some type of indicator or signaling device that is capable of alerting a user of proximity to the located beacon and device. Examples of suitable indicators or signaling devices include but are not limited to a light or LED (not shown for the beacon B′ and, e.g., <b>960</b> for the tag <b>25</b>′ as shown in <figref idref="DRAWINGS">FIG. <b>26</b></figref>) and/or sound-generating device (not shown for the beacon B′ and, e.g., <b>970</b> for the tag <b>25</b>′ as shown in <figref idref="DRAWINGS">FIG. <b>26</b></figref>). Signaling devices can include other types of devices such as haptic feedback devices (buzzers/vibrators), a smartphone display notification, or any other device that can be actuated to alert a user when he or she (or an autonomous device such as a robot) is sent to physically locate and perhaps retrieve an object.
0370Such a portable object location device <b>950</b> may also be a mobile telephone with a Bluetooth radio circuit, as the preferred tag <b>25</b>′ is capable of receiving Bluetooth transmissions from sources other than BLE beacons B′. Such portable object location device <b>950</b>, e.g., a mobile telephone with a Bluetooth radio circuit may also communicate directly or indirectly (e.g., via cloud and/or internet) with the beacons B′.
0371Alternatively, the portable location device <b>950</b> may be the same as the survey device <b>60</b> used to transmit signals to the tags for survey purposes, but also configured to receive signals from beacons. According to this aspect, the survey device <b>60</b> or other portable location device <b>950</b> transmits a trigger signal, preferably limited to the object that is to be located, upon entering the pre-identified room in which the object is predicted to be located. In accordance with an aspect, the portable location device <b>950</b> is supplied with an identifier of the object to be located, the transmitted trigger signal contains the identifier, and each tag and/or beacon is configured to respond only to a trigger signal that includes the identifier that is specific to the particular beacon B′ and the object associated with that beacon.
0372According to these and related aspects, when a user having such a portable object location device <b>950</b> approaches the identified object whose location is to be determined physically by the user, after having been previously informed of a particular room or subspace in which the object is predicted to be located, the object location device transmits a predetermined trigger signal via BLE to the beacon B′ and/or tag <b>25</b>′, which in response to the trigger signal actuates the indicator (beacon-local tag, light, sound generator, haptic, etc.) to signal of its nearby proximity. According to a related aspect, the portable object location device <b>950</b> such as a mobile telephone may be provided with an application that sends a command to the beacon B′ and/or the tag <b>25</b>′ (the tag <b>25</b>′ may in turn send a command to the beacon B′ associated with the particular object). This command, for example, causes the beacon B′ to flash the LED or sound the audible alarm, thereby enabling the user to find the object rapidly even when it may be located in an area with other nearby identical objects or packages.
0000Object Location System Architecture
0373<figref idref="DRAWINGS">FIG. <b>27</b></figref> illustrates the hardware architecture of aspects of the objection location system <b>10</b>, in particular details of the object location engine <b>700</b> and location services <b>720</b> in <figref idref="DRAWINGS">FIG. <b>24</b></figref>, and customer services module <b>770</b>. In particular, the disclosed object location engine <b>700</b> comprises an API gateway <b>1010</b>, location integration service <b>1020</b>, packet pre-processing <b>1030</b>, and a rules engine <b>1040</b>. The API gateway <b>1010</b> provides a connection portal to the UHF radio gateway <b>710</b> so as to receive information transmitted by tags <b>25</b> that is received from the beacons B associated with objects <b>20</b> in the master space. A principal component of the gateway <b>710</b> is a UHF radio gateway <b>712</b>, which includes one or more gateway receivers, or is coupled with a network of distributed gateway receivers, that receive the tag signals. According to one aspect, the gateway <b>710</b> may also include comprises other location data APIs or inputs (not shown), for example, location information can be received from third-party location service partners that may provide cellular radio type tags that can be deployed in connection with the system <b>10</b>.
0374It will be understood from the discussion in connection with <figref idref="DRAWINGS">FIG. <b>20</b></figref> that a mobile device such as RF scanning device <b>60</b> or collection of one or more tags and/or beacons is used for scanning a master space in a survey operation for purposes of building and/or maintaining one or more data models, as described elsewhere herein. The gateway receivers <b>712</b> may include specific interfaces or protocols for communicating with devices such as a survey device, or a portable object location device <b>950</b> as discussed in connection with <figref idref="DRAWINGS">FIG. <b>26</b></figref>.
0375The API gateway <b>1010</b> is preferably implemented by a computer service such as Amazon Web Services (AWS), a cloud-based computing service provided by Amazon Web Services, Inc., Seattle WA USA, which allows deployment of a readily scalable system that can handle a large variety of users and master spaces for use by a number of different entities. Details of use of the AWS for data input services is available from the service provider.
0376The API gateway <b>1010</b> provides location data inputs to other components of the object location engine <b>700</b>, namely, raw RF packet data <b>1014</b> received from the disclosed UHF radio gateway <b>712</b>.
0377The location integration service <b>1020</b> of the object location engine <b>700</b> collects location information received from the location services <b>720</b>, as described elsewhere. The location integration service <b>1020</b> provides location data from a prior object location operation that can be combined with current location data derived from the RF tags <b>25</b>, so as to provide an “integrated” or combination location data for use in locating objects, and/or refining the training data.
0378Still referring to <figref idref="DRAWINGS">FIG. <b>27</b></figref>, the raw RF data packets <b>1014</b> comprise data obtained from transmissions from RF tags <b>25</b>, received via the API gateway <b>1010</b>, to a packet pre-processing service or component <b>1030</b>, which disassembles the raw RF packets and obtains the information contained in the tag data packages such as RSSI indicators, tag ID information, beacon ID information, and object ID information. This data is thus prepared for storage into databases, as discussed elsewhere, and also for backup to a data backup system.
0379According to an aspect, both the location integration service <b>1020</b> and packet pre-processing service <b>1030</b> are implemented in the cloud with AWS Autoscaling EC2/JVM cloud-based data processing services provided by Amazon Web Services, Inc., Seattle WA, USA.
0380Outputs in the form of messages, identified as SensorMsg <b>1035</b>, from the location integration service <b>1020</b> and packet-preprocessing service <b>1030</b> are provided to a collection of functions shown in <figref idref="DRAWINGS">FIG. <b>27</b></figref> as a rules engine <b>1040</b>, which is also preferably implemented in the cloud, e.g. via AWS Autoscaling EC2/JVM services. The rules engine <b>1040</b> provides services including but not limited to a real-time location service (RTLS) <b>1042</b>, a geofencing service <b>1044</b>, a sensor threshold service <b>1046</b>, and a custom rules service <b>1048</b>.
0381According to one aspect, the RTLS (real time location system) service <b>1042</b> is operative for the primary function of accessing one or more data models stored in the system <b>10</b> and maintaining by the location services <b>720</b> and generating specific location information (e.g., a particular room or subspace) of a particular object associated with a particular beacon, on demand by a user or customer of the system. Thus, the RTLS service <b>1042</b> provides one of the primary functions of the disclosed system and its advantages. The RTLS service <b>1042</b> is coupled to the location services component or services <b>720</b> for accessing the one or more data models.
0382The geofencing service <b>1044</b> is a specialized function according to a complementary aspect of this disclosure. In particular, a “geofence” will be understood by those skilled in the art to be a virtual “fence” for confining an object within a particular predefined space. In particular, a geofence is useful for detecting whether a particular object might be moved from one particular location or subspace or room to another location or subspace or room. Such a geofence is useful for detecting unauthorized movement of an object (such as theft, deliberate mislocation, or inadvertent mislocation. A geofence is constructed by a user that inputs one or more rooms or subspaces within which particular objects are permitted to reside, in association with object ID and customer ID, and maintains the list of permitted rooms in a database, and access the database to determine room location in response to the movement actuation of a beacon B associated with a particular object that is subject to geofencing.
0383According to one aspect, the sensor threshold service <b>1046</b> provides a function that permits limited movement of an object within one or more rooms or subspaces, before triggering an alarm of other indicator of movement of the object. This function can be implemented in conjunction with geofencing. In accordance with a sensor threshold service, the system maintains a predetermined distance movement threshold value, or alternatively an RSSI signal threshold value, for a particular object, in association with object ID and customer ID. In response to a signal of the beacon B indicating movement of a particular identified object, a new location of the object is compared to the threshold value (distance and/or RSSI value), so as to determine whether the object has moved a sufficient amount, as indicated by a change in the distance (or RSSI) values from an initial value when the object was last located, to different values. In the event that the determined movement of the object exceeds the predetermined change threshold, there is an indication that the object has moved sufficiently to note the change in position, and perhaps trigger an alarm of movement. Such a sensor threshold service is useful for allowing limited movement of objects within an approved subspace, without necessarily triggering an alarm.
0384A custom rules service <b>1048</b> is also provided so as to store custom rules provided by users or customers, as may be determined from time to time.
0385Still referring to <figref idref="DRAWINGS">FIG. <b>27</b></figref>, the location services <b>720</b> provides two major functions in the disclosed object location system <b>10</b>: a model training function <b>1070</b> and a model lookup and prediction function <b>1080</b>. Both the model training function <b>1070</b> and model lookup and prediction function <b>1080</b> are implemented in the disclosed embodiment by AWS SageMaker service provided by Amazon Web Services, Inc., Seattle WA, USA, or alternatively by a TensorFlow open-source ML platform. As known to those skilled in the art, AWS SageMaker is a fully managed cloud-based service that provides services for building, training, and deploying machine learning (ML) models quickly. TensorFlow is an open-source machine learning model building and deployment platform, details of which are available at http://www.tensorflow.org. As will be appreciated, the TensorFlow ML environment may be implemented within services provided by AWS.
0386According to one aspect, the model training function <b>1070</b> is implemented with a machine learning (ML) function, which is species of artificial intelligence (AI) technology. In the disclosed embodiment, the preferred ML function is a Support Vector Machine (SVM) algorithm, the general operations of which are known to those skilled in the art. The SVM accesses data in the survey database and/or training database <b>730</b> and creates one or more SVM data models that are used for object location prediction, based on RSSI values provided by the beacon B and further provided to the tag <b>25</b> that is activated to transmit its tag data package containing such RSSI values. Further details of the preferred SVM algorithm are described below. A data model formed from processing the survey data and/or training data in the respective databases is then stored in the model storage database <b>750</b>, shown in other figures.
0387According to one aspect, the model lookup and prediction function <b>1080</b> is an application algorithm that accesses models constructed by the preferred SVM stored in the model storage database <b>750</b> and provides a prediction output comprising a location prediction (identification) of a particular subspace in which a particular, pre-identified object <b>20</b>, as associated with an identified beacon B, may be located. According to a related aspect, the model lookup and prediction function <b>1080</b> accesses one or more data models, e.g., as discussed in detail below, and processes the received RSSI values from a tag data package against the one or more data models to arrive at a prediction candidate, which is provided as the location prediction output.
0388According to one aspect, a location prediction output for a particular object from the model lookup and prediction function <b>1080</b> is provided to a location fixes service <b>1012</b> for use in a location integration service <b>1020</b>. The location integration service <b>1020</b> combines the predicted location for the beacon B and associated object <b>20</b> with data corresponding to the tag data package that triggered the location operation, to form “scan” associating the RF values of the tag data package with the predicted location of the beacon B and object <b>20</b>. The location integration service <b>1020</b> and the packet pre-processing function <b>1030</b> generate data messages SensorMsg, as described elsewhere, which are further handled by the rules engine <b>1040</b>, according to the particular function invoked, e.g. geofencing, sensor threshold, any custom rules, or in case of a new incoming tag data package, an RTLS lookup function and location prediction.
0389The location services <b>720</b> accesses data in the survey database <b>730</b>, the model training database <b>740</b>, and the model storage database <b>750</b> (not shown in <figref idref="DRAWINGS">FIG. <b>27</b></figref>) for purposes of constructing one or more data models for machine learning of a master space and its associated subspaces, maintaining those models with additional data and “machine learning” (i.e. updating of the data models) resulting from object location operations, and also for conducting the primary function of object location by invoking and running one or more data models in response to an object location operation. Typically, an object location operation is triggered by a “command” from the RTLS lookup service <b>1042</b>, which provides data received from an RF tag <b>25</b> indicating the set of RSSI values received from the beacon B, object ID, and customer ID, among other potential data items, and uses that data to run a data model to obtain a prediction candidate for a likely location of the particular object associated with the beacon B that provided the data. The tag <b>25</b> typically provides its tag data package in response to detection that the beacon B (and its associated object <b>20</b>) have stopped moving, after of course beginning to move.
0390As indicated above, the various functions of the rules engine <b>1040</b> provide several outputs for utilization by various functions associated with the system <b>10</b>. For example, and further to that as described above, the RTLS lookup function <b>1042</b> provides location information as to a predicted location for a particular object from an object location operation to customer services function <b>770</b>. And although not shown, information from an object location operation is also provided to the training data base <b>740</b>. It will be understood that location data from a located object may be added to the training database <b>740</b>, in which case the database may more properly be considered a “location data storage database,” as it contains data used for initial training of the model, plus updates from changes to the RF environment as detected by other functions, as well as location data from actual object location operations. All of such data forms a part of the machine learning database and used to refine the model subsequent to initial training. By updating the training database to include location data from actual object location operations, as well as from detected changes in the environment due to tag failure, new tag additions, moved tags, changes in the physical infrastructure such as changes to shelving, doors, walls, etc., the data models used for object location prediction are dynamically updated for subsequent object location operations.
0391In the disclosed embodiment, the survey database <b>730</b>, the training database <b>740</b>, and the model storage database <b>750</b> are all implemented in cloud-based data storage services provided by Amazon Web Services, Inc., Seattle WA USA, such as AWS S3, AWS SQL, and/or AWS ElasticSearch, details of which are available from the service provider. It will of course be understood and appreciated that databases can be maintained in other known manners such as with local storage or by use of other cloud-based data storage services, as determined by one who builds and operates an object location system <b>10</b> as described herein.
0392<figref idref="DRAWINGS">FIG. <b>27</b></figref> also illustrates aspects of customer services function <b>770</b>, as introduced in <figref idref="DRAWINGS">FIG. <b>24</b></figref>. Customer services <b>770</b> provides application programming interfaces (APIs) into the disclosed object location system <b>10</b> (not shown in <figref idref="DRAWINGS">FIG. <b>27</b></figref>) for the purpose of allowing users such as customers of a provider of the system <b>10</b> to input their information as to objects to be located and/or tracked, aspects of the master space and its associated subspaces including the surveying thereof, and conducting object location operations to locate specific objects within the user's respective master space(s).
0393In the disclosed embodiment, the customer services functions <b>770</b> are implemented with various AWS services and storage facilities, as for other functions in the system <b>10</b>. An API service (not shown) provides an interface to the Internet <b>40</b> or other data communication network so that particular customers or users can employ mobile devices such as networked computers, data tablets, cellphones, or other devices to conduct survey operations and object location operations using applications that execute on such devices. These operations generate API queries, for example, to access and invoke functions of the system <b>10</b>. The API services include functions such as a load balancer for handling and balancing a number of simultaneous/high volume of operations in the system, a monitoring and observability service for providing metrics as to operations and performance of the system, an API endpoints service for providing web-based access to the system by users, and an event notification service for generating real-time information to users including automatically updated object location information, violations of geofence rules, and/or movement threshold indications. In the disclosed embodiment, these aspects are implemented respectively by AWS Elastic Load Balancer, AWS Cloudwatch service, API Endpoints service, and AWS SNS event notification service, all provided by Amazon Web Services, Inc., Seattle WA. Details of these cloud-based services are available from the service provider. These services store and retrieve data in the customer database <b>760</b>, also provided in the disclosed embodiment by Amazon Web Services, but of course may be implemented locally in a user's facility or via other cloud-based storage and web-accessible service providers.
0000Exemplary Training Data, Object Location Prediction, and Model Update
0394Turn now to <figref idref="DRAWINGS">FIGS. <b>28</b> and <b>29</b></figref> for a discussion of exemplary data used in constructing a data model of a master space and associated subspaces, based on use of pre-collected survey data, of exemplary data in use of a data model to generate an prediction candidate for the location of a particular object, and of updating a data model based on subsequently-acquired data from object location operations or changes to the RF environment, respectively. <figref idref="DRAWINGS">FIG. <b>28</b></figref> provides one example of exemplary data, and <figref idref="DRAWINGS">FIG. <b>29</b></figref> provides another example of exemplary data.
0395<figref idref="DRAWINGS">FIG. <b>28</b>A</figref> illustrates an exemplary data table of RSSI data values, expressed in dBm, that represent the results of a survey operation by a user of the disclosed object location system <b>10</b>. Each row in the table in this figure represents a single “scan”, comprising a collection of RSSI data values. The data values represent a plurality of data values obtained by use of a survey device <b>60</b>, after a user has obtained RF data samples within a plurality of exemplary subspaces or rooms Room A, Room B, and Room C in a survey operation. Each data value in the table represents RSSI value measured by a survey device, for example at sample locations S<b>1</b>, S<b>2</b>, . . . Sn, taken within a predefined subspace of a master space. Preferably each sample—e.g., S<b>1</b> in <figref idref="DRAWINGS">FIG. <b>28</b>A</figref>—will include the RSSI values measured from one or more RF channels of an RF tag, assuming that each RF tag provides one or more discrete RF channels. For example, note in <figref idref="DRAWINGS">FIG. <b>28</b>A</figref>, on the first row of the table, that a tag identified as Tag <b>25</b><i>a </i>has three channels, Ch. 1, Ch. 2, and Ch. 3, each receiving at a different frequency within the specified RF band for the tags deployed in the master space. Sample S<b>1</b> has RSSI values of −70 dbM, −68 dbM, and −69 dBm, as measured within Room A. Similar samples, e.g., S<b>2</b> are taken of RF signals from other tags with multiple channels, e.g., Tag <b>25</b><i>b </i>and Tag <b>25</b><i>c</i>, in the example shown. Assume further that another set of data samples is taken within Room A, preferably at another physical location within Room A as represented in the second row of data values in the table. Preferably, each set of data samples is taken at a different location within the subspace being surveyed.
0396In a similar manner, other data samples are taken within the subspaces Room B and Room C, capturing RSSI data from various locations within each subspace from signals as received by tags, e.g., the signals that are detectable within that subspace, to build out a data table such as that shown in <figref idref="DRAWINGS">FIG. <b>28</b>A</figref>. Such a table of data values is then used to train and deploy a machine-learning model. In <figref idref="DRAWINGS">FIG. <b>28</b>A</figref>, the data values for the first two rows represents a first data model A. In like fashion, the data values for the next two rows represent a second data model B, and the last three rows represent a third data model C. These data values and their respective identifiers for data Models A, B, and C are then stored in the survey database <b>730</b>, and once the models are identified, the constructed data models are stored in the Training Database <b>740</b>, for access by the model training function <b>1070</b> (<figref idref="DRAWINGS">FIG. <b>27</b></figref>). Once a set of data from a survey is used in building a data model, that data is transferred into the model storage database <b>750</b>.
0397<figref idref="DRAWINGS">FIG. <b>28</b>B</figref> illustrates an exemplary data table of RSSI data values, expressed in dBm, that represent the results of an object location operation by a user of the disclosed object location system <b>10</b>. In the example, a plurality of data samples provided in tag data packages from an RF tag <b>25</b> are provided by a set of scans or data acquisition samples of beacon signals received by RF tag and transmitted to the object location system for an object location operation. The example shown has four (4) scans or sets of data samples, as represented by the four rows in the table, taken from signals received by three tags Tag <b>25</b><i>a</i>, Tag <b>25</b><i>b</i>, and Tag <b>25</b><i>c</i>, e.g., the signals that are transmitted by the beacon B and that are detectable by the RF Tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, and <b>25</b><i>c</i>. As shown, each tag has three RF channels, Ch. 1, Ch. 2, Ch. 3. It is believed that at least three sets of data samples from a beacon provide acceptably reliable location operations, although predictions may be made with more or fewer data samples.
0398In the example shown, each set (row) of data samples from the beacon B that transmits the RF beacon signals to the three tags is run against a location prediction algorithm that accesses one or more data models built from a prior survey and data model training operation. Note that three of the four sets of scans have resulted in the prediction of Room A as the likeliest location for the object <b>20</b> whose beacon B transmitted the RF beacon signals that were further transmitted by tags <b>25</b> to the system for the location operation. Note that one of the sets of data (the third row), resulted in the prediction of Room B. In accordance with one aspect of the present disclosure, a weighting or “voting” algorithm is used to determine that the three predictions of Room A outweigh (outvote) the single prediction of Room B, such that a location prediction of Room A is output by the system as the determined location of the object <b>20</b> associated with the beacon B that provided the data.
0399<figref idref="DRAWINGS">FIG. <b>28</b>C</figref> illustrates an exemplary data table or schema of RSSI data values, expressed in dBm, that represent the results of an object location data update and/or model maintenance operation resulting from additional data obtained by use of the disclosed object location system <b>10</b>. In the example shown, assume that the first four rows of data (RSSI value) from an initial set of scans of values from a beacon.
0400Assume further that the data items used in model construction and maintenance now include additional data items from any one of a number of additional sources, e.g., known static objects or beacons, newly added tags, confirmed object beacon location operations, triggered environment changes, follow-up surveys, tag failures, diminished RF signals, moved or replaced tags, added or removed external IRFSS, etc. Such additional data items are shown in <figref idref="DRAWINGS">FIG. <b>28</b>C</figref> as “additional scan data”, and are used to update, reinforce, and/or maintain the data model constructed in initials scans from an initial survey. In the figure, two (2) additional data items are shown, reflecting in this particular example the receipt of signals by tags Tag <b>25</b><i>a</i>, Tag <b>25</b><i>b</i>, and Tag <b>25</b><i>c</i>, and by different RF channels of such tags. Although this exemplary schema shows signals received by tags that communicate such information to the system for the location operation, it will be understood that such additional scan data can be obtained by the system for the location operation from other identifiable RF signal sources (IRFSS).
0401It will be understood in connection with <figref idref="DRAWINGS">FIG. <b>28</b>C</figref> that the additional scan data is used to run the data model and determine (or verify) that a particular room, e.g., Room A, Room B, is predicted to be the location of the receiver that generated the additional scan data. Upon updating the data model using the additional data continuously in response to triggered circumstances such as tag failure, or object location operations, or in response to follow-up surveys.
0402According to a related aspect of <figref idref="DRAWINGS">FIG. <b>28</b>C</figref>, it will be understood that the disclosed system and methods contemplated at least three different ways or methods for reinforcement of data models constructed as described herein. Examples of such situations are described above in connection with <figref idref="DRAWINGS">FIGS. <b>21</b>, <b>22</b>, and <b>23</b></figref>. Such methods involve use of data from circumstances or conditions detected in the RF environment, stationary or static beacons, additional or removed tags and providing additional data scans such as those shown in <figref idref="DRAWINGS">FIG. <b>28</b>C</figref> for use in subsequent model construction and usage or subsequent object location predictions. For example, a first reinforcement or updating method involves user intervention for correction of an erroneous subspace prediction. In this method, the system provides for user entry of a corrected room or subspace identifier in the training database, in response to a user determination that the system has erroneously predicted an object location. In such a method, the system may provide for user override of the incorrect prediction, and/or provision of a corrected subspace identifier for the beacon data that prompted the erroneous subspace prediction.
0403A second reinforcement or updating method involves the inclusion of additional scans into the training database in response to a determination that the RF environment may have changed, or by the inclusion of additional tags or RF sources, or the utilization of static of stationary beacons such as shown in <figref idref="DRAWINGS">FIG. <b>21</b></figref>. This may be determined by the occurrence of mispredicted locations, as well as the identification of initial survey scans that included signals received by the tags and/or signals received from other IRFSS that are no longer present or are significantly attenuated, and replacement and/or updating of scans forming the data models.
0404A third method involves automatic reinforcement based on each successful object location operation. In this method, the data from each successful object location prediction, as represented by the tag data package with the scan at prediction time, is provided to the training database for use in subsequent model construction and usage.
0405<figref idref="DRAWINGS">FIG. <b>29</b></figref>, consisting of <figref idref="DRAWINGS">FIGS. <b>29</b>A-<b>29</b>D</figref>, is another example of exemplary data derived and used in aspects of the present invention(s), in connection with, respectively, a survey operation, training of a ML database, adjustment of data used in construction of models used for object location prediction, and model construction by assigning rooms (subspaces) to particular sets of adjusted data values.
0406<figref idref="DRAWINGS">FIG. <b>29</b>A</figref> illustrates exemplary data derived in an initial survey operation or process, as described in this disclosure. As indicated in the figure, a survey operation or process provides data, exemplary data of which is illustrated, collected in scans Sn collected by tags <b>25</b><i>n </i>in indicated rooms identified by Room Label Rn as a result of survey scan within the identified room. During the survey process, a room or subspace label is associated with each scan, as represented by a Scan ID data value. The data in <figref idref="DRAWINGS">FIG. <b>29</b>A</figref> is considered an initial survey scan.
0407It may be noted in <figref idref="DRAWINGS">FIG. <b>29</b>A</figref> that certain scans, e.g., scans S<b>1</b>, S<b>2</b>, S<b>3</b> provided no data to tags <b>25</b><i>d</i>, <b>25</b><i>e</i>, and <b>25</b><i>f</i>, for room R<b>1</b>, and scan S<b>1</b> provided no data to tag <b>25</b><i>c </i>for R<b>1</b>. Likewise, scans S<b>7</b>, S<b>8</b>, and S<b>9</b> provided no data to tags <b>25</b><i>c</i>, <b>25</b><i>d</i>, <b>25</b><i>e</i>, <b>25</b><i>f</i>, and scan S<b>8</b> provided no data to tag <b>25</b><i>g</i>, for room R<b>3</b>. “No data” in this example means that the signals transmitted to those respective tags were either totally missing or alternatively below some predetermined threshold, e.g., less than −120 dBm.
0408Also, in <figref idref="DRAWINGS">FIG. <b>29</b>A</figref>, note that the scans from the survey labeled with room R<b>2</b> has a distinctively different set of values. This survey data indicates that the rooms R<b>1</b> and R<b>3</b> have signals received by a set of tags that have a number of the same tag identifiers, i.e., tag <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>g</i>, <b>25</b><i>h</i>, and <b>25</b><i>i</i>. In order to conduct an object location operation, a plurality of data models are constructed using this survey data, and allow selection of which room a particular object is located, based on a scan taken at the time of object location prediction.
0409<figref idref="DRAWINGS">FIG. <b>29</b>B</figref> illustrates both an exemplary scan from a beacon associated with an object to be located at prediction time, as well as the result of a selection or determination of a set of survey scans from the data in <figref idref="DRAWINGS">FIG. <b>29</b>A</figref> from the initial survey database to use for model construction. The selection of scans Sn for use in model constructing and training is based on scan data from a beacon at prediction time. An exemplary process for constructing a set of training data for the ML SVM classification algorithm thus involves, at Step 1, selection of a set of survey scans Sn for model construction based on the RSSI values from a scan from a beacon that is to be located. In this case, because the beacon to be located has received signals by tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>g</i>, <b>25</b><i>h</i>, and <b>25</b><i>i</i>, and because scans S<b>1</b>, S<b>2</b>, S<b>3</b>, S<b>7</b>, S<b>8</b>, and S<b>9</b> in the initial survey data show significant signals received by the same tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>g</i>, <b>25</b><i>h</i>, and <b>25</b><i>i</i>, the data from these initial survey scans are selected for model construction. In accordance with an aspect of this disclosure, provided that a predetermined percentage of the tags, for example 75%, in an initial survey data item Sn have values received by the tags (represented by tag identifiers) that match the tag identifiers received from the beacon to be located, such initial survey scans are used in training. For example, and in other words, if a particular initial survey scan Sn has data values for at least 75% of the same tags in the beacon data, then that scan value may be selected as training data for model construction.
0410Note in <figref idref="DRAWINGS">FIG. <b>29</b>B</figref> that two of the initial scans S<b>2</b> and S<b>8</b> show zero values by tags <b>25</b><i>h </i>and <b>25</b><i>g</i>, respectively. Still, in this example, 80% of the tag identifiers (4 out of the 5 in the prediction time scan data) in the scans S<b>2</b> and S<b>8</b> are the same as in the prediction time scan data. Thus, scans S<b>2</b> and S<b>8</b> are still eligible for use in training, according to this particular aspect of scan selection for model construction. Note also, and as discussed next, the presence of the zero values creates a certain complication in model construction.
0411<figref idref="DRAWINGS">FIG. <b>29</b>C</figref> illustrates the exemplary training data of <figref idref="DRAWINGS">FIG. <b>29</b>B</figref>, below the scan data from the beacon at prediction time for comparison, showing the adjustment of certain training data by insertion or inclusion of data for certain tags, for completion of model construction in accordance with a particular aspect of the present disclosure. Note that at Step 2, the initial survey scans for S<b>2</b> and S<b>8</b> in <figref idref="DRAWINGS">FIG. <b>29</b>B</figref> had zero values for one particular tag of the five indicated (<b>25</b><i>h </i>and <b>25</b><i>g</i>, respectively) but otherwise had values for four other tags. In accordance with this aspect, the zero values are replaced with values that represent an interpolation of values from adjacent scans, it being understood that that scans S<b>1</b>, S<b>2</b>, and S<b>3</b> were all associated with room R<b>1</b>, and scans S<b>7</b>, S<b>8</b>, S<b>9</b> were all associated with room R<b>3</b>. Having a zero value for scans where most of the values are reasonable is perhaps anomalous, and according to this aspect of the disclosure, will be replaced by a value determined by a predetermined statistical computation or pure interpolation so as to provide a meaningful value for use in object location prediction. In the example shown for scan S<b>2</b> in the training data, the value of −117 dB is inserted, as average of the adjacent values from S<b>1</b> and S<b>3</b> from tag <b>25</b><i>h</i>. Similarly for scan S<b>8</b>, the value of −97 dB is inserted, as an average of the values from S<b>7</b> and S<b>9</b>. Although a statistical average is used in this example, it will be understood that other statistical computations may be employed to fill in for missing and/or anomalous values, such as pure interpolation, median, mode, or other types of statistical values.
0412In <figref idref="DRAWINGS">FIG. <b>29</b>C</figref>, once any anomalous or missing values are filled in, the training data may be considered completed and ready for use in model construction and object location prediction.
0413<figref idref="DRAWINGS">FIG. <b>29</b>D</figref> illustrates two particular data models in accordance with an aspect of this disclosure. This figure illustrates the assignment of a first data model R<b>1</b> associated with room R<b>1</b>, and a second data model R<b>3</b> associated with room R<b>3</b>, based on the collection of a set of initial survey scans (survey data) as shown in <figref idref="DRAWINGS">FIG. <b>29</b>A</figref>, training of a ML algorithm by selection of a predetermined set of survey scans from the initial survey scans based on the RSSI values of a beacon data scan at prediction time for a beacon associated with an object to be located as shown in <figref idref="DRAWINGS">FIG. <b>29</b>B</figref>, as such a set of selected survey scans may be adjusted to compensate for anomalies and/or missing values as in <figref idref="DRAWINGS">FIG. <b>29</b>C</figref>.
0414<figref idref="DRAWINGS">FIG. <b>29</b>D</figref> illustrates the data resulting from construction of a data model for room R<b>1</b> and R<b>3</b>. At Step 3a, model identifier Model R<b>1</b>, comprising scans S<b>1</b>, S<b>2</b>, and S<b>3</b>, as adjusted in a manner as previously described, is assigned to these scans. At Step 3b, a model identifier Model R<b>3</b>, comprising scans S<b>7</b>, S<b>8</b>, and S<b>9</b>, as similarly adjusted, is assigned to these scans. At Step 3c, a binary version of these data models is stored in the model storage database <b>750</b> (<figref idref="DRAWINGS">FIG. <b>24</b></figref>).
0415Still referring to <figref idref="DRAWINGS">FIG. <b>29</b>D</figref>, in accordance with aspects of this disclosure, an object location prediction is conducted upon construction and/or retrieval of the constructed training data models. As described elsewhere herein, an object location operation involves prediction of the room in which the object to be located is most likely found, based on the beacon data from the scan from a beacon associated with the object to be located at prediction time. In accordance with aspects of this disclosure, an ML algorithm, an SVM in the disclosed preferred aspects, is applied to the data in the constructed models (Model R<b>1</b> and Model R<b>3</b> in the example shown). In this example, a typical classification algorithm, such as SVM, will return room (subspace) R<b>1</b> as the room in which the beacon and its associated object is most likely to be found.
0000Flow Charts of Processes for Survey, Survey Pre-Processing, Model Training, Model Serving
0416Turn next to <figref idref="DRAWINGS">FIGS. <b>30</b>-<b>33</b></figref> for a discussion of flow charts of various computer-implemented processes that are executed by the object location system <b>10</b> constructed in accordance with aspects of this disclosure. These flow charts are examples of steps that can be used to implement various functions of the disclosed object location system in a networked computer system, having a location gateway <b>710</b> for receiving RF signals from RF tags <b>25</b> that include the data received from the beacon(s) B associated with an object <b>20</b> to be located, which is coupled to an object location engine <b>700</b> that carries out survey operations, model building and training, object location, in conjunction with user-provided information relating to the defining of subspaces or rooms within a master space, object ID, customer ID, and other data items used in carrying out the functions described herein. According to one aspect, it will be appreciated that the steps described in the flowcharts described are carried out in computer code executed on the various cloud-based computing and communicating components described above, in particular in <figref idref="DRAWINGS">FIG. <b>27</b></figref>.
0417<figref idref="DRAWINGS">FIG. <b>30</b></figref> is a high-level flow chart that illustrate primary computational data collection, model training, and object location operations that are conducted in order to carry out the functions required for object location in accordance with this disclosure. Each of the major steps shown in <figref idref="DRAWINGS">FIG. <b>30</b></figref> are effected by a computer program process that is executed in the object location system <b>10</b>, constructed as described herein. First, at process <b>3100</b>, the master space in which objects to be located may be found is surveyed, to obtain RF data samples of the RF environment of the master space and assigned appropriate subspaces or room identifiers. At process <b>3200</b>, the survey data from a survey operation is pre-processed to build a training database. At process <b>3300</b>, one or more data models are constructed by selection of a set of scans from the initial survey database based on values received from the tags transmitting data received from a beacon associated with an object to be located. At process <b>3400</b>, an object location process is conducted by executing selected data models and predicting a room in which the object is likely to be located. As shown, data from an object location operation <b>3400</b> are fed back to the model training process <b>3300</b>, as in certain aspects of this disclosure the data models used for object location prediction are continuously updated with data from successful object location predictions. Details are these major processes are described below.
0418<figref idref="DRAWINGS">FIG. <b>31</b></figref> illustrates steps that can be used to implement a survey function or process <b>3100</b>, identified in <figref idref="DRAWINGS">FIG. <b>31</b></figref> as a field survey application (app). Starting at step <b>3105</b>, a survey function begins upon a command, for example from a survey device <b>60</b> as shown generally in <figref idref="DRAWINGS">FIG. <b>20</b></figref>, which contains an application for collecting RF data samples by tags in a master space, from signals sent by a transmitter associated with or built into the survey device <b>60</b>. Such a begin survey command is shown as “Start Measurement Session.” In a measurement session, the survey device <b>60</b> is activated and deployed within one or more subspaces or rooms within this master space, and the associated transmitter sends signals to the tags and/or associated receiver receives tag signals, preferably multi-channel, from one or more tags whose signals propagate into the subspace being surveyed. Functions of the transmitter and receiver of the survey device <b>60</b> may be configured to be performed by, for example, transceiver, one or more microprocessors, and the like.
0419At step <b>3108</b>, a session ID is generated to identify the particular survey session being conducted. At step <b>3110</b>, a customer site number for the master space is retrieved from the customer database <b>760</b>. The customer site number is used to associate a particular master space and its identified subspaces with a particular user or customer. The customer site number may include a subspace or room identifier for association with RF data samples obtained within the room being surveyed. At step <b>3113</b>, the survey device begins collecting RF data samples within an identified subspace.
0420At step <b>3115</b>, a “zone label”, also known here as a subspace identifier, and its coordinates within the master space, are identified based on customer site information, and written at step <b>3118</b> to a Location List, as shown in the accompanying table. According to one aspect, a Location List comprises data items including but not limited to the session identifier (SessionID), a start time for the session (SessionStartTime), a customer identifier (CustomerLabel), one or more master and/or subspace identifiers (ZoneLabel), and one or more location identifiers (LocationNumber) associated with the master space and/or associate subspaces, coordinates of the master space and/or associated subspaces as may be required (X Coord, Y Coord, Z Coord) for a three dimensional master space, and, if desired, a reference to a predetermined map of the space and subspace maintained by the user (Map Point Ref). These data items are associated with a customer or user LocationNumber at step <b>3120</b>. The LocationNumber data item is a customer-supplied data item that distinguishes one particular location associated with a customer or user, within a plurality of locations. The data items, as listed above and as shown in the accompanying Location List table, are then stored (uploaded) in the survey database <b>730</b> at step <b>3122</b>.
0421After step <b>3115</b>, a scan identifier (Scan ID) is generated at step <b>3125</b> to identify the particular scan or data acquisition operation for obtaining RF tag signal samples, and the survey device <b>60</b> begins to collect the RF tag signal samples, or signal sample from any other RF sources that are used as IRFSS. At step <b>3130</b>, the RSSI values of multi-channel tags are collected and stored, in association with a particular location in the master space and subspace, and associated with Location N, where N will increment for each sample location S<b>1</b>, S<b>2</b>, . . . Sn. At step <b>3132</b>, the scan is completed for that sample location S<b>1</b>, and the data values are recorded or written at step <b>3135</b> to a measurement log, as shown in the accompanying table. According to an aspect, the Measurement Log comprises data items including but not limited to SessionID, SessionStartTime, CustomerLabel, SiteLabel (identifying a particular master space), ZoneLabel (identifying a particular subspace or room), a scan identifier (ScanID), a scan start time and duration (ScanStartTime, ScanDuration), a time at which a tag signal is received (PacketReceiveTime), a tag identifier (TagMAC), and the signal strength measurement itself (RSSI) of the particular data value of a particular channel of a particular tag.
0422In addition, and although not shown in <figref idref="DRAWINGS">FIG. <b>31</b></figref>, a data item for the Measurement Log may include a channel identifier (Channel ID) for configurations that involve multi-channel tags or other multi-channel RF sources as IRFSS, as well as value or data item representing the frequency or frequencies of a tag or other RF source.
0423The Measurement Log written at step <b>3135</b> is then associated with a user Location Number established at step <b>3120</b> and uploaded at step <b>3122</b> to the survey database <b>730</b>.
0424After writing a Measurement Log at step <b>3135</b>, the inquiry is made at step <b>3140</b> whether additional scans at additional sample locations are to be made, and if so, the process returns to step <b>3125</b> and another scan is initiated. If at step <b>3140</b> the user conducting the survey has completed his or her survey of the master space and associated subspaces, the process passes to step <b>1450</b> and the survey process is complete.
0425<figref idref="DRAWINGS">FIG. <b>32</b></figref> illustrates steps that can be used to implement a survey data pre-processing function or process <b>3200</b>, identified as a Survey Pre-Processing application (app). According to one aspect, a survey pre-processing process is carried out so as to transform survey data as stored in the survey database <b>730</b> into data that is used to construct (i.e., train a machine with “machine learning”) one or more data models that are used for location of objects. The output or result of the pre-processing function or process <b>3100</b> is stored in the Training Database <b>740</b>.
0426Another purpose of the Pre-Processing app <b>3200</b> is to normalize the RSSI values obtained during a survey of a master space so as to compensate for variations that might occur as a result of use of different RF tags having somewhat different characteristics, e.g., from different manufacturers, calculate mean values of RSSI values for various locations within an identified subspace so as to identify aberrations that might occur due to tag malfunction, additional tag placement, tag movement, and other issues.
0427Starting at step <b>3205</b>, a survey pre-processing function <b>3200</b> accesses data in the survey database <b>730</b> collected during a prior survey operation, and first counts the number of distinct tags detected during the survey. Such a count is effected by a pass through all data samples in the survey for a specific master space and identifying all unique MAC (media access control) addresses for tags. It is understood at this juncture that each tag has a unique identifier so as to distinguish signals from different tags; all tags deployed in a master space should have a unique identifier that is provided as a part of the tag's signal. A MAC address is a convenient identifier for this purpose. Upon counting all unique MAC addresses in the survey data of the specified master space that was surveyed, at step <b>3208</b> data corresponding to this count is written to a tag metadata file, as shown in the accompanying table, and stored in the training database <b>740</b>. The data items in the tag metadata file include but are not limited to the following: a user or customer identifier (CustomerLabel), an identifier of the specific master space associated with the particular survey data being pre-processed (SiteLabel), and a list of all tags detected in the survey by tag identifier (TagMAC).
0428After the counting of the unique number of tags detected in the survey, after step <b>3205</b>, the RSSI data values for each unique tag from the survey device <b>60</b> are normalized at step <b>3210</b>. The normalization of RSSI values is for the purpose of determining the variation in a RSSI values that were detected in the survey. In other words, it is expected that the RSSI values for all RF tag signals will vary according to some function, and that there will be a maximum value seen and a minimum value seen, a mean value of all the values of a particular tag, and a standard deviation of those values. This normalization assists in later object identification error detection using data from a particular RF beacon, if for example a value significantly above or below the mean is seen, e.g., more than 2 standard deviations from the mean, which may indicate an anomalous RSSI value read from a beacon. After the normalization calculations for the data associated with each individual tag are completed, a Preprocessed Tag File for the tags is created at step <b>3215</b>. Data items in the Preprocessed Tag File, as shown in the accompanying table, include but are not limited to: a customer or user identifier (CustomerLabel), an identifier of the particular master space of the survey (SiteLabel), a time stamp associated with the survey (SessionStartTime), and a list that associates tags with particular zones (rooms or subspaces), namely: a zone identifier (room or subspace identifier (ZoneLabel), the mean value and standard deviation of the RSSI values seen in that zone for each tag (e.g. MAC 1 RSSI Mean, MAC 1 RSSI StdDev . . . MAN N RSSI Mean, MAC N RSSI StdDev).
0429Also, after step <b>3205</b>, the RSSI data from the survey is associated with each particular zone (area, room, subspace) at step <b>3220</b>, in a Per-Zone Data collection. The data items in the Per-Zone Data collection, as shown in the accompanying table, include but are not limited to a user or customer identifier (CustomerLabel), an identifier of the master space associated with this survey data (SiteLabel), a time stamp of the survey (SessionStartTime), a zone identifier (area, room, subspace), and data of the survey samples S in the form of Category (−1/1) identifying a channel and RSSI value, and the sample data in the form of MAC 1 Mean, MAC 1 StdDev . . . MAC N Mean, MAC N StdDev. The Per-Zone Data is then written to the training database <b>740</b>.
0430<figref idref="DRAWINGS">FIG. <b>33</b></figref> illustrates steps that used to implement a ML model training function or process <b>3300</b>, identified as a Model Training application (app), according to one aspect of the disclosed invention. According to one aspect, the Model Training app <b>3300</b> is run against each specific zone (area, room, subspace) so as to generate a data model using the training data in the training database <b>740</b>, and the resultant data model(s) are stored in the model storage database <b>750</b>. According to one aspect, the machine learning model construction involves construction of a Support Vector Machine (SVM), which is known to those skilled in the art as a supervised machine learning model that uses classification algorithms for a two-group classification problem: whether a particular object, as indicated by data provided by an associated beacon B, is or is not, predicted to be in a particular room or subspace, identified as a zone (ZoneLabel).
0431The Model Training app <b>3300</b> has two nested routines or procedures: a Parallelize per Zone process <b>3305</b> and a Parallelize per parameter choice process <b>3310</b>. Those skilled in the art will understand that when training an SVM, the user needs to make a number of decisions: how to preprocess the data, what type of kernel to use, and finally, setting the parameters and hyperparameters of the SVM and the kernel. Kernels in an SVM will be understood by those skilled in the art to be algorithms implementing certain mathematical functions that are defined as the kernel. The function of a kernel is to take data as input and transform it into the required form. Different SVM algorithms use different types of kernel functions, for example linear, nonlinear, polynomial, radial basis function (RBF), and sigmoid. Each of these different types of kernels have an associated set of parameters that are used in constructing a model.
0432In the disclosed embodiment, a linear kernel has been employed, as the classification function is a simple yes/no decision—a data model for a particular room or subspace will indicate either that a particular object, as represented by a set of RSSI data samples provided by an associated beacon, are predicted to be either “yes—in the room associated with the model” or “no—not in this room.”
0433Those skilled in the art will also understand that certain SVM kernels also have another set of parameters called hyperparameters, for example the “soft margin constant” and other parameters of the chosen kernel function such as the width of a Gaussian ken or degrees of a polynomial kernel. Those skilled in the art of implementing SVM functions will understand how to select and optimize parameters and hyperparameters for a chosen SVM kernel, as well as choosing an appropriate kernel (or other classification algorithm) for a specific application of the present invention.
0434The Parallelize per parameter choice process starts at step <b>3320</b>, where the data in the training database (or survey database, original or as updated/reinforced) is processed on a partitioned basis, for example, all the data associated with a particular tag are found and processed, or all the data associated with a particular zone or room are processed.
0435At step <b>3322</b>, any required hyperparameters for the selected parameter are chosen and applied. At step <b>3325</b>, a SVM data model is generated, i.e., by application of the selected kernel, to assess the closeness of the “fit” of the data to an expected minimized “distance” of the particular data of a sample to the associated line, plane, hyperplane, or other reference geometry. Stated in other words, the fit of an SVM is a determination of the acceptable error margin of the soft margin parameter. It will be understood that an SVM with a linear kernel (or classifier) may be easier to determine a suitable fit, since the only parameter that affects performance is the soft margin constant. Of course, other kernels and degrees of fit may be employed, e.g., Gaussian, polynomial, and others.
0436After determining an acceptable fit of the data used for training, the SVM model is validated at step <b>3328</b>. Validation of an SVM model may be effected by running the same training data, and/or additional data, through the model again, and assessing the error.
0437The result of each Parallelize per parameter choice process <b>3310</b> is provided to a Choose Best Fit step <b>3330</b>, a part of the Parallelize per Zone process <b>3205</b>. This step entails assessing the results of different kernels, parameters, and hyperparameters, and determining a particular model with kernel, parameter and hyperparameters, for use with the training data set, that represents a chosen “best fit” of the training data to provide acceptable results in location prediction. It will be understood that various different types of kernels may be employed in embodiments of the invention, and that different kernels may be used for the same training data, as a matter of selected performance and accuracy.
0438The result of the Parallelize per Zone process <b>3305</b> is a Data Model export file provided at step <b>3340</b>, one or more depending upon the choice of SVM kernels, parameters, and hyperparameters used to construct the data model. The Data Model export file, as illustrated in the accompanying table, is written to the model storage database <b>750</b>. The data items of the Data Model export file <b>3340</b> include but are not limited to the following: a user or customer identifier (CustomerLabel), a master space identifier (SiteLabel), a time stamp of the data of the survey used to construct the model (SessionStartTime), one or more zone identifiers (area, room, subspace), and model delimiters (<Model> . . . </Model>) encapsulating the data corresponding to the data model.
0439According to one aspect of this disclosure, the Data Model export file is stored in the model storage database <b>750</b> indexed and/or searchable by a parameter corresponding to identification of the “tags that heard”, that is, by a parameter that represents the particular tags whose signal values from the initial survey scan are present. Data models are preferably retrieved for use in an object location operation by using a set of tags, based on the tag and beacon identifiers received from the tag data packages that include the beacon data package retrieved from the beacon associated with the object to be found, to search in the model storage database for models that have a matching set of tags. For example, referring back to <figref idref="DRAWINGS">FIG. <b>29</b>D</figref>, note that the scan from the beacon at prediction time included signals received from tags <b>25</b><i>a</i>, <b>25</b><i>b</i>, <b>25</b><i>g</i>, <b>25</b><i>h</i>, and <b>25</b><i>i</i>. These are the “tags that heard”, e.g., the tags that “heard” the beacon. The data models Model R<b>1</b> and Model R<b>3</b> also have the same set of “tags that heard”. Thus, these particular data models are retrieved from the model storage database <b>750</b> for use in the object location operation, as will be described. Those skilled in the art will understand how to construct an efficient retrieval algorithm for data model retrieval.
0440<figref idref="DRAWINGS">FIG. <b>34</b></figref> illustrates a process <b>3400</b> used to implement an Object Location function or process. According to one aspect, a specific object <b>20</b> associated with a particular RF beacon B located in a particular zone (area, room, subspace) is located in response to receipt at the disclosed object location system <b>10</b> of tag data package transmitted from the RF tag <b>25</b> (the tag data package represents the beacon data package received from the beacon B), and a room prediction data item (also known as a Zone Prediction) is returned by the process, which is then provided for use by the customer or user of the system <b>10</b> for its own purposes and applications. In accordance with one aspect, one or more ML data models are employed to conduct the room prediction, based on data accumulated during one or more surveys of the tag signals that are receivable in the master space, as described above.
0441In one aspect, the Object Location process <b>3400</b> comprises several nested subroutines or subprocesses including a Parallelize for all inbound requests process <b>3410</b>, which is executed for each object location operation however invoked, and a Parallelize per sample process <b>3420</b>, which is executed for each collection of RF data samples in tag data packages that represent the beacon data received from the beacon associated with the object to be located.
0442The Parallelize for all inbound requests process <b>3420</b> begins at step <b>3412</b>, where the system <b>10</b> has received a tag data package from the tag <b>25</b> that received data from the beacon B (not shown) associated with an object <b>20</b> to be located. The step <b>3412</b> is identified as Submit BLE scan with Cust/Site ID, indicating that the object location operation is invoked by providing an object location request data package <b>3414</b> that includes particular customer identifier (CustID), an identifier of the master space involved (SiteID), and a collection of RF data (RSSI values) associated with the RF beacon signals received from the beacon by the one or more RF tags within the to-be-identified subspace, and, the tag identifiers associated with the RF tags to which the beacon transmitter transmitted RF beacon signals. As shown in <figref idref="DRAWINGS">FIG. <b>34</b></figref>, the data items associated with an object location request data package command or request to identify an object location include but are not limited to: a customer identifier (CustID), a master space identifier (SiteID), and one or more sets of “scans” comprising a tag identifier and the RSSI values detected from the beacon by the tag and its one or more channels. Here is an exemplary format for an object location request data package as seen in <figref idref="DRAWINGS">FIG. <b>34</b></figref>:
0443<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>CustID: Acmelnc</entry></row><row><entry>SiteID: BeepBeep190</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="63pt" align="center" /><tbody valign="top"><row><entry>MAC address</entry><entry>Channel ID</entry><entry>RSSI</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="42pt" align="center" /><tbody valign="top"><row><entry>dcl8bdfl0</entry><entry>ch37</entry><entry>−45</entry><entry>−45</entry><entry>−50</entry></row><row><entry /><entry>ch38</entry><entry>−60</entry></row><row><entry>9381c8043</entry><entry>ch36</entry><entry>−45</entry><entry>−45</entry><entry>−50</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0444Upon receipt of this object location request data package <b>3414</b>, at step <b>3416</b> the model storage database <b>750</b> is accessed to obtain one or more prestored data models for the particular SiteID of the particular user of customer, as well as any required supplementary data (e.g., metadata further identifying locations, rooms, master spaces, street addresses, etc.) from the Customer Database <b>760</b>. Upon fetching of any data models (also known as Zone Models), a Parallelize Per Sample process <b>3420</b> is invoked.
0445At step <b>3425</b>, an array is filled with the RSSI data values/samples in the object location request data package (Fill X Array), and at step <b>3430</b>, a Parallelize Per Zone process <b>3430</b> is executed to obtain a prediction of whether the beacon and associated object are predicted to be in or out of a particular zone (room, subspace).
0446The result of the Parallelize Per Zone process <b>3430</b> is one or more predictions of a particular zone (room, subspace) in which the beacon B that provided the RSSI values received by the tag(s) in the subspace. Typically, a plurality of predictions of rooms will be generated, as multiple data models will be employed for a room prediction. At step <b>3435</b>, these multiple room predictions are preferably sorted by “strength” i.e., which according to one aspect facilitates a calculation of a probability and/or use of a “weighted voting” scheme that the object is located in that particular room. Reference is made in this regard to <figref idref="DRAWINGS">FIG. <b>29</b></figref>, which is an exemplary table of RSSI values and room predictions. By sorting a table of this nature populated with RSSI values by the detecting tags in the columns by RSSI value, it will be seen that the predictions of Room A are more frequent than those of Room B.
0447A list or table of sorted room predictions such as shown in the example of <figref idref="DRAWINGS">FIG. <b>29</b></figref> is then inspected at step <b>3440</b> to consolidate, i.e., identify, any contradictory samples. For example, as in the example table in <figref idref="DRAWINGS">FIG. <b>28</b></figref>, the prediction of Room B may be in error, as three of four data models predicted Room A; Room B is therefore contradictory according to a voting scheme, as employed in one aspect, and may be eliminated as a room prediction, or used in a probability calculation. At step <b>3445</b> a response (a zone or subspace prediction) is formatted, and at step <b>3450</b> a zone (or room, subspace) prediction of location is provided as an output. A typical format of a zone prediction data package returned is shown at <b>3455</b>, and includes data items including but not limited to: customer or user identifier (CustID), a master space identifier (SiteID), and a result comprising a confidence level e.g. <b>0</b>.<b>983</b> representing a probably calculation, a zone or subspace or room identifier (Room A), and optionally, accompanying metadata such as a name of the zone or subspace obtained by reference to customer information e.g. “Storeroom SE Corner.”
0000Use of Static Object for Calibration and Object Location Determination Resolution
0448According to another aspect, a static or reference object is used for calibration of the disclosed object location system, as providing additional, static, stable reference data for use in a data model.
0449Referring back to <figref idref="DRAWINGS">FIG. <b>21</b></figref>, a stationary object <b>20</b><i>b </i>with associated beacon B<b>2</b> is shown positioned in Room D. The beacon B<b>2</b> does not need to be associated with an object but may provide a suitable indicator to the system that it is stationary. According to this aspect, the beacon B<b>2</b> is queried on some predetermined basis (e.g., periodically, on a set schedule, randomly, etc.) to provide a tag data package that comprises readings from a predetermined set of tags who receive the signals that are transmitted by the beacon B<b>2</b>. For example, in <figref idref="DRAWINGS">FIG. <b>21</b></figref>, the beacon B<b>2</b> is shown transmitting signals to the tags <b>25</b><i>b</i>, <b>25</b><i>d</i>, and <b>25</b><i>e</i>. Signals received by these tags <b>25</b><i>b</i>, <b>25</b><i>d</i>, and <b>25</b><i>e </i>were previously identified and used in generating one or more data models for Room D in a prior survey operation. Generally, it is expected that the signals received by these tags will remain consistent over time and that the RSSI values received from beacons within Room D will only vary by a small, acceptable error, perhaps due to component drift, deterioration, temperature, or other factors. However, those skilled in the art will recognize that radio signals will change over time due to those factors. Furthermore, the radio signals received from the stationary beacon B<b>2</b>, as well as received from any beacons and objects in a location operation, may be altered or affected by other changes in the environment. For example, the introduction of Faraday barriers or cages, removal or addition of structural features such as windows, doors, roof or ceiling materials, flooring, obstacles, items on a shelf, etc. may significantly alter the RF environment and change the signals received by the stationary beacon B<b>2</b>.
0450If the change is sufficiently nominal, there is no need to take any action. However, there may be an error margin that suggests, or mandates, that adjustments be made in the data model(s) to compensate for changes. According to an aspect, the system <b>10</b> is operative to access the stationary beacon B<b>2</b> from time to time, and log the tag signals received from the beacon, and process the log for a deviation of the RSSI values that are indicative of a change in the environment. Steps for accessing the beacon B<b>2</b> and monitoring for changes in the RF environment may include, but are not limited to: (a) transmit a trigger signal to the beacon B<b>2</b> to cause a sampling operation, (b) the beacon B<b>2</b> collects a set of data values for the tags whose signals it detects and transmits to the tags this set of data values as part of the beacon data package, (c) one of the tags, for example, the tag <b>25</b><i>b </i>transmits a tag data package (representing the beacon data package) to the object location system, (d) the object location system receives the transmitted data from the tag and stores it in a local database in association with data from this particular stationary beacon (as well as any other stationary beacons), (e) the system processes the data from the stationary beacon to compare the readings with a calculated standard, (f) in the event that an error or deviation of the stationary beacon data exceeds a predetermined threshold, an “action condition” is indicated and provided to a system operator. It will be understood that data from prior operations that has accumulated over a certain predetermined time period may be used to determine the predetermined threshold, e.g., a mean of RSSI values of the various detecting tags over a predetermined time period, a sliding/moving set of values, etc.
0451According to one aspect, in the event of an error of a predetermined magnitude, but less than a second predetermined magnitude that amounts to an error condition that needs attention, may be used for a calibration operation. In such an operation, the system operator may conclude that the tags or other components are experiencing a drift of an acceptable degree over time, but not sufficient to indicate failure or unusability. In this exemplary case, the deviation amount may be used as the basis for a calibration adjustment of data values that were used to make up the data model(s). Therefore, the training data (and/or associated model) may be adjusted by adding a calibration value or offset to each prestored survey data item to compensate for the acceptable error or drift. From the foregoing, those skilled in the art will be enabled to provide computer program code to effect such calibration or error condition alerts.
0452Accordingly, it will now be understood that a monitored static object in a subspace provides for calibration and/or some degree of error compensation. In the event that the RF environment, shielding by other objects or structures, or other RF-affecting issues occur, a user of the system can continue to improve its model in ML iterations by knowing that the static object is still at its location but with alerts that the RF environment may have changed.
0453From the foregoing, it will now be appreciated that there is disclosed a system for location of objects within an identified subspace of a plurality of subspaces defined within a predefined master space. The disclosed system comprises a plurality of radio frequency (RF) transmitting and receiving tags positioned in a predetermined arrangement such that the RF energy from the RF beacons may illuminate at least a portion of the predefined master space and one or more of the subspaces, each of the RF tags located in a position spaced apart from other RF tags, each of the RF tags receiving an RF beacon signal at a predetermined frequency that has a beacon identifier.
0454The system further comprises one or more RF emitting beacons in proximate association with objects to be located in the master space, the RF beacon including (i) an electronic beacon identifier, (ii) a beacon transmitter operative to transmit RF beacon signals to one or more of the RF tags as the beacon assumes a position within the predefined master space, and (iii) a beacon data package assembler, wherein the beacon transmitter is operative to transmit a beacon data package assembled by the beacon data package assembler.
0455The system further comprises a models database for storing machine learning (ML) models.
0456The system further comprises an object location system including a radio gateway for receiving tag data packages transmitted by the RF transmitting and receiving tag, and a computer-implemented object location engine coupled to the radio gateway. In accordance with disclosed aspects of the system, the object location system is operative for: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0457">(a) for a predefined master space in which an object is to be located, in a master space survey operation, assigning a plurality of subspace identifiers to a plurality of subspaces having specific spatial boundaries within the master space and storing the subspace identifiers in a master space database for later association with RF signal data samples taken in a master space survey operation;</li><li id="ul0008-0002" num="0458">(b) conducting a master space survey operation by collecting data comprising RF signal data samples within the master space, generating one or more subspace data models from the RF signal data samples for use in connection with an object location operation, and storing the one or more subspace data models in the models database;</li><li id="ul0008-0003" num="0459">(c) for an object location operation to locate an object associated with a particular RF beacon within a to-be-identified subspace within the master space, receiving RF beacon signals at the tag receiver by one or more of the RF tags within the to-be-identified subspace within the master space, to thereby obtain a beacon-specific RF tag signal reading data comprising data derived from one or more RF tag signals and their associated tag identifiers within the to-be-identified subspace;</li><li id="ul0008-0004" num="0460">(d) at the tag data package assembler associated with the particular RF tag, using the RF beacon signal reading data, generating a tag data package comprising (i) a tag identifier of the particular RF tag, (ii) data associated with the RF beacon signals received from the one or more RF beacons within the to-be-identified subspace, and (iii) the beacon identifiers associated with the RF beacons from which the tag receiver received RF beacon signals;</li><li id="ul0008-0005" num="0461">(e) at the beacon data package assembler associated with the particular RF beacon, generating a beacon data package comprising (i) a beacon identifier of the particular RF beacon, (ii) data associated with the RF tag signals received from the one or more RF tags within the to-be-identified subspace, and (iii) the tag identifiers associated with the RF tags from which the beacon receiver received RF tag signals;</li><li id="ul0008-0006" num="0462">(f) at the particular RF beacon, transmitting the beacon data package to the RF tag receiver from the beacon data package assembler via the beacon transmitter of the RF beacon;</li><li id="ul0008-0007" num="0463">(g) at the particular RF tag, transmitting the tag data package (including the beacon data package received from the beacon) via the tag transmitter of the RF tag;</li><li id="ul0008-0008" num="0464">(h) receiving a transmitted tag data package from the tag transmitter of the particular RF tag at the receiver associated with the radio gateway so as to receive RF signals containing tag data packages including the beacon data package transmitted from one or more RF beacons within the to-be-identified subspace within the predefined master space;</li><li id="ul0008-0009" num="0465">(i) processing a tag data package received by the radio gateway receiver to extract the RF beacon signals received by the tag receiver in respect to the particular RF beacon associated with the object to be located in the to-be-identified subspace, the beacon identifiers, and the tag identifiers associated therewith;</li><li id="ul0008-0010" num="0466">(j) retrieving one or more stored subspace data models from the databases of the models based on one or more tag identifiers contained in the beacon data package retrieved from the beacon associated with the object to be located;</li><li id="ul0008-0011" num="0467">(k) executing the retrieved one or more stored subspace data models using as input parameters the RF beacon signals extracted from the beacon data package received from the beacon associated with the object to be located, to identify one or more prediction candidates of subspaces in which the object may be located, each prediction candidate comprising a subspace identifier produced by execution of each of the subspace data models;</li><li id="ul0008-0012" num="0468">(l) processing the one or more prediction candidates with a selection operation to determine a particular one of the subspace identifiers as the selected subspace identifier in which the object is predicted by the system to be located and thereby generate a determined subspace identifier for the object; and</li><li id="ul0008-0013" num="0469">(m) based on the determined subspace identifier, providing a data output from the object location system as a data package identifying the particular beacon and the determined subspace identifier to an external system, as indicating the location of the object associated with the beacon.</li></ul></li></ul>
0470It also be appreciated that the identified subspace may be a physical subspace defined by physical boundaries including but not limited to as walls, ceiling, floors, and the like. The identified subspace may also be a virtual subspace defined by virtual boundaries within one or more physical rooms. The master space may be a building and the subspace may be a room in the building.
0471According to one aspect, the above-mentioned master space survey is conducted by the steps of: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0472">(1) receiving data from a sampling operation with a sampling RF receiver in a survey device, by collecting RF data in the plurality of subspaces within the predefined master space by collecting RF signal samples from one or more RF tags at a plurality of sampling locations within each of the one or more of the subspaces in the predefined master space;</li><li id="ul0010-0002" num="0473">(2) for each of the subspaces, storing sampling data corresponding to said RF signal samples and tag identifiers associated with the RF signal samples from the sampling receiver in a sampling database correlated with a sampling location corresponding to a particular one of the subspaces as indicated by a corresponding subspace identifier;</li><li id="ul0010-0003" num="0474">(3) generating one or more subspace data models of the subspaces by applying a machine learning (ML) algorithm to the sampling data in the sampling database; and</li><li id="ul0010-0004" num="0475">(4) storing the one or more subspace data models in an ML model database for later access in connection with an object location operation.</li></ul></li></ul>
0476In accordance with an aspect, the master space survey operation collects RF signal data from one or more identifiable RF signal sources (IRFSS) in addition to signal data from RF tags, and wherein the one or more subspace data models are generated using data from said one or more IRFSS. The one or more IRFSS may include but are not limited to: Wi-Fi (IEEE 802.11) access points, Zigbee access points, Bluetooth transmitters, cellular network transmitters (2G-5G and beyond), AM/FM/shortwave/television transmitters.
0477According to one aspect, the RF signal data samples are in the form of received signal strength indicator (RSSI) data.
0478According to another aspect, the subspace data models are generated using a machine learning (ML) classification algorithm. The preferred ML classification algorithm is a support vector machine (SVM).
0479According to another aspect, a subspace data model comprises a collection of RF signal samples associated with each subspace identifier, associated tag identifiers, and RSSI values taken in the master space survey operation, each of said data models predicting a particular subspace identifier. The subspace data models are preferably derived from multiple sampling operations conducted at different locations within each subspace of the master space. In some implementations, each subspace is associated with a plurality of subspace data models, wherein the system is operative to generate a plurality of prediction candidates of subspaces in which the object may be located from a plurality of data models for each object location operation.
0480According to an aspect, the system for location of objects includes an RF beacon associated with an object, the RF beacon transmitting signals to one or more of RF tags transmitting to an object location system a tag data package including an identification of the signals received by the one or more RF tags from the RF beacon. According to an aspect, the object location system includes a gateway and a location engine. In some implementations, the gateway receives and extracts, from the transmitted tag data package, the identification of signals. According to an aspect, the location engine accesses an ML model trained by performing a survey of RF signals received from a plurality of RF signal sources during a prior RF master space survey operation and determining a subspace identifier corresponding to a predicted subspace location for the object by comparing the identification of signals included in the received tag data package to a model plurality of signals accessed from the model.
0481According to a further aspect, a selection from the plurality of prediction candidates includes determining an identified subspace for the object based on a voting algorithm executed on the plurality of prediction candidates. For example, the selection operation includes a voting process based on the greatest number of instances of determination of a particular subspace identifier by one of a plurality of different stored subspace data models.
0482According to another aspect, the system further conducts steps whereby the data values derived from an object location operation are added to a database together with the data from the master space survey operation and used to dynamically update the subspace data models. For example, in some implementations, the system updates the ML model(s) when (i) a user intervenes to correct an erroneous prediction of the subspace location for the object, (ii) a successful object location operation is performed, and/or (iii) scanned data is received from other additional sources providing data different from data in the transmitted tag data package.
0483According to another aspect, the RF beacon includes a signaling component, wherein a user is provided with a communication device for communicating to the system indicating proximity to a subspace identified as containing the beacon, and wherein the system executes a “last ten feet” proximity operation to notify a user of proximity to the RF beacon upon approach by the user having possession of the communication device, by actuating the signaling component. As disclosed, the signaling device may include one or more of a light, an audible sound generating device, a haptic signaling component.
0484According to one preferred aspect, the RF beacon includes a motion sensor that is operative to trigger transmission of a beacon data package (that is further included in the tag data package) in response to detection of movement of the beacon.
0485According to another aspect, the system is further operative to automatically detect changes in the RF environment of the master space resulting from physical changes to the environment by detecting a change in RF signals received by one or more tags or other IFRSS during an object location operation, and update one or more subspace data models to compensate for the changed environment. In this regard, the system may be configured to automatically detect changes in the RF environment of the master space resulting from failure or degradation of one or more tags by detecting a change in or absence of RF signals received by one or more tags during an object location operation, and update one or more subspace data models to compensate for the changed environment.
0486It will also now be appreciated that the present disclosure described a method for location of objects within an identified subspace defined within a predefined master space. The disclosed method comprises steps including: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0487">(a) for a predefined master space in which an object is to be located, in a master space survey operation, assigning a plurality of subspace identifiers to a plurality of subspaces having specific spatial boundaries within the master space and storing the subspace identifiers in a master space database for later association with RF signal data samples taken in a sampling operation;</li><li id="ul0012-0002" num="0488">(b) placing a plurality of radio frequency (RF) receiving and transmitting tags in a predetermined arrangement such that the RF energy from the one or more RF beacons may illuminate at least a portion of the predefined master space and one or more of the subspaces, each of the RF tags located in a position spaced apart from other RF tags, each of the RF tags receiving an RF beacon signal at a predetermined frequency and having a beacon identifier;</li><li id="ul0012-0003" num="0489">(c) conducting a master space survey operation by collecting data comprising RF signal data samples within the master space, generating one or more subspace data models from the RF signal data samples for use in connection with an object location operation, and storing the one or more subspace data models in the models database;</li><li id="ul0012-0004" num="0490">(d) for an object to be located within a particular subspace within the master space via an object location operation via an object location system, associating an RF emitting beacon with the object, the RF beacon including (i) an electronic beacon identifier, (ii) a beacon transmitter operative to transmit RF beacon signals to one or more of the RF tags as the beacon assumes a position within the predefined master space, and (iii) a beacon data package assembler, wherein the beacon transmitter is operative to transmit a beacon data package assembled by the beacon data package assembler;</li><li id="ul0012-0005" num="0491">(e) for an object to be located within a particular subspace within the master space via an object location operation via an object location system, providing the RF tag that includes (i) an electronic tag identifier, (ii) a tag receiver operative to receive RF beacon signals from one or more of the RF beacons as the RF beacon assumes a position within the predefined master space, (iii) a tag data package assembler, and (iv) a tag transmitter operative to transmit a tag data package assembled by the tag data package assembler;</li><li id="ul0012-0006" num="0492">(f) for an object location operation, at particular RF beacon associated with an object to be located within a to-be-identified subspace via the object location operation within the master space, transmitting RF beacon signals to the tag receiver from the RF beacon as the object associated with the RF beacon assumes a position within the to-be-identified subspace within the master space, to thereby generate a beacon-specific RF tag signal reading data included in data derived from one or more RF tag signals and their associated tag identifiers within the to-be-identified subspace;</li><li id="ul0012-0007" num="0493">(g) at the beacon data package assembler associated with the particular RF beacon, using the RF tag signal reading data, generating a beacon data package comprising (i) a beacon identifier of the particular RF beacon, (ii) data associated with the RF tag signals received from the one or more RF tags within the to-be-identified subspace, and (iii) the tag identifiers associated with the RF tags from which the beacon receiver received RF tag signals;</li><li id="ul0012-0008" num="0494">(h) at the particular RF beacon, transmitting the beacon data package to the RF tag receiver from the beacon data package assembler via the beacon transmitter of the RF beacon;</li><li id="ul0012-0009" num="0495">(i) at the particular RF tag, transmitting the tag data package (including the beacon data package received from the beacon) via the tag transmitter of the RF tag;</li><li id="ul0012-0010" num="0496">(j) at an object location system, receiving a transmitted tag data package from the tag transmitter of the particular RF tag at receiver associated with a radio gateway so as to receive RF signals containing tag data packages transmitted from one or more RF tags within the to-be-identified subspace within the predefined master space;</li><li id="ul0012-0011" num="0497">(k) at the object location system, processing a tag data package received by the radio gateway receiver to extract the RF beacon signals received by the tag receiver in the particular RF beacon associated with the object to be located in the to-be-identified subspace, the beacon identifiers, and the tag identifiers associated therewith;</li><li id="ul0012-0012" num="0498">(l) with the object location system, retrieving one or more stored subspace data models from the ML database based on one or more tag identifiers contained in the beacon data package retrieved from the beacon associated with the object to be located;</li><li id="ul0012-0013" num="0499">(m) with the object location system, executing the retrieved one or more stored subspace data models using as input parameters the RF beacon signals extracted from the tag data package received from the beacon associated with the object to be located, to identify one or more prediction candidates of subspaces in which the object may be located, each prediction candidate comprising a subspace identifier produced by execution of each of the subspace data models;</li><li id="ul0012-0014" num="0500">(n) processing the one or more prediction candidate with a selection operation to determine a particular one of the subspace identifiers as the selected subspace identifier in which the object is predicted by the system to be located and thereby generate a determined subspace identifier for the object;</li><li id="ul0012-0015" num="0501">(o) based on the determined subspace identifier, providing a data output from the object location system as a data package identifying the particular beacon and the determined subspace identifier to an external system, as indicating the location of the object associated with the beacon.</li></ul></li></ul>
0502From the foregoing, it will be understood that various aspects of the processes described herein are software processes that execute on computer systems that form parts of the system. Accordingly, it will be understood that various embodiments of the system described herein are generally implemented as specially configured computers including various computer hardware components and, in many cases, significant additional features as compared to conventional or known computers, processes, or the like, as discussed in greater detail herein. Embodiments within the scope of the present disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media which can be accessed by a computer, or downloadable through communication networks. By way of example, and not limitation, such computer-readable media can comprise various forms of data storage devices or media such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage, magnetic disk storage, solid state drives (SSDs) or other data storage devices, any type of removable nonvolatile memories such as secure digital (SD), flash memory, memory stick, etc., or any other medium which can be used to carry or store computer program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose computer, special purpose computer, specially-configured computer, mobile device, etc.
0503When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such a connection is properly termed and considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device such as a mobile device processor to perform one specific function or a group of functions.
0504Those skilled in the art will understand the features and aspects of a suitable computing environment in which aspects of the disclosure may be implemented. Although not required, some of the embodiments of the claimed inventions may be described in the context of computer-executable instructions, such as program modules or engines, as described earlier, being executed by computers in networked environments. Such program modules are often reflected and illustrated by flow charts, sequence diagrams, exemplary screen displays, and other techniques used by those skilled in the art to communicate how to make and use such computer program modules. Generally, program modules include routines, programs, functions, objects, components, data structures, application programming interface (API) calls to other computers whether local or remote, etc. that perform particular tasks or implement particular defined data types, within the computer. Computer-executable instructions, associated data structures and/or schemas, and program modules represent examples of the program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
0505Those skilled in the art will also appreciate that the claimed and/or described systems and methods may be practiced in network computing environments with many types of computer system configurations, including personal computers, smartphones, tablets, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, and the like. Embodiments of the claimed invention are practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
0506An exemplary system for implementing various aspects of the described operations, which is not illustrated, includes a computing device including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The computer will typically include one or more data storage devices for reading data from and writing data to. The data storage devices provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for the computer.
0507Computer program code that implements the functionality described herein typically comprises one or more program modules that may be stored on a data storage device. This program code, as is known to those skilled in the art, usually includes an operating system, one or more application programs, other program modules, and program data. A user may enter commands and information into the computer through keyboard, touch screen, pointing device, a script containing computer program code written in a scripting language or other input devices (not shown), such as a microphone, etc. These and other input devices are often connected to the processing unit through known electrical, optical, or wireless connections.
0508The computer that effects many aspects of the described processes will typically operate in a networked environment using logical connections to one or more remote computers or data sources, which are described further below. Remote computers may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to the main computer system in which the inventions are embodied. The logical connections between computers include a local area network (LAN), a wide area network (WAN), virtual networks (WAN or LAN), and wireless LANs (WLAN) that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets, and the Internet.
0509When used in a LAN or WLAN networking environment, a computer system implementing aspects of the invention is connected to the local network through a network interface or adapter. When used in a WAN or WLAN networking environment, the computer may include a modem, a wireless link, or other mechanisms for establishing communications over the wide area network, such as the Internet. In a networked environment, program modules depicted relative to the computer, or portions thereof, may be stored in a remote data storage device. It will be appreciated that the network connections described or shown are exemplary and other mechanisms of establishing communications over wide area networks or the Internet may be used.
0510While various aspects have been described in the context of a preferred embodiment, additional aspects, features, and methodologies of the claimed inventions will be readily discernible from the description herein, by those of ordinary skill in the art. Many embodiments and adaptations of the disclosure and claimed inventions other than those herein described, as well as many variations, modifications, and equivalent arrangements and methodologies, will be apparent from or reasonably suggested by the disclosure and the foregoing description thereof, without departing from the substance or scope of the claims. Furthermore, any sequence(s) and/or temporal order of steps of various processes described and claimed herein are those considered to be the best mode contemplated for carrying out the claimed inventions. It should also be understood that, although steps of various processes may be shown and described as being in a preferred sequence or temporal order, the steps of any such processes are not limited to being carried out in any particular sequence or order, absent a specific indication of such to achieve a particular intended result. In most cases, the steps of such processes may be carried out in a variety of different sequences and orders, while still falling within the scope of the claimed inventions. In addition, some steps may be carried out simultaneously, contemporaneously, or in synchronization with other steps.
0511The embodiments were chosen and described in order to explain the principles of the claimed inventions and their practical application so as to enable others skilled in the art to utilize the inventions and various embodiments and with various modifications as are suited to the particular use contemplated. Alternative embodiments will become apparent to those skilled in the art to which the claimed inventions pertain without departing from their spirit and scope. Accordingly, the scope of the claimed inventions is defined by the appended claims rather than the foregoing description and the exemplary embodiments described therein.
Contents7
43 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8957812B1 | Cites | United States of America | Applicant |
| US9065699B2 | Cites | United States of America | Applicant |
| US9363784B1 | Cites | United States of America | Applicant |
| US9408040B2 | Cites | United States of America | Search report |
| US9584193B2 | Cites | United States of America | Applicant |
| US9807724B2 | Cites | United States of America | Applicant |
| US10135499B2 | Cites | United States of America | Applicant |
| US10222448B2 | Cites | United States of America | Applicant |
| US10554253B2 | Cites | United States of America | Applicant |
| US10769812B2 | Cites | United States of America | Applicant |
| US10772059B2 | Cites | United States of America | Applicant |
| US20120066035A1 | Cites | United States of America | Applicant |
| US20140194143A1 | Cites | United States of America | Applicant |
| US20150079942A1 | Cites | United States of America | Search report |
| US20150091702A1 | Cites | United States of America | Search report |
| US20160295372A1 | Cites | United States of America | Search report |
| US20180160269A1 | Cites | United States of America | Search report |
| US20200285977A1 | Cites | United States of America | Search report |
| US20200288284A1 | Cites | United States of America | Search report |
| US20210279953A1 | Cites | United States of America | Applicant |
| US20210364298A1 | Cites | United States of America | Search report |
| US20220141619A1 | Cites | United States of America | Applicant |
| US20240230821A1 | Cites | United States of America | Applicant |
| WO2015049660A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| US2015079942A1 | Cites | United States of America | Search report |
| US2015091702A1 | Cites | United States of America | Search report |
| US2016295372A1 | Cites | United States of America | Search report |
| US2018160269A1 | Cites | United States of America | Search report |
| US2020285977A1 | Cites | United States of America | Search report |
| US2020288284A1 | Cites | United States of America | Search report |
| US2021364298A1 | Cites | United States of America | Search report |
| US2012066035A1 | Cites | United States of America | Applicant |
| US2014194143A1 | Cites | United States of America | Applicant |
| US2021279953A1 | Cites | United States of America | Applicant |
| US2022141619A1 | Cites | United States of America | Applicant |
| US2024230821A1 | Cites | United States of America | Applicant |
| WO2015049660A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| Final Office Action on U.S. Appl. No. 17/083,981 Dtd Jun. 13, 2022. | Non-patent | – | Applicant |
| Non-Final Office Action on U.S. Appl. No. 17/083,981 Dtd Oct. 17, 2022. | Non-patent | – | Applicant |
| US Office Action on U.S. Appl. No. 17/083,981 Dtd Oct. 21, 2021. | Non-patent | – | Applicant |
| Ajayannan et al., Smart Indoor Navigation Using Wifi Triangulation, International Journal of Engineering Research & Technology (IJERT), NCRTET-2015 Conference Proceedings, Special Issue—2015, vol. 3, Issue 04, pp. 1-5. | Non-patent | – | Applicant |
| Ben-Hur et al., A User's Guide to Support Vector Machines, Ch. 13 in Methods in Molecular Biology (Clifton, N.J.), Jan. 2010, pp. 223-239. | Non-patent | – | Applicant |
| Chen et al., High Accuracy Indoor Localization: A WiFi-based Approach, 2016 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), Shanghai, 2016, pp. 6245-6249, doi: 10.1109/ICASSP.2016.7472878. | Non-patent | – | Applicant |
| Faragher et al., An Analysis of the Accuracy of Bluetooth Low Energy for Indoor Positioning Applications, Proceedings of the 27th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2014), Sep. 8-12, 2014, pp. 201-210. | Non-patent | – | Applicant |
| Faragher et al., Location Fingerprinting With Bluetooth Low Energy Beacons, IEEE Journal on Selected Areas in Communications, Nov. 2015, pp. 2418-2428, vol. 33, No. 11. | Non-patent | – | Applicant |
| Han et al., A Visual Analytics System for Radio Frequency Fingerprinting-based Localization, Proceedings of the IEEE Symposium on Visual Analytics Science and Technology, IEEE Vast 2009, Atlantic City, New Jersey, USA, Oct. 11-16, 2009, part of VisWeek 2009, Jan. 2009, pp. 1-8. | Non-patent | – | Applicant |
| He et al., Wi-Fi Fingerprint-Based Indoor Positioning: Recent Advances and Comparisons, IEEE Communications Survey & Tutorials, First Quarter 2016, pp. 466-490, vol. 18, No. 1. | Non-patent | – | Applicant |
| Hu et al., WLAN location determination in e-home via support vector classification, Conference Paper / Feb. 2004, Proceedings of the 2004 IEEE International Conference on Networking, Sensing & Control, Taipei, Taiwan, Mar. 21-25, 2004, pp. 1026-1032. | Non-patent | – | Applicant |
| Ibrahim et al., CNN based Indoor Localization using RSS Time-Series, Conference Paper IEEE ISCC At: Brazil, Jun. 2018, DOI: 10.1109/ISCC.2018.8538530, pp. 1-7. | Non-patent | – | Applicant |
| Jang et al., Indoor Positioning Technologies Without Offline Fingerprinting Map: A Survey, IEEE Communications Surveys & Tutorials, First Quarter 2019, pp. 508-525, vol. 21, No. 1. | Non-patent | – | Applicant |
| Kennedy et al., Topic Models for RFID Data Modeling and Localization, 2017 IEEE Intl Conference on Big Data, pp. 1438-1445 (2017). | Non-patent | – | Applicant |
| Non-final Office Action for U.S. Appl. No. 17/083,981 dated Oct. 24, 2023. | Non-patent | – | Applicant |
| Non-Final Office Action for U.S. Appl. No. 18/613,946 dated Nov. 13, 2024. | Non-patent | – | Applicant |
| Paek et al., A Measurement Study of BLE iBeacon and Geometric Adjustment Scheme for Indoor Location-Based Mobile Application, Mobile Information Systems, Hindawi Publishing Corporation, vol. 2016, Article ID 8367638, http://dx.doi.org/10.1155/2016/8367638, pp. 1-13. | Non-patent | – | Applicant |
| Raghavan et al., Accurate Mobile Robot Localization in indoor environments using Bluetooth, 2010 IEEE Intemational Conference on Robotics and Automation, Anchorage Convention District, May 3-8, 2010, Anchorage, Alaska, USA, pp. 4391-4396. | Non-patent | – | Applicant |
| Simonoff et al., Intra-Spacecraft RFID Localization, 2021 IEEE Intl Conference on RFID, 8 pp. (pages not numbered). | Non-patent | – | Applicant |
| Wen et al., “Indoor Localization algorithm based on artificial neural network and radio-frequency identification reference tags”, Advances in Mechanical Engineering, 2018, vol. 10(12) 1-12. | Non-patent | – | Applicant |
| Wu et al., WILL: Wireless Indoor Localization Without Site Survey, publication and date unknown, believed to be earller preprint of NPL7, above. | Non-patent | – | Applicant |
| Zhu et al., RSSI Based Bluetooth Low Energy Indoor Positioning, 2014 International Conference on Indoor Positioning and Indoor Navigation, Oct. 27-30, 2014, pp. 526-533. | Non-patent | – | Applicant |
| Zhu et al., RSSI-based Algorithm for Indoor Localization, Communications and Network, 2013, 5, 37-42, doi:10.4236/cn.2013.52B007 Published Online May 2013 (http://www.scirp.org/journal/cn). | Non-patent | – | Applicant |
| Final Office Action for U.S. Appl. No. 18/613,946 dated Jun. 16, 2025. | Non-patent | – | Applicant |
| Final Office Action on U.S. Appl. No. 17/083,981 Dtd Jun. 13, 2022. | Non-patent | – | Applicant |
| Non-Final Office Action on U.S. Appl. No. 17/083,981 Dtd Oct. 17, 2022. | Non-patent | – | Applicant |
| US Office Action on U.S. Appl. No. 17/083,981 Dtd Oct. 21, 2021. | Non-patent | – | Applicant |
| Ajayannan et al., Smart Indoor Navigation Using Wifi Triangulation, International Journal of Engineering Research & Technology (IJERT), NCRTET-2015 Conference Proceedings, Special Issue—2015, vol. 3, Issue 04, pp. 1-5. | Non-patent | – | Applicant |
| Ben-Hur et al., A User's Guide to Support Vector Machines, Ch. 13 in Methods in Molecular Biology (Clifton, N.J.), Jan. 2010, pp. 223-239. | Non-patent | – | Applicant |
| Chen et al., High Accuracy Indoor Localization: A WiFi-based Approach, 2016 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), Shanghai, 2016, pp. 6245-6249, doi: 10.1109/ICASSP.2016.7472878. | Non-patent | – | Applicant |
| Faragher et al., An Analysis of the Accuracy of Bluetooth Low Energy for Indoor Positioning Applications, Proceedings of the 27th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2014), Sep. 8-12, 2014, pp. 201-210. | Non-patent | – | Applicant |
| Faragher et al., Location Fingerprinting With Bluetooth Low Energy Beacons, IEEE Journal on Selected Areas in Communications, Nov. 2015, pp. 2418-2428, vol. 33, No. 11. | Non-patent | – | Applicant |
| Han et al., A Visual Analytics System for Radio Frequency Fingerprinting-based Localization, Proceedings of the IEEE Symposium on Visual Analytics Science and Technology, IEEE Vast 2009, Atlantic City, New Jersey, USA, Oct. 11-16, 2009, part of VisWeek 2009, Jan. 2009, pp. 1-8. | Non-patent | – | Applicant |
| He et al., Wi-Fi Fingerprint-Based Indoor Positioning: Recent Advances and Comparisons, IEEE Communications Survey & Tutorials, First Quarter 2016, pp. 466-490, vol. 18, No. 1. | Non-patent | – | Applicant |
| Hu et al., WLAN location determination in e-home via support vector classification, Conference Paper / Feb. 2004, Proceedings of the 2004 IEEE International Conference on Networking, Sensing & Control, Taipei, Taiwan, Mar. 21-25, 2004, pp. 1026-1032. | Non-patent | – | Applicant |
| Ibrahim et al., CNN based Indoor Localization using RSS Time-Series, Conference Paper IEEE ISCC At: Brazil, Jun. 2018, DOI: 10.1109/ISCC.2018.8538530, pp. 1-7. | Non-patent | – | Applicant |
| Jang et al., Indoor Positioning Technologies Without Offline Fingerprinting Map: A Survey, IEEE Communications Surveys & Tutorials, First Quarter 2019, pp. 508-525, vol. 21, No. 1. | Non-patent | – | Applicant |
| Kennedy et al., Topic Models for RFID Data Modeling and Localization, 2017 IEEE Intl Conference on Big Data, pp. 1438-1445 (2017). | Non-patent | – | Applicant |
| Non-final Office Action for U.S. Appl. No. 17/083,981 dated Oct. 24, 2023. | Non-patent | – | Applicant |
| Non-Final Office Action for U.S. Appl. No. 18/613,946 dated Nov. 13, 2024. | Non-patent | – | Applicant |
| Paek et al., A Measurement Study of BLE iBeacon and Geometric Adjustment Scheme for Indoor Location-Based Mobile Application, Mobile Information Systems, Hindawi Publishing Corporation, vol. 2016, Article ID 8367638, http://dx.doi.org/10.1155/2016/8367638, pp. 1-13. | Non-patent | – | Applicant |
| Raghavan et al., Accurate Mobile Robot Localization in indoor environments using Bluetooth, 2010 IEEE Intemational Conference on Robotics and Automation, Anchorage Convention District, May 3-8, 2010, Anchorage, Alaska, USA, pp. 4391-4396. | Non-patent | – | Applicant |
| Simonoff et al., Intra-Spacecraft RFID Localization, 2021 IEEE Intl Conference on RFID, 8 pp. (pages not numbered). | Non-patent | – | Applicant |
| Wen et al., “Indoor Localization algorithm based on artificial neural network and radio-frequency identification reference tags”, Advances in Mechanical Engineering, 2018, vol. 10(12) 1-12. | Non-patent | – | Applicant |
| Wu et al., WILL: Wireless Indoor Localization Without Site Survey, publication and date unknown, believed to be earller preprint of NPL7, above. | Non-patent | – | Applicant |
| Zhu et al., RSSI Based Bluetooth Low Energy Indoor Positioning, 2014 International Conference on Indoor Positioning and Indoor Navigation, Oct. 27-30, 2014, pp. 526-533. | Non-patent | – | Applicant |
| Zhu et al., RSSI-based Algorithm for Indoor Localization, Communications and Network, 2013, 5, 37-42, doi:10.4236/cn.2013.52B007 Published Online May 2013 (http://www.scirp.org/journal/cn). | Non-patent | – | Applicant |
| Final Office Action for U.S. Appl. No. 18/613,946 dated Jun. 16, 2025. | Non-patent | – | Applicant |
1 priority claim, no other members on record
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 202017083981 | United States of America | A |
85 transactions on the USPTO file
Allowed after 1 non-final rejection, 1 final rejection and 1 RCE.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Mail Patent eGrant NotificationMEPG_NTF | MEPG_NTF | |
| Patent eGrant NotificationEPG_NTF | EPG_NTF | |
| Recordation of Patent eGrantEPG/ | EPG/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Workflow - Drawings FinishedDRWF | DRWF | |
| Printer Rush- No mailingTCPB | TCPB | |
| Email NotificationEML_NTR | EML_NTR | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail PUB other miscellaneous communication to applicantMM327-D | MM327-D | |
| Mail PUB other miscellaneous communication to applicantMM327-D | MM327-D | |
| PUB Other miscellaneous communication to applicantM327-D | M327-D | |
| PUB Other miscellaneous communication to applicantM327-D | M327-D | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Terminal Disclaimer FiledDIST | DIST | |
| Interview Summary - Examiner Initiated - TelephonicEXET | EXET | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Miscellaneous Communication to ApplicantMM327 | MM327 | |
| Miscellaneous Communication to Applicant - No Action CountM327 | M327 | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTR | EML_NTR | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Pre-Exam NoticeMPEN | MPEN | |
| Application Is Now CompleteCOMP | COMP | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Sent to Classification ContractorPGPC | PGPC | |
| FITF set to YES - revise initial settingFTFS | FTFS | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Email NotificationEML_NTR | EML_NTR | |
| Notice of Incomplete ReplyINCR | INCR | |
| Mail Pre-Exam NoticeMPEN | MPEN | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTR | EML_NTR | |
| Email NotificationEML_NTF | EML_NTF | |
| Email NotificationEML_NTF | EML_NTF | |
| Corrected PaperCPAP | CPAP | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Corrected PaperCPAP | CPAP | |
| Mail Pre-Exam NoticeMPEN | MPEN | |
| Applicant Has Filed a Verified Statement of Small Entity Status in Compliance with 37 CFR 1.27SMAL | SMAL | |
| PTO/SB/69-Authorize EPO Access to Search ResultsSREXR141 | SREXR141 | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS | |
| Entity Status Set To Undiscounted (Initial Default Setting or Status Change)BIG. | BIG. | |
| Initial Exam Team nnIEXX | IEXX |
14 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| Information on status: patent application and granting procedure in generalPUBLICATIONS -- ISSUE FEE PAYMENT RECEIVEDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalPUBLICATIONS -- ISSUE FEE PAYMENT VERIFIEDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalNOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONSSTPP | STPP | |
| Information on status: patent application and granting procedure in generalAWAITING TC RESP., ISSUE FEE NOT PAIDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalNOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONSSTPP | STPP | |
| Information on status: patent application and granting procedure in generalALLOWED -- NOTICE OF ALLOWANCE NOT YET MAILEDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalDOCKETED NEW CASE - READY FOR EXAMINATIONSTPP | STPP | |
| Information on status: patent application and granting procedure in generalFINAL REJECTION MAILEDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalNON FINAL ACTION MAILEDSTPP | STPP | |
| Information on status: patent application and granting procedure in generalDOCKETED NEW CASE - READY FOR EXAMINATIONSTPP | STPP | |
| Fee payment procedureENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| Fee payment procedureENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITYFEPP | FEPP |
Numbers
- Publication
- 12596169
- Application
- 17959422
Titles
- English
- Method and system for locating objects within a master space using machine learning on RF radiolocation
Patent term adjustment
- A delay
- +450 daysthe office missed an examination deadline
- B delay
- +123 dayspendency past three years
- Applicant delay
- −37 days
- Net adjustment
- 536 days
Classification
- CPC, 11
- G01S5/013
- G06N20/00
- G01S5/0278
- H04W4/029
- G06K7/10297
- H04W4/80
- G06N20/10
- G06K17/00
- G01S5/0036
- G01S5/017
- G06N3/084
- IPC, 4
- G01S5 00
- G01S5 02
- G06K7 10
- G06N20 10