Method and system for route planning

Abstract

This disclosure relates to providing basic navigation guidance. In some embodiments, the computing device may proactively determine a destination and request traffic information for the route from the starting point to that destination. In some embodiments, the computing device may identify some routes between the starting point and the destination as non-recommended routes and recommend other routes. In some embodiments, the computing device may rank routes between the starting point and the destination based on automatically determined user interests. In some embodiments, the computing device may determine routes that the user is familiar with and adjust the information presented to the user about those routes accordingly.

Description

[0001] This application is a divisional application of the invention patent application with the international filing date of May 25, 2018, which entered the Chinese national phase on November 26, 2019, with Chinese national application number 201880034657.6 and the invention title "Providing Optical Navigation Guidance". Technical Field

[0002] This disclosure generally relates to acquiring and displaying map and route planning data on a device. Background Technology

[0003] Mobile devices such as smartphones, tablets, smartwatches, and other computing devices typically include applications that provide interfaces allowing users to utilize services from network service providers. Examples of such applications and / or services are map and / or navigation applications and / or services (e.g., Apple Maps). For instance, when a user uses a map application on a mobile device, the map application can use a network connection (e.g., an internet connection) to obtain map data (e.g., map imagery, navigation data, estimated travel times, ETAs, traffic conditions, etc.) from a map service. The map application can then use the map data received from the map service to provide the user with various map-related services. For example, the map application can notify the user when there is traffic or an incident on the route between the user's location and destination. However, users familiar with routes may not always check the map application before starting their journey, and the map application may not always plan routes for the user in a way that avoids traffic events in a manner suitable for the user's specific needs. Summary of the Invention

[0004] In some implementations, the computing device can proactively determine the destination and request traffic information for the route from the starting point to that destination. In some implementations, the computing device can identify certain routes between the starting point and the destination as non-recommended routes and recommend other routes. In some implementations, the computing device can rank routes between the starting point and the destination based on automatically determined user interests. In some implementations, the computing device can determine routes familiar to the user and adjust the information presented about those routes accordingly.

[0005] Specific implementations offer at least the following advantages: Based on location data automatically collected by the device, the device can determine its destination and proactively request traffic information for those locations from a server. Even if the user does not have a map application open, the device can proactively notify the user of abnormal traffic conditions. The device can receive and store recommended route information from the server to improve the efficiency of future traffic information requests. The server can identify non-recommended routes based on traffic conditions, so the device can suggest and replan routes when non-recommended routes exist. The device can rank possible routes based on the location data collected by the device, taking into account the anticipated user interest in these routes. The device can determine how familiar the user is with reaching their destination and present navigation information tailored to users familiar with those routes (e.g., smaller-scale information). This tailored navigation information can be presented even if the user does not have a map application open. Users may be able to switch between smaller-scale and full-scale information within the map application.

[0006] Details of one or more specific embodiments are set forth in the following figures and detailed descriptions. Other features, aspects, and potential advantages will become apparent from the detailed descriptions, the figures, and the claims. Attached Figure Description

[0007] Figure 1 This is a block diagram of an exemplary system for acquiring and displaying map and route planning data.

[0008] Figure 2A An exemplary map is shown, on which the locations of the route planning are marked.

[0009] Figures 2B to 2G An exemplary map is shown, on which routes between planned locations are marked.

[0010] Figure 3 An exemplary ladder diagram is shown for route evaluation performed by user equipment and server equipment.

[0011] Figures 4A to 4B An example notification indicating a non-recommended route is shown.

[0012] Figure 5 An exemplary map navigation interface is shown.

[0013] Figure 6A An exemplary location process is shown.

[0014] Figure 6B An exemplary location process superimposed on the road is shown.

[0015] Figure 6C An example route is shown.

[0016] Figures 7A to 7O An exemplary map navigation interface with mild guidance features is shown.

[0017] Figure 8 This is a flowchart of an exemplary process for proactively requesting route planning information.

[0018] Figure 9 This is a flowchart of an exemplary process for identifying routes, evaluating them, and identifying alternatives.

[0019] Figure 10 This is a flowchart of an exemplary process for ranking routes.

[0020] Figure 11 This is a flowchart of an exemplary process for evaluating a preferred route.

[0021] Figure 12 This is a flowchart of an exemplary process for launching a map application in light-boot mode.

[0022] Figure 13 It is achievable. Figures 1 to 12 A block diagram of an exemplary computing device illustrating its features and processes.

[0023] Similar reference symbols in the various figures indicate similar elements. Detailed Implementation

[0024] Overview

[0025] Figure 1 This is a block diagram of an exemplary system 100 for acquiring and displaying map and route planning data. For example, system 100 may include a map application that allows users to view maps, search maps, select locations on maps, view directions between locations on maps, receive navigation instructions, and / or perform other tasks. The map application may be installed on a computing device and may obtain map information from a server device via a network connection.

[0026] In some implementations, system 100 may be configured to proactively determine locations where the user frequently commutes and / or routes the user frequently travels. For example, in the disclosed implementation, system 100 may automatically perform proactive determination without user input before system 100 anticipates that the user may be interested in commuting data for locations and / or routes. Given current traffic conditions, system 100 may determine when the user should depart to reach a certain location. System 100 may inform the user of problems with the route. System 100 may determine when frequently used routes should not be recommended and identify alternatives based on traffic conditions. For example, a direct highway route between locations may experience unusually congested traffic and delays due to an accident. Accidents and traffic congestion may add enough time to the route that alternative routes (e.g., routes that primarily use surface roads) may be significantly faster. When the user is familiar with the route, system 100 may provide the user with a smaller range of navigation information. For example, system 100 may provide suggestions for deviating from the route to avoid traffic problems instead of full turn-by-turn navigation.

[0027] In some implementations, alerts and / or alternative routes can be identified and / or presented even if the user does not request route planning or navigation information. Therefore, alerts and / or alternative routes can be presented when the user is expected to travel along one or more non-recommended routes.

[0028] In some implementations, system 100 may include server device 102. For example, server device 102 may represent a computing device or multiple computing devices associated with a map service provider. The map service provider may provide data such as map information, navigation information, and / or information about points of interest. Server device 102 may correspond to a well-known server hardware architecture and include a processor for performing operations such as providing map services such as route planning and notification services as described herein.

[0029] In some implementations, server device 102 may include map service 104. For example, map service 104 may be executed by a software server that provides backend processing for map service providers. Map service 104 may obtain map data (e.g., map images, points of interest, etc.) from map data database 106, and send the map data to various client devices (e.g., user device 130), enabling the client devices to present maps to their users. Map service 104 may use map data and other data (e.g., real-time traffic data) in map data database 106 to determine navigation and / or route planning information, and send the navigation and / or route planning information to client devices (e.g., user device 130), enabling the client devices to present navigation information to their users. In some implementations, map service 104 may also send offline map data from map data database 106 to allow user device 130 to provide some map functionality when user device 130 is offline. For example, map service 104 may send map data to client devices when the client devices are connected to server device 102 via network 150 (e.g., the Internet). Client devices can use map or navigation applications on the client device to present map and / or navigation data to users. The data can be presented through the application's graphical user interface (UI) and / or through notifications that may pop up on the client device's home screen and / or during operation of other applications.

[0030] In some implementations, map service 104 may provide traffic and / or route planning data to user device 130. For example, map service 104 may provide traffic and / or route planning data in response to proactive automated traffic (e.g., automated requests without user input) and / or route planning data requests or user-initiated requests.

[0031] In some implementations, system 100 may include user equipment 130. For example, user equipment 130 may be a mobile device, such as a smartphone, tablet, laptop, smartwatch, or other computing device. In some implementations, user equipment 130 may include and / or be configured to work with an in-vehicle computer system (e.g., Apple CarPlay and / or an in-vehicle navigation and / or entertainment unit).

[0032] In some implementations, user device 130 may include map application 134. For example, map application 134 may be a client application of map service 104. Map application 134 may request map data from map service 104. Map service 104 may send map data to map application 134 via network 120.

[0033] In some implementations, user equipment 130 may include a route planning module 132. Route planning module 132 may be a component of map application 134 or a separate application. Route planning module 132 may automatically or in response to user input generate route planning requests 110. Some route planning requests 110 may specify the start and end points of the requested route. Some route planning requests 110 may specify a route and request traffic information for the specified route. User equipment 130 may send route planning requests 110 to server equipment 102 via network 150. Server equipment 102 may respond by sending route planning data 120 to user equipment 130 via network 150. Route planning data 120 may include one or more routes and / or traffic data for one or more routes.

[0034] In some implementations, user equipment 130 may store data in map data database 136. For example, when user equipment 130 receives route planning data 120 from map service 104 and / or other data from map service 104 (e.g., historical speed and / or traffic data of the route, as discussed below), map application 134 may store route planning data 120 and / or other data in map data database 136. Map application 134 can then use the data stored in map data database 136 to provide map-related services, such as notifications and / or navigation assistance.

[0035] In some implementations, user equipment 130 may include a location module 138. The location module 138 can determine the location of user equipment 130. For example, the location module 138 can determine the location of user equipment 130 using data collected by a Global Positioning System (GPS) receiver and / or a Wi-Fi receiver of user equipment 130. The location module 138 can determine the location of user equipment 130 periodically and / or in response to a request from another module. For example, a map application 134 can request the location of user equipment 130 and display the location of user equipment 130 on a map GUI.

[0036] In some implementations, user equipment 130 may include a data collection module 140. The data collection module 140 may monitor data generated and / or received by user equipment 130. The data collection module 140 may store at least a portion of the monitored data and / or generate metadata describing at least a portion of the monitored data.

[0037] For example, data collection module 140 can monitor location data generated by location module 138. By monitoring this data, data collection module 140 can determine the relevant locations of the user of user device 130. Relevant locations may include places the user frequently visits and / or places the user plans to visit. For example, if location module 138 reports that user device 130 is in a specific location almost every evening between 10 p.m. and 6 a.m., data collection module 140 can determine based on this pattern that the specific location is the user's home. If location module 138 reports that user device 130 is in a specific location between 9 a.m. and 5 p.m. every weekday, data collection module 140 can determine based on this pattern that the specific location is the user's workplace or school. If location module 138 reports that user device 130 frequently visits certain locations for extended periods, data collection module 140 can determine that these are locations the user may be interested in revisiting (e.g., favorite restaurants, bars, shops, or other businesses; the homes of acquaintances; etc.). In some implementations, the data collection module 140 may perform monitoring in accordance with the teachings of U.S. Patent 9,615,202, the entire contents of which are incorporated herein by reference.

[0038] For example, the data collection module 140 can monitor data input by the user. The user can interact with applications on the user device 130, including map application 134 and other applications not shown. For instance, the user can use map application 134 to search for restaurants and hotels in a specific area. The user can use a calendar application to schedule meetings at specific locations. The user can use a web browser application or other applications to book travel and dining. The user can receive booking confirmations in an email application. These actions can cause the user device 130 to generate data indicating one or more locations (e.g., the location of a meeting, a travel destination, a booked restaurant, etc.). By monitoring this data, the data collection module 140 can determine that these one or more locations may be relevant locations for the user of the user device 130.

[0039] In some implementations, user equipment 130 may explicitly define a location as a relevant location. For example, a user may be able to use a GUI to define a specific location as their home, office, school, or other notable location. User equipment 130 may store data describing the defined relevant location in a collected data database 142. For example, the stored data may include location coordinates (e.g., latitude and longitude), location name (e.g., a user-specified name and / or a generic name, such as a business name), and / or location address.

[0040] In some implementations, user equipment 130 may store the collected data in a collected data database 142. For example, data collection module 140 may store at least a portion of monitoring data indicating locations visited by the user or locations the user may visit, and / or data describing the monitoring data, in the collected data database 142 (e.g., addresses and / or coordinates describing the monitoring data without including details such as the nature of the location (home, school, restaurant, etc.)). The stored data may describe a set of potentially relevant locations. Therefore, the collected data database 142 may store data indicating one or more potentially relevant locations. For example, the stored data may include location coordinates (e.g., latitude and longitude), location names, and / or location addresses.

[0041] In some implementations, the data collection module 140 can monitor not only the relevant location but also the time when the user device 130 frequently travels to the relevant location. For example, the data collection module 140 can identify the location of the home (through data collection or user input) and the time when the user device 130 arrives at the home location each day. In many cases, users may arrive home, at work, or at school at the same or nearly the same time each day. The data collection module 140 can store records of the user's daily arrival time at home and / or the average arrival time over several days in the collected data database 142.

[0042] In some embodiments, the data collection module 140 can monitor not only relevant locations but also routes frequently traveled by the user device 130 between relevant locations. For example, the location module 138 can periodically determine the location of the user device 130. When the user device 130 leaves a relevant location (e.g., home), the data collection module 140 can collect data from the location module 138. When the user device arrives at another relevant location (e.g., workplace), the data collection module 140 can store records of the locations determined by the location module 138 during the time the user device 130 moves between home and workplace. In some embodiments, the data collection module 140 can use the method disclosed in U.S. Patent Application 13 / 773,866 (published as U.S. Patent Publication 2013 / 0166208), the entire contents of which are incorporated herein by reference.

