DETAILED DESCRIPTION OF OUR INVENTION

[0013] FIG. 1 shows a block diagram of a secure location-aware services infrastructure 100 of our invention that tracks geographical and identity sensitive information and makes this information accessible in a standardized format to authorized applications to provide location-based services. Specifically, on its simplest scale, system 100 comprises a set of sensors 102 - 104 based on a particular technology, an interface aggregator 106 corresponding to the sensors 102 - 104 , an entity identity register 108 , a location identity register 110 , and subscriber applications 112 - 114 . As system 100 is scaled to cover larger areas, it may comprise additional sensors based on a plurality of technologies, additional aggregators corresponding to these sensors and technologies, and additional entity identity and location identity registers. This is further explained below.

[0014] A sensor 102 or 104 is any device and/or system that is capable of determining the location and identity of an entity (e.g., a person or physical object). The granularity of the entity's location capable of being determined by a sensor depends on the specific sensor technology. Unique to our inventive system, a sensor may be a specific technology/system whose purpose is to track location; however, our inventive location-aware service infrastructure also allows a sensor to be a technology/system where location detection is a side affect of the system's primary function. For example, credit card systems, when a user swipes a card, detect that user's location as a side affect of the system's primary function. A credit card system is a sensor in accordance with our invention.

[0015] Sensors essentially come in two forms: location-based sensors and entity-based sensors. An entity-based sensor is a sensor that knows the identity of an entity and senses location. An example of such a sensor is the short-range wireless micro-location system provided by ActiveRF Ltd, and is further described below. A location-based sensor is a sensor at a fixed known location that detects the presence of an entity. An example of such a sensor is the credit card scanner example from above. Upon a card being scanned, the scanner determines the identity of the user and conveys this information along with the store identity to the credit card company's server. Hence, the server has both the location and identity of a user and together with the scanner, acts as a sensor. Other examples of location based sensors are security card-scanners, face recognition scanners, and mobile phone systems (e.g., location could be based on a cell location), each of which would operate similarly to the credit card scanner.

[0016] It is also important to note that the deployment of sensors and therefore the scale of system 100 can vary. System 100 can correspond to a home or building, in which case the sensors are confined to these areas. On the contrary, system 100 may correspond to a mall or town, etc., in which case sensors are more widely deployed. With that said, its should be further noted that system 100 may comprise a single sensor technology or a plurality of sensor technologies simultaneously deployed. The varying sensor technologies may correspond to separate geographical regions. However, they may also correspond to the same geographical region, providing overlapping coverage. Advantageously, this unique aspect of our invention allows an entity's location to be simultaneously tracked on different scales; for example, the system can track an entity indicating that the entity is in a town, in a mall within the town, within a store within the mall, and perhaps even a location within the store. For example, an individual engaged in a cell phone call while using a credit card could be tracked by two sensors, thereby providing two different degrees of location granularity.

[0017] An interface aggregator 106 is associated with one or more sensors 102 - 104 and may be specific to a particular sensing technology. Upon sensing an entity's presence, a sensor conveys both the identity and location of that entity to the sensor's corresponding interface aggregator. An interface aggregator performs two specific functions. First, because each sensing technology will maintain location and identity information in a format specific to that technology, the interface aggregator converts the information to a standardized format. This standardization is what allows system 100 to comprise a plurality of different sensing technologies and sensors. The second function is related to the concept that the sensors of system 100 can be viewed as existing within different domains, or in other word, different logical or physical regions. The size and number of domains monitored by system 100 depends, for example, on the scale in which system 100 is deployed and the number and types of applications that will be using the system. For example, a home could be viewed as a single domain, a building could be viewed as several domains, etc. As such, the interface aggregator also determines the domain of a sensed entity.

[0018] Once the interface aggregator 106 standardizes the detected information, it forwards the information to the entity identity and location entity registers 108 - 110 for storage. Because system 100 may cover multiple domains, multiple registers may be used to store the information, each register storing information for one or more domains. As such, the importance of the interface aggregator determining the domain of a detected entity is to determine which register should store the information.

[0019] As mentioned, entity identity register 108 and location identity register 110 maintain/store the location(s) and identity information for the sensed entities, but each stores the information in a different format. The differing formats allow the location identity register to specify the entities within a particular location and allow the entity identity register to specify the location(s) of an entity. Hence, the format of each register allows queries of the form, “who is at location x?” and “where is user y?” (Note in general that the dual register functionality could also be provided by a single register). As described above, as system 100 grows, it may be broken into multiple domains and each domain may be assigned a location identity register and an entity identity register. Hence, system 100 may comprise a plurality of register pairs, each pair maintaining information for one or more domains (Note that multiple registers could also be used to serve the same domain for redundancy purposes). Hence, a location identity register for a specific domain is able to provide which entities are at specific locations within that domain (and again, the locations maintained by the register may be at different scales.) An entity identity register for a particular domain is able to provide the specific location(s) of entities within that domain (the register may provide multiple locations if the entity is sensed by multiple sensors at different scales).

