PRIVATE LOCATION DETECTION SYSTEM This application claims benefits from U.S. Provisional Application No. 60/555,968, filed March 25, 2004, the contents of which are hereby incorporated by reference.
FIELD OF THE INVENTION The present invention relates generally to ubiquitous location tracking system, method, and devices that includes a system with people and objects wearing tags, a network that communicates with the tags, and a supervisory program (server) that can track information concerning the tags such as their location. The tag can be worn, is capable of communicating with a wireless network, providing real-time information about the wearer, and specifically providing information from which the system can derive the tag's location.
BACKGROUND OF THE INVENTION
Private locating systems have been designed for a number of applications. Each of these design systems offers certain advantages depending on their related applications. A sample private detection systems is described in U.S. Patent No. 6,362,778 to
Neher et al. This patent describes a location system where the user retains a portable locator device employing various location technologies that include Global Positioning Satellite (GPS) System and a beacon for pinpointing the device. The system designed by Neher has deficiencies that are: 1. The Wherify device operates on one network protocol at a time. Does not support concurrent communication networks; 2. Can not be used to track people or assets in-doors; 3. Can not route location information between in-door and out-door facilities or campuses; 4. The server is an ASP model; hence, integration with other critical mission customer applications at customer site is not possible. An example of a location detection systems is described in PCT Application No. WO 02/054813, to Myllymaki et at. This application describes a location system and components of such where a device in a wireless communication environment uses
measured signal parameters, calibration data and statistical modeling to approximate the location of the receiver. Another location detection systems is described in PCT Application No. WO 03/102620, to Myllymaki et al. This application describes a component of a location system where a device's location is estimated based on a probabilistic model and a set of measured signal parameters in a wireless communication environment. Yet another location detection system is described in PCT Application No. WO 03/102621, to Myllymaki et al. T-his application describes a component of a location system where a device's location is estimated based on a location estimation module using a probabilistic model and sequence of observations in a wireless communication environment. Furthermore, PCT Application No. WO 03/102622, to Myllym ki et al. describes a component of a location system where a device's location is estimated based on a location estimation module using a probabilistic model and construction of the model based on probability distributions of signal parameters in a wireless communication environment. Further, PCT Application No. WO 2004/008795 to Misikangas et al. describes a component of a location system where a graph representing permissible locations and transitions is used to estimate a device's location based on sequence of measured signal parameters, calibration data and statistical modeling to approximate the location of the receiver. These systems designed by Myllymaki and Misikangas have the following deficiencies: 1. The systems do not provide for simple calibration for premise modeling. 2. The systems do not provide for ground-truth location information. It does not eliminate uncertainties due to RF propagation. 3. The systems have no scheme for real-time calibration. It relies on statistical best estimate on input. 4. The systems are server software solution only. In order to meet current demands placed on locating applications, there is a need to further enhance the tracking and locating capabilities of these systems.
SUMMARY OF THE INVENTION The invention is advantageous in that it provides a private ubiquitous end-to-end locating detection system. There is another advantage in that the invention provides seamless in-door and outdoors coverage.
There is another advantage in that the invention does not depend on the use of GPS but can incorporate it as required. A further advantage of the present invention is to provide the Ubiquitous Location Tracking (ULT) system with concurrent commercial network communication paths; provides flexibility in geographic coverage. Cost incursion for end-user public networks are utilized only when necessary. Still a further advantage is the API which incorporates new commercial networks or proprietary networks such as ?RF(Radio Frequency), 1XRTT, GPRS, WiFi, IrDA (Infrared Data) and UWB for an end-user plug-and-play deployment. It is yet a further advantage of the present invention wherein the user wears a
"wearable" tag for detection of motion and location wirelessly. Still a further advantage of the present invention is that it is possible to send messages to the "wearable" tag via bi-directional communication or messaging that stores data to device or server dynamically. Still a further advantage of the present invention is that the Ubiquitous Location
Tracking (ULT) tag uses tapping to signal for help and can also trigger more extreme emergency alarm if the wearer falls. Yet a further advantage of the present invention is that it can update location and other real-time information of people and objects wearing the tags to other applications without affecting the acquisition of this data. h accordance with a first aspect of the invention, there is provided a method of assessing the location of a moveable device, comprising receiving from each of a plurality of base stations, a radio frequency signal used by the moveable device to assess a signal strength of the radio frequency signal from the one of the plurality of base stations originating the radio frequency signal; receiving a proximity signal indicating that the moveable device is in the vicinity of a proximity sensor at a known location; transmitting indicators of signal strengths of the radio frequency signals, and transmitting proximity data indicative of the proximity signal to a computing device for computing at the computing device an estimate of the location of the moveable device based on the indicators of signal strength and the proximity data. In accordance with a second aspect of the present invention, there is provided at a computing device, a method of estimating the location of a moveable device, comprising
storing groups of signal strengths for each of a plurality of geographic zones, each group representative of expected signal strengths of radio frequency signals from multiple base stations as received by the moveable device when in the zone; receiving from the moveable device, a plurality of signal strength indicators, each of the signal strength indicators indicative of a strength of a radio frequency signal originated by one of a plurality of base stations; comparing groups of the plurality of received signal strength indicators to the groups of stored signal strength indicators, to assess which of the plurality of geographic zones the moveable device is in. In accordance with a third aspect of the present invention, there is provided a computing device comprising a processor in communication with computer readable memory, the computer readable memory storing groups of signal strengths for each of a plurality of geographic zones, each group representative of expected signal strengths of radio frequency signals from multiple base stations as received by a moveable device when in the zone; the computer readable memory further storing processor executable instructions adapting the computing device to receive from the moveable device, a plurality of signal strength indicators, each of the signal strength indicators indicative of a strength of a radio frequency signal originated by one of a plurality of base stations; and compare groups of the plurality of received signal strengths to the groups of stored signal strength indicators, to assess which of the plurality of geographic zones the moveable device is in. In accordance with a fourth aspect of the present invention, there is provided at a computing device, a method of estimating the location of a moveable device, comprising receiving from the moveable device, a plurality of signal strength indicators, each of the signal strength indicators indicative of a strength of a radio frequency signal originated by one of a plurality of base stations; receiving proximity data indicative of having sensed the moveable device in the vicinity of a proximity sensor at a known location; computing an estimate of the location of the moveable device based on the indicators of signal strength and the proximity data. In accordance with a fifth aspect of the present invention, there is provided a moveable device, comprising a plurality of radio receivers, each radio receive for receiving a specific type of radio frequency signal from a plurality of base stations; a processor operable to provide signals indicative of signal strengths of radio frequency signals from a plurality of
base stations originating radio frequency signals received by a selected active one of the plurality of radio receivers; the processor operable to activate different ones of the plurality of radio receivers as the mobile device moves; at least one radio transmitter, operable to transmit the signals indicative of signal strengths of radio frequency signals.
BRIEF DESCRIPTION OF THE DRAWINGS These and other features of the invention will become more apparent in the following detailed description wherein reference is made to the accompanying drawings, in which like reference characters designate the same or similar parts throughout. FIG. 1 is an illustration of a private ubiquitous location system in accordance with an embodiment of the present invention; FIG. 2 is a flow diagram illustrating the flow between different operating modes of the private ubiquitous location system; FIG. 3 A and 3B are block diagrams of the internal components of the wearable/aimer devices in accordance with an embodiment of the present invention; and
FIG.4A, 4B, 5 and 6 are flow charts of software for controlling the devices illustrated in FIG 1 ;
DESCRIPTION OF THE PREFERRED EMBODIMENT In order to meet current demands placed on locating applications, there is a need to further enhance the tracking and locating capabilities of systems incorporated in the prior art. This is achieved by the present embodiment of the invention through real-time data collection of people and objects wearing tags, as well as ensuring that the device being tracked does not broadcast its position, hence providing greater security. The ubiquitous private detection system of the present embodiment supports concurrent communication networks, ability to track people and assets in-doors and out-doors, route information between in-door and out-door facilities, integrate with customer applications, enable simple calibration for premise modeling, include ground truth information, incorporate real-time calibration, minimize computations, and be a full system solution comprising devices, methods, network integration, and application integration. It is possible to replace these systems with a wearable/aimer/network system offering various advantages that may include: 1. Ubiquitous devices can switch to different networks as user moves between indoor or out-door locations; 2. Uses simple data model for deriving location. Does not need extensive calibration data and; 3. Provides accurate positional information. FIG. 1 illustrates a private Ubiquitous Location Tracking (ULT) system, 10, of the present invention incorporating the Position Inference Engine (PIE), 22, and mesh networks, 11. The detection system, 10, comprises the following: a wearable device, 46 , an aimer device, 16, server, 20 , wireless network, 18, cellular phone infrastructure, 26, GPS satellites, 32, and client, 24, which can operate in-door and out-door. Later sections will reference FIG. 2, 3 A, 3B, 4, 5, and 6, to describe the aimers, 16, wearable, 46, and Position Inference Engine, 22. For in-door operation, the mesh network, 11, consisting of aimers, 16, broadcast low-power beacon packets, 33, which are received by wearable, 46, which are a
component of tags worn by people, 28, or items being tracked. The mesh network, 11 , consists of aimers, 16, located within close proximity to one another such as within 10 metres. The wearable device also referred to as "tags", 46, includes the wearable module,
12, and optionally includes other data acquisition systems (such as for acceleration, pulse rate, etc.), 13, -RFID (Radio Frequency Identification) tag, 14, and IrDA (Infrared Data) interface, 15. Each wearable, 46, receives the beacon packets, and extracts signal parameters from these packets. It collects data from the other data acquisition systems,
13, and the RFID tag, 14, and transmits them in sniff packets, 34, to a server 20 via a wireless network, 18. During operation, wearers, 28, may wander within physical proximity of an aimer, 16. Some aimers have ground truth sensors, 17, for detecting proximity of objects, such as wearers, 28. The implementation of proximity sensors can be implemented using -known technology such as proximity switches based on Infrared, photocell, ultrasonic, magnetic, RFID tagging, and others. The purpose for ground truth sensing is to improve the accuracy of location information of the wearable, 46. Upon detection of a wearable within proximity, the aimer, 16, identifies the wearable, 46, within vicinity based on data in its sniff packets, 34, or other data such as the wearable RFID tag, 14, or other identifying markings that may be incorporated. The aimer, 16, transmits ground truth packets, 35, to the wireless network, 18. The wireless network, 18, is typically part of a facilities infrastructure and can support other wireless network data traffic and applications, for communication through a link, 36, which may be wireless or wired, such as Ethernet, to a server, 20. The server, 20, generally supports other applications, but in order to support the ubiquitous location system, it uses an instant messaging server (IMS), 21, to collect the data from the sniff packets, 34, and ground truth packets, 35. The IMS is known software technology already used in other distributed software applications. The Position Inference Engine (PIE), 22, uses the data from sniff packets, 34, and ground truth packets, 35, to determine the location of the wearable, 46, within the in-door facility. PIE, 22, provides a software interface to define wearable location, 38, for other applications, 23, and a client program, 24, in particular, to use the wearable location data and other real-time data if any. The client program graphically displays the locations of wearables, 46, and may reside on a device such as a notebook computer, PDA, cell phone, tablet PC, desktop PC, or other systems.
For out-door operation, the wearable, 46, will be out of range for receiving beacon packets, 33, from the aimers, 16, in the mesh network, 11. The invention provides for two optional techniques for tracking location although with lower accuracy. The first technique uses the cellular phone infrastructure, 26. The cellular infrastructure, 26, uses existing technology for as location determination for mobile phones placing emergency 911 calls. The second technique uses GPS satellites, 32. h this case, the wearable, 46, receives GPS satellite data, 44, and assess its geographic coordinates. For both of the techniques, the wearable, 46, acts like a mobile phone to connect to the cellular infrastructure, 26, through a cellular phone call link, 42. The cellular phone infrastructure, 26, dispatches location information to the server, 20 through a link, 40, which may be implemented using known technology such as a wide-area network (WAN) connection. For the first technique, the cellular phone infrastructure determines the location of the calling wearable, 46, and in the second technique, it passes along the GPS data. The server, 20, makes this information accessible to PIE, 22, which then provides this data through a software interface, 38, to other applications, 23, or to the client program, 24, which graphically displays the location of the wearable, 46. The client program, 24, works on .NET, Pocket PC, Windows, RIM, PALM operating on various machines such as cell phones, PDA's, tablets, laptops or desktops where the client communicates with the server 20, has instant messaging to other components, 22, 23 and 12. FIG. 2 illustrates the flow between different operating modes for the key components identified in FIG. 1 as the aimers, 16, wearable, 46 and Position Inference Engine, 22. The Wearable device spends a portion of time in a sleep mode in order to conserve battery power. It periodically wakes up, and enters a sniff mode. In this mode, it checks for beacon packets,33, sent by aimers, 16. Upon reading beacon packets, 33, in an in-door scenario, it enters the in-door mode. Alternatively, when no beacon packets, 33, are detected, it enters an out-door mode. In the in-door mode, the wearable device stores the beacon packet data, which in particular includes signal strength received from the aimer and transmits this beacon packet information to the in-door wireless network. The out-door mode uses the cellular phone infrastructure, optionally with GPS, as
described earlier concerning FIG. 1. In both cases, the wearable returns to the sleep mode to repeat the sequence. The aimer device, 16, operates repetitively in two modes. In the timer synchronization mode, all aimers, 16, receive a synchronization packet originating from the server using the wireless network. Each aimer, 16, will use a specified time offset to schedule when it broadcasts beacon packets. The offsets are assigned in a way so that aimers, 16, only use the same time offset if they are out of range of each other. This enables aimers, 16, to share the same radio frequency channel with minimal risk of beacon packets, 33, colliding when they are transmitted at the same time. After timer synchronization, the aimers broadcast beacon packets, 33, at the same periodic interval as specified by their assigned time offsets. Message packets for wearables 46, if any, are sent immediately following a beacon packet, 33. Over time, the aimer, 16, clocks will drift out of synchronization. Hence, after a specified time period, the aimers, 16, will re- enter the time synchronization mode to repeat the sequence. The Position Inference Engine (PIE), 22, uses four primary subtasks of processing. Standard multiprocessing data synchronization techniques commonly used in software systems ensures that data is conectly passed from one subtask to the next. In the sniff update subtask, PIE , 22,acquires and updates a table of data, including aimer received signal strength values from sniff data sent by the wearables, 46. The next subtask is locate wearables, 46, within zones. A zone is a group of aimers, 16, within range of each other. Generally, zones are defined so that any aimer, 16, may be assigned to several zones. Each zone has a data table, also -known as a zone map, that defines expected Aimer, 16, signal values for a set of physical locations within that zone. Using signal strength data from the previous subtask, PIE, 22, determines the table entry with the closest match. Hence this table lookup procedure provides the physical location of the wearable, 46, within that zone. PIE, 22, converts the local zone position for each wearable, 46, and zone combination to a global coordinate based on a common reference point within a facility. Because aimers, 16, broadcast at low power, multi-path effects of radio propagation are minimized, and there is a stronger correlation of signal strength to linear distance from aimers,16. Furthermore, because aimers, 16, are located closer to one another, there are fewer walls and other objects between a wearable
and an aimer to cause radio attenuation propagation effects. Hence there is a stronger correlation between the signal strengths of aimers, 16, for points located within that zone. The next subtask is wearable global locations. A wearable, 46, is generally within several zones. In the previous subtask, PIE, 22,has determined the wearable, 46 location locally within that zone. To improve location accuracy, PIE, 22, averages the global locations derived from the different zones for each wearable. This produces one global coordinate based location for each wearable,46. The last subtask is display and management. In this subtask, PIE, 22, provides the most current set of wearable data, including location in particular. Other applications such as graphical client displays can use this data. This subtask also archives previous snapshot data to use for historical movement information and tracking. A block diagram illustrating the internal components of the wearable device, 46, is shown in FIG 3 A. Positioned within the wearable core, 12, and controlling the operation thereof is a processor, 70. The processor 70 includes a real-time clock to control the timing for switching modes. Connected to the processor 70 and providing power to the wearable unit device 46 is an internal power source 72. The battery sensor 78 senses the power of the power source and provides a battery power signal to the processor 70 to safely shutdown the wearable device 46 if required. The shutdown feature may include a special shutdown message sent to the Position Inference Engine 22, so that this event may be acted upon as required. A memory 76 is provided for storing data processed by the processor. A wireless RF interface 74 is provided for receiving beacon packets 33 and transmitting sniff packets 34. A diversity switch 80 is provided for receiving beacon packets 33 from alternative antennas for improved location estimation by PIE 22. A GPS receiver option 82 is provided for receiving GPS satellite signals 44. A cell phone interface option 84 is provided for connecting with the cellular phone infrastructure 26. A data acquisition interface 86 is provided for acquiring other data from a wearer 28, such as an accelerometer 88 which can be provided for a feature to assess whether the wearer 28 has fallen. An IrDA (Infrared data interface) option 90 is provided for exchanging data to and from the wearable device 46 using a device such as a PDA used by a physician. An -RFID tag option 92 is provided for RFID tracking systems.
A USB (Universal Serial Bus) is provided for connecting a computing device for maintenance purposes. A block diagram illustrating the internal components of the aimer device 16 and ground truth sensor 17 is shown in FIG 3B. Positioned with the aimer device, 16, and controlling the operation thereof is a processor, 50. The processor includes a real-time clock to control the timing for switching modes, timer synchronization, and beacon packet 33 transmission as illustrated in FIG. 2. Connected to the processor 50 and providing power to the aimer 16 and ground truth sensor 17 is an external power source. Normally the power source uses power from a wired data communication line such as power over Ethernet, although standard wall outlet power can also be used. A memory 53 is providing for storing data processed by the processor such as data received for transfer to other devices. A wireless RF interface 54 is provided for transmitting beacon packets 33 and messages to wearables 46. A proximity detector option 58 is provided for implementing the ground truth sensor 17. An RFID reader option 60 is provided for RFID tracking systems and alternative ground truth sensor implementation. A flowchart illustrating control of the wearable devices for in-door use is illustrated in FIG. 4A. Step 100 is putting the wearable device, 46, in a sleep mode as shown in FIG. 2. Step 101 is the process of sniffing beacon packets 33 and storing beacon data in memory 76. For in-door operation, beacon packets 33 were detected. Step. 102 is a decision block to assess whether additional messages have been sent by aimers 16. Program execution proceeds to step 103 if yes. Otherwise it proceeds directly to step 104. Step 103 is the process of handling of messages as required. For example, a software management system may send a reminder message to a wearer 28 with a wearable device 46 to take specified medication. Step 104 is a decision block to assess whether the wearable device 46 has other data to send, such as from other data acquisition 13, RFID tag 14, or IrDA 15. Program execution proceeds to step 105 if yes. Otherwise it proceeds directly to step 106. Step 105 is the process to acquire the other data and to store it in memory 76. Step 106 is the process to retrieve the data stored in memory 76 and transmit sniff packets 34 using the wireless RF interface 74. Upon completion of this data transmission, the wearable proceeds to step 100 to resume a sleep state for power saving.
A flowchart illustrating for control of the wearable devices for out-door use is illustrated in FIG. 4B. Step 107 is a decision block to assess whether beacon packets 33 were received. Program execution proceeds to step 102 if yes, being the in-door scenario illustrated in FIG 4 A. Program execution proceeds to step 108 if no beacon packets 33 were detected. The wearable device 46 assumes that it is no longer in-doors within range of the mesh network of aimers 11. Therefore it attempts to use other means of communication if available. Step 108 is a decision block to assess whether the wearable device 46 includes a GPS receiver 82. Program execution proceeds to step 109 if yes. Otherwise it proceeds to step 111. Step 109 is the process to read GPS data 44 from GPS satellites 32, and then proceeds to step 110. Step 110 is the process to calculate the GPS coordinates of the wearable device 46 and to send GPS coordinates to the server 22 using a cellular phone connection 42 to the cellular phone infrastructure 26. After the GPS coordinate data has been sent, program execution proceeds to step 100 to return to a sleep mode. Step 111 is a decision block to assess whether the wearable device 46 includes a cell phone interface 84. Program execution proceeds to step 112 if yes. Otherwise it proceeds to step 113. Step 112 is the process to call the cellular phone infrastructure 26 using cell phone interface 84 to instruct it to assess the location of the wearable device 46. After the call has been handled, program execution proceeds to step 100 to return to sleep mode. Step 113 is the process to indicate that location update data is unavailable. In the event that a wireless network connection is possible to the server 20, the sending of this data will inform PIE 22 that no update data was available. P?IE 22 can use this information to inform other applications concerning the situation. After step 113 is completed, program execution proceeds to step 102 as shown in FIG 4A. A flowchart illustrating control of the Aimer device is illustrated in FIG 5. Step 200 is the process to control timer synchronization mode described previously when describing the aimer device 16 in FIG. 2. The result of this process is that the aimer device 16 will have specified time interval scheduling to broadcast beacon packets 33. Program execution proceeds to step 201 to enter a program loop for sending a set number of beacon packets 33 until timer synchronization of step 200 is to be repeated. Step 201 is the process to transmit the beacon packet 33 at the specified time interval using the wireless RF interface 54. Note that processor 50 uses an internal clock to determine the
time interval. The process waits at step 201 until the internal clock has timed out to the specified interval. Program execution proceeds to step 202, which is to increase the beacon packet count. Program execution proceeds to step 203. Step 203 is a decision block to assess whether there are messages to send to wearable device 46. Program execution proceeds to step 204 if yes. Otherwise it proceeds to step 205. Step 204 is the process to broadcast messages that are stored in memory 53 using the wireless ?RF interface 54. Step 205 is a delay process. The purpose of the delay is to enable the aimer device 16 to handle ground truth data if any. Program execution proceeds to step 206. Step 206 is a decision block to assess whether a wearable has been detected by a proximity detector 58 or by RFID reader 60. Program execution proceeds to step 207 if yes. Otherwise it proceeds to step 208. Step 207 is the process to acquire the ground truth data. For example, it may record the time when proximity detector 58 has been triggered. PIE 22 can use the time information to see which wearable device 46 recorded very high beacon packet 33 signal strength for that aimer 16. This would imply the wearable device 46 was the one detected by the proximity detector 58. If the RFID reader 60 was used, the data from the wearable -RFID tag 14 is sent by the aiiner 16. Program execution proceeds, to step 208. Step 208 is a decision block to assess whether a predetermined number of beacon packets 33 have been sent by using the count variable that was incremented in step 202. Program execution proceeds to step 209 if yes. Otherwise it proceeds to step 201 to repeat the program loop for sending beacon packets 33. In the case when the set number of beacon packets 33 have been sent, step 209 resets the beacon packet count. Program execution proceeds from step 209 to step 200 to control the timer synchronization mode. A flowchart illustrating control of the Position Inference Engine is illustrated in FIG 6. Update sniff table 400 is the process to update the subtask as described for FIG 2. Time synchronization 200 is the startup and initialization process for the subtask locate wearables within zones for FIG 2. The program loop begins at step 301 whic-h is the process to point to the first zone. In step 302, PIE 22 retrieves the zone map. In step 303, PIE 22 determines which wearables 46 are in the current zone being examined. It builds a list of the wearables 46 within that zone. Step 304 is a decision block for assessing whether there are wearables 46 remaining to be processed from the list of wearables 46.
Program execution proceeds to step 305 if there are any to be check. Otherwise it proceeds to step 307 for handling the next zone. Step 305 are the processes involved in determining the table entry with the closest match as described for FIG 2. PIE 22 retrieves the beacon signal strength data from the wearable device 46. It searches for the table entry with the closest match. It also retrieves ground truth data if any. PIE 22 then retrieves the position coordinate information stored in the table entry to use as the local location coordinate for the wearable device 46. It then transforms the local coordinates to global coordinates and stores the wearable global coordinate and the zone. Program execution proceeds to step 306 to retrieve the identifier for the next wearable device 46 in that zone. Program execution then proceeds to step 304 to repeat the loop. If there are no remaining wearables 46 to check in the current zone, the loop exits and program execution proceeds to step 307. Step 307 is a decision block to assess whether there are more zones to check. If yes, program execution proceeds to step 308 to point to the next zone and to resume the processes in steps 302, 303 and so on to determine the positions of the wearable device 46 in that zone. Otherwise, program execution proceeds to step 301 to repeat the whole cycle beginning with the first zone. Step 500 is the startup and initialization process for the subtask wearable global locations for FIG 2. In step 501, PIE begins a loop for averaging the global locations derived from the different zones for each wearable. Alternately, if the wearable is outdoors, multiple outdoor readings may be obtained for calculating its position more accurately. This produces one global coordinate based location for each wearable device 46. Step 501 is the process to point to the first wearable 12. Step 502 is to retrieve the global coordinates recorded for that wearable 12 from all the zones the wearable was located within. Step 503 is the calculation to produce the average. Step 504 is to record a single location coordinate for that wearable 12. Step 505 is a decision block to assess whether there are more wearable devices 46 to process. If yes, program execution proceeds to step 506 to point to the next wearable. Otherwise program execution proceeds to step 501 to repeat the cycle beginning with the first wearable. Task synchronization is necessary to ensure that repeating the cycle occurs with new wearable data updates from the previous PIE 22 subtasks.
Steps 600 and 601 are processes for the subtask display and management for FIG. 2. Step 600 is the process to retrieve the wearable locations recorded by step 504. Process synchronization techniques can ensure that data for any wearable device 46 is not being accessed while step 504 is updating location data for that specific wearable 12. Step 601 involves any processes that use the location and other information from the wearable devices 46. Furthermore, step 600 stores the data in a table for access by step 601. This acts like a double buffer. Other applications in step 601 can access a stable image of wearable condition without consideration to other wearable data updates that are underway in other parts of PIE 22. While certain novel features of this invention have been shown and described, it is not intended to be limited to the details above, since it will be understood that various omissions, modifications, substitutions and changes in the forms and details illustrated and in its operation can be made by those skilled in the art without departing in any way from the spirit of the present invention. It should be noted that although the description refers specifically to indoor and outdoor locator mechanisms, the indoor locator mechanism may extend to an outside area depending on the implementation, as will be appreciated by a person skilled in the art. For example, if an institution comprises a courtyard that is physically located outside, aimers may be set up for the courtyard. Ultimately, it is a business rule decision for the administration of the institution; which the technology is capable of performing.