[0043] System 100 is shown as including server device 102 and user device 130, each of which further includes several discrete components (e.g., map service 104 and map data database 106 of server device 102; route planning module 132, map application 134, map data database 136, location module 138, data collection module 140, and collected data database 142 of user device 130). In some embodiments, components within the respective devices (server device 102 and user device 130) may be combined or separated. For example, some components of user device 130 may be sub-components of a single map component or operating system component. In some embodiments, map data database 136 and collected data database 142 may be part of a single memory system of user device 130. In some embodiments, the functions of the various components may be further divided and processed by separate components not shown (e.g., the functions of location module 138 may be performed by separate GPS and WiFi modules, etc.).

[0044] Route planning example

[0045] Figures 2A to 2G Several views of map 200 are shown, which has route planning locations 204A and 204B and several alternative routes 206A to 206F between route planning locations 204A and 204B. These examples illustrate how route planning module 132 and map service 104 can use data determined by data collection module 140 and real-time traffic data (e.g., data determined by map service 104 or a traffic service describing real-time or near-real-time traffic conditions) to identify recommended and / or non-recommended routes, prioritize routes to be displayed to the user, and provide information about the routes. Routes 206A to 206F will be used as examples throughout this specification; however, map application 132 and / or map service 104 may generate different routes or alternative routes based on user behavior and / or needs.

[0046] Figure 2A An exemplary map 200 is shown, marked with route planning locations 204A and 204B. Map 200 presents an exemplary area with multiple roads between route planning locations 204A and 204B. In some embodiments, map application 134 may display map 200 on the display of user device 130. For ease of visualization, map 200 is represented only by the main highway 201 and main surface streets 202 shown. However, in some embodiments, other features such as smaller roads, bodies of water, commercial areas, landmarks, etc., may be presented on map 200.

[0047] Route planning locations 204A and 204B can be determined by data collection module 140. The route planning locations 204A and 204B determined by data collection module 140 can be locations where user device 130 is typically located for extended periods. For example, one route planning location 204A could be the user's home, and the other route planning location 204B could be the user's office. In some implementations, data collection module 140 can identify other route planning locations, such as the user's school, favorite restaurant or bar, a friend's or family member's home, etc. In some implementations, the route planning locations can be user-specified. For example, the user can specify the location of their home 204A and / or their office 204B.

[0048] In some implementations, route planning locations 204A and 204B can be determined based on the time of day. For example, data collection module 140 can determine the location of home and office as described above. Data collection module 140 can also determine when a user is likely to be traveling to their home or office location based on movement or travel patterns that indicate the user is likely to be home, going to the office, or going to another location at or near a specific time of day.

[0049] In some implementations, route planning locations 204A and / or 204B can be determined based on the current location of user device 130. For example, if the user is at their workplace (e.g., current location) at 6 PM, data collection module 140 can determine that the user typically travels from their workplace to their home at 6 PM, and determine that location 204A (e.g., starting location) corresponds to the workplace, and location 204B (e.g., destination location) corresponds to the home location. However, if user device 130 is at their home location at 6 PM, data collection module 140 can determine that the user will not travel from their workplace to their home, but rather from their home (e.g., location 204A) to the gym (e.g., location 204B) for their evening workout. Therefore, locations 204A and / or 204B can be determined based on the time of day and / or the current location of user device 130.

[0050] In some implementations, the route planning location can be defined in response to a user request for route planning information. For example, a user can interact with a map application 134 to define a start and end point for route planning. The start point can be the current location of the user device 130 determined by the location module 138 or a location selected by the user (e.g., an address, coordinates, or a predefined location, such as a predefined home location). The end point can be a location selected by the user (e.g., an address, coordinates, or a predefined location, such as a predefined home location).

[0051] Figures 2B to 2GAn exemplary map is shown, on which the route planning locations 204A and 204B are marked. For example, Figure 2B Route 206A is shown, which is the most direct route between locations 204A and 204B, which are mainly highways. Figure 2C and Figure 2D Routes 206B and 206C are shown respectively; they are routes that deviate from part of route 206A onto the ground road. Figure 2E and Figure 2F Routes 206D and 206E are shown respectively; they are alternative routes between the main highway route planning locations 204A and 204B. Figure 2G Route 206F is shown. Route 206F is a direct route between route planning locations 204A and 204B, but it is a route entirely located on ground roads.

[0052] Non-recommended route

[0053] In some implementations, route planning module 132 and map service 104 can evaluate one or more routes between locations to determine if any routes should not be recommended, and provide alerts and / or alternatives. For example, in Figures 2A to 2G In the context of the route planning, several logical and / or commonly used routes 206A to 206F may exist between route planning locations 204A and 204B. However, due to traffic conditions and / or events, it may sometimes take significantly longer than usual to traverse one or more routes 206A to 206F. When a route is predicted to experience significant delays, map service 104 can determine that the route is a non-recommended route. When map service 104 identifies one or more non-recommended routes, route planning module 132 can cause user device 130 to display alerts and / or alternative routes. These alerts and / or alternative routes can be determined and / or presented even if the user has not yet requested route planning or navigation information (e.g., through map application 134). Therefore, alerts and / or alternative routes can be presented when the user is expected to travel along one or more non-recommended routes.

[0054] Figure 3An exemplary ladder diagram 300 is shown for route evaluation performed by user device 130 and server device 102. User device 130 and server device 102 can perform route evaluation to identify non-recommended routes between route planning locations 204A and 204B. User device 130 and server device 102 can perform route evaluation proactively (e.g., based on observed user behavior anticipating that a user will travel between locations 204A and 204B) and / or in response to a user request. First, user device 130 and server device 102 can identify one or more recommended routes. Recommended routes may be routes expected to be the fastest under free-flow traffic conditions (e.g., traffic speeds at least at speed limits) or typical traffic conditions (e.g., historical average traffic conditions for a given time and date). After establishing one or more recommended routes, user device 130 and server device 102 can determine whether one or more of the recommended routes are non-recommended routes due to traffic problems (such as heavy traffic, road closures, accidents, weather conditions, etc.). If any non-recommended route is found, user device 130 and server device 102 may provide the user with a notification and / or recommend alternative routes.

[0055] To initiate a route assessment, in operation 305, the route planning module 132 of user device 130 may query the map service 104 of server device 102 for a route between locations 204A and 204B. In some implementations, the route planning module 132 may automatically query the map service 104 without user command. For example, data collected by the data collection module 140 may indicate that the user typically departs for their office at approximately 8:30 AM and arrives at approximately 9:00 AM. Therefore, the route planning module 132 may query the map service 104 before 8:30 AM. In some implementations, the route planning module 132 may specify a target departure time and begin querying the map service 104 within a commute window prior to the target departure time. For example, the route planning module 132 may attempt to query the map service 104 at 15-minute intervals, starting 60 minutes before the target departure time. In the example where the user departs at 8:30 AM, the route planning module 132 may begin attempting to query at 7:30 AM. In some implementations, the route planning module 132 may query the map service 104 in response to a user command requesting route planning information between locations 204A and 204B.

[0056] In some implementations, to conserve battery power of user equipment 130, route planning module 132 may query map service 104 only when user equipment 130 is operating in active mode, not in low-power mode. For example, route planning module 132 may have a target query time (e.g., a time determined by user equipment 130 prior to the expected user departure time, such as one hour before the average departure time of user equipment 130). Route planning module 132 may define a window of a few minutes before and after the target query time during which it may opportunistically send queries. For example, this window may begin 5 minutes before the target query time and end 5 minutes after the target query time. Therefore, if user equipment 130 is plugged in 5 minutes before the target query time, route planning module 132 may query map service 104 at the start of the window. If user device 130 wakes up from low-power mode within a window (e.g., due to user interaction or other scheduled tasks), route planning module 132 can query map service 104 when user device 130 wakes up (e.g., when user device 130 is active due to an active display, an unlocked input device, effective use of one or more radio components for WiFi, GPS, or cellular communication, etc.).

[0057] When route planning module 132 first generates query 302 for a given set of route planning locations 204A and 204B, at operation 305, route planning module 132 can send data describing route planning locations 204A and 204B to map service 104. For example, route planning module 132 can send the latitude and longitude coordinates of each route planning location 204A and 204B, or route planning module 132 can send the street address of each route planning location 204A and 204B.

[0058] Map service 104 can identify one or more potential recommended routes 306. For example, map data database 106 can store free-flow traffic data and historical traffic data for some or all roads between route planning locations 204A and 204B. Map service 104 can identify the fastest route between route planning locations 204A and 204B under free-flow conditions. For example, in some implementations, map service 104 can identify three fastest routes. In some implementations, map service 104 can designate the fastest route under free-flow conditions as a potential recommended route 306.

[0059] Map service 104 can examine historical traffic data for the identified routes to determine if any routes are expected to be slower than they are typically queried. For example, route 206A (in...) Figure 2BRoute 204A is the most direct highway route between route planning locations 204A and 204B. However, in an exemplary scenario, route 206A may be fully loaded during peak hours, and the average traffic speed may drop from a free-flow speed of 65 mph along route 206A to 25 mph along route 206A. Map data database 106 may store historical data indicating slower traffic speeds during peak hours (e.g., a few hours between 3:30 p.m. and 6:30 p.m.). In some implementations, map service 104 may identify the fastest route between route planning locations 204A and 204B under historical conditions associated with the query time and date (e.g., 4:30 p.m. on Thursday). For example, in some implementations, map service 104 may use historical data from the query time and date to identify three fastest routes. In some implementations, map service 104 may designate the fastest route under the relevant historical conditions as a potential recommended route 306. For example, map service 103 can identify routes 206A, 206B, and 206D as potential recommended routes.

[0060] Map service 104 may evaluate potential recommended routes 306 to determine whether any of these routes should not be recommended due to current traffic problems or because traffic is congested at the current time of day and / or on this day of the week. For example, map service 104 may receive real-time traffic updates from one or more traffic data reporting services. Map service 104 may determine, based on the real-time traffic updates, whether any potential recommended routes 306 are slower than expected. For example, map service 104 may compare the time required to cross the route under current traffic conditions with the free-flow time or historical time used to cross the route. If the current time to cross the route is longer than the free-flow or historical time compared to it (for the current time of day and / or on this day of the week) by a certain threshold amount, map service 104 may determine that the route is a non-recommended route that should not be recommended. For example, the threshold amount may be a percentage (e.g., if the route will take 10% longer than expected, it is not recommended) or a time (e.g., if the route will take more than 10 minutes longer than expected, it is not recommended). In some implementations, map service 104 may designate up to three non-recommended routes. For example, map service 104 may determine that route 206A should not be recommended because the accident has doubled the time required to cross route 206A. Map service 104 may determine that route 206D should not be recommended because congested traffic has increased the time required to cross route 206D by 20 minutes. Map service 104 may designate routes 206A and 206D as unrecommended routes.

[0061] After evaluating all potential recommended routes 306, map service 104 can provide evaluation results 308 to route planning module 132. For example, if one or more non-recommended routes are found, evaluation result 308 can indicate which routes are not recommended. If map service 104 does not find any non-recommended routes, evaluation result 308 can indicate that there are no significant traffic problems on any of the potential recommended routes 306.

[0062] When one or more non-recommended routes exist, map service 104 may provide one or more alternative routes in evaluation result 308. To determine alternative routes, map service 104 may discard non-recommended routes and evaluate one or more routes between route planning locations 204A and 204B that are not non-recommended routes for the current real-time traffic conditions. In some specific implementations, map service 104 may determine up to two alternative routes and evaluate each of the two routes for the current real-time traffic conditions. Continuing with the example in paragraph

[0056] above, map service 104 may discard non-recommended routes 206A and 206D and identify routes 206E and 206F as alternatives. Map service 104 may also evaluate route 206C but finds the impact of the same incident on its affected route 206A and therefore does not select it as an alternative route.

[0063] In some cases, map service 104 may look for alternative routes, but find no routes faster than the non-recommended routes. For example, potential recommended routes 206A, 206B, and 206D may all be non-recommended routes due to traffic conditions. Map service 104 may evaluate routes 206C, 206E, and 206F, but determines that none of these routes will take less time than at least one of the non-recommended routes 206A, 206B, and 206D. Therefore, the evaluation result 308 may indicate that the best available route is the non-recommended route.

[0064] The aforementioned processing can be performed when route planning module 132 first requests route planning information between specific route planning locations (e.g., route planning locations 204A and 204B), but this processing can be simplified for future queries 304 involving the same route planning locations. For example, route planning module 132 can store potential routes 306 from map service 104 in map data database 136. In subsequent queries 304 for route planning information between the same locations 204A and 204B, route planning module 132 can send the stored potential routes 306 to map service 104. Map service 104 can evaluate the sent potential routes 310 without having to determine them based on route planning locations 204A and 204B as in the first query 302. Therefore, after performing less processing than in the first query 302, map service 104 can return an evaluation result 312 (e.g., one or more non-recommended routes or indications of no problems).

