Patent Application
20080147311
Automotive navigation systems built into vehicles, and other mobile devices such as GPS-equipped handheld devices and phones, can provide mobile mapping services to users. For example, a user can view a map that regularly updates itself based on the user's current location, and can hear computer-generated directions and the like based upon a current location and a specified destination. Users (e.g., on a desktop personal computer) can also use the Internet to generate static a map and/or directions based upon a starting location and a specified destination.
Mobile mapping may include features similar those provided with desktop computing concepts. For example, desktop mapping applications often allow the placing of location marker icons (e.g., placeholders resembling “pushpins” or equivalent representations such as star-shaped or flag-shaped icons and so forth) on a displayed map to represent static, saved locations. Such marker locations may be directly user-specified such as by entering an address that maps to coordinates, or may be user-selected, such as by entering search criteria and then selecting a search result that causes a location marker to be shown on the map. While at times valuable, the user's selection of such location markers can result in too many location markers being visible while the user is in one area, or no relevant location markers appearing while in another area.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which a virtual location marker is determined, in which the virtual location marker corresponds to one (e.g., a first) coordinate set (such as a latitude and longitude and/or an altitude) to represent a point on a map. Upon detecting a state change, the virtual location marker may be re-determined, including changing the virtual location marker to correspond to another, (e.g., a second) coordinate set (a different latitude, longitude and/or altitude) that is different from the first coordinate set. As a result, unlike a fixed location marker, the coordinates of a virtual location marker may change in response to a state change, possibly long after an initial query. A state change may be a change in one or more of the following, including a current location, and/or a change in direction, speed, time, a start location, an end destination, or the contents of any searchable database or data store.
In one example embodiment, a preference mechanism obtains a query from a query input mechanism. Based on the query results, along with a data store set containing at least one data store, and dynamic data, a virtual location marker may be computed, and output, e.g., plotted on a map and/or used to provide audio directions or the like. The virtual location marker may be re-computed, such as based on a change to the dynamic data and/or to data from the data store set.
Thus, when processing a query directed towards identifying a location other than a current location, a virtual location marker may be computed from the results of the query to determine a first location corresponding to a first coordinate set. The output corresponding to the virtual location marker may change upon detecting a state change that causes the location marker to be recomputed to correspond to a second coordinate set.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards virtual location markers. As will be understood, a virtual location marker has a dynamically-computed location (e.g., a latitude and longitude or other coordinate system), rather than a static location. At any given instant in time a static location marker can be created from a virtual location marker and displayed on a map, with any other currently visible location marker possibly removed. Thus, unlike a static location marker which has fixed underlying coordinates, a virtual location marker can change its underlying coordinates. For example, a map can show a location marker for the closest coffee shop relative to the user's current location, which can change to show a different location marker as the user moves away from one coffee shop and closer to another.
In one example implementation, a virtual location marker typically comprises an image or the like such as an icon, with the virtual location marker dynamically computed to position its representative icon relative to the real-time location of a mapping-equipped device. Like a regular location marker, the virtual location marker thus appears to move on the screen as the user moves and the map is redrawn, however the virtual location marker can be computed to completely change its underlying coordinates and thus “jump” to a new relative location. Although in one drawing an icon representing a “pushpin” is used to represent a virtual location marker, it is understood that a virtual location marker is not limited to an image resembling any particular shape, or even to a visible image, but rather may be any practical image, audible sound or the like that can convey the concept of a location to a user that is viewing a map and/or is listening to audio directions based on map data.
As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities and/or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and networking in general.
Unlike conventional static location markers, the location marker technology described herein is capable of generating a location marker based on a request for data and on dynamic state data 124, (e.g., from any suitable data source 125) as well as other data, such as user preference data, e.g., maintained in a user data store 1261. As represented in
A query 128 or the like may be used to cause generation of a virtual location marker (or multiple virtual location markers), with the query possibly submitted by a user, such as to “find a coffee shop on my route” from a current location to a submitted destination. A user input mechanism 130 may be used to provide such a query. A query may be a one-time event, or programmed to reoccur. A user may also re-query or parse through query results, such as to cycle through one or more alternative results when the current result does not meet the user's expectations. Alternatively, a query 128 may be provided by default; e.g., a device manufacturer may include one or more queries or query results corresponding to defined points of interest. Further, the query 128 may be computer generated, such as a vehicle's computer that requests a virtual location marker be displayed to represent a gasoline station when the vehicle's gasoline tank gets below a threshold level. Such other types of query input are represented in
Unlike a static location marker, a user need not select a location (e.g., corresponding to a business) and fix it on a map based on its associated coordinates. Instead, based on the query 128, preference filter/logic (comprising a preference mechanism) 131 re-computes query results, typically based on some or all of the dynamic state data. Thus, for example, a user may query for a coffee shop, resulting in a virtual location marker appearing at a location on the map that corresponds to the nearest coffee shop, but then have that location marker disappear and be replaced by a newly-computed one as the user moves and thereby becomes closer to a different one.
The preference filter/logic 131 (which is coupled to the output mechanism 120) may use the dynamic state data 124 and other relevant data 1261-126N to determine whether to output a virtual location marker for a given query. For example, to keep from having undesirable location markers generated and displayed on an automotive navigation system display, the user data store 1261 may specify that a location marker for a gasoline station not be generated/displayed except in a state in which the vehicle's gasoline tank is below one-eighth full, and only when a location that provides a certain brand of gasoline is available on the user's route. Other filtering criteria including as time may be used, e.g., a user may not want a location marker generated as a reminder to pick up dry cleaning until the dry cleaning is supposed to be ready, e.g., after 3 PM; note that this information may be found by accessing the user's task data, represented as part of the user data store 1261. The user data store 1261 may reside locally on the mapping device, such as accessed via the input mechanism 130 of the user device, or may be remotely located, e.g., accessed over the Internet 140 via the input mechanism 130 or another means, such as a browser on a desktop computer. Often (but not necessarily always) at least a copy of such user data is present locally for access when no network/Internet connection is present.
As also represented in
By way of example, returning to the above coffee shop query example, but using the example map 250 represented in
In response to the “find a coffee shop query,” actual coordinates found in a data store search may locate the closest coffee shop, as well as possibly many other coffee shops. However certain ones, including the physically closest one, represented in
Many other examples of data stores that provide data may be used for filtering purposes. For example, a point-of-interest (POI) data store 1263 may provide well known or important landmarks. A user may want such point-of-interest locations virtualized into location markers at one time, such as when driving a visitor around a city, but not at other times, such as when driving to work. Note that point-of-interest markers may be combined with audio that provides a “tour” scenario as different landmarks are approached.
Other data stores 126N are also shown in
Contacts data may also serve to generate a location marker. For example, if a user has contacted a friend and is near that friend's house or appears to be on the way there, a virtual location marker may be generated to indicate the location of that friend's house and/or suggest providing directions thereto. Alternatively, lack of recent contact with a physically nearby contact's location can generate a virtual location marker, e.g., when a user has not recently visited a contact (such as stored by a navigation computer based on time spent at those coordinates), and/or based on phone data that indicates the user has not called or been called by a contact.
Calendar and task data are other examples of user data that may be used to compute a virtual location marker. For example, a task such as pick up dry cleaning may be used to generate a virtual location marker at a location where the dry cleaning was dropped off, whereas a task such as drop off dry cleaning may show the nearest dry cleaner. Note that non-location-related tasks (e.g., call home) ordinarily would not result in location marker generation. Calendar and current time data may be used to generate a virtual location marker, e.g., a virtual location marker automatically appears at an offsite meeting location when it is time to start heading for the meeting. Task, time and calendar data may be combined, e.g., do not show location marker icon for picking up the dry cleaning when it is before 3 PM, or when the user's calendar indicates there is not sufficient time to stop.
Businesses and other enterprises may provide relevant information, such as via a defined schema used when generating a query and/or filtering its results with respect to virtual location marker computations. For example, virtual location marker computations may factor in whether a store is currently open based on the current time, whether the business has a drive through, whether cash, checks and/or credit cards are accepted, (and if so, which ones, and whether there is room on the user's limit for each that will be accepted). Other business criteria can include whether the desired business sells related accessories, does the business have everything needed (e.g., a grocery store with a pharmacy, whether the pharmacy takes insurance, does a filling station have diesel fuel, and so forth).
Price data (e.g., current price, an available discount and so forth) may be accessed as state data, whether currently accessed or recently cached, such as to find the cheapest gasoline on the current route. Additional computations such as whether the savings is justified by the extra distance and time may be used to select one virtual marker over another. These additional computations may be according to user preference data, miles per gallon, and so forth.
Another type of data corresponds to preferred business data. For example, a business may contract with a mapping company so that its products or services are pre-loaded or weighted when computing a virtual location marker, instead of computing a marker for another business that may likewise meet a query's criteria. For example, via computation weighting, a query to locate a hotel room may come up with virtual location marker for a particular hotel chain, even though another hotel may be closer. User preference data (e.g., favoring one hotel where the user has privileges), state data (e.g., vacancy or not), and practicality (e.g., a user does not want to receive directions to a hotel fifty miles away when one is a mile away) may supersede preferred business recommendations.
The representation of a virtual location marker can also convey information to a user. For example, instead of a generic pushpin icon or the like as a marker, the icon's appearance may be selected so as to distinguish a gasoline station versus a coffee shop. The user may select icons from a set, which may be downloaded. A company may pay to have its logo or custom icon appear as a virtual location marker. Other information may be conveyed by the icon's appearance, such as to fade one icon out as the map moves away from its location, and fade another one in as the user approaches its location. An icon's appearance may blink, flash, grow, shrink, change color and so forth to convey information.
Another aspect of virtualized location markers is that certain markers can be predefined, such as home and work. During installation, for example, a user may provide a home and work address, whereby virtualized location markers are generated at those locations, and possibly converted to fixed location markers. Thereafter, when seeking closest to home, closest to work and so forth, a user will not need to re-enter the same information.
Further, a user may specify start and end locations, along with some number of virtual location markers to generate relative to the user's current location. For example, the best coffee shop based on the route, and the best gasoline station based on the route, current price (but only when the tank is below a threshold) may be two that the user regularly wants to see, when relevant. A third may be to select an errand from the user's personal task list that can be accomplished on the route, or by detouring within some number of feet of the route.
Note that mobility is not needed with respect to generation of virtual location markers, and indeed, current location is only an optional input. For example, a user may request that a mapping service compute the closest florist to home, even when the user is not at home and/or is stationary. What is basically needed is a query plus sufficient data (e.g., home plus closest florist) to narrow that query to generate at least one virtual location marker that matches the user's expectations.
Virtual location markers can also be computed to satisfy queries relative to another device, e.g., to determine where the children are now, to materialize only when the children are outside of a predefined boundary or are exceeding the speed limit, and so forth.
Similarly, a device can output information as a user hones in on a location marker, such as to automatically notify a business that the user having a particular identifier will be arriving in an estimated time of five minutes, and would like a usual order placed, charging the usual account. Estimated times of arrival can be updated as time and other (e.g., traffic) conditions change. A business can track live customer locations to time/match orders as customers arrive.
By way of summary, essentially, any dynamic and/or or relatively static data may be used in a computation of a virtual location marker. As described above, for dynamic data from a remote source such as the Internet, a local cache can simulate live data, at least when refreshed relative recently, (and cached data can expire if not). For example,
For example, step 402 represents determining whether the current location has changed; if so, the map is updated at step 404 to show the new location and the current markers. Steps 402 and 404 may happen relatively frequently, e.g., each time the user device moves a certain distance, as in conventional mapping scenarios. If no query results are available (or still apply) with respect to virtual location markers, step 404 can return to step 402 (e.g., the dashed line, possible after some delay) until query results exist.
If the location has changed, step 406 determines whether the location change is sufficient to cause re-computation of a virtual location marker. If so, the process branches ahead to step 410 to re-compute the virtual location marker markers based on the new location, any other current state, and other data such as user preferences. Note that although step 410 refers to a re-compute operation, it can be readily appreciated that this step also represents any first time computation, such as by evaluating query results before virtual location markers presently have been computed. Further, the re-computation step 410 may include issuing a new query to obtain possibly different query results or additional query results.
With respect to a location change not being sufficient to cause a change at step 406, it can be readily appreciated that there may be a number of factors that prevent or at least delay the virtual location markers from being re-computed. For example, a user may not want to see a sudden change or receive a sudden change in directions when the user is very close to arriving at a current virtual location marker. This is true even when a new virtual location marker would be computed, for example, because the user may have moved into a turn lane in response to a previous instruction; indeed, the turn itself based on the instruction may cause the location change. Some dampening heuristics thus may be applied to avoid sudden virtual location marker changes in response to minor location changes.
Step 408 similarly evaluates whether another (non-location) state change is sufficient to cause re-computation of at least one virtual location marker. Such other state may be time, speed, direction, weather, and essentially anything else that can change, including a user or other change to otherwise static data. If so, the process branches ahead to step 410 to re-compute the virtual location marker or markers based on the current state change, the current location, any other current state, and other data such as user preferences. Again, this allows for dampening heuristics to be applied, e.g., a user may not want to suddenly see or hear new directions because the price of gasoline just dropped a penny per gallon at a different location. Note that time can be a sufficient state change, whereby, for example, virtual location markers are updated even if the user is stationary.
Steps 412 and 414 update the virtual location marker or markers as necessary based on the computation at step 410.
In this manner, a user or other mechanism pre-builds a query, and a virtual location marker automatically materializes at an appropriate location and/or appropriate time. This provides the user with a result as needed. As the user moves, so may any location marker, and the location marker can change to another location without needed to query again. Other factors such as dynamic and static state data can cause a change, including when the user's device is not moving.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