[0020] The services provided by the registers can be subscribed to by subscriber applications 112 - 114 . In general, subscriber applications can make two types of requests to these registers. First, an application can query a location register for the entities within a specific location (similarly, it can query an entity register for the location of a specific entity). Second, an application can request to be notified based on changes in locations and entities. In other words, an application can request a location identity register to notify it each time the entities within a given location change (and similarly, can request a entity identity register for a notification each time an entity's location changes.) Note that a subscriber application may subscribe to many registers at one time. Also note that in order to ensure the location information maintained by the registers is timely and accurate, time and date information can be associated with the entries and purged by the registers after a period of time has expired.

[0021] Reference will now be made to a specific embodiment of our invention as shown in FIG. 2 . Beginning with the sensing technology, an entity-based sensor 201 is shown, specifically, the short-range wireless micro-location system provided by ActiveRF Ltd. This sensing technology comprises three components: beacon transmitters 202 - 204 , active tags, such as active tag 206 , and a base station 208 . Beacon transmitters are fixed location devices each with a known identifier, which identifiers correspond to the fixed locations of the transmitters. At regular intervals, each beacon transmitter transmits its identifier using a low frequency radio signal.

[0022] Active tags are typically carried by a user (or attached to an object being moved) and each tag has a unique identifier, associated with that user. The tags monitor for beacon identifiers broadcast by the beacon transmitters 202 - 204 . When an identifier is detected by a tag as the tag passes through the region covered by the corresponding transmitter, the tag transmits both its known identity and the identity of the detected region to the base station 208 using a higher radio frequency.

[0023] The base station monitors the transmissions from the active tags. When a message is received from a tag, the base station conveys the information to an interface aggregator 210 (note that the interface aggregator 210 is unique to our invention and separate from the ActiveRF technology) that translates the tag identifier and beacon transmitter identifier to a standardized entity identifier and location. The interface aggregator 210 may be co-located with the base station 208 and interconnected through an RS-232 connection, for example. However, the sensor and interface aggregator may also be interconnected through a data network, allowing the aggregator to service multiple sensors.

[0024] After standardizing the format of the identity and location information, the interface aggregator next associates the location of the entity with a domain and uses this domain to locate the appropriate entity identity register 214 and location identity register 216 that maintain the information for this domain. Specifically, in this embodiment the aggregator and identity registers are interconnected through a data network 212 . Hence, the domain served by the registers can also be used as a domain name for the registers. As such, using DNS (domain name server) server 222 (containing for example, appropriately configured DNS A-records or DNS SRV records), the aggregator can determine the network addresses of the registers 214 - 216 and, using these addresses, forward the location/identity information to the registers.

[0025] As indicated, the entity identity and location identity registers also reside on network 212 and maintain location information for one or more domains. In general, the configuration of a register with respect to the domains it manages must match the configuration of the DNS server 222 regarding the translation of domain names to the appropriate register. Each register on the network maintains a well-known TCP (transmission control protocol) port, as an example, through which the aggregators can establish communications and send the location-based information. As part of this procedure, a register may determine if the entity being reported has authorized a specific sensor and therefore aggregator to report its location. This authorization can be performed through access control lists maintained by the register and set by the entity. If an aggregator is not authorized to report a location, the register will not store the location.

[0026] Each register also maintains, for example, a second well-known TCP port through which service applications 218 - 220 , which are also located on network 212 , can make location requests to the registers. Service applications again use the domain concept to determine a general location on which information is desired and similar to the aggregators, use the domain to locate and communicate with the register(s) that control that domain. Similar to the above, a register may determine if an entity, whose information is being requested by a service application, has authorized the service application to receive the information. Again, this authorization can be performed through access control lists maintained by the register and set by the entity.

[0027] Subscriber applications with appropriate access can obtain information from the registers either by querying a register for current information or by registering (or unregistering) with a register requesting to be notified when entities within a location change or the location of an entity changes. Whether a query or notification request, the subscriber applications provide the register with an identifier of the entity or location to be monitored. In the case of an update, the subscriber application also provides a TCP port, for example, through which updates can be sent.

[0028] Note that TCP advantageously provides reliable communications; however, rather than using TCP, SIP (session initiation protocol) could also be used for establishing communications. Advantageously, SIP is also reliable and offers authentication and encryption. It should also be noted that for scalability purposes, one set of location identity and entity identity registers can be assigned per domain. However, one set could also service multiple domains and multiple sets could service the same domain. The latter example (i.e., multiple sets could service the same domain) provides redundancy in the event of a system failure and also helps to alleviate the problem of data hotspots if too many subscriber applications are trying to determine information on a particular domain. In this case, aggregators would need to update all registers, or the registers themselves could maintain the redundancy. As for access by the subscriber applications, techniques similar to those used in email could be used to manage the requests among the redundant registers.

[0029] An example application of the above embodiment is a system 200 deployed within a building where employees wear badges containing the active tag functionality. The system may monitor a set of secure doors, and, as employees approach these doors, the system updates a location identity register with the employee identity and location. In turn, a subscriber application could register with the location identity register for each specific door and request automatic updates each time an employee approaches a door. Based on an update, the application could cross-reference a security database to determine if the employee is authorized to enter the door and, if so, communicate with the door via a network connection to automatically unlock the door.

[0030] The above-described embodiments of our invention are intended to be illustrative only. Numerous other embodiments may be devised by those skilled in the art without departing from the spirit and scope of our invention.