[0065] Because the first step is skipped (e.g., operations 305-308), map service 104 experiences a significantly reduced processing load (e.g., a 25% improvement) for future queries 304 compared to the first query 302. Since user device 130 may frequently query the same location (e.g., because the user may commute between the same locations daily), this simplification can provide substantial performance improvements for server device 102 over time.

[0066] In some implementations, the route planning module 132 may timestamp potential routes 306 when storing them in the map data database 136. For example, when the route planning module 132 receives a potential route 306, it may store the time of receipt of the potential route 306 in the database 136 in association with the potential route 306 (e.g., as metadata, within the same record, etc.). After a certain amount of time has elapsed since the potential routes 306 were stored (e.g., 1 day, 5 days, 2 weeks, etc.), the route planning module 132 may determine that the potential routes 306 are too old to be effective. For example, new traffic patterns and / or new routes may be available for route planning between locations 204A and 204B. Therefore, after a threshold time period since the potential routes 306 were stored in the database 136 (as determined based on the timestamp of each potential route 306), the route planning module 132 may delete the old potential routes 306 from memory. When the route planning module 132 queries the map service 104 for route planning information between route planning locations 204A and 204B, the route planning module 132 can resend the data describing the route planning locations 204A and 204B and repeat the entire process.

[0067] User device 130 can use the evaluation results 308 to provide information to the user. For example, map application 134 can generate notifications to present to the user. Figures 4A to 4B An exemplary notification indicating a non-recommended route is shown. When the evaluation result 308 includes both a non-recommended route and an alternative route, the user device 130 may display... Figure 4A The non-recommended route notification 400. In this example, the starting location is the current location of the user device 130, the ending location is home (e.g., a user-defined or automatically determined home location), and the two possible routes between the current location and home are route 101 and route 280 (where the non-recommended route is route 101, and the alternative route is route 280). The map application 134 can generate a title string 402 for the non-recommended route notification 400 by inserting text describing the problem of the non-recommended route (“traffic congestion”) and text describing the destination (“home”). The map application 134 can generate a detail string 404 for the non-recommended route notification 400 by inserting text describing the alternative route (suggested road name, e.g., “280”), text describing the event type (“traffic congestion”), and text describing the non-recommended route (non-recommended road name, e.g., “101”).

[0068] When evaluation result 308 only includes non-recommended routes, user equipment 130 can display... Figure 4B The unrecommended route notification 450. In this example, the starting location is the current location of the user device 130, the ending location is home (e.g., a user-defined or automatically determined home location), and the unrecommended route is route 280. The map application 134 can generate a title string 452 for the unrecommended route notification 450 by inserting text describing the problem of the unrecommended route (“traffic congestion”) and text describing the destination (“home”). The map application 134 can generate a detail string 454 for the unrecommended route notification 450 by inserting a message related to the event type (“expected delay”).

[0069] If the evaluation result 308 does not include non-recommended routes, the map application 134 may not generate a notification.

[0070] Users can choose to receive a notification (e.g., tap the notification) to view more details about evaluation result 308. Figure 5An exemplary map navigation GUI 500 is illustrated. A non-recommended route notification 400 or 450 may appear, for example, on the home screen or lock screen of user device 130 or pop up on the currently active application. The user can select the non-recommended route notification 400 or 450, causing user device 130 to switch to a map application 134 (e.g., Apple Maps). The map application GUI 500 may display a map 502 including the origin and destination, along with information related to the evaluation results 308 displayed on it. For example, the evaluation result 308 that triggers the non-recommended route notification 400 includes both the non-recommended route and alternative routes. Map 502 may display the alternative routes. In some implementations, the alternative route may be marked as an alternative route, colored differently from the non-recommended route, or otherwise visually represented as an alternative route. The evaluation result 308 that triggers the non-recommended route notification 450 includes only the non-recommended route. Map 502 may display the non-recommended route, including locations where traffic events caused deceleration.

[0071] In some implementations, user equipment 150 may locally cache and / or otherwise store a subset of notifications and / or notification data. For example, a single event may cause traffic problems on a route for several consecutive days (e.g., road closures due to construction or some other long-term issue). After the event first occurs, the user may become aware of it, but may no longer need notifications because the user may understand that the event is inherently long-term. User equipment 150 may store notification data such that if multiple notifications describing the same event on the same route are received, user equipment 150 can avoid displaying multiple notifications.

[0072] As described above, the evaluation result 308 can provide information about non-recommended routes, and the user device 150 can present a notification about the non-recommended routes. The evaluation result 308 may include information about the non-recommended routes, such as a destination ID and an event ID. The destination ID uniquely indicates the destination of the route. The event ID uniquely indicates an event. For example, the map service 104 may generate event IDs and / or an event reporting service that can communicate with the map service 104 to receive event data may receive event IDs. The evaluation result 308 received by the user device 150 may include these destination IDs and event IDs for the non-recommended routes, where the destination ID identifies the route and the event ID identifies a specific event that causes the route to be unrecommended.

[0073] When user equipment 150 first receives an evaluation result 308 including a specific destination ID and an event ID combination, user equipment 150 may display a non-recommended route notification as described above. If user equipment 150 receives subsequent evaluation results 308 including the same specific destination ID and event ID combination, user equipment 150 may avoid displaying the non-recommended route notification because user equipment 150 has already notified the user of events on the route.

[0074] To facilitate the suppression of subsequent non-recommended route notifications for a specific destination ID and event ID combination, user equipment 150 may store the specific destination ID and event ID combination in local memory upon first receiving it. In some implementations, user equipment 150 may use a timestamp to store the specific destination ID and event ID combination. Therefore, user equipment 150 can suppress subsequent non-recommended route notifications for a specific destination ID and event ID combination for a specific time period. For example, within 7 days after the timestamp (or 3 days, 5 days, 2 weeks, or any other desired time period), user equipment 150 can suppress subsequent non-recommended route notifications for the specific destination ID and event ID combination.

[0075] Because user equipment 150 can store a combination of a specific destination ID and an event ID, user equipment 150 can still provide notifications for other routes affected by the same event (e.g., identified by other destination IDs).

[0076] Rank the routes

[0077] In some implementations, route planning module 132 can use frequently used route planning information to rank routes for presentation to the user. As described above, data collection module 140 can monitor the routes frequently traveled by user device 130 between locations. When map service 104 returns multiple routes between route planning locations 204A and 204B, route planning module 132 can determine which route(s) are most attractive to the user based on past behavior. Route planning module 132 can rank the routes and use the ranking to determine which route(s) to recommend to the user.

[0078] In some implementations, location module 138 may periodically determine the location of user device 130. For example, when map application 134 is active, location module 138 may periodically determine the location of user device 130, allowing map application 134 to display the location of user device 130 on the displayed map. When map application 134 is providing navigation information to the user, location module 138 may periodically determine the location of user device 130, allowing map application 134 to determine navigation guidance instructions and display them to the user. Other applications (not shown) may also use the location data of user device 130, and location module 138 may determine the location of user device 130 for these other applications. Examples include bike-sharing applications, web browsing applications, weather applications, social media applications, food delivery applications, and / or many other applications that may use location data.

[0079] In some implementations, the data collection module 140 may record the location of the user device 130 over time. For example, whenever the location module 138 determines the location of the user device 130 that supports the map application 134 or other applications, the data collection module 140 may record the location data in the collected data database 142. Over time, the location data recorded in the collected data database 142 can provide a record of how the user travels between locations.

[0080] For ease of illustration, and to explain how the recorded locations can generate route rankings, a subset of the recorded user equipment 130 locations can be considered as a location process. A location process may include a series of locations determined by the location module 138. Figure 6A An exemplary location process 600 is shown. Each point in location process 600 represents a location in the sequence of recorded locations 602.

[0081] The sequence of recorded locations 602 can define routes between locations. Continuing the example discussed above, the data collected by data collection module 140 can indicate that a user typically leaves home at approximately 8:30 a.m. to go to their office and arrives at approximately 9:00 a.m. For example, the recorded locations 602 in location process 600 could be locations recorded between 8:30 a.m. and 9:00 a.m. on a Monday. Clusters 604A, 604B, and 604C are corresponding series of recorded locations 602 that are closely grouped together in space and time. For example, cluster 604A could include locations 602 that are first recorded in the sequence before the user leaves home. Cluster 604B could include locations 602 that are last recorded in the sequence after the user arrives at their office. Cluster 604C is a smaller cluster that could represent brief slowdowns or stops during the user's commute (e.g., a coffee shop the user likes to stop at on their way to work each morning).

[0082] Assuming a user commutes to work in the same way most days, data collection module 140 can record a pattern similar to the location process 600 on most weekday mornings. Due to variables such as commuting time differences, random deviations from the route, and / or time differences in location checks performed by location module 138, it may be unlikely to repeat the exact location process 600. However, over time, data collection module 140 can record a large number of locations 602 along a similar process at similar times of the day.

[0083] In some implementations, the data collection module 140 may form a route based on the location process 600. For example, the data collection module 140 may identify clusters 604A and 604B as the start and end points of the journey because clusters 604A and 604B include a large number of densely spaced locations 602 collected over a long period of time. For example, cluster 604A may include location data from the time a user arrives home at night to the time the user departs for work. Cluster 604B may include location data from the time the user arrives at work to the time the user departs for home. Therefore, clusters 604A and 604B may indicate that the user has been at a specific location for a long time. On the other hand, wider-spaced locations 602 between clusters 604A and 604B may be collected sequentially, and movement between clusters 604A and 604B may be indicated. The data collection module 140 may identify the wider-spaced locations 602 between clusters 604A and 604B as the location process 600. Data collection module 140 may use time thresholds to avoid identifying smaller clusters (e.g., cluster 604C) as process endpoints (e.g., data collection module 140 may terminate position process 600 after user equipment 130 has been in a relatively fixed position for more than a certain predefined time period).

[0084] In some implementations, the route planning module 132 can correlate the location 602 along the location process 600 with known map data. For example, Figure 6B An exemplary comparison between location process 600 and map data from map service 104 is shown. Route planning module 132 can associate location 602 with points on one or more roads 201. Route planning module 132 can correct for discrepancies on the route (e.g., due to errors in location data collection) by fitting location 602 to a known route provided by the known locations of roads 201. Route planning module 132 can associate clusters 604A and 604B with route planning locations 204A and 204B (e.g., by comparing the locations of clusters 604A and 604B with known route planning locations 204A and 204B (such as predefined home and work locations) and / or with addresses). Based on these comparisons, route planning module 132 can define user route 610 according to location process 600, such as... Figure 6C As shown. User route 610 can be a route frequently used by the user. Route planning module 132 can store user route 610 in map data database 136.

[0085] In some implementations, whenever user equipment 130 travels between route planning locations 204A and 204B, route planning module 132 may store user route 610, thereby accumulating a count of the number of times the user travels along a given route in map data database 136. In some implementations, route planning module 132 may count routes that are substantially similar to the same routes in map data database 136. For example, route planning module 132 may use a dynamic time warping algorithm to measure the similarity between two time series (e.g., routes) that may vary in time (e.g., due to differences in start time, end time, and / or speed at various points along the journey). Route planning module 132 may consider routes that are considered similar by the dynamic time warping algorithm as the same routes for counting purposes.

[0086] In some implementations, route planning module 132 can rank routes provided by map service 104 using user route 610. For example, route planning module 132 can automatically and / or in response to a user request request a route between route planning locations 204A and 204B. Map service 104 can return multiple routes between route planning locations 204A and 204B. In some implementations, routes can be enhanced through the non-recommended route determination process described above. In other implementations, routes can be free-flowing routes, routes recommended based on historical traffic data, or routes recommended based on current traffic conditions. Route planning module 132 can evaluate each route from map service 104 against the recorded user route 610 to determine which routes from map service 104 the user might be interested in.

[0087] In some implementations, route planning module 132 may compare each route received from map service 104 with user route 610. In some implementations, route planning module 132 may use a similarity algorithm to determine the similarity between routes received from map service 104 and user route 610. For example, route planning module 132 may use a dynamic time warping algorithm to measure the similarity between two time series (e.g., routes) that may vary in time (e.g., due to differences in start time, end time, and / or speed at various points along the journey). Therefore, route planning module 132 may determine whether any route received from map service 104 matches any user route 610. For example, Figure 6C User route 610 can be combined with, for example Figure 2D The route 206C shown is roughly the same as the route between locations 204A and 204B.

[0088] In some implementations, the route planning module 132 can rank the routes received from the map service 104 based on the number of records in the map data database 136 associated with each route. For example, the route planning module 132 can determine that route 206C is associated with 100 user routes stored in the map data database 136, route 206A is associated with 30 user routes stored in the map data database 136, and route 206B is associated with 8 user routes stored in the map data database 136. The route planning module 132 can set the ranking of route 206C as the highest, the ranking of route 206A as the second highest, and the ranking of route 206B as the lowest.

