1. Technical Field
This invention relates generally to a system and method for processing tracking data, and more specifically to a system and method for enabling a user to determine criteria for tracking and notifying a user.
2. Background Art
Currently, systems exist for tracking the location of persons and/or property. Generally, such systems include a tracking device that transmits the location of the tracking device a central station, which may then take some action based on the location data.
Known systems have generally been developed as “enterprise systems.” For example, custom systems designed for a business enterprise to track assets. Such systems were not designed for, nor are they well suited for, providing tracking services to individual consumers.
What is needed is a system and method for providing personalized tracking services to consumers. What is also needed is a system and method that facilitates user defined criteria for monitoring tracking data. What is also needed is a system and method that facilitates user defined criteria for providing alerts when certain tracking conditions are met and/or violated. What is also needed is a system and method for dynamically defining criteria for monitoring tracking data. What is also needed is a system and method for dynamically defining criteria for monitoring tracking data based on data retrieved from outside data sources.
A “Geofence” is an indication of a predetermined location, for example an electronic perimeter zone setting. In one embodiment, the geofence offers at least 2 types of zone settings; a “green zone” (safe) and a “red zone” (unsafe). A personal tracking device for use with this system will be colocated (e.g., worn, carried, etc.) with the subject to be tracked. The personal tracking device and/or a remote server can store multiple zones of each type. For example, a green zone may be defined around the subject's home, school, and a nearby park, while a red zone may be placed around a prison, reservoir, or any other forbidden or dangerous location. If the tracking device breaches the zones an alert (e.g., via text message, automated call, etc.) to a phone, e-mail address, or any other predetermined destination is sent. Zone breaching occurs if the tracking device either enters a zone or leaves a zone. For example, if a tracked subject were forbidden from entering an establishment serving alcohol, a red zone could be setup around the perimeter of all bars within a given locale, and an alert could be sent to those subscribers tracking the subject if the subject entered any of these red zones. As another example, if a subject (e.g., a child) is supposed to be in school during a given time period, a green zone could be setup around the perimeter of the school and an alert could be sent to those subscribers tracking the subject if and when the subject exited the green zone.
The inventors envision many uses for a tracking system utilizing a multiple zone geofence. By way of example, the inventors envision at least the following features:
1) Velocity or geography based alerts;
2) Red zone (unsafe) or green zone (safe) zone settings;
3) The ability to store multiple zone settings of both types;
4) The ability to pre-set the zones and name them; and
5) The ability to use outside data (e.g., data from external databases, public services, vendors, etc.) to automatically update or create new zones.
The following examples are provided without limitation to illustrate certain capabilities of the system. For example, an alert could be sent and/or and event recorded if a subject is moving faster than 45 MPH or has not moved in 15 minutes. As another example, an alert can be sent and/or and event recorded if a geographical zone is breached. Named zones can be stored by or sent to those subscribers tracking the subject in the form “Red Zone—Moe's Tavern” or “Green Zone—Soccer Field”. Additionally, velocity based zones and alerts may be sent in the form “Red Zone—Subject is moving faster than 45 MPH” or “Red Zone—Subject has not moved in 15 minutes”. Once set and named, until deleted, they can be selectively activated or deactivated with one push of a button. The alert notifications may also be set up to be sent to multiple locations for multiple members tracking a subject. For example, an alert may be sent to the e-mail and/or cell phone as a text message.
The inventors envision a platform that will support defining both velocity and geography based geofences. For velocity-based geofences, alarming can be based on the device exceeding a set velocity limit, or remaining stationary for a set period of time. Such a feature would be particularly useful in tracking movement by and/or in a vehicle, or tracking the stops of a subject. Geography-based geofences can define a circular or polygon region, and notification from the tracking device to server is triggered when the device transitions across the boundary between the inside and outside of the region. In this embodiment, the geofence definitions are stored and breaches are monitored in the tracking device. Alternatively, the geofence definitions can be stored and monitored for breach on the server or jointly by the tracking device and the server. Inclusion notification occurs when the device transitions from being inside a defined region to outside the defined region (i.e., the region is “included” or allowed). Exclusion notification occurs when the device transitions from being outside a region to inside the region (i.e., the region is “excluded” or not allowed). The system can be configured to send and or record only one type or both types of notifications for each defined geographic geofence. “Red zone” geographic geofences are implemented to alarm the subscriber when the device transitions from outside to inside a geofence region. “Green zone” geographic geofences are implemented to alarm the subscriber when the device transitions from inside to outside a geofence region.
Alarm generation can be sent in multiple forms, including but not limited to email, SMS, as well as techniques to update the web display if the subscriber is viewing the site when the transition occurs. For example, a subscriber could choose which alert types they'd like to receive, as well as having the ability to view a web site showing the position and status of the subject.
Dynamic geofence generation allows the system to build real-time, instantaneous geofences to support rule-based applications as described below: For example, one application creates dynamic exclusion geofences around registered pedophiles, sex offenders, drug houses, etc. in the device's vicinity, and sets up contextually appropriate alarm messages if the device transitions into one of the dynamic geofence boundaries. Indeed, it is foreseeable that through monitoring of key databases, geofences could be setup automatically around the homes, workplaces, or even the individual pedophiles if they are tracked.
As another example, an application can define a geofence and/or trigger an alarm when the tracking device approaches businesses with set SIC codes, such as adult bookstores, strip clubs, liquor stores, etc.
A “rendezvous” application creates dynamic exclusion geofences of devices that are both in the subscriber's vicinity and on the subscriber's “friend list” (these are devices registered to other primary accounts, both which have been published to and subscribed by the subscriber and are allowed to see location). When the device nears another device on the “friend list”, both subscribers are notified of the other's proximity, including calculated distance and reverse geocode address.
The present invention is described with reference to the following drawings, wherein like reference numbers denote substantially similar elements:
Servers 104 host services for subscribers 118 and/or other authorized users that facilitate the tracking and/or monitoring of the location of tracking devices 102, including the geofence features described herein. Subscriber profile database 106 stores information associated with particular subscribers 118 and/or other users of system 100. Vendor information database 108 stores information associated with vendors 116 that provide goods and or services that can be made available to subscribers 118 and/or other users of system 100 based on information from subscriber profile database 106 and/or location data received from tracking devices 102. Public database cache 110 provides temporary storage for data retrieved from public databases 120. Tracking interface 112 transmits (via wireless communication) data and commands to tracking devices 102 and receives data (e.g., location data, sensor readings, distress signal, etc.) from tracking devices 102. Vendors 116 offer goods and services that may be offered to subscribers and other users of system 100 as described above. In addition, information associated with vendors (e.g., type of business) can be used to help define geofences used to monitor tracking devices 102. Similarly, public databases 120 provide information (e.g., sex offender registries, etc.) that can be used as criteria for defining geofences.
Subscribers 118 are the primary users of system 100 and interact with servers 104 to define tracking criteria and to obtain information and alerts regarding the tracking of associated tracking devices 102. In this example, the primary users are referred to as subscribers, because it is expected that users will be willing to pay for the right to use system 100. However, it should be understood that system 100 is not limited to a subscription type business model. For example, access to system 100 could be provided to users on a free basis, relying on some other business model to raise revenue.
The records of Users table 150 include a UserID field 160, a Name field 162, a ContactInfo field 164, and an OtherInfo field 166. UserID field 160 is the key field of table 150 and includes a unique identifier for each user of system 100. Name field 162 includes data indicative of the name of the associated user. ContactInfo field 164 includes information (or the location of information) used to contact the associated user, for example in the case of a geofence breach. OtherInfo field 166 can include any additional information considered necessary or desirable by the system designer, for example to enable other functionality not specifically disclosed herein.
The records of Tracking Devices table 152 include a DeviceID field 170, a ConData field 172, an OpData field 174, and an OtherInfo field 176. DeviceID field 170 is the key field of table 152 and includes a unique identifier for each device tracked by system 100. ConData filed 172 includes information necessary to contact the associated device. OpData field 174 includes data regarding the operational capabilities (e.g., type of device, application programs running, etc.) of the associated device. OtherInfo field 176 can include any additional information considered necessary or desirable by the system designer, for example to enable other functionality not specifically disclosed herein.
The records of GeoFences table 154 include a GeoFenceID field 180, a GeoDef 182, OtherInfo field 184, and Private field 186. GeoFenceID field 180 is the key field of table 154 and includes a unique identifier for each geofence record stored therein. GeoDef field 182 includes a definition and/or a location of the definition (e.g., geographical boundaries, max speed, other device locations, etc.) of the associated geofence. OtherInfo field 184 can include any additional information considered necessary or desirable by the system designer, for example to enable other functionality not specifically disclosed herein. Private field 186 includes data indicative of whether the associated geofence record/definition is made available to all users, or whether the associated geofence is available to and/or was created by a particular user or particular group of users (e.g., subscribers to a geofence creation service).
GeoUsers table 156 associates a particular user, a particular device, and a particular geofence. The records of GeoUsers table 156 include a UserID field 190, a DeviceID field 192, a GeoFenceID field 194, and an Enabled? field 196. UserID field 190, DeviceID field 192, and GeoFenceID field 194 include the same type data as the related fields of the same names of tables 150, 152, and 154, respectively. Thus, the records of GeoUsers table 156 associate a particular geofence definition with a particular user and a particular tracking device. Enabled? field 196 indicates whether the associated geofence has been selectively enabled or disabled by the associated user. This provides an advantage, because it is easier to selectively enable/disable an associated geofence than it is to associate/dissociate the geofence with/from a particular user and a particular tracking device. In addition, the records of table 156 can be easily searched in order to present a user with a list of all geofences associated with the user, whether enabled or not.
For the sake of clear explanation data and code are shown in memory 206 as functional blocks. It should be understood, however, that the various functions of server 104 need not be run in any particular location of memory 206 and may grouped in any useful manner. For example, the several application program interfaces (APIs) shown could be grouped into a single API.
Memory 206 includes an operating system 214, public database API 216, subscriber API 218, processing queues 220, vendor API 222, control and coordination routines 224, application programs 226, and geofence routines 228. Operating system 214 provides low level control of server 104 and provides a platform on top of which the other modules can operate. Application programs 226 are tracking service programs that receive and process location and/or sensor data from tracking devices 102, process the received data, communicate with subscribers 118, read and/or update subscriber profile database 106, search remote data sources, and so on. Public database API 216, vendor API 222, and subscriber API 218 provide a means of communication between application programs 226 and public databases 120, vendors 116, and subscribers 118, respectively. Control and coordination module 224 provides overall control and coordination of the tracking services provided by server 104. Processing queues 220 provide temporary storage for tracking data that is being processed.
Geofence routines 228 facilitate the definition and monitoring of geofences. For example, geofence routines 228 can define a geofence based on input received from a subscriber via subscriber API 218 (or subscriber profiles 106) and associate the geofence with a particular one (or several) of tracking devices 102. Optionally, geofence routines 228 can create/modify a geofence based on information received from one or more of subscriber profile database 106, vendor information database 108, public database cache 110, public databases 120, vendors 116, and location data from tracking devices 102.
Geofences can be stored and/or monitored in a variety of locations including, but not limited to, server 104, subscriber database 106, and/or tracking devices 102. For example, after defining the geofence, geofence routines 228 can transfer the geofence definition(s) to the associated tracking device(s) 102. Then, the associated tracking device(s) 102 monitor the location of the associated tracking device(s) 102 and notify server 104 in the event of a geofence breach. Optionally, the geofence definition is stored by server 104 and geofence routines 228 use location data received from tracking device 102 to monitor for geofence breaches. It is presently thought that transmitting the geofence definitions to the tracking device so that the tracking device can monitor the geofence for breach provides an advantage, because the required number of communications between the tracking device and the server is significantly reduced, thereby saving power and time-based communication charges. However, there are some circumstances where monitoring the geofences on the server is equally acceptable or preferred. These circumstances include, but are not limited to, the monitoring of dynamic geofences that change frequently; the monitoring of geofences that require location data from other tracking devices; and monitoring tracking devices that have a flat rate charge communication plan. In yet another embodiment, the geofences are monitored by tracking device 102, but the geofence definitions are updated by server 104 and the updated definitions are periodically communicated to tracking device 102, thereby updating the geofence definitions on tracking device 102. Periodically updating the geofence definitions provides an advantage in a number of situations including, but not limited to, where there is a significant change in the position of the tracking device and/or changes in the database(s) or other underlying information upon which the geofence definitions are based. In yet another embodiment, the tracking data is transmitted to subscriber system 118, and the geofences are monitored on subscriber system 118.
As indicated previously herein, notification is transmitted to the user in the event of a geofence breach. The notification can be sent via any useful form including, but not limited to, SMS, e-mail, telephone, an so on. The particular transport medium will depend on the notification type. For example, e-mail notification can be sent via internetwork 122. As another example, a telephone message can be sent over internetwork 122 (voice over IP) or over a separate telephone (wired or wireless) network (not shown).
The description of particular example embodiments of the present invention is now complete. Many of the described features may be substituted, altered or omitted without departing from the scope of the invention. For example, alternate zone types, alert types, and so on, may be added to and/or substituted for those shown herein. As another example, geofences can be defined by a user placing line segments on an image of a map (e.g., along depicted streets) to define a closed polygonal area. These and other deviations from the particular embodiments shown will be apparent to those skilled in the art, particularly in view of the foregoing disclosure.
This application claims the benefit of copending U.S. provisional Patent Application No. 60/898,902, filed Feb. 1, 2007 by the same inventors, which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60898902 | Feb 2007 | US |