Patent Grant
9389088
The present disclosure relates to map rendering systems, such as electronic map display systems, and more specifically to a method of and system for pre-fetching map data from a remote database.
With the widespread use of mobile devices, such as mobile phones, personal data assistants, tablet personal computers, etc., consumer demand for ready access to varied types of data continues to grow at a high rate. These devices are used to transmit, receive, and store text, voice, image, and video data. Consumers often look to store large numbers of applications on these devices, such that mobile devices are often touted more for the number of available applications, than internal processor speed. While consumers have come to desire fast access to data, the sheer amount of data required to run these applications places a premium on data management, which may apply on both the device level and at the network level. This premium may limit the effectiveness of applications such as mapping applications, which may typically require comparatively large amounts of network data (e.g., for systems that retrieve map data from a remote database).
Mapping applications are found in a variety of mobile devices, including car navigation systems, hand-held GPS units, mobile phones, and portable computers. These applications are among the most frequently used applications and are considered, by some, necessary for personal safety. Although the underlying digital maps are easy to use from a user's perspective, creating a digital map is a data intensive process. Every digital map begins with a set of raw data corresponding to millions of streets and intersections. That raw map data is derived from a variety of sources, each providing different amounts and types of information. To effectively map a location, locate a driving route between a source and a destination, identify points of interest, etc. requires substantial amounts of data. Furthermore, many mapping applications require a display of different map data at different zoom levels, i.e., different scales, where the amount of detail and the nature of that detail changes at each zoom level. For example, at a lowest zoom level, scaled furthest away from a target, the map data may contain the boundaries of continents, oceans, and major landmasses. At subsequent zoom levels, that map data may identify countries, states, homelands, protectorates, other major geographic regions. While at even further subsequent zoom levels, that map data may contain major roads, cities, towns, until eventually the map data contains minor roads, buildings, down to even sidewalks and walk ways depending on the region. The amount of detail is determined by the sources of information used to construct the map data at each zoom level. But no matter the zoom level, the amount of information is voluminous and may be generally too large for storage, in total, on mobile devices and too large for continuous download over a wireless communication network.
In operation, mapping applications typically download map data to the mobile device through a wireless communication network and in response to a user entering a location of interest and/or based on the current location of the mobile device, such as the current global positioning satellite (GPS) data or current cellular network location data for the device. A conventional technique for downloading map data is to have the mobile device communicate this location data to a remote processor on the wireless communication network, which, in response, downloads all map data to the mobile device or the map data requested for display to the user.
Map data may generally be stored in blocks known as map data tiles, where the number of map data tiles increases with zoom level. The remote processor provides a subset of the available map data tiles for a particular location or region to the mobile device for storage and display at any particular time via a map display application. By providing large numbers of map data tiles, the mobile device may buffer the map data for display to the consumer as the consumer scrolls across an area using the mapping application looking for adjacent or other mapping locations. However, the larger the number of map data tiles provided at any particular time, the longer the download time and the higher the buffer memory usage while the user is using the map display application.
Map data tiles may be downloaded and cached in an inefficient manner that may not take advantage of a viewing context to more efficiently retrieve higher priority mapping data over lower priority data. One such viewing context relates to map data with respect to pre-fetching map data for different portions of a route. Pre-fetching data for later usage is important in mobile devices where a connection to a map database (e.g., via a map database server) may only be intermittent at best. Further, because mobile computing devices are generally more bandwidth and processor limited than, for example, a desktop computer, efficiency of retrieval and processing of map data is even more critical in mobile applications. As a result, there is a need to have more intelligent mechanisms for retrieving (e.g., downloading) and/or processing map data, in particular map data tiles, to sufficiently satisfy visual requirements of a limited computing device without wasting bandwidth and processing services.
A computer-implemented method for pre-fetching map data for a mapping application includes initiating a function to generate a first route, wherein the first route is defined by an origin, a destination, a set of roads connecting the origin to the destination, and a first direction of travel. The method accesses a set of pre-fetch map data tiles corresponding to a set of secondary routes from a map database in response to initiating the function. The method stores the set of pre-fetch map data tiles in a local memory. In one embodiment, the method accesses the set of pre-fetch map data tiles from the map data base and stores the set of pre-fetch map data tiles in the local memory before a function is initiated to generate one of the set of secondary routes.
In one embodiment, the set of secondary routes includes a set of return routes of the first route wherein each of the return routes are defined by a second direction of travel opposite the first direction of travel of the first route. At least one return route of the set of return routes includes a sequence of roads that is different from the first route. The set of secondary routes may include a route from the first route to an external point of interest. The method may include determining the set of secondary routes and/or the set of pre-fetch map data tiles based on a number of parameters.
In another embodiment, a computer device includes a communications network interface, one or more processors, one or more memories coupled to the one or more processors and a display device coupled to the one or more processors. The one or more memories include computer executable instructions that are executed on the processor to initiate a function to generate a first route, the first route defined by an origin, a destination, a set of roads connecting the origin to the destination, and a first direction of travel. The set of roads may be a sequence of roads. The one or more memories include computer executable instructions that are executed on the processor to determine a set of secondary routes based on the first route, wherein the set of secondary routes includes a set of return routes defined by a second direction of travel opposite the first direction of travel of the first route, and wherein at least one return route of the set of return routes includes a set of roads that is different from the first route. The one or more memories include computer executable instructions that are executed on the processor to determine a first set of pre-fetch map data tiles corresponding to map surface areas of at least one of the set of secondary routes. The one or more memories include computer executable instructions that are executed on the processor to access the first set of pre-fetch map data tiles from a map database, wherein the first set of pre-fetch map data tiles are a subset of a total number of map data tiles stored in the map database. The one or more memories include computer executable instructions that are executed on the processor to store the first set of pre-fetch map data tiles in a local memory before a function is initiated at the client computing device to display the first set of pre-fetch map data tiles.
In another embodiment, a computer device includes a communications network interface, one or more processors, one or more memories coupled to the one or more processors and a display device coupled to the one or more processors. The one or more memories include computer executable instructions that are executed on the processor to transmit a request for map data corresponding to a first route, the first route defined by an origin, a destination, a sequence of roads connecting the origin to the destination, and a first direction of travel. The one or more memories include computer executable instructions that are executed on the processor to receive, in response to the request, a first set of pre-fetch map data tiles corresponding to map surface areas around and including the first route and a second set of pre-fetch map data tiles corresponding to map surface areas around and including a second route, the second route being a return route defined by a direction of travel opposite a direction of travel of the first route, and wherein the return route includes a sequence of roads that is different from the first route. The one or more memories include computer executable instructions that are executed on the processor to store the first and the second set of pre-fetch map data tiles in the one or more memories of the computer device.
The present application generally relates to pre-fetching map data from a map database. Pre-fetching map data may refer to access/retrieval of map data by an application or device before the map data is immediately required for use. In one embodiment, map data may be pre-fetched before an initiation of a function that uses the pre-fetched data. For example, map data from a map database may be accessed and/or retrieved by a computing device before a user activates or executes a function (e.g., a display or rendering function) to use that map data. A benefit of pre-fetching the map data is that during periods in which a map database is unavailable (e.g., when a mobile computing device is offline), the pre-fetched map data may be available to a mapping application or computing device to provide some services or functions, such as displaying a pre-fetched route. Generally, a route includes two endpoints (e.g., origin and destination) and a set of paths or roads connecting the two endpoints. The set of paths or roads may have a sequence. The sequence may also correspond to a direction of travel. Routes and route types are described in more detail below.
More specifically, the present application describes techniques for fetching map data as a selected subset of entire map data available, by selecting map data tiles corresponding to an area that encompasses a route. An amount of map data accessed may be adjusted based on a priority of points along the route. In an example implementation, greater amounts of map data may be fetched or retrieved for endpoints of the route (representing origin and destination locations) than for points in the middle of the route. For determining what map data corresponds to an area about the route, a set of map tile radii may be used to designate map data tiles to be accessed that correspond to areas of a map surface along the route.
Referring now to
The map database 12 may store any desired types or kinds of map data including raster image map data and vector image map data. However, the image rendering systems described herein may be, in some embodiments, optimized for use with vector image data which may define or include a series of vertices or vertex data points for each of numerous sets of image objects, elements or primitives within an image to be displayed. Generally speaking, each of the image objects defined by the vector data may have a plurality of vertices associated therewith and these vertices may be used to display a map related image object to a user via one or more of the client devices 16-22.
As will also be understood, each of the client devices 16-22 may include an image rendering engine having one or more processors 30, one or more memories 32, a display device 34, and in many cases a rasterizer or graphics card 36 which may be generally programmed and interconnected in known manners to implement or to render graphics (images) on the associated display device 34. The display device 34 for any particular client devices 16-22 may be any type of electronic display device such as a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, a cathode ray tube (CRT) display, or any other type of known or suitable electronic display.
Generally, speaking, the map-related imaging system 10 of
Referring now to
During operation, the map logic of the map application 48 may execute on the processor 30 to determine the particular image data needed for display to a user via the display device 34 using, for example, user input, GPS signals, prestored logic or programming, etc. The display or map logic of the application 48 may interact with the map database 12, using the communications routine 43, by communicating with the server 14 through the network interface 42 to obtain map data, preferably in the form of vector data or compressed vector data from the map database 12. This vector data may be returned via the network interface 42 and may be decompressed and stored in the data memory 49 by the routine 43. In particular, the data downloaded from the map database 12 may be a compact, structured, or otherwise optimized version of the ultimate vector data to be used, and the map application 48 may operate to transform the downloaded vector data into specific vertex data points using the processor 30a. In one embodiment, the image data sent from the server 14 may include vector data generally defining data for each of a set of vertices associated with a number of different image elements or image objects to be displayed on the screen 34 and possibly one or more lookup tables. If desired, the lookup tables may be sent in, or may be decoded to be in, or may be generated by the map application 48 to be in the form of vector texture maps which are known types of data files typically defining a particular texture or color field (pixel values) to be displayed as part of an image created using vector graphics. More particularly, the vector data for each image element or image object may include multiple vertices associated with one or more triangles making up the particular element or object of an image. Each such triangle includes three vertices (defined by vertex data points) and each vertex data point has vertex data associated therewith. In one embodiment, each vertex data point includes vertex location data defining a two-dimensional or a three-dimensional position or location of the vertex in a reference or virtual space, as well as an attribute reference. Each vertex data point may additionally include other information, such as an object type identifier that identifies the type of image object with which the vertex data point is associated. The attribute reference, referred to herein as a style reference or as a feature reference, references or points to a location or a set of locations in one or more of the lookup tables downloaded and stored in the data memory 43.
Generally speaking, map data in the map database 12 for a particular geographic region may be stored in different zoom levels, where each zoom level is formed of a plurality of map data blocks, termed map data tiles, which may be used, in one embodiment, to construct a visual display of the map or surface of the map at different levels of detail.
The number of tiles for a fixed geographic region at each zoom level may increase, e.g., linearly, quadratically, exponentially, or otherwise as the zoom level number increases. The zoom levels in the illustrated example (z=1, 2, and 5) have 6, 18, and 60 map data tiles, respectively, covering the same geographic area or region. Because the number of map data tiles may increase for the same area as zoom level increases, zoom level may be considered a density of map data corresponding to a number of tiles per unit area. Higher zoom levels may generally require more tiles per unit area and thus provide higher map data density over lower zoom levels.
In the illustrated embodiment, all map data is stored in map data tiles, and each map data tile in a zoom level data structure may be allocated the same or similar memory allocation size. For example, each tile 204A-204R may be a bitmap image 10 Kbytes in size. This may be achieved, for example, by having each map data tile cover the same sized geographic area. For map data tiles containing vector data, the data size for each tile may vary, but each tile may still, in some embodiments, be allotted the same maximum memory space. Although not illustrated, in other embodiments, the data tiles may have different memory space allocations within each zoom level data structure. In some embodiments, each map data tile may contain map data stored in a bitmap format while in other embodiments each map data tile may contain map data stored in vector format.
In operation, the server 14 may be configured to transmit map data to respective client devices 16-22 in chunks of data defined by these map data tiles. For example, to transmit the map data needed to construct the map display 300, the server 14 may transmit each map data tile in a frame, having a header portion providing identification data of the frame (such as geographic position, client device address, map data tile version number, etc.) and a payload portion containing the specific map data tile data to be used in forming the visual display. Map data tiles may provide an effective mechanism for quantizing map data stored in the map database 12 and for quantizing communication of the map data over the network 25 to the client devices 16-22.
In comparison to
Each of the displays 300, 400, and 480 may illustrate a portion of the overall map data, which comprises many more map data tiles. As illustrated across
While a user interacts with the visual map displays 300, 400, and 480, the user may wish to scroll around to display other map data (corresponding to different geographic areas) near the illustrated map data. Therefore, the client devices 16-22 may use a system to fetch and store a sufficient amount of map data to form the visual map display while buffering additional map data at one of the local client devices 16-22 to allow efficient user interaction with that display.
In an embodiment of the techniques described herein, a map database, such as map database 12, may be accessed to pre-fetch or retrieve map data (e.g., map data tiles) corresponding to a map area that encompasses a determined route. In another embodiment, map data may be pre-fetched to generate one or more routes. The map data used to generate a route may be contained in the same map data tiles used to provide information for displaying a route. In a different embodiment, the data used to generate the route may be contained in map data tiles separate from the map data tiles used to render the route. In another embodiment, the data used to generate the route may be contained in a data form different from map data tiles. Pre-fetching generally involves initiating a retrieval of map data before that data is needed for processing. For example, pre-fetching may involve retrieving map data before an initiation of a rendering or display function utilizing that map data. Pre-fetching may also involve storing map data in a local memory for faster retrieval over a map database. For example, the speed of accessing a local memory may be faster than the speed of accessing a map database (e.g., due to intermittent connection, connection bandwidth, etc.). In situations where a mobile device is only able to intermittently access the server 14 over network 25, pre-fetching may involve scheduling access and retrieval of map data whenever the client device is able to connect to the server 14, whether or not the mobile device/user has even requested access to that data (e.g., via a request or function to render map data corresponding to the pre-fetched data).
A greater area around the route may be desired for some rendering situations of a mapping application. Generally, the method and system may determine a subset of map data tiles for an area encompassing the route (e.g., the route of
A block 904 may determine a set of map tile radii for points along the route. In one embodiment, block 904 may determine a minimum tile radius for all points along the route. The minimum map tile radius may be selected to enable a minimum number of map data tiles to be selected that corresponds with an area that encompasses the entire route (such as that of
In one embodiment, a point along a route may be assigned a priority value. For example, priority may be assigned or designated using a flag, an attribute, or other indicator associated with a point on the route. A route segment may be defined by a set of points, and thus, the route segment (e.g., a road segment of the route) may correspond to a priority when a set of points defining the route segment are assigned that priority. Further, a priority attribute may simply be a high or a low value (i.e., priority or no priority). In other embodiments, the priority may be a scaled value between a high and a low value.
The method and system described herein may determine one or more points of interest to display to a user via the interface 34. The points of interest may be determined based on a user input, for example, through the user providing an address into a data field presented on the interface 34, or through the user selecting to find a point of interest obtained through interaction with the interface 34. Generally, the priority of a point along the route may represent or may be determined by a likelihood that a user may initiate a function that accesses map data corresponding to the point. This may correspond to a user initiating a function to display a portion of the map using particular map data. The likelihood of access may be determined based on metrics of the system in operation, including, for example, analysis of the average number and times that instructions of the mapping application are executed to access the map data.
In one embodiment, the origin and destination may be assigned by default as points of interest having a high priority.
In some embodiments, the destination 504 may have higher priority, and thus more map data corresponding to a greater area, than the origin 502. This may apply to situations when a user intends to travel to the destination and is more likely to require more information at the destination (potentially longer stay time) than at an origin (potentially less stay time since the user may be leaving). There are some situations, however, where the origin may require a greater amount of priority and may have a greater map area. This may be the case, for example, when the complexity of the area about the origin (e.g., complexity increases as the number of junctions, roads, and terrain complexities increases) is high and a greater amount of map area is needed for navigating through the area about the origin.
Priority of points along the route may be determined based on user input, for example, through the user providing an address into a data field presented on the interface 34, or through the user selecting to find a point of interest obtained through interaction with the interface 34, more generally. For example, the user can access a web-browser or other program running on the client device that identifies a location, business, home, etc., from which one of the client devices 16-22 may allow the user to select such item for building a map display of the vicinity around such point of interest.
Any suitable manual method for entering or otherwise identifying one or more points of interest may be used by one of the client devices 16-22. Furthermore, a mapping application on one of the client devices 16-22 may automatically identify points of interest, for example, by determining a GPS position of the current location of one of the client devices 16-22, by determining most recently searched points of interest, by accessing a database of stored points of interest, or by determining the most recently visited points of interest (e.g., cities, neighborhoods, etc.). Of course, in some of these cases, the mapping application may determine locations for which to download map data for storage at the user device as a background application and thus without any particular user interaction.
As discussed above, process blocks 906-908 may access a map database to pre-fetch larger numbers of map data tiles corresponding to larger map areas around points of interest at a single zoom level. In one embodiment, instead of or in addition to pre-fetching more map data tiles at a first single zoom level for high priority points, the method and system may pre-fetch map data tiles for high priority points at a second higher zoom level.
Of course, in addition to retrieving additional map data tiles at the second higher zoom level, the method and system may also retrieve map data tiles at a second higher zoom level for a different area than that of the first zoom level or for a different area in relation to other points on the route at the second higher zoom level. Also, the method and system may or may not retrieve higher zoom level data for points along the route at low priority (e.g., in the middle of the route, without a point of interest, etc.). Whether higher zoom level map data is retrieved for points about the middle of the route may be dependent on the priority of points along the route. As discussed above, priority of a point on the route may be based in part on a determination of a likelihood of access for that map data.
The method and system described above may retrieve or process and store into a cache memory of a client device 16-22 only a subset of available or retrievable map data tiles based on determined areas encompassing a determined route. This method and system may provide a faster response time when anticipated map data is downloaded to a local cache memory for quick retrieval and processing. While one type of priority discussed above is based on designating what map data (area and/or zoom level data around a route) to retrieve, a second type of priority may be an order or sequence in which that map data is retrieved. The sequence of map data retrieval (e.g., map data tiles) may help to reduce bandwidth and processor tolls. The sequence of map data retrieval may also ensure that more important, high priority tiles are downloaded first in case a connection to a server containing the map data is lost during retrieval.
A block 1304 may then determine a current condition of the system (e.g., a viewing window state, a current bandwidth, a current processor capacity, etc.). A block 1306 may then determine a sequence for pre-fetching each set of map data determined in block 1302. The determination of block 1306 may be performed based on the condition determined in block 1304. The sequence determined by block 1306 may be a fixed default sequence that is based on a likely order of access by a user. This may be the case when block 1304 indicates a default condition. At block 1308, a map database may be accessed in the sequence determined by block 1307 for each set of map data tiles of block 1302. At block 1310, the accessed map data may then be retrieved and/or stored in a local memory for quick access when a user or the map application initiates an access or processing function requiring the map data.
A general sequence may involve retrieving map data for a destination, an origin, additional points of interest along the route, and then connection segments (roads segments) to various off-route points of interest. Another sequence may lead with an overview set of map data that includes a minimum map tile data for a zoom level and viewing window position that includes the origin and destination in one displayable viewing screen (such as that of
In one embodiment, both the sequence and area of map data tiles may be accessed or pre-fetched based on a viewing window state. In particular, the map data tiles may be accessed based on a viewing window position. The viewing window position may be centered near a particular point along the route. As the viewing window position is changed so that the center position approaches other portions of the route, either additional area map data may be retrieved (e.g., via blocks 906-908) or a sequence of retrieval may be changed (e.g., via blocks 1306-1310). This embodiment may be used in situations in which a current position of a device rendering a map is provided to center the map at that current position (e.g., using a GPS system).
The amount of map tile data and the sequence in which subsets of the map tile data are accessed may be based on a current bandwidth or processor load of the system of
Processor capacity for performing map database access may be considered. For example, a current processor capacity may be checked against a threshold. This may be the case when a current condition of the mapping application requires reduced data retrieval and/or processing due to processor load. For example, where the processor is overloaded or backed up (the processor capacity is low or below a threshold), the map data tile radii may be shortened to reduce the total amount of map data tiles retrieved and processed, thereby lessening processor workload.
Further, the sequence and amount of the pre-fetch map data tiles may be based on memory conditions. For example, there may be a limited amount of memory allocated for pre-fetch map data. The corresponding areas of map data tiles may be scaled appropriately to take into account a memory budget. The sequence of retrieval may be reordered based on a memory budget. Alternatively, the number of map data tile sets may be reduced based on the memory budget.
Any suitable subset of the blocks of
According to another embodiment, secondary routing information for a set of routes associated with an initial route may be determined where map data corresponding to the routes may be accessed and pre-fetched. An initial route may be referred to hereinafter as a primary route, while the associated routes may be referred to as secondary routes. The secondary routing information may include turn-by-turn instructions for each of the set of secondary routes. Corresponding map data in the form of map data tiles for the secondary routes may also be pre-fetched in a manner similar to that described above. The map data tiles that are pre-fetched using this embodiment may be used to provide routing information when the client device is not connected to a server. As discussed above, a client device may only be intermittently connected to a map database and may be unable to retrieve map data tiles from the database during an offline period when there is no connection between a user computing device and a map database server that provides the map data tiles. Pre-fetching the map data tiles may allow a client device to continue providing client requested map displays even when the client device is offline.
A block 1406 may determine a set of secondary routes based on the primary route. The set of secondary routes may be determined based on a number of factors and parameters as discussed further below. A block 1408 may then access pre-fetch map data tiles from a map database, wherein the pre-fetch map data tiles correspond to one or more of the set of secondary routes determined by block 1406. More particularly, the pre-fetch map data tiles may correspond to areas encompassing one or more of the secondary routes. The size of the area encompassing the one or more secondary routes may be determined in a similar manner as described above. In one embodiment, the block 1406 may pre-fetch data used to generate the set of secondary routes. For example, some of the pre-fetch data may be used to generate each of the set of roads defining one or more secondary routes. As discussed above, this map data may be the same or similar to the map data tiles used to render a route or take a different form altogether. A block 1410 may then retrieve, receive, transmit, and/or store the pre-fetch map data tiles of the primary and secondary routes into a local memory of a client device. As discussed above, pre-fetching may involve retrieving or otherwise accessing the map data before an initiation of a rendering or a display function utilizing that map data. Pre-fetching may involve retrieving or otherwise accessing the map data before an initiation of a function for generating any of the secondary routes at a client device. Also, the method of determining areas encompassing the secondary routes may be implemented using any of the techniques described above, such as those illustrated in
In one embodiment, one of the blocks 1402 of 1404 may include transmitting a request for map data corresponding to the first route. Block 1406 may be performed at a server device external to the computer transmitting the request. Block 1410 may then receive map data for the first route and secondary routes from the server where only a map data was requested for the first route at block 1402.
The secondary routes may be categorized by road type(s) used to connect the endpoints of the return route. Generally, a speed rating may be used to grade roads. For example, some roads are narrower and less easily navigated, which may cause those roads to be considered slow, while other larger roads (e.g., highways) are considered fast roads. Additionally, an anticipated speed of a road may be based on known posted speed limits for those roads. In these cases a set of associated routes may be determined based on designated or determined high speed roads for routes, regardless of a total distance of the routes. Other secondary routes may include road or path segments that are based on a user profile. For example, a secondary route may be determined to include one or more path segments that are frequently traveled by a user. This may be useful, in some instances, to a user because the user is familiar with those path segments.
Additional routes (not shown) may be calculated from the point of interest back to a point of deviation (e.g., the point of origin of a path to the point of interest) of the primary route. Alternatively, another route may be determined from the point of interest back to a point along the route different from the point of deviation. This may be displayed, for example, when a more efficient route exists to guide a user closer to the destination or origin of the primary route. Alternatively, a route from the point of interest may end at a second different point of interest. These are merely some of the types of secondary routes that may be accessed and displayed.
A priority may be assigned to each of the set of a set of possible secondary routes. Priority of a secondary route may be based on a likelihood of access to the route information of the secondary route. In particular, priority may represent a likelihood that a user may initiate a function that requires access to map data corresponding to a secondary route. The initiating function may be a function that, for example, requires turn-by-turn instructions to be generated, that displays map tile data for the route, etc. The likelihood of access may be determined based on metrics of the system in operation, including, for example, analysis of the average number and times of initiating access to a route or to portions of a route (e.g., a set of path segments of a route). The access metrics may be specific to a user or a group of users. The likelihood of access may be based on a user pattern or profile that is generated for or by the user. The user pattern may include a usage pattern that provides information on locations that a user frequents, preferred routes segments, and other preferences. Similar to the priorities assigned to points along a route, as discussed above, priorities may be assigned to a determined route using a flag, an attribute, or other indicator associated with a point on the route. Further, a priority attribute may simply be a high or a low value (i.e., priority or no priority) or may be a scaled value between a high and a low value.
A block 1804 may assign priorities to the categories of routes. A block 1806 may determine what set of route categories for which to generate secondary routes. For example, where priority is high or low (e.g., 0 or 1), block 1806 may determine that only routes belonging to categories having a high priority may be processed. Alternatively, where priority is a scale value, for example a value from 1-5, block 1806 may simply determine a priority range such that only categories having a value higher than a threshold priority of 3 (e.g., priority range 3-5, 5 being highest) will be processed. Block 1808 may then determine a number of routes to generate or include for each category and subcategory. A total number of routes per category may be determined based on the priority of each category. For example, there may be a pre-determined limit on the number of routes for a priority of 1, a pre-determined limit on the number of routes for a priority of 2, etc. Alternatively, the number of routes for each category may have a constant limit (e.g., all priority 3 route categories are limited to two generated routes). Block 1810 may then generate or determine route information for each of the route categories of block 1806 up to a number of routes for each category as determined by block 1808.
The priorities and categories of blocks 1804-1806 and limits/thresholds of block 1808 may be adjusted or based, according to one embodiment, on a current system condition. The system condition may be a current processor load or a current bandwidth. For example, in a situation in which processor load is above a threshold and bandwidth is below a threshold, high priority assignments may be limited to fewer categories. Similarly, a priority range may be reduced to limit the amount of secondary routing data that is determined and processed. For example, where a priority range is limited to priorities above 3, the priority range may be changed to priorities above 4 when processor load is high and bandwidth is low.
In another embodiment, the number of secondary routes per category may be adjusted based on bandwidth and/or processor considerations. For example, an initial bandwidth or processor condition may allow two routes per category where only categories of a least distance return route, a fastest traffic route, and a scenic route are allowed. When conditions change where one or both of an increase in processor load over a threshold or bandwidth reduction below a threshold occurs, the number of routes per category may be limited to one. In addition, it may be determined that only least distance and fastest traffic routes will be processed.
Another system condition may be a current location of a client device. For example, the primary route from an origin or destination may have been determined at a prior time where the user is now located somewhere further along the route. In this case, additional secondary routes to points of interest, for example, that are close to the current location may be determined or the priority of these secondary routes may be increased. Additional priorities for other categories may be adjusted accordingly. Similarly, thresholds may be adjusted based on the current location as well.
According to another embodiment, access, transmission, or retrieval of map data (e.g., map data tiles) corresponding to the set of secondary routes may be performed in a sequence based on the priorities of the secondary routes. Generally, the sequence of access, transmission, or retrieval (e.g., of block 1410) may coincide with a sequence in which the secondary routes are determined and accessed (e.g., blocks 1406-1408). In cases in which the routes may be generated in a sequence that is not based on priority, the map data corresponding to the secondary routes may be accessed, transmitted, or retrieved based on priority and may be different from the order in which the routes are generated. This may be implemented using a buffer that collects the pre-fetch data tiles corresponding to the secondary routes and releases the set of pre-fetch map data tiles corresponding to the secondary routes in order of priority. In another embodiment, only map data tiles corresponding to a subset of the determined secondary routes may be accessed, transmitted, or retrieved. This subset may be determined based on the system conditions described above, such as processor load or current bandwidth. This embodiment may be beneficial in situations in which the processor load or bandwidth changes after the set of secondary routes have already been determined.
As discussed above, map data may be manipulated in a number of ways to effect a reduction in bandwidth usage and processor load, and effect an increase in response times. In addition, the priority and speed in which important high priority data is pre-fetched may enable a user computing device to provide off-line mapping support for times when the user computing device is not able to connect to a map server. In an embodiment, the method and system may determine map data (e.g., map data tiles) corresponding to a primary first route, and then determine one or more secondary routes for additional map data retrieval. According to another embodiment, the method and system may receive a first primary route and begin to prioritize data for pre-fetching based on the types of map data related to the route. At the same time or sequentially after this process, additional secondary routes may be generated and considered for pre-fetching as well. The amount of map data tiles required to render displays of the primary and secondary routes as well as the number and types of secondary routes may be adjusted based on a system condition (e.g., bandwidth or processor load) or user profile/preference information (including, e.g., usage patterns).
Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
For example, the network 25 may include but is not limited to any combination of a LAN, a MAN, a WAN, a mobile, a wired or wireless network, a private network, or a virtual private network. Moreover, while only four client devices are illustrated in
Additionally, certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term hardware should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware and software modules can provide information to, and receive information from, other hardware and/or software modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware or software modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware or software modules. In embodiments in which multiple hardware modules or software are configured or instantiated at different times, communications between such hardware or software modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware or software modules have access. For example, one hardware or software module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware or software module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware and software modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented hardware modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” or a “routine” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms, routines and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.
As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other. The embodiments are not limited in this context.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
Still further, the figures depict preferred embodiments of a map rendering system for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for rendering map or other types of images using the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.
The present application claims the benefit of U.S. Provisional Patent Application No. 61/569,634 filed Dec. 12, 2011, the disclosure of which is incorporated herein by reference in its entirety for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4984279 | Kidney et al. | Jan 1991 | A |
| 5345086 | Bertram | Sep 1994 | A |
| 5793310 | Watanabe et al. | Aug 1998 | A |
| 5848373 | DeLorme et al. | Dec 1998 | A |
| 6061688 | Kilpatrick et al. | May 2000 | A |
| 6073076 | Crowley et al. | Jun 2000 | A |
| 6094685 | Greenberg et al. | Jul 2000 | A |
| 6191782 | Mori et al. | Feb 2001 | B1 |
| 6199150 | Yoshikawa | Mar 2001 | B1 |
| 6330453 | Suzuki et al. | Dec 2001 | B1 |
| 6400690 | Liu et al. | Jun 2002 | B1 |
| 6442757 | Hancock et al. | Aug 2002 | B1 |
| 6453233 | Kato | Sep 2002 | B1 |
| 6546334 | Fukuchi et al. | Apr 2003 | B1 |
| 6571279 | Herz et al. | May 2003 | B1 |
| 6615131 | Rennard et al. | Sep 2003 | B1 |
| 6671424 | Skoll et al. | Dec 2003 | B1 |
| 6691128 | Natesan et al. | Feb 2004 | B2 |
| 6853911 | Sakarya | Feb 2005 | B1 |
| 6889134 | Nakane et al. | May 2005 | B2 |
| 7006820 | Parker et al. | Feb 2006 | B1 |
| 7050905 | Nemeth | May 2006 | B2 |
| 7136748 | Umezu et al. | Nov 2006 | B2 |
| 7263368 | Knauerhase et al. | Aug 2007 | B2 |
| 7315259 | Sacks | Jan 2008 | B2 |
| 7327349 | Robbins et al. | Feb 2008 | B2 |
| 7461528 | Taniguchi et al. | Dec 2008 | B2 |
| 7464109 | Modi | Dec 2008 | B2 |
| 7472172 | Anderson et al. | Dec 2008 | B2 |
| 7502780 | Thorpe | Mar 2009 | B2 |
| 7502876 | Nemirovsky et al. | Mar 2009 | B1 |
| 7529639 | Rasanen et al. | May 2009 | B2 |
| 7551182 | Bethune et al. | Jun 2009 | B2 |
| 7571422 | Adel et al. | Aug 2009 | B2 |
| 7577520 | Nomura | Aug 2009 | B2 |
| 7584434 | Okamura | Sep 2009 | B2 |
| 7610147 | Umezu et al. | Oct 2009 | B2 |
| 7663671 | Gallagher et al. | Feb 2010 | B2 |
| 7710421 | Muramatsu | May 2010 | B2 |
| 7711473 | Sekine et al. | May 2010 | B2 |
| 7734412 | Shi et al. | Jun 2010 | B2 |
| 7739037 | Sumizawa et al. | Jun 2010 | B2 |
| 7746343 | Charaniya et al. | Jun 2010 | B1 |
| 7796837 | Lueck | Sep 2010 | B2 |
| 7831383 | Oohashi | Nov 2010 | B2 |
| 7831387 | Golding et al. | Nov 2010 | B2 |
| 7839421 | Bethune et al. | Nov 2010 | B2 |
| RE41983 | Wallner | Dec 2010 | E |
| 7873465 | Geelen et al. | Jan 2011 | B2 |
| 7920968 | Chapin et al. | Apr 2011 | B2 |
| 7925624 | Vosshall et al. | Apr 2011 | B2 |
| 7925982 | Parker et al. | Apr 2011 | B2 |
| 7962565 | Coker | Jun 2011 | B2 |
| 7974959 | Sawai et al. | Jul 2011 | B2 |
| 7975025 | Szabo et al. | Jul 2011 | B1 |
| 7983659 | Shinya | Jul 2011 | B2 |
| 7996445 | Fair et al. | Aug 2011 | B2 |
| 8005612 | Asahara et al. | Aug 2011 | B2 |
| 8010407 | Santoro et al. | Aug 2011 | B1 |
| 8014796 | Boudreau et al. | Sep 2011 | B2 |
| 8014945 | Cooper et al. | Sep 2011 | B2 |
| 8032297 | Jakobson | Oct 2011 | B2 |
| 8060389 | Johnson | Nov 2011 | B2 |
| 8060406 | Blegen | Nov 2011 | B2 |
| 8060582 | Bliss et al. | Nov 2011 | B2 |
| 8078641 | Mao et al. | Dec 2011 | B2 |
| 8095307 | Ebert et al. | Jan 2012 | B2 |
| 8126885 | Prasad et al. | Feb 2012 | B2 |
| 8180851 | CaveLie | May 2012 | B1 |
| 8204966 | Mendis et al. | Jun 2012 | B1 |
| 8229914 | Ramer et al. | Jul 2012 | B2 |
| 8280414 | Nourse et al. | Oct 2012 | B1 |
| 8301371 | Sheha et al. | Oct 2012 | B2 |
| 8340898 | Currie et al. | Dec 2012 | B2 |
| 8361543 | Nielsen et al. | Jan 2013 | B2 |
| 8363065 | Scott et al. | Jan 2013 | B2 |
| 8385591 | Anguelov et al. | Feb 2013 | B1 |
| 8489332 | Tomobe et al. | Jul 2013 | B2 |
| 8489669 | Johnson | Jul 2013 | B2 |
| 8538685 | Johnson | Sep 2013 | B2 |
| 8543130 | Golds | Sep 2013 | B2 |
| 8549105 | Nourse et al. | Oct 2013 | B1 |
| 8683008 | CaveLie | Mar 2014 | B1 |
| 8711181 | Nourse et al. | Apr 2014 | B1 |
| 8803920 | Kalai et al. | Aug 2014 | B2 |
| 8805959 | Mendis et al. | Aug 2014 | B1 |
| 8812031 | CaveLie et al. | Aug 2014 | B2 |
| 20020067353 | Kenyon et al. | Jun 2002 | A1 |
| 20020133491 | Sim et al. | Sep 2002 | A1 |
| 20030187984 | Banavar et al. | Oct 2003 | A1 |
| 20040044752 | Hamaguchi et al. | Mar 2004 | A1 |
| 20040117108 | Nemeth | Jun 2004 | A1 |
| 20040203998 | Knauerhase et al. | Oct 2004 | A1 |
| 20040220730 | Chen et al. | Nov 2004 | A1 |
| 20050140524 | Kato et al. | Jun 2005 | A1 |
| 20050287509 | Mohler | Dec 2005 | A1 |
| 20060007022 | Endo et al. | Jan 2006 | A1 |
| 20060026170 | Kreitler et al. | Feb 2006 | A1 |
| 20060067224 | Ohara | Mar 2006 | A1 |
| 20060069749 | Herz et al. | Mar 2006 | A1 |
| 20060080032 | Cooper et al. | Apr 2006 | A1 |
| 20060106534 | Kawamata et al. | May 2006 | A1 |
| 20060195256 | Nakamura et al. | Aug 2006 | A1 |
| 20060277271 | Morse et al. | Dec 2006 | A1 |
| 20070050128 | Lee et al. | Mar 2007 | A1 |
| 20070080830 | Sacks | Apr 2007 | A1 |
| 20070143014 | Sekine et al. | Jun 2007 | A1 |
| 20070218891 | Cox | Sep 2007 | A1 |
| 20070242077 | Danan | Oct 2007 | A1 |
| 20070273558 | Smith et al. | Nov 2007 | A1 |
| 20070282621 | Altman et al. | Dec 2007 | A1 |
| 20070282915 | Vosshall et al. | Dec 2007 | A1 |
| 20080065329 | Wilcox et al. | Mar 2008 | A1 |
| 20080071988 | Schloter et al. | Mar 2008 | A1 |
| 20080082225 | Barrett | Apr 2008 | A1 |
| 20080086264 | Fisher | Apr 2008 | A1 |
| 20080102857 | Kim | May 2008 | A1 |
| 20080132249 | Hamilton | Jun 2008 | A1 |
| 20080154655 | Hartmann et al. | Jun 2008 | A1 |
| 20080177469 | Geelen et al. | Jul 2008 | A1 |
| 20080192053 | Howell et al. | Aug 2008 | A1 |
| 20080195311 | Karaoguz et al. | Aug 2008 | A1 |
| 20080214210 | Rasanen et al. | Sep 2008 | A1 |
| 20080215240 | Howard et al. | Sep 2008 | A1 |
| 20080238723 | Fein et al. | Oct 2008 | A1 |
| 20080270579 | Herz et al. | Oct 2008 | A1 |
| 20080291205 | Rasmussen et al. | Nov 2008 | A1 |
| 20090030778 | Zapata et al. | Jan 2009 | A1 |
| 20090054103 | Stavenow et al. | Feb 2009 | A1 |
| 20090063042 | Santesson et al. | Mar 2009 | A1 |
| 20090125228 | Dicke et al. | May 2009 | A1 |
| 20090128483 | Robbins et al. | May 2009 | A1 |
| 20090132163 | Ashley, Jr. et al. | May 2009 | A1 |
| 20090153563 | Tudose | Jun 2009 | A1 |
| 20090182500 | Dicke | Jul 2009 | A1 |
| 20090198767 | Jakobson et al. | Aug 2009 | A1 |
| 20090210388 | Elson et al. | Aug 2009 | A1 |
| 20090228211 | Rasanen et al. | Sep 2009 | A1 |
| 20090244095 | Bowman et al. | Oct 2009 | A1 |
| 20090281718 | Gibran et al. | Nov 2009 | A1 |
| 20090287750 | Banavar et al. | Nov 2009 | A1 |
| 20090319177 | Khosravy et al. | Dec 2009 | A1 |
| 20090319181 | Khosravy et al. | Dec 2009 | A1 |
| 20090319188 | Otto | Dec 2009 | A1 |
| 20090326810 | Callaghan et al. | Dec 2009 | A1 |
| 20100017129 | Wilcox et al. | Jan 2010 | A1 |
| 20100020091 | Rasmussen et al. | Jan 2010 | A1 |
| 20100106397 | Van Essen | Apr 2010 | A1 |
| 20100106801 | Bliss et al. | Apr 2010 | A1 |
| 20100117810 | Hagiwara et al. | May 2010 | A1 |
| 20100131186 | Geelen et al. | May 2010 | A1 |
| 20100153007 | Crowley | Jun 2010 | A1 |
| 20100174721 | Mou | Jul 2010 | A1 |
| 20100179940 | Gilder et al. | Jul 2010 | A1 |
| 20100182500 | Ishii et al. | Jul 2010 | A1 |
| 20100250646 | Dunagan et al. | Sep 2010 | A1 |
| 20100274899 | Shrivastava et al. | Oct 2010 | A1 |
| 20100321399 | Ellren et al. | Dec 2010 | A1 |
| 20100332120 | Tomobe et al. | Dec 2010 | A1 |
| 20100333085 | Criddle et al. | Dec 2010 | A1 |
| 20110054776 | Petrov et al. | Mar 2011 | A1 |
| 20110093515 | Albanese | Apr 2011 | A1 |
| 20110095993 | Zuverink | Apr 2011 | A1 |
| 20110098917 | LeBeau et al. | Apr 2011 | A1 |
| 20110098918 | Siliski et al. | Apr 2011 | A1 |
| 20110130949 | Arrasvuori | Jun 2011 | A1 |
| 20110161875 | Kankainen | Jun 2011 | A1 |
| 20110213798 | Osuka et al. | Sep 2011 | A1 |
| 20110276263 | Shimotani et al. | Nov 2011 | A1 |
| 20110300848 | Boudreau et al. | Dec 2011 | A1 |
| 20110307648 | Nomura | Dec 2011 | A1 |
| 20110316854 | Vandrovec | Dec 2011 | A1 |
| 20120005290 | Cooper et al. | Jan 2012 | A1 |
| 20120022786 | Siliski et al. | Jan 2012 | A1 |
| 20120022787 | LeBeau et al. | Jan 2012 | A1 |
| 20120038662 | Dicklin et al. | Feb 2012 | A1 |
| 20120083995 | Vorona | Apr 2012 | A1 |
| 20120146809 | Oh et al. | Jun 2012 | A1 |
| 20120221239 | Cooper et al. | Aug 2012 | A1 |
| 20120253488 | Shaw et al. | Oct 2012 | A1 |
| 20120254804 | Sheha et al. | Oct 2012 | A1 |
| 20130097197 | Rincover et al. | Apr 2013 | A1 |
| 20130147846 | Kalai et al. | Jun 2013 | A1 |
| 20130325307 | Agarwal et al. | Dec 2013 | A1 |
| 20140073358 | Sridhar et al. | Mar 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 288 622 | Mar 2003 | EP |
| 10-2008-071228 | Aug 2008 | KR |
| WO-9828714 | Jul 1998 | WO |
| WO-2009027161 | Mar 2009 | WO |
| Entry |
|---|
| Descampe et al., “Data Prefetching for Smooth Navigation of Large Scale JPEG 2000 Images,” IEEE, Multimedia and Expo, pp. 1-4 (2005). |
| International Preliminary Report on Patentability for Application No. PCT/US2012/051564, dated Apr. 1, 2014. |
| Weber et al., “Mobile Map Browers: Anticipated User Interaction for Data Pre-Fetching,” University of Maine, 101 pages (2010). |
| Kirchner et al. “A Location-aware Prefetching Mechanism,” Project work at Distributed Information Systems Laboratory LSIR (2004). |
| Molina, “Aiming and Guiding Navigation with a Non-visual GPS Application,” Department of Design Sciences Faculty of Engineering, Lund University (2010). |
| Office action for U.S. Appl. No. 13/244,717 dated Nov. 15, 2011. |
| Office action for U.S. Appl. No. 13/244,764 dated Nov. 28, 2011. |
| Piras et al., “Compact GML: merging mobile computing and mobile cartography,” CRS4, Center for Advanced Studies, Research and Development in Sardinia (2004). |
| Reichenbacher et al., “The World in Your Pocket—Towards a Mobile Cartography,” Proc. of the 20th International Cartographic Conference (2001). |
| Weber, “Mobile Map Browsers: Anticipated User Interaction for Data Pre-Fetching,” Thesis, The University of Maine, (2010). |
| Google Developers, “Google Maps API,” (2012). Retrieved from the Internet on Aug. 31, 2012: URL:https://developers.google.com/maps/. |
| International Search Report and Written Opinion for Application No. PCT/US2012/051574, dated Feb. 15, 2013. |
| International Search Report and Written Opinion for Application No. PCT/US2012/051577, dated Feb. 15, 2013. |
| International Search Report and Written Opinion for Application No. PCT/US2012/065002, dated Mar. 29, 2013. |
| International Search Report and Written Opinion for Application No. PCT/US2012/065008, dated Mar. 29, 2013. |
| International Search Report for Application No. PCT/US2012/051564, dated Feb. 18, 2013. |
| Mapquest, “JavaScript Maps API,” (2012). Retrieved from the Internet on Aug. 31, 2012: URL:http://developer.mapquest.com/web/products/featured/javascript. |
| MSDN, “Get Started Using Bing Maps,” (2012). Retrieved from the Internet on Aug. 31, 2012: URL:http://msdn.microsoft.com/en-us/library/dd877180.aspx. |
| Wiki, “API,” (2012). Retrieved from the Internet on Aug. 31, 2012: URL:http://wiki.openstreetmap.org/wiki/API. |
| International Preliminary Report on Patentability for Application No. PCT/US2012/065008, dated Jun. 10, 2014. |
| International Preliminary Report on Patentability for Application No. PCT/US2012/065002, dated May 20, 2014. |
| International Preliminary Report on Patentability for Application No. PCT/US2012/051574, dated Jun. 17, 2014. |
| International Preliminary Report on Patentability for Application No. PCT/US2012/051577, dated Jun. 17, 2014. |
| Extended European Search Report for Application No. 12855169.4, dated Mar. 23, 2015. |
| Magdalene et al., “Cache Prefetch and Replacement with Dual Valid Scopes for Location Dependent Data in Mobile Environments,” Proceedings of the 11th International Conference on Information Integration and Web-Based Applications & Services, pp. 364-371 (2009). |
| Ren et al., “Using Semantic Caching to Manage Location Dependent Data in Mobile Computing,” Proceedings of the Annual International Conference on Mobile Computing and Networking, pp. 210-221 (2000). |
| Extended European Search Report for Application No. 12857463.9, dated May 22, 2015. |
| Number | Date | Country | |
|---|---|---|---|
| 20130147820 A1 | Jun 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61569634 | Dec 2011 | US |