[0089] In some implementations, map application 134 may use the ranking determined by route planning module 132 to recommend routes to the user. For example, the highest-ranked route may be most relevant to the user. Therefore, map application 134 may present the highest-ranked route to the user. For example, if multiple routes are predicted to take the same amount of time to travel, map application 134 may select the highest-ranked route to present to the user. In some implementations, map application 134 may present the highest-ranked route to the user even when lower-ranked routes are predicted to be faster.

[0090] In some implementations, route planning module 132 may proactively request traffic data from map service 104 using route ranking (e.g., automatically and without user input before the user anticipates traveling between locations). In some implementations, this proactive request may differ from the proactive requests discussed above, as it is a request for traffic data on a specific, defined route rather than a request for recommended routes between locations. For example, map data database 136 may include user routes (e.g., user route 610) between known related locations (e.g., user-defined or automatically determined related locations as described above). In some implementations, route planning module 132 may group and rank user routes between known related locations and identify one or more preferred routes from each group (e.g., user-preferred routes based on the frequency with which the route appears in the collected data database 142). User routes may be grouped based on the similarity measures described above, such that similar user routes are grouped together. In each group, the preferred route representing the group may be identified as one of the user routes in that group, or constructed by combining common road segments of user routes in the group. The preferred route can be one or more routes corresponding to the largest group of user routes between the origin and destination stored in the collected data database 142 (e.g., the routes most frequently traveled by the user). Returning to the example above, the preferred route could be route 206C, because route 206C is associated with the largest number of user routes stored in the map data database 136 for routes between route planning locations 204A and 204B. The route planning module 132 can proactively request traffic data for route 206C (e.g., the time before the user is predicted to leave). The map service 104 can respond to the traffic data for route 206C.

[0091] Map application 134 can generate notifications when traffic data for the preferred route indicates problems on that route. For example, returning... Figure 4B When traffic data indicates a problem on the preferred route, user device 130 may display a non-recommended route notification 450. In this example, the starting location is the current location of user device 130, the ending location is home (e.g., a user-defined or automatically determined home location), and the preferred route includes route 280. Map application 134 can generate a title string 452 for the non-recommended route notification 450 by inserting the problem (“traffic congestion”) and destination (“home”) of the preferred route. Map application 134 can generate a detail string 454 for the non-recommended route notification 450 by inserting a message related to the event type (“expected delay”). The user can select the notification to view more details about the preferred route. For example, selecting the notification can bring up... Figure 5The map navigation GUI 500, as described above, can display a map 502 with information related to the preferred route shown thereon.

[0092] Mild guidance features

[0093] In some implementations, map application 134 may (e.g., based on data collected by data collection module 140 as described above) determine areas and / or routes familiar to the user. Map application 134 may customize the displayed traffic and route planning information for users familiar with routes between areas and / or locations. Due to familiarity, the user may not require the display of audible narration or detailed navigation instructions. For example, route planning module 132 may use location information collected by data collection module 140 as described above to determine whether the user is traveling on a familiar route. When route planning module 132 determines that the user is on a familiar route, map application 134 may display “light” guidance information instead of full directional guidance. In light guidance mode, map application 134 may present information relevant to drivers familiar with the area. For example, light guidance may include traffic and / or event information, alternative route suggestions, reduced guidance (e.g., guidance only for parts of the route that deviate from the familiar route), guidance without audible prompts, guidance without detailed street and / or next move descriptions, or combinations thereof. Light guidance may be automatically invoked, for example, in response to route planning module 132 determining that the user is on a familiar route (e.g., as determined by the process described in the route ranking section above), automatically invoked at certain times (e.g., during the user's usual commute time), or automatically invoked in response to a user request.

[0094] In some implementations, the map application 134 can be launched or transition to a lightly guided mode based on context. For example, the route planning module 132 can generate proactive notifications for non-recommended routes and / or preferred routes as described above. The route planning module 132 can generate proactive notifications for non-recommended routes when it is predicted that the user will travel between two familiar locations. The route planning module 132 can also generate proactive notifications for preferred routes identified as frequently used by the user. In either case, the proactive notifications can be based on frequently observed user behavior. The notification context indicates that the user is expected to be familiar with the routes presented in the map application 134. Therefore, the map application 134 can be launched in lightly guided mode when the user selects a proactive notification.

[0095] For example, map application 134 may provide light guidance by default during a time period defined as a commuting window and / or at locations between the start and end of the commute. As described above, data collection module 140 may collect information indicating that the user frequently commutes from a first location to a second location at the same approximate time on the same day of the week. For example, the user may leave home for work at or around 8:30 a.m. on Mondays and arrive at or around 9:00 a.m.

[0096] In some implementations, if a user launches the map application 134 during a commuting window (e.g., from one hour before the user typically leaves to one hour after the user typically arrives), the map application 134 can start in a lightly guided mode.

[0097] In some implementations, if a user launches the map application 134 in a commuting window while the user device 130 is located between the start and end points, the map application 134 can start in a lightly guided mode.

[0098] In some implementations, location module 138 may determine whether user device 130 is in a vehicle. For example, location module 138 may determine that user device 130 is on a road and moving at a speed indicative of a vehicle (such as a car). Alternatively, location module 138 may detect that user device 130 (e.g., via Bluetooth connection) is connected to a car audio and / or navigation system. If the user launches map application 134 in a commuting window while user device 130 is in a vehicle, map application 134 may begin in a lightly guided mode.

[0099] Figures 7A to 7O An example of a GUI 700 with lightly guided features for a map application 134 is shown.

[0100] Figure 7A A user device 130 is shown displaying a GUI 700 in an exemplary implementation of a lightly guided mode. The GUI 700 may include a lightly guided map 702. A map application 134 may display the lightly guided map 702 when launched in lightly guided mode (e.g., as described below) and / or in response to a user command to enter lightly guided mode. The lightly guided map 702 may display one or more routes (e.g., routes determined by the non-recommended route processing and / or ranking processing described above) and estimated time to traverse the route from the current location to the destination. The GUI 700 may include a navigation status bar 706 that may display information such as estimated time of arrival, estimated remaining time, and estimated distance. The GUI 700 may include an end button 708 that a user can select to exit the GUI 700.

[0101] UI 700 may include a control indicator 704. The control indicator 704 can display the next control that a driver familiar with the area might be interested in. For example, in... Figure 7A In the map, a lightly guided map shows two possible routes, and manipulation indicator 704 indicates recommended manipulations for points where the two routes deviate. Because the user is familiar with the area, step-by-step guidance may not be necessary, but the manipulation instructions at decision points may be helpful.

[0102] In some implementations, GUI 700 allows the user to switch between a light boot mode and a full boot mode that provides step-by-step guidance. For example, selecting operation flag 704 causes GUI 700 to switch to full boot mode. In some implementations, GUI 700 may, for example, briefly display the prompt text in operation flag 704 when entering light boot mode. Figure 7B A GUI 700 is shown, in which a control icon 704 is displaying prompt text instructing the user to tap the control icon 704 to enter a fully booted mode. In some implementations, after a certain amount of time (such as five seconds), the control icon 704 may change from displaying prompt text to displaying boot (e.g., as...). Figure 7A (As shown).

[0103] In some specific implementations, the GUI 700 allows the user to change the orientation of the lightly guided map 702. For example, in Figure 7C In the GUI 700, a compass 710 is included. The GUI 700 may hide the compass 710 by default and display the compass 702 when the user interacts with the light-guided map 702 (e.g., by tapping or manipulating the light-guided map 702). The compass 710 may appear for a certain amount of time (e.g., up to three seconds) and then disappear. The user may select the compass 710 to place the destination on the light-guided map 702 (where the user device 130 is positioned at the bottom of the light-guided map 702 and the destination is at the top of the light-guided map 702). Figures 7A to 7C As shown) and as Figure 7D The pasted North is shown in the light guide map 702, which is switched between.

[0104] In some implementations, the GUI 700 may include a control panel that provides additional functionality. For example, such as... Figure 7E As shown, GUI 700 can display disk 712 upon user command (e.g., in response to a user swiping up on status bar 706). Disk 712 can provide additional options such as searching for specific points of interest (e.g., gas stations, food, or coffee), adjusting the zoom level of lightly guided map 702, displaying details about the route, and / or adjusting audio notification settings.

[0105] In some specific implementations, the zoom level of the lightly guided map 702 can be adjusted in a view that displays the entire route (e.g., as shown in the image). Figures 7A to 7D (as shown) and as Figure 7F The system allows switching between "driving mode" zoom levels. For example, a user can select zoom level icon 713 on the dial 712 to enter driving mode. In driving mode zoom levels, the GUI 700 can display a driving icon 714 indicating the direction of travel of the user device 130 and the name of the road where the user device 130 is located or traveling. The map application 134 can determine the direction of travel and road name based on location data collected by the location module 138. The driving icon 714 can remain in a fixed position on the light-guidance map 702, which itself can scroll and reorient to track the movement of the user device 130. In some embodiments, the GUI 700 may use a stronger font (e.g., larger and / or bolder font) for at least some information (e.g., street names and / or landmark names) in the driving mode view compared to the view displaying the entire route, making the information readily visible to the user while driving. In some embodiments, the GUI 700 may include different options on the dial 712 when in driving mode. For example, disk 712 may include an overview option that the user can select to return to a view that displays the entire route.

[0106] In some specific implementations, when the user selects the audio icon 715 on disk 712, the GUI 700 can display the audio settings interface 716, such as... Figure 7H As shown. The audio settings interface 716 facilitates adjustments to audio notifications. For example, when in light guidance mode, the map application 134 can provide audio notifications for each instruction presented by the maneuver sign 704, audio notifications only for reporting traffic events, or mute all audio notifications. In some implementations, the map application 134 may default to providing audio notifications only for reporting traffic events.

[0107] In some implementations, the GUI 700 can adjust the audio icons in the disk 712 according to the audio notification settings selected in the audio settings interface 716. For example, when audio notifications for reporting traffic incidents only are selected, the disk 712 may include... Figure 7E and Figure 7G The audio icon is shown in the image. Disk 712 can include audio notifications when full audio notification is selected. Figure 7I The audio icon is shown in the image. When the audio notification is muted (not shown), disk 712 may display a mute icon.

[0108] In some implementations, the GUI 700 can adjust the currently displayed navigation route. For example, as described above, the lightly guided map 702 can show one or more routes determined through the non-recommended route processing and / or ranking processing (or through other route processing) described herein. In some cases, the route planning module 132 can communicate with the map service 104 and detect events on the current route that make the current route slower than alternative routes. If so, the route planning module 132 can recommend different routes. Therefore, the GUI 700 can display as follows: Figure 7J The notification 718 is shown. Notification 718 may describe an alternative route (e.g., "380W") and / or the effect of choosing the alternative route (e.g., "save 15 minutes"). Notification 718 may include an interface 720 that allows the user to accept or reject the alternative route. If the user rejects the alternative route, the map application 134 may continue to present navigation instructions for the current route. If the user selects an alternative route, the map application 134 may begin presenting navigation instructions for the alternative route. In some implementations, if the user does not provide input through interface 720 after a certain amount of time (e.g., 10 seconds), the map application 134 may switch to presenting navigation instructions for the alternative route. In some cases, despite a traffic event, the route planning module 132 and map service 104 may not be able to determine a better alternative route than the current route. In this case, notification 718 may suggest the event to the user without providing details of the alternative route or interface 720, such as... Figure 7K As shown.

[0109] As mentioned above, GUI 700 may also include a fully boot mode that displays turn-by-turn navigation instructions. Figure 7L This is an example of a GUI 700 displaying a complete guide map 722 and a step-by-step guide 724. When the collected data database 142 lacks information indicating the user's familiarity with the area (e.g., indications collected by the data collection module 140, such as information detected by the location module 138 that the user device 130 frequently exists in the area), the GUI 700 can begin in full boot mode. As mentioned above, the user can also switch from light boot mode to full boot mode by clicking the manipulation icon 704. When the GUI 700 is in full boot mode, the user can switch to light boot mode by clicking the step-by-step guide 724. In some implementations, the step-by-step guide 724 may display prompts indicating how to switch to light boot, such as... Figure 7L As shown. In some implementations, the prompt may appear upon entering full boot mode and disappear after a certain amount of time (e.g., five seconds).

