1. Technical Field
The present disclosure relates generally to location-based services, and more specifically to geo-fences.
2. Background Information
Location-based services are a field of mobile applications that leverage the ability of many mobile devices to determine their current location and perform actions based on that location. Location-based services may involve supplying location-dependent content (e.g., advertisements, weather forecasts, driving directions, traffic updates, or other content) on the mobile device itself, providing location information for the mobile device to other devices (e.g., to enable “buddy” finding, child monitoring, or other services), collecting location-based statistical information (e.g., consumer demographic data, traffic data, or other data), or other types of operations.
Some location-based services utilize geo-fences. A geo-fence is a virtual perimeter that may be established around a real-world geographic area. Crossing a geo-fence may cause a service to be provided, cause a service to be withheld, or trigger some other sort of action, depending on the particular application. However, there are several shortcomings in the present implementation of geo-fences on many mobile devices. Two prominent shortcomings involve limits on the number of geo-fences that a mobile device may concurrently monitor, and restrictions on the shape and/or size of geo-fences that the mobile device may monitor.
In order to support geo-fences, mobile devices typically repeatedly determine their current location and compare that location to the virtual perimeter defined by the geo-fence. Such location determination and comparison consumes resources of the mobile device, including processing resources, and, often more importantly, power resources. Given the importance of battery life for many mobile devices, there may be practical limits on how many geo-fences can be concurrently monitored. In some cases, these practical limits are codified into restrictions imposed by the mobile device's operating system or firmware. For example, some mobile devices currently allow concurrent monitoring of about 20 geo-fences for a given application and about 100 geo-fences across all applications. These geo-fence limits are becoming increasingly problematic, as geo-fences are being utilized in more and more location based services. However, increasing these limits has proven difficult, given the compelling desire to even further reduce power consumption of mobile devices.
Further, in order to simplify processing and achieve other efficiencies, some mobile devices impose limits on the possible shapes and sizes of monitored geo-fences. While geo-fences may theoretically be defined to have any of a wide variety of shapes and sizes, some mobile devices only support monitoring of geo-fences having certain supported shapes and sizes. For example, a mobile device may only support circular-shaped geo-fences having a radius of 100 meters. This limitation is becoming increasingly burdensome on developers and users, who may desire to utilize geo-fences having shapes and/or sizes other than those natively supported.
Accordingly, there is a needed for improved techniques that may allow for monitoring of a number of geo-fences beyond a mobile device's geo-fence limit, and for using geo-fences of shapes and/or sizes other than those natively support by the mobile device.
In one example embodiment, a client on a mobile device approximates use of geo-fences of various shapes and/or sizes, potentially including geo-fences having geometries that are not natively supported on the mobile device. An approximation process (included in the client and/or on the server) receives an initial geo-fence. The initial geo-fence may be a non-supported geo-fence having a shape and/or size that is not natively support by the mobile device. The approximation process generates a group of M geo-fences (e.g., a group of M geo-fences having geometries supported by the device) whose union approximates the initial geo-fence (e.g., supported geo-fence). The group of M geo-fences is mapped to a single identity. If the mobile device is moved to new location proximate to (e.g., has crossed) the union of the M geo-fences (e.g., M supported geo-fences), an application that utilizes the initial geo-fence (e.g., the non-supported geo-fence) is notified. For example, if the mobile device has crossed one of the M geo-fences, and has not crossed into another of the M geo-fences, but has instead left the union of the M geo-fences, an application that utilizes the initial geo-fence (e.g. the non-supported geo-fence) may be notified.
It should be understood that the example embodiments discussed in this Summary may include a variety of other features, including other features discussed below, and variations thereof. This Summary is intended simply as a brief introduction to the reader, and does not imply that those specific features mentioned herein are all the features of the invention, or are necessary, or essential, features of the invention.
The Detailed Description below refers to the accompanying drawings of example embodiments, of which:
The machine-executable instructions on the mobile device 110 may include instructions for a mobile operating system 140, for example the iOS® operating system available from Apple Computer Inc., the Android® operating system available from Google Inc., or another operating system that functionally organizes the mobile device. The machine-executable instructions may also include instructions for a client application (or simply a “client”) 145 that implements client-side portions of the presently described techniques. The client 145 may include a geo-fence cache 150 that maintains geo-fences, including a number of active geo-fences 152 and a number of in-active geo-fences 154. As discussed in more detail below, a request process 160 of the client 145 may initially load the geo-fence cache 150 with geo-fences, and replenish the geo-fence cache 150 with additional geo-fences, when needed. Further, as discussed in more detail below, an activation process 170 of the client may move geo-fences between the active geo-fences 152 and the inactive geo-fences 154 as needed. Likewise, in some implementations, some or all of an approximation process 195 may be included in the client and operate to approximate use of geo-fences of various shapes and/or sizes.
The machine-executable instructions on the server 120 may include instructions for maintaining one or more collections of geo-fences 180 that store geo-fences used with one- or more location based services. The machine-executable instructions may also include instructions for a response process 190 that may interact with the request process 150 on the mobile device 110, to supply geo-fences from the geo-fence collections 180 on the server 120 to the geo-fence cache 150 on the mobile device 110. In some implementations, some or all of the approximation process 195 may be resident on the server 120.
At step 230, the client 145 adds the set of N1 geo-fences to the geo-fence cache 150 maintained on the mobile device 110. Initially, all the geo-fences in the geo-fence cache 150 may be inactive (i.e., not currently monitored). At step 240, the client 145 activates (i.e. causes to be monitored) a sub-set of N2 geo-fences from the set of N1 geo-fences that are most proximate the location of the mobile device 145, where N2 is generally a number less than or equal to N1 (i.e. N2<=N1). For example, as shown in
At step 250, the client 145 establishes and monitors an “envelope” geo-fence that provides a basis for determining when the activated sub-set of N2 geo-fences may need to be updated to select a new activated sub-set of N2 geo-fences. The envelope geo-fence may contain all of the N2 geo-fences, or it may contain a proximate subset of the N2 geo-fences. When the envelope geo-fence contains all of the N2 geo-fences it will generally encompass the N2 geo-fences. For example, as shown in
At step 620, the geo-fence cache is updated to ensure there is a set of N1 geo-fences. The new set of N1 geo-fences may include some geo-fences already in the geo-fence cache, as well as new geo-fences obtained from the server. Obtaining the new geo-fences may be performed using operations similar to as discussed above in relation to
In another example embodiment, the client on the mobile device approximates use of geo-fences of various shapes and/or sizes, potentially including shapes and/or sizes other than those natively support by the mobile device 110.
At step 820, the approximation process generates a group of M geo-fences whose union approximates the initial geo-fence (e.g., non-supported geo-fence), where M is a value greater than or equal to one (i.e. M>=1). The group of M geo-fences may be natively supported by the mobile device 110, such that the geo-fences are considered “supported geo-fences.” For example, as shown in
At step 830, the group of M geo-fences (e.g., the group of M supported geo-fences) are mapped to a single identity. At step 840, whenever it is detected that mobile device 110 is moved to new location proximate to (e.g., has crossed) the union of the M geo-fences (e.g., M supported geo-fences), an application that utilizes the initial geo-fence (e.g., the non-supported geo-fence) is notified. For example, if the mobile device has crossed one of the M geo-fences, and has not crossed into another of the M geo-fences, but has instead left the union of the M geo-fences, an application that utilizes the initial geo-fence (e.g. the non-supported geo-fence) may be notified. In this manner, the union of the group of M geo-fences (e.g., the group of M supported geo-fences) is effectively treated as an equivalent and the initial geo-fence (e.g., non-supported geo-fence). For example, in reference to
In summary, the above described techniques may be used to approximate concurrent monitoring of a large number of geo-fences, potentially beyond a number supported by a mobile device, and to approximate use of geo-fences of various shapes and/or sizes, potentially other than those natively support by the mobile device. It should be understood that the techniques, and portions, thereof may be utilized together, individually, or in combination with other techniques, depending on the implementation. Further, it should be understood that aspects of the techniques may be modified, added to, removed, or otherwise changed depending on the implementation.
For example, while some of the examples discussed above involve two-dimension (2-D) geo-fences, it should be understood that the techniques are readily applicable to three-dimensional (3-D) geo-fences. For instance, rather than circles, polygons, and the like, the geo-fences may be arranged as spheres, prisms and similar 3-D shapes.
Further, while certain processes 160, 170190, 195 discussed above, are described as resident on the mobile device 110 and/or the server 120, it should be understood that the processes, and portions thereof, may be otherwise located, such that operations may be performed on different devices. For instance, at least portions of the activation process 170 may performed on the server 120 rather than on the mobile device 110. Likewise, an additional server (not shown) or other electronic device may be called upon to perform some operations.
In general, while specific example hardware and software is discussed above, it should be understood that the technique may be implemented using a variety of different types of hardware, software, and combination thereof. Such hardware may include a variety of types of processors, memory chips, programmable logic circuits, application specific integrated circuits, and/or other types of hardware components that support execution of software. Such software may include executable instructions that implement applications stored in a non-transitory computer-readable medium, such as a volatile or persistent memory device, a hard-disk, or other data store. Combinations of software and hardware may be adapted to suit different environments and applications.
Accordingly, it should be understood that the above descriptions are meant to be taken only by way of example.
The present application claims priority to U.S. Provisional Patent Application No. 61/925,437, filed on Jan. 9, 2014 by Christopher Steger et al., titled “Active Geo-Fence Management and Geo-Fence Splitting”, the contents of which are incorporated by reference herein in their entirety.
Number | Name | Date | Kind |
---|---|---|---|
8531293 | Putz | Sep 2013 | B2 |
8755824 | Wang et al. | Jun 2014 | B1 |
8798646 | Wang et al. | Aug 2014 | B1 |
20090164118 | Breen | Jun 2009 | A1 |
20110136468 | McNamara | Jun 2011 | A1 |
20120077536 | Goel | Mar 2012 | A1 |
20130045760 | Obermeyer et al. | Feb 2013 | A1 |
20130099977 | Sheshadri et al. | Apr 2013 | A1 |
20130138334 | Meredith | May 2013 | A1 |
20130178233 | McCoy | Jul 2013 | A1 |
20130295955 | Sheshadri et al. | Nov 2013 | A1 |
20130310053 | Srivastava et al. | Nov 2013 | A1 |
20130324160 | Sabatellil | Dec 2013 | A1 |
20140045516 | Turgman | Feb 2014 | A1 |
20140057648 | Lyman et al. | Feb 2014 | A1 |
20140066090 | Henderson | Mar 2014 | A1 |
20140171099 | Sydir | Jun 2014 | A1 |
20140242947 | Ali et al. | Aug 2014 | A1 |
20140274118 | Carmel | Sep 2014 | A1 |
20140302879 | Kim | Oct 2014 | A1 |
20140351560 | Lautner | Nov 2014 | A1 |
20140370909 | Natucci, Jr. et al. | Dec 2014 | A1 |
20140370911 | Gorgenyi | Dec 2014 | A1 |
20150095157 | McDevitt | Apr 2015 | A1 |
20150120455 | McDevitt | Apr 2015 | A1 |
20150141037 | Saha | May 2015 | A1 |
20150181549 | Batada | Jun 2015 | A1 |
Number | Date | Country | |
---|---|---|---|
61925437 | Jan 2014 | US |