[0110] In some implementations, when the user selects the end button 708, the map application 134 can exit its navigation mode and switch to standard map mode (e.g., provided as...). Figure 7M (As shown in the fully booted mode). Therefore, the GUI 700 can switch from displaying a light boot mode or a full boot mode to displaying... Figure 7M Standard map view 726 or Figure 7N The driving map view 730. In some specific implementations, the location module 138 can determine whether the user device 130 is traveling in a vehicle. For example, the location module 138 can determine that the user device 130 is on a road and moving at a speed indicating a vehicle (such as a car). The GUI 700 can switch to a driving map view 730 when the location module 138 determines that the user device 130 is traveling in a vehicle. Figure 7N The driving map view 730 is shown, and otherwise switches to the standard map view 726. The standard map view 726 and the driving map view 730 may include a disk 728 that provides the user with options for searching for navigation destinations and / or selecting predetermined navigation destinations (e.g., the location of home, workplace, or nearest location).

[0111] In some specific implementations, when the map application 134 determines that light guidance is appropriate based on context, the GUI 700 may initially display the "Start and Departure" map 732, such as... Figure 7O As shown. The launch and departure map 732 can be displayed in light boot mode (see, for example, see...). Figure 7A The same route is overlaid, but without navigation information. GUI 700 may display a switching interface 734, which may include information such as route recommendations (e.g., "Use 280"), traffic status (e.g., "Normal traffic"), and / or timing information (e.g., "20 minutes to home"). If the user is not interested in navigation information, the user may select switching interface 734, and GUI 700 may switch to either standard map view 726 or driving map view 730, depending on whether the user device 130 is in a moving vehicle. If the user does not select switching interface 734 within a certain amount of time (e.g., 10 seconds), GUI 700 may switch to a lightly guided mode.

[0112] Example process

[0113] To enable readers to clearly understand the technical concepts described herein, the following process describes specific steps performed in a particular order. However, one or more steps of a particular process may be rearranged and / or omitted while remaining within the intended scope of the technology disclosed herein. Furthermore, different processes and / or their steps may be combined, recombined, rearranged, omitted, and / or performed in parallel to create different processing flows also within the intended scope of the technology disclosed herein. Moreover, although some details of the technology disclosed herein may be omitted or briefly summarized in the following process for clarity, the details described in the preceding paragraphs can be combined with the process steps described below to obtain a more complete and comprehensive understanding of these processes and the technology disclosed herein.

[0114] Figure 8 This is a flowchart of an exemplary process 800 for proactively requesting route planning information (e.g., see the "Non-Recommended Routes" section above). Process 800 may be performed by one or more components of user equipment 130. For example, process 800 may be performed by route planning module 132, location module 138, and / or data collection module 140 of user equipment 130. Process 900, which may be coordinated with process 800 by server device 102, is described below.

[0115] At step 802, route planning module 132 may determine whether there are any locations where route planning information can be actively requested, and if so, when the route planning information can be requested. For example, data collection module 140 may store data indicating locations frequently visited by user equipment 130 in a collected data database. Data collection module 140 may also store the number of times user equipment 130 frequently travels to a location. Route planning module 132 may use the stored data to identify target locations and commuting windows for active requests, wherein the commuting window may be open some time before the user typically departs for the location (e.g., one hour in advance).

[0116] At step 804, user equipment 130 may be woken up within a commuting window. In some implementations, to conserve battery power, process 800 may proceed only when user equipment 130 is in active mode, not in low-power mode. Route planning module 132 may not wake user equipment 130 independently to execute process 800, but may wait for user equipment 130 to wake up for other reasons and then continue process 800 in response. In other implementations, process 800 may proceed even when user equipment 130 is not active.

[0117] At step 806, route planning module 132 may determine whether any potential routes exist between the location of user device 130 and the target location stored in map data database 136. For example, route planning module 132 may have already received and stored potential routes from map service 104 in a previous iteration of process 800.

[0118] If no potential route exists between the location of user device 130 and the target location stored in map data database 136, then at step 808, route planning module 132 may send the location of user device 130 and the target location to map service 104. For example, route planning module 132 may use the networking hardware and software of user device 130 to communicate with server device 102 via a cellular or WiFi connection to the Internet or other network 150.

[0119] At step 810, the route planning module 132 may receive a potential route from the map service 104 in response to the transmitted location. For example, the map service 104 may, based on... Figure 9 The process of generating potential routes is as follows.

[0120] If a potential route exists between the location of user device 130 and the target location stored in map data database 136, then at step 814, route planning module 132 may send the potential route to map service 104. For example, route planning module 132 may use the networking hardware and software of user device 130 to communicate with server device 102 via a cellular or WiFi connection to the Internet or other network 150. As described below, sending the potential route may allow map service 104 to skip the steps for determining the potential route.

[0121] At step 816, the route planning module 132 may receive evaluation results from the map service 104. The evaluation results may describe whether any problems exist with the potential routes. For example, if no problems exist with the potential routes, the evaluation results may be a confirmation from the map service 104. If one or more potential routes have problems, the evaluation results may describe these problems. For example, the evaluation results may identify which routes are affected by traffic events and how travel on these routes may be affected, and / or identify alternative routes.

[0122] If the assessment results indicate one or more problems with one or more routes and / or include alternative route recommendations, then at step 818, the route planning module 132 can generate information to display to the user. For example, the route planning module 132 can create alerts describing traffic incidents and / or alternative routes. When the map application 134 is active, the route planning module 132 can indicate traffic incidents and / or alternative route recommendations in the map application 134 GUI.

[0123] Figure 9 This is a flowchart of an exemplary process 900 for identifying and evaluating routes and identifying alternatives (e.g., see the "Non-Recommended Routes" section above). For example, process 900 may be performed by map service 104 of server device 102. Process 900 may be triggered by user device 130 that performs process 800 and thereby sends data to server device 102. Process 800, which may be coordinated and executed by user device 130 with process 900, has been described above.

[0124] In some cases, process 900 may begin when map service 104 receives a route planning location requesting route planning information. At step 902, map service 104 may receive the route planning location from route planning module 132. The route planning location may be sent by user equipment 130 at step 808 of process 800. For example, map service 104 may receive the route planning location via network 150.

[0125] At step 904, map service 104 may determine free-flow routes between route planning locations. For example, map service 104 may identify three fastest routes from the starting location to the destination location when traffic is moving at or above the speed limit.

[0126] At step 906, map service 104 may evaluate free-flow routes based on historical traffic information for the time the route planning location was received. For example, map data database 106 may include historical traffic information indicating typical traffic at different times of day. Therefore, map service 104 may look up historical traffic information for each free-flow route at the current time and date. For example, some routes that are faster under free-flow conditions may become congested at certain times (such as peak hours). Map service 104 can use historical traffic information to determine whether any free-flow route is typically slower at the current time and date. Map service 104 may select routes that are faster under both free-flow conditions and historical conditions as potential routes.

[0127] At step 908, map service 104 may send potential routes to route planning module 132. For example, map service 104 may send potential routes via network 150.

[0128] In some cases, process 900 may begin when map service 104 receives a potential route previously stored by user device 130. At step 910, map service 104 may receive the potential route from route planning module 132. For example, map service 104 may have already determined the potential route by performing steps 902-908 in a previous iteration of process 900 and sent it to route planning module 132. The potential route may be sent by user device 130 at step 814 of process 800. For example, map service 104 may receive the potential route via network 150.

[0129] At step 912, map service 104 may assess the real-time traffic conditions of potential routes. Map service 104 may perform step 912 using potential routes identified in steps 902 through 908 or potential routes received in step 910. For example, map service 104 may receive real-time traffic updates from one or more traffic data reporting services. Map service 104 may determine from the real-time traffic updates whether there are any potential recommended routes 306 that are slower than expected. For example, map service 104 may compare the time required to cross the route under current traffic conditions with the free-flow time used to cross the route or the historical time for crossing the route. If the current time to cross the route is longer than the free-flow or historical time compared to it by a certain threshold amount, map service 104 may determine that the route is a non-recommended route and should not be recommended. Map service 104 may designate routes that are slower than the threshold tolerance as non-recommended routes.

[0130] At step 914, if map service 104 did not identify any non-recommended routes at step 912, map service 104 may send a message indicating that there are no problems with any potential routes. For example, map service 104 may send a confirmation message without further information, thus sending a minimal response.

[0131] At step 916, if map service 104 identified one or more non-recommended routes at step 912, map service 104 may perform further route evaluation to potentially identify alternative routes. To determine alternative routes, map service 104 may discard non-recommended routes and evaluate one or more additional routes between route planning locations for the current real-time traffic conditions. In some implementations, map service 104 may determine up to two alternative routes and evaluate each of them for the current real-time traffic conditions. In some cases, the evaluation may show one or more alternative routes that are faster than the non-recommended routes. In some cases, map service 104 may look for alternative routes but find no routes faster than the non-recommended routes.

[0132] At step 918, map service 104 may send the results of the evaluation performed at step 916. For example, if one or more alternative routes are available, map service 104 may send information describing one or more alternative routes. If there is no alternative route faster than the non-recommended route, map service 104 may send information suggesting that the non-recommended route should be used and describing the traffic events on the non-recommended route in detail. If the evaluation performed at step 916 does not produce any non-recommended routes, map service 104 may not send any route information (e.g., send a confirmation message).

[0133] Figure 10 This is a flowchart of an exemplary process for ranking routes (see, for example, the "Ranking Routes" section above). Process 1000 may be performed by one or more components of user equipment 130. For example, process 1000 may be performed by route planning module 132, location module 138, and / or data collection module 140 of user equipment 130.

[0134] At step 1002, the data collection module 140 may collect location data of the user equipment 130. For example, when the mapping application 134 or other applications using location data are running, the location module 138 may determine the location of the user equipment 130. The data collection module 140 may store the location data determined by the location module 138 in the collected data database 142.

[0135] At step 1004, route planning module 132 may associate at least a portion of the stored location data with one or more routes between route planning locations. For example, data collection module 140 may identify closely spaced locations collected over a long period as the start and end points of a journey. Data collection module 140 may identify locations between start and end points collected in a wide-interval, sequential manner as indications of movement between start and end points. Route planning module 132 may associate the sequentially collected locations between start and end points with known map data. For example, route planning module 132 may associate the locations with points on one or more roads. Route planning module 132 may correct for discrepancies on the route (e.g., due to errors in location data collection) by fitting the locations to known routes provided by known locations of roads. Route planning module 132 may associate closely spaced locations with known route planning locations (such as predefined home and work locations) and / or with addresses. Therefore, route planning module 132 can use the stored location data to identify routes between locations.

[0136] At step 1006, the route planning module 132 may count whenever the user equipment 130 travels along the identified route. For example, the route planning module 132 may record whenever the user equipment 130 traverses a given route in the collected data database 142.

[0137] As the location module 138 collects more location data over time, steps 1002 to 1006 can be repeated. For example, the route planning module can periodically execute steps 1002 to 1006 to continue counting route usage as evidenced by the location data collected by the location module 138.

[0138] At step 1008, the route planning module 132 may receive route planning information from the map service 104. For example, a user may use the map application 134 to request route planning information between route planning locations, or the route planning module 132 may proactively request route planning information. In either case, the map service 104 may respond using route planning information for multiple possible routes.

[0139] At step 1010, route planning module 132 may rank the multiple possible routes received at step 1008. For example, route planning module 132 may use a similarity algorithm to determine the similarity between the routes received from map service 104 and the routes determined in steps 1002 to 1006. Route planning module 132 may rank the routes received from map service 104 based on how many records the routes are related to in map data database 136. For example, route planning module 132 may rank the route received from map service 104 that is related to the route with the highest count in collected data database 142 as the highest, the route that is related to the route with the second highest count in collected data database 142 as the second highest, and the route that is related to the route with the next lowest count in collected data database 142 (or that does not appear in collected data database 142) as the lowest.

[0140] At step 1010, route planning module 132 may display routes in ranking order. For example, if route planning module 132 is generating a notification about traffic conditions, it may include information about the highest-ranked route in the notification. If route planning module 132 is supplying route planning information to map application 134 for display in a navigation GUI, it may suggest the highest-ranked route as the selected route and the second-highest-ranked route as an alternative route to be displayed.

[0141] Figure 11This is a flowchart of an exemplary process for evaluating preferred routes (e.g., see the "Ranking Routes" section above), process 1100 which may be performed by one or more components of user equipment 130. For example, process 1100 may be performed by route planning module 132, location module 138, and / or data collection module 140 of user equipment 130.

[0142] At step 1102, the data collection module 140 may collect location data of the user equipment 130. For example, when the mapping application 134 or other applications using location data are running, the location module 138 may determine the location of the user equipment 130. The data collection module 140 may store the location data determined by the location module 138 in the collected data database 142.

[0143] At step 1104, route planning module 132 may associate at least a portion of the stored location data with one or more routes between route planning locations. For example, data collection module 140 may identify closely spaced locations collected over a long period as the start and end points of a journey. Data collection module 140 may identify locations between start and end points collected in a wide-interval, sequential manner as indications of movement between start and end points. Route planning module 132 may associate the sequentially collected locations between start and end points with known map data. For example, route planning module 132 may associate the locations with points on one or more roads. Route planning module 132 may correct for discrepancies on the route (e.g., due to errors in location data collection) by fitting the locations to known routes provided by known locations of roads. Route planning module 132 may associate closely spaced locations with known route planning locations (such as predefined home and work locations) and / or with addresses. Therefore, route planning module 132 can use the stored location data to identify routes between locations.

[0144] At step 1106, the route planning module 132 may count whenever the user equipment 130 travels along the identified route. For example, the route planning module 132 may record whenever the user equipment 130 traverses a given route in the collected data database 142.

[0145] As the location module 138 collects more location data over time, steps 1102 to 1106 can be repeated. For example, the route planning module can periodically execute steps 1102 to 1106 to continue counting route usage as evidenced by the location data collected by the location module 138.

[0146] At step 1108, route planning module 132 may determine that the route with the highest count in the collected data database 142 is the preferred route (e.g., the route most frequently used by the user). In some implementations, route planning module 132 may group user routes and determine one or more routes from the group with the highest cardinality in the collected data database 142 as preferred routes (e.g., the route most frequently used by the user).

[0147] At step 1110, route planning module 132 may send a preferred route to map service 104 to request traffic information for the preferred route. For example, route planning module 132 may use the networking hardware and software of user equipment 130 to communicate with server equipment 102 via a cellular or WiFi connection to the Internet or other network 150.

[0148] At step 1112, route planning module 132 may receive traffic information for the preferred route from map service 104. In some cases, route planning module 132 may display information about the preferred route. For example, if traffic information indicates a problem on the preferred route when it predicts the user's interest (e.g., during the preferred route's commuting window), route planning module 132 may display a notification describing the problem. Alternatively, route planning module 132 may feed the preferred route information to map application 134 for display in the navigation GUI.

[0149] Figure 12 This is a flowchart of an exemplary process for launching the map application 134 in either light-boot mode or full-boot mode, depending on the context in which the map application 134 is launched (e.g., see the “Light Boot Features” section above). Process 1200 may be executed by one or more components of the user device 130.

[0150] At step 1202, map application 134 may be launched. For example, map application 134 may be launched in response to a user request to open the application or a user selection of a notification regarding traffic conditions.

[0151] At step 1204, the map application 134 can determine whether the initiation is based on a user selection of a notification indicating a non-recommended route (e.g., proactive in some implementations), generated as described above. For example, if the user selects a non-recommended route notification or a preferred route notification (e.g., notification 400 or 450), the user may want information about the traffic problem that triggered the notification. Based on data in the collected data database 142, non-recommended route notifications and preferred route notifications can be generated for areas or routes familiar to the user. Therefore, if the initiation is a proactive notification based on a user selection, the map application can initiate in a mildly guided mode (e.g., displaying the initiation and departure interface) at step 1210.

[0152] At step 1206, map application 134 can determine whether the launch was initiated at a location along a frequently used route within a commuting window. For example, if a user launches map application 134 from home at their usual commute time, the ranked routes and commuting window information in the collected data database 142 can indicate that the user may be interested in commuting information for areas they are familiar with. Therefore, map application can launch in a lightly guided mode (e.g., displaying a launch and departure interface) at step 1210.

[0153] In step 1208, map application 134 can determine whether launch was initiated when user device 130 was in a vehicle during a commute window. For example, if a user typically launches map application 134 in a car during their commute, the ranked routes and commute window information in the collected data database 142 can indicate that the user may be interested in commuting information for areas they are familiar with. Therefore, map application can launch in a lightly guided mode (e.g., displaying a launch and departure interface) in step 1210.

[0154] At step 1212, if there is no context indicating that the map application 134 should be launched in light boot mode, the map application 134 may be launched in full boot mode.

[0155] privacy

[0156] This disclosure recognizes that the use of such personal information data in the present invention can benefit users. For example, personal information data can be used to deliver in-app recommendations, proactive downloads, suggestions, and / or targeted content that is of greater interest to the user. Therefore, the use of such personal information data enables planned control over the delivered content. Furthermore, this disclosure also anticipates other uses of personal information data that benefit the user.

[0157] This disclosure also envisions that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities should implement and adhere to privacy policies and practices that are recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. For example, personal information from users should be collected for legitimate and reasonable purposes of the entity and not shared or sold outside of these legitimate purposes. Furthermore, such collection should only be conducted with the user's informed consent. Additionally, such entities should take any necessary steps to safeguard and protect access to such personal information data and ensure that others with access to such personal information data comply with their privacy policies and procedures. Furthermore, such entities may be subject to third-party evaluations to demonstrate their compliance with widely accepted privacy policies and practices.

[0158] Regardless of the foregoing, this disclosure also contemplates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure contemplates providing hardware and / or software components to prevent or block access to such personal information data. For example, with respect to advertising delivery services, the technology of this invention can be configured to allow users to choose to "join" or "opt out" of the collection of personal information data during service registration. As another example, users can choose not to provide location information for a targeted content delivery service. Yet another example is that users can choose not to provide precise location information but allow the transmission of location area information.

[0159] Graphical User Interface

[0160] This disclosure describes above various graphical user interfaces (GUIs) for implementing various features, processes, or workflows. These GUIs can be presented on a variety of electronic devices, including, but not limited to, laptop computers, desktop computers, computer terminals, television systems, tablet computers, e-book readers, and smartphones. One or more of these electronic devices may include a touch-sensitive surface. The touch-sensitive surface can process multiple simultaneous input points, including processing data related to the pressure, degree, or position of each input point. Such processing can facilitate gestures using multiple fingers, including pinching and swiping.

[0161] When this disclosure refers to user interface elements in a “selecting” GUI, these terms are understood to include clicking or “hovering” over a user interface element using a mouse or other input device, or touching, tapping, or gesturing over a user interface element using one or more fingers or a stylus. User interface elements can be virtual buttons, menus, selectors, switches, sliders, brushes, knobs, thumbnails, links, icons, radio buttons, checkboxes, and any other mechanisms used to receive input from or provide feedback to the user.

[0162] Example System Architecture

[0163] Figure 13 It is achievable. Figures 1 to 12 A block diagram of an exemplary computing device 1300 illustrating its features and processes. The computing device 1300 may include a memory interface 1302, one or more data processors, a graphics processor and / or a central processing unit 1304, and a peripheral device interface 1306. The memory interface 1302, the one or more processors 1304, and / or the peripheral device interface 1306 may be separate components or integrated into one or more integrated circuits. The various components in the computing device 1300 may be coupled by one or more communication buses or signal lines.

[0164] Sensors, devices, and subsystems can be coupled to peripheral interface 1306 to enable multiple functions. For example, motion sensor 1310, light sensor 1312, and proximity sensor 1314 can be coupled to peripheral interface 1306 to enable orientation, illumination, and proximity functions. Other sensors 1316 can also be connected to peripheral interface 1306, such as Global Navigation Satellite System (GNSS) (e.g., GPS receiver), temperature sensors, biometric sensors, magnetometers, or other sensing devices to enable related functions.

[0165] The camera subsystem 1320 and optical sensor 1322 (such as a charge-coupled device (CCD) or complementary metal-oxide-semiconductor (CMOS) optical sensor) can be used to facilitate camera functions such as taking photos and video clips. The camera subsystem 1320 and optical sensor 1322 can be used to collect images of a user to be used during user authentication, for example, by performing facial recognition analysis.

[0166] Communication functionality can be facilitated by one or more wireless communication subsystems 1324, which may include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystems 1324 may depend on one or more communication networks that the computing device 1300 is intended to operate through. For example, the computing device 1300 may include subsystems designed for communication via GSM networks, GPRS networks, EDGE networks, Wi-Fi or WiMax networks, and Bluetooth. ™ A network-operated communication subsystem 1324. Specifically, the wireless communication subsystem 1324 may include a host protocol that allows device 1300 to be configured as a base station for other wireless devices.

[0167] The audio subsystem 1326 can be coupled to the speaker 1328 and the microphone 1330 to facilitate voice-enabled functions such as speaker recognition, voice copying, digital recording, and telephone functions. The audio subsystem 1326 can be configured to facilitate, for example, processing of voice commands, voiceprint identification, and voice authentication.

[0168] I / O subsystem 1340 may include touch surface controller 1342 and / or one or more other input controllers 1644. Touch surface controller 1342 may be coupled to touch surface 1346. Touch surface 1346 and touch surface controller 1342 may detect contact and movement or interruption thereof using, for example, any of a variety of touch-sensitive technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch surface 1346.

[0169] One or more other input controllers 1344 may be coupled to other input / control devices 1348, such as one or more buttons, rocker switches, thumbwheels, infrared ports, USB ports, and / or pointing devices (such as styluses). One or more buttons (not shown) may include volume up / down buttons for speaker 1328 and / or microphone 1330.

[0170] In some implementations, pressing the button for a first duration unlocks the touch surface 1346; and pressing the button for a second duration longer than the first duration turns the computing device 1300 on or off. Pressing the button for a third duration activates a module for voice control or voice commands, allowing the user to speak commands into the microphone 1330 so that the device executes the spoken commands. The user can customize the function of one or more buttons. For example, the touch surface 1346 can also be used to implement virtual or soft buttons and / or a keyboard.

[0171] In some embodiments, computing device 1300 may display recorded audio and / or video files, such as MP3, AAC, and MPEG files. In some embodiments, computing device 1300 may include the functionality of an MP3 player, such as an iPod. ™ The computing device 1300 may therefore include a 36-pin connector compatible with iPod. Other input / output and control devices may also be used.

[0172] Memory interface 1302 may be coupled to memory 1350. Memory 1350 may include high-speed random access memory and / or non-volatile memory, such as one or more disk storage devices, one or more optical storage devices, and / or flash memory (e.g., NAND, NOR). Memory 1350 may store operating system 1352, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or embedded operating system (such as VxWorks).

[0173] Operating system 1352 may include instructions for handling basic system services and for performing hardware-related tasks. In some implementations, operating system 1352 may be a kernel (e.g., a UNIX kernel). In some implementations, operating system 1352 may include instructions for performing voice authentication. For example, operating system 1352 may implement offline map features, as referenced... Figures 1 to 12 As stated above.

[0174] The memory 1350 may also store communication instructions 1354 to facilitate communication with one or more additional devices, one or more computers, and / or one or more servers. The memory 1350 may include graphical user interface instructions 1356 facilitating graphical user interface processing; sensor processing instructions 1358 facilitating sensor-related processing and functions; telephone instructions 1360 facilitating telephone-related processes and functions; electronic message processing instructions 1362 facilitating electronic message processing and functions; web browsing instructions 1364 facilitating web browsing-related processes and functions; media processing instructions 1366 facilitating media processing-related processes and functions; GNSS / navigation instructions 1368 facilitating GNSS and navigation-related processes and instructions; and / or camera instructions 1370 facilitating camera-related processes and functions.

[0175] Memory 1350 can store data collection and route planning software instructions 1372 to facilitate other processing and functions, such as offline map processing and functions like reference. Figures 1 to 12 As stated above.

[0176] The memory 1350 may also store other software instructions 1374, such as network video instructions that facilitate processes and functions related to network video; and / or network shopping instructions that facilitate processes and functions related to online shopping. In some embodiments, the media processing instructions 1366 are divided into audio processing instructions and video processing instructions, respectively, for facilitating processes and functions related to audio processing and processes and functions related to video processing.

[0177] Each of the instructions and applications identified above may correspond to a set of instructions for performing one or more of the functions described above. These instructions do not need to be implemented as a separate software program, process, or module. Memory 1350 may include additional instructions or fewer instructions. Furthermore, various functions of computing device 1300 may be implemented in hardware and / or software, including in one or more signal processing and / or application-specific integrated circuits.

[0178] Implementation Features

[0179] The above-described specific implementation can provide at least the following features.

[0180] A method may include: evaluating the current traffic conditions of multiple potential routes between a start location and an end location by a map service of a computing device, wherein each potential route is a recommended route under free-flow traffic conditions or historical traffic conditions; determining, based on the current traffic conditions, whether at least one of the potential routes is a non-recommended route by the map service; and in response to determining that at least one of the potential routes is a non-recommended route: determining, by the map service, at least one alternative route between the start location and the end location, the at least one alternative route being different from each of the potential routes; evaluating the current traffic conditions of the at least one alternative route by the map service; identifying, by the map service, the fastest route from the potential routes and the at least one alternative route based on the current traffic conditions; and sending data describing the fastest route to a user computing device by the map service.

[0181] The method may also include receiving multiple potential routes from the user's computing device at a map service.

[0182] The method may also include receiving a start location and an end location from a user's computing device at a map service; and determining multiple potential routes by the map service, which includes evaluating multiple possible routes to discover recommended routes under free-flow traffic conditions or historical traffic conditions.

[0183] The method may also include sending multiple potential routes to the user's computing device via a map service.

[0184] Determining whether at least one of the potential routes is a non-recommended route based on current traffic conditions may include, for each of the potential routes: determining, by the map service, the time to traverse the potential route under the current traffic conditions; comparing, by the map service, the time to traverse the potential route under the current traffic conditions with the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; determining, by the map service, whether the comparison indicates that the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; and, in response to determining the threshold amount by which the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions, identifying the potential route as a non-recommended route by the map service.

[0185] The method may also include sending a confirmation message to the user's computing device by the map service in response to determining that no potential route is a non-recommended route.

[0186] A method may include: a route planning module of a user computing device sending a request for route planning information between a start location and an end location to a server computing device; receiving from the server computing device at the route planning module information describing a non-recommended route between the start location and the end location, wherein the non-recommended route is a route recommended under free-flow traffic conditions or historical traffic conditions, and is determined to have a crossing time under the current traffic conditions that is longer than a threshold amount under free-flow traffic conditions or historical traffic conditions; and a map application of the user computing device displaying an alert including at least a portion of the information received from the server computing device.

[0187] The method may further include collecting location information defining a start position and an end position by a data collection module of a user computing device. This collection includes identifying the current position and past position of the computing device, and identifying at least one of the current position and the past position as the start position and at least one of the current position and the past position as the end position.

[0188] The request may include a start position and an end position, and the method may further include: receiving multiple potential routes between the start and end positions from the server computing device at the route planning module; and storing the multiple potential routes in the memory of the user computing device by the route planning module.

[0189] The request may include multiple potential routes between the start and end points; and a non-recommended route may be one of these multiple potential routes.

[0190] The information from the server device may also include at least one alternative route that is faster than the non-recommended route under current traffic conditions.

[0191] The method may also include route planning information displayed by the map application that corresponds to at least a portion of the information in the alert.

[0192] A non-transitory computer-readable medium may include one or more instruction sequences that, when executed by one or more processors, cause the processors to perform operations including: evaluating the current traffic conditions of a plurality of potential routes between a start location and an end location, wherein each potential route is a recommended route under free-flow traffic conditions or historical traffic conditions; determining, based on the current traffic conditions, whether at least one of the potential routes is a non-recommended route; and in response to determining that at least one of the potential routes is a non-recommended route: determining at least one alternative route between the start location and the end location, the at least one alternative route being different from each of the potential routes; evaluating the current traffic conditions of the at least one alternative route; identifying the fastest route from the potential routes and the at least one alternative route based on the current traffic conditions; and transmitting data describing the fastest route to a user computing device.

[0193] This operation may also include receiving multiple potential routes from the user's computing device.

[0194] The operation may also include: receiving a start location and an end location from a user computing device; and determining multiple potential routes, which includes evaluating multiple possible routes to discover recommended routes under free-flow traffic conditions or historical traffic conditions.

[0195] This operation may also include sending multiple potential routes to the user's computing device.

[0196] Determining whether at least one of the potential routes is a non-recommended route based on current traffic conditions may include performing operations, for each of the potential routes: determining the time to traverse the potential route under the current traffic conditions; comparing the time to traverse the potential route under the current traffic conditions with the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; determining whether the comparison indicates that the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; and identifying the potential route as a non-recommended route in response to determining that the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions by a threshold amount.

[0197] The operation may also include sending a confirmation message to the user's computing device by the map service in response to determining that no potential route is a non-recommended route.

[0198] A non-transitory computer-readable medium may include one or more instruction sequences that, when executed by the one or more processors, cause the processors to perform operations including: sending a request for route planning information between a start position and an end position to a server computing device; receiving from the server computing device information describing a non-recommended route between the start and end positions, wherein the non-recommended route is a route recommended under free-flowing traffic conditions or historical traffic conditions, and is determined to have a crossing time under current traffic conditions that is longer than a threshold amount under free-flowing traffic conditions or historical traffic conditions; and displaying an alarm including at least a portion of the information received from the server computing device.

[0199] The operation may also include collecting location information defining a start position and an end position, the collection including identifying the current position and past position of the computing device, and identifying at least one of the current position and the past position as the start position and at least one of the current position and the past position as the end position.

[0200] The request may include a start position and an end position; and the operation may also include: receiving multiple potential routes between the start position and the end position from the server computing device; and storing the multiple potential routes in the memory of the user computing device.

[0201] The request may include multiple potential routes between the start and end points; and a non-recommended route may be one of these multiple potential routes.

[0202] The information from the server device may also include at least one alternative route that is faster than the non-recommended route under current traffic conditions.

[0203] The operation may also include displaying route planning information corresponding to at least a portion of the information in the alert.

[0204] A system may include: one or more processors; and a non-transitory computer-readable medium comprising one or more instruction sequences, which, when executed by the one or more processors, cause the processors to perform operations including: evaluating current traffic conditions of a plurality of potential routes between a start location and an end location, wherein each potential route is a recommended route under free-flow traffic conditions or historical traffic conditions; determining, based on the current traffic conditions, whether at least one of the potential routes is a non-recommended route; and in response to determining that at least one of the potential routes is a non-recommended route: determining at least one alternative route between the start location and the end location, the at least one alternative route being different from each of the potential routes; evaluating the current traffic conditions of the at least one alternative route; identifying the fastest route from the potential routes and the at least one alternative route based on the current traffic conditions; and transmitting data describing the fastest route to a user computing device.

[0205] The operation may also include receiving multiple potential routes from the user's computing device.

[0206] The operation may also include: receiving a start location and an end location from a user computing device; and determining multiple potential routes, which includes evaluating multiple possible routes to discover recommended routes under free-flow traffic conditions or historical traffic conditions.

[0207] The operation may also include sending multiple potential routes to the user's computing device.

[0208] Determining whether at least one of the potential routes is a non-recommended route based on current traffic conditions may include performing operations, for each of the potential routes: determining the time to traverse the potential route under the current traffic conditions; comparing the time to traverse the potential route under the current traffic conditions with the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; determining whether the comparison indicates that the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions; and identifying the potential route as a non-recommended route in response to determining that the time to traverse the potential route under the current traffic conditions is longer than the time to traverse the potential route under free-flow traffic conditions or historical traffic conditions by a threshold amount.

[0209] The operation may also include sending a confirmation message to the user's computing device by the map service in response to determining that no potential route is a non-recommended route.

[0210] A system may include: one or more processors; and a non-transitory computer-readable medium comprising one or more instruction sequences, which, when executed by the one or more processors, cause the processors to perform operations including: sending a request for route planning information between a start position and an end position to a server computing device; receiving from the server computing device information describing a non-recommended route between the start position and the end position, wherein the non-recommended route is a route recommended under free-flowing traffic conditions or historical traffic conditions, and is determined to have a crossing time under current traffic conditions that is longer than a threshold amount under free-flowing traffic conditions or historical traffic conditions; and displaying an alarm including at least a portion of the information received from the server computing device.

[0211] The operation may also include collecting location information defining a start position and an end position, the collection including identifying the current position and past position of the computing device, and identifying at least one of the current position and the past position as the start position and at least one of the current position and the past position as the end position.

[0212] The request may include a start position and an end position; and the operation may also include: receiving multiple potential routes between the start position and the end position from the server computing device; and storing the multiple potential routes in the memory of the user computing device.

[0213] The request may include multiple potential routes between the start and end points; and a non-recommended route may be one of these multiple potential routes.

[0214] The information from the server device may also include at least one alternative route that is faster than the non-recommended route under current traffic conditions.

[0215] The operation may also include displaying route planning information corresponding to at least a portion of the information in the alert.

[0216] A method may include: determining the location of a user computing device multiple times by a location module of the user computing device; storing the location determined by the location module by a data collection module of the user computing device to create a location record; analyzing the location record by a route planning module of the user computing device to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record by the route planning module; ranking the multiple observed routes by the route planning module based on the count of each route in the location record; receiving multiple suggested routes from a server computing device by the route planning module; associating at least two of the suggested routes with the corresponding observed routes by the route planning module; and displaying route planning information for one of the suggested routes associated with the observed routes, the observed route having the highest ranking among the observed routes associated with the suggested routes by the route planning module.

[0217] The analysis may include fitting at least one of the locations to at least one location on at least one road.

[0218] The counting may include applying a similarity algorithm to at least a first route among the observed routes to determine whether the first route among the observed routes matches at least a second route among the observed routes.

[0219] The method may further include: the route planning module requesting the route planning information from the server computing device; and the route planning module receiving the route planning information from the server computing device.

[0220] The display may include a notification that shows the route planning information.

[0221] This display may include navigation information for that route from among the suggested routes in a map application.

[0222] A method may include: determining the location of a user computing device multiple times by a location module of the user computing device; storing the location determined by the location module by a data collection module of the user computing device to create a location record; analyzing the location record by a route planning module of the user computing device to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record by the route planning module; designating the route with the highest count among the observed routes as the preferred route by the route planning module; and displaying route planning information for the preferred route by the route planning module.

[0223] The method may include the route planning module determining the commuting windows that frequently cross the preferred route during this period.

[0224] The method may include: requesting route planning information from a server computing device by the route planning module during the commuting window; and receiving the route planning information from the server computing device by the route planning module.

[0225] Determining the commuting window may include determining the number of times instances of a user's computing device traversing the preferred route are recorded.

[0226] The display may include a notification that includes the route planning information, or it may include navigation information for that route from a suggested route in a map application.

[0227] A non-transitory computer-readable medium may include one or more instruction sequences that, when executed by one or more processors, cause the processors to perform operations including: determining the location of a user computing device multiple times; storing the location determined by the location module to create a location record; analyzing the location record to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record; ranking the multiple observed routes by counting each route in the location record; receiving multiple suggested routes from a server computing device; associating at least two of the suggested routes with the corresponding observed routes; and displaying route planning information about one of the suggested routes associated with the observed route, the observed route having the highest ranking among the observed routes associated with the suggested route.

[0228] The analysis may include fitting at least one of the locations to at least one location on at least one road.

[0229] The counting may include applying a similarity algorithm to at least a first route among the observed routes to determine whether the first route among the observed routes matches at least a second route among the observed routes.

[0230] The operation may also include: requesting the route planning information from the server computing device; and receiving the route planning information from the server computing device.

[0231] The display may include a notification that shows the route planning information.

[0232] This display may include navigation information for that route from among the suggested routes in a map application.

[0233] A non-transitory computer-readable medium may include one or more instruction sequences that, when executed by one or more processors, cause the processors to perform operations including: determining the location of a user computing device multiple times; storing the location determined by the location module to create a location record; analyzing the location record by a route planning module of the user computing device to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record; designating the route with the highest count among the observed routes as the preferred route; and displaying route planning information for the preferred route.

[0234] The operation may also include identifying commuter windows that frequently cross the preferred route during this period.

[0235] The operation may also include: requesting the route planning information from the server computing device during the commuting window; and receiving the route planning information from the server computing device.

[0236] Determining the commuting window may include determining the number of times instances of a user's computing device traversing the preferred route are recorded.

[0237] The display may include a notification that shows the route planning information.

[0238] This display may include navigation information for that route from among the suggested routes in a map application.

[0239] A system may include: one or more processors; and a non-transitory computer-readable medium comprising one or more instruction sequences that, when executed by the one or more processors, cause the processors to perform operations including: determining the location of a user computing device multiple times; storing the location determined by the location module to create a location record; analyzing the location record to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record; ranking the multiple observed routes by counting each route in the location record; receiving multiple suggested routes from a server computing device; associating at least two of the suggested routes with the corresponding observed routes; and displaying route planning information about one of the suggested routes associated with the observed route, the observed route having the highest ranking among the observed routes associated with the suggested route.

[0240] The analysis may include fitting at least one of the locations to at least one location on at least one road.

[0241] The counting may include applying a similarity algorithm to at least a first route among the observed routes to determine whether the first route among the observed routes matches at least a second route among the observed routes.

[0242] The operation may also include: requesting the route planning information from the server computing device; and receiving the route planning information from the server computing device.

[0243] The display may include a notification that shows the route planning information.

[0244] This display may include navigation information for that route from among the suggested routes in a map application.

[0245] A system may include: one or more processors; and a non-transitory computer-readable medium comprising one or more instruction sequences that, when executed by the one or more processors, cause the processors to perform operations including: determining the location of a user computing device multiple times; storing the location determined by the location module to create a location record; analyzing the location record by a route planning module of the user computing device to identify multiple observed routes traveled by the user computing device; counting instances of the user computing device that traverse each of the multiple observed routes in the location record; designating the route with the highest count among the observed routes as the preferred route; and displaying route planning information for the preferred route.

[0246] The operation may also include identifying commuter windows that frequently cross the preferred route during this period.

[0247] The operation may also include: requesting the route planning information from the server computing device during the commuting window; and receiving the route planning information from the server computing device.

[0248] Determining the commuting window may include determining the number of times instances of a user's computing device traversing the preferred route are recorded.

[0249] The display may include a notification that shows the route planning information.

[0250] This display may include navigation information for that route from among the suggested routes in a map application.

[0251] A method may include: receiving a command for launching a map application on a user computing device, the map application including a fully guided mode configured to display turn-by-turn navigation instructions and a lightly guided mode configured to display light navigation instructions excluding turn-by-turn navigation instructions; determining, based on aspects of the command, whether a route displayed by the map application has been previously traveled by the user computing device or whether the destination of the route has been previously visited by the user computing device; and launching the map application in the lightly guided mode in response to determining that the route has been previously traveled or the destination has been previously visited.

[0252] The method may include: launching the map application in full-guided mode in response to determining that the route has not been previously traveled or the destination has not been previously visited.

[0253] The method may include: collecting commuting information, including start location, end location and departure time, by a data collection module of a user computing device; and defining a commuting window based on the departure time by a route planning module of the user computing device.

[0254] The method may include: determining the current location of the user computing device by a location module of the user computing device; wherein the aspect of the command includes the time and location at which the command was issued; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and the starting location or the location between the starting and ending locations.

[0255] The method may include: determining, by a location module of the user computing device, whether the user computing device is in a moving vehicle; wherein the aspect of the command includes the time at which the command was issued; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and when the user computing device is in the moving vehicle.

[0256] The method may include: a route planning module of a user computing device automatically requesting traffic information between a start location and an end location from a server computer device; the route planning module receiving traffic data from the server computer device in response to the request; and the route planning module displaying a notification including at least a portion of the traffic data; wherein the aspect of the command includes an object selected by the user to issue the command; and wherein the aspect of the command indicates that the route has been previously traveled or the destination has been previously visited when the command is issued from the user who selected the notification to issue the command.

[0257] The mild navigation instruction may include instructions for the next navigation instruction that deviates from the standard navigation instruction.

[0258] The light navigation instructions may include alerts indicating traffic events.

[0259] This light navigation instruction may include displaying a new route in response to traffic events on the current route.

[0260] The method may include: receiving a command for switching between the light boot mode and the full boot mode; and switching from the light boot mode to the full boot mode.

[0261] The method may include: receiving a command for switching between the full boot mode and the light boot mode; and switching from the full boot mode to the light boot mode.

[0262] A non-transitory computer-readable medium may include one or more instruction sequences that, when executed by one or more processors, cause the processors to perform operations including: receiving a command to launch a map application for a user computing device, the map application including a fully guided mode configured to display turn-by-turn navigation instructions and a lightly guided mode configured to display light navigation instructions excluding turn-by-turn navigation instructions; determining, according to aspects of the command, whether a route displayed by the map application has been previously traveled by the user computing device or whether the destination of the route has been previously visited by the user computing device; and launching the map application in the lightly guided mode in response to determining that the route has been previously traveled or the destination has been previously visited.

[0263] The operation may also include: launching the map application in full-guided mode in response to determining that the route has not been previously traveled or the destination has not been previously visited.

[0264] The operation may also include: collecting commuting information including start location, end location and departure time; and limiting the commuting window based on the departure time.

[0265] The operation may further include: determining the current location of the user's computing device; wherein this aspect of the command includes the time and location at which the command was issued; and wherein this aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and the starting location or the location between the starting and ending locations.

[0266] The operation may further include: determining whether the user computing device is in a moving vehicle; wherein the aspect of the command includes the time when the command was issued; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and when the user computing device is in the moving vehicle.

[0267] The operation may further include: automatically requesting traffic information between a start location and an end location from a server computer device; receiving traffic data from the server computer device in response to the request; and displaying a notification including at least a portion of the traffic data; wherein the aspect of the command includes an object selected by the user to issue the command; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued from the user who selected the notification to issue the command.

[0268] The mild navigation instruction may include instructions for the next navigation instruction that deviates from the standard navigation instruction.

[0269] The light navigation instructions may include alerts indicating traffic events.

[0270] This light navigation instruction may include displaying a new route in response to traffic events on the current route.

[0271] The operation may also include: receiving a command to switch between the light boot mode and the full boot mode; and switching from the light boot mode to the full boot mode.

[0272] The operation may also include: receiving a command to switch between the full boot mode and the light boot mode; and switching from the full boot mode to the light boot mode.

[0273] A system may include: one or more processors; and a non-transitory computer-readable medium including one or more instruction sequences that, when executed by the one or more processors, cause the processors to perform operations including: receiving a command to launch a map application for a user computing device, the map application including a fully guided mode configured to display turn-by-turn navigation instructions and a lightly guided mode configured to display light navigation instructions excluding turn-by-turn navigation instructions; determining, based on aspects of the command, whether a route displayed by the map application has been previously traveled by the user computing device or whether the destination of the route has been previously visited by the user computing device; and launching the map application in the lightly guided mode in response to determining that the route has been previously traveled or the destination has been previously visited.

[0274] The operation may also include: launching the map application in full-guided mode in response to determining that the route has not been previously traveled or the destination has not been previously visited.

[0275] The operation may also include: collecting commuting information including start location, end location and departure time; and limiting the commuting window based on the departure time.

[0276] The operation may further include: determining the current location of the user's computing device; wherein this aspect of the command includes the time and location at which the command was issued; and wherein this aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and the starting location or the location between the starting and ending locations.

[0277] The operation may further include: determining whether the user computing device is in a moving vehicle; wherein the aspect of the command includes the time when the command was issued; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued at the time and location of the commuting window, and when the user computing device is in the moving vehicle.

[0278] The operation may further include: automatically requesting traffic information between a start location and an end location from a server computer device; receiving traffic data from the server computer device in response to the request; and displaying a notification including at least a portion of the traffic data; wherein the aspect of the command includes an object selected by the user to issue the command; and wherein the aspect of the command indicates that the route had previously been traveled or the destination had previously been visited when the command was issued from the user who selected the notification to issue the command.

[0279] The mild navigation instruction may include instructions for the next navigation instruction that deviates from the standard navigation instruction.

[0280] The light navigation instructions may include alerts indicating traffic events.

[0281] This light navigation instruction may include displaying a new route in response to traffic events on the current route.

[0282] The operation may also include: receiving a command to switch between the light boot mode and the full boot mode; and switching from the light boot mode to the full boot mode.

[0283] The operation may also include: receiving a command to switch between the full boot mode and the light boot mode; and switching from the full boot mode to the light boot mode.

[0284] Although various implementation schemes have been described above, it should be understood that they are presented merely as examples and not as limitations. Various changes in form and detail may be made without departing from the substance and scope, which will be apparent to those skilled in one or more related fields. In fact, after reading the above instructions, how to implement alternative implementation schemes will be obvious to those skilled in one or more related fields.

[0285] Furthermore, it should be understood that any figures emphasizing functionality and advantages are used only as examples. The disclosed methods and systems are each flexible and configurable enough to be utilized in ways other than those shown.

[0286] While the term “at least one” is commonly used in the specification, claims and drawings, the terms “a / an,” “the,” “the,” etc., also mean “at least one” or “the at least one” in the specification, claims and drawings.

[0287] Finally, the applicant intends that claims including only the expressions "apparatus for..." or "steps for..." are to be interpreted under 35 USC 112(f). Claims that do not expressly include the phrases "apparatus for..." or "steps for..." should not be interpreted under 35 USC 112(f).

Claims

1. A method for route planning, the method comprising: The user's computing device's route planning module sends a first request to the map service for route planning information between the starting and ending locations; The route planning module of the user computing device receives multiple potential recommended routes between the starting location and the ending location from the map service in the first instance, wherein the multiple potential recommended routes are expected to be the fastest under free-flow traffic conditions or historical traffic conditions; The route planning module stores the multiple potential recommended routes in the storage device of the user's computing device; At a second time following the first time point, it is determined that a recommended route should be presented to the user; It is determined that the multiple potential recommended routes stored exist in the storage device; Based on the determination that the stored multiple potential recommended routes exist, the route planning module sends a second request to the map service for route planning information between the same start position and the same end position indicated in the first request, the second request including the stored multiple potential recommended routes previously received from the map service; The route planning module receives an evaluation result from the map service, the evaluation result indicating one or more of the stored potential recommended routes sent by the route planning module to the map service, the one or more routes having a crossing time greater than a threshold amount under the current traffic conditions or under the free-flow traffic conditions or the historical traffic conditions. The route planning module selects multiple recommended routes for the user of the user computing device from the multiple potential recommended routes based on user behavior data. The user behavior data represents historically observed travel patterns, and the travel patterns predict the probability that the user will travel along the routes in the potential recommended routes. Based on the evaluation results received from the map service, the first route among the multiple recommended routes is determined to be a non-recommended route; as well as The user's computing device presents an alert that includes a suggestion to avoid the first route.

2. The method of claim 1, further comprising: The user computing device's data collection module collects location information defining the start position and the end position. The collection includes identifying the current position and the past position of the user computing device, and identifying at least one of the current position and the past position as the start position and at least one of the current position and the past position as the end position.

3. The method according to claim 1, wherein the request includes the start position and the end position, and the method further includes: The route planning module receives the multiple potential recommended routes between the start and end locations from the map service. as well as The route planning module stores the multiple potential recommended routes in the storage device of the user computing device.

4. The method according to claim 3, The map service uses a first amount of processing resources to evaluate whether to recommend the multiple potential routes, and The sending process causes the map service to use a second amount of processing resources to evaluate whether to recommend the multiple potential routes, where the second amount of processing resources is less than the first amount of processing resources.

5. The method according to claim 1, further comprising: Determine at least one alternative route that is faster than the first route under the current traffic conditions; as well as The alert presents suggestions including using at least one alternative route and suggestions to avoid the first route.

6. The method of claim 5, further comprising displaying route planning information corresponding to the at least one alternative route.

7. The method of claim 1, further comprising receiving information describing the first route from the map service, wherein the information describing the first route includes a destination ID for the first route and an event ID for a specific current traffic condition on the first route, the method further comprising storing the destination ID, the event ID, and a timestamp in the storage device of the user computing device, the timestamp indicating when the information describing the first route was received.

8. The method according to claim 7, further comprising: Receive a second set of information from the map service describing a second route between the start location and the end location, the second set of information including the same destination ID for the first route and the same event ID for the first route; as well as The user computing device suppresses a second alarm, which includes at least a portion of the second set of information received from the map service.

9. A non-transitory computer-readable medium comprising one or more instruction sequences, which, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 8.

10. A system for route planning, the system comprising: One or more processors; as well as A non-transitory computer-readable medium comprising one or more instruction sequences, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 8.

11. A method for route planning, the method comprising: The map service of the computing device evaluates the current traffic conditions for multiple potential routes between the start and end locations, where each potential route is a route recommended under free-flow traffic conditions or historical traffic conditions; The map service determines, based on the current traffic conditions, whether at least one of the multiple potential routes is a non-recommended route; as well as In response to determining that at least one of the plurality of potential routes is a non-recommended route: The map service determines at least one alternative route between the start location and the end location, the at least one alternative route being different from each of the plurality of potential routes; The map service assesses the current traffic conditions for the at least one alternative route; Based on the current traffic conditions, identify the fastest route from among the multiple potential routes and the at least one alternative route; as well as The map service will send data describing the fastest route to the user's computing device. The data describing the fastest route includes a destination identifier for the fastest route and information corresponding to the current traffic conditions on the fastest route.

12. The method of claim 11, further comprising receiving the plurality of potential routes from the user computing device at the map service.

13. The method of claim 11, further comprising: The starting location and the ending location are received from the user's computing device at the map service. as well as The map service determines the multiple potential routes, and the determination includes evaluating multiple possible routes to discover recommended routes under the free-flow traffic conditions or the historical traffic conditions.

14. The method of claim 13, further comprising sending the plurality of potential routes to the user computing device by the map service.

15. The method of claim 11, wherein determining whether at least one of the plurality of potential routes is the non-recommended route based on the current traffic conditions includes, for each of the potential routes: The map service determines the time required to traverse the potential route under the current traffic conditions. The map service compares the time taken to cross the potential route under the current traffic conditions with the time taken to cross the potential route under the free-flow traffic conditions or the historical traffic conditions. The map service determines whether the comparison indicates that the time taken to traverse the potential route under the current traffic conditions is longer than the time taken to traverse the potential route under the free-flow traffic conditions or the historical traffic conditions; as well as In response to determining that the time taken to traverse the potential route under the current traffic conditions is longer than the time taken to traverse the potential route under the free-flow traffic conditions or the historical traffic conditions by a threshold amount, the map service identifies the potential route as the non-recommended route.

16. The method of claim 11, further comprising, in response to determining that none of the potential routes is a non-recommended route, the map service sending a confirmation message to the user computing device.

17. The method of claim 11, wherein the information corresponding to the current traffic conditions on the fastest route includes an event identifier for a specific current traffic condition on the fastest route.

18. A non-transitory computer-readable medium comprising one or more instruction sequences, said one or more instruction sequences causing said one or more processors, when executed by said one or more processors, to perform the method according to any one of claims 11 to 17.

19. A system for route planning, the system comprising: One or more processors; as well as A non-transitory computer-readable medium comprising one or more instruction sequences, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 11 to 17.

Images