Method and apparatus for route feature determination and presentation

Abstract

The present disclosure provides "Methods and Devices for Route Feature Determination and Presentation". A system includes a processor configured to receive a set of user attribute preferences for a trip. The processor is further configured to determine multiple trip routes that have a change in the value of at least one user attribute preference compared to other routes in the routes. The processor is further configured to present the multiple routes in a selectable manner, including displaying the attribute values associated with each route and implementing navigation for the selected route.

Description

Technical Field

[0001] Exemplary embodiments generally relate to methods and apparatus for route feature determination and presentation. Background Art

[0002] As vehicle mobility changes from humans as drivers to computers as drivers, people will spend less time operating the vehicle and can pay additional attention to other aspects of mobility. As part of the overall experience, an effective and personalized way of navigating, route selection, and communicating with the user may be important as the world adopts personalized autonomous vehicles (AVs). During the destination selection and subsequent route selection process, typical definitions of travel attributes such as travel time and distance may need to be supplemented with additional or other attributes.

[0003] Systems have been proposed for automatically summarizing frequently visited locations and associated loop routes. Basic travel information such as travel time, travel distance, and stop duration can be initialized (using the first observation) and then incrementally updated with subsequent repeats. Alternatively, if those data sets are available, user-managed location and route information can also be used for the same purpose. Summary of the Invention

[0004] In a first exemplary embodiment, a system includes a processor configured to receive a group of user attribute preferences for a trip. The processor is further configured to determine multiple trip routes that have a change in the value of at least one user attribute preference compared to other routes in the group. The processor is further configured to present the multiple routes in a selectable manner, including displaying the attribute values associated with each route and implementing navigation for the selected route.

[0005] In a second exemplary embodiment, a system includes a processor configured to receive a group of route attributes. The processor is further configured to sort the group of attributes based on route features corresponding to the attributes of the travel route. The processor is further configured to determine multiple routes to an input destination. Additionally, the processor is configured to present an ordered, pre-defined number of multiple routes in a list-selectable manner, the multiple routes being sorted and selected based on the sorted group of attributes, and to use one of the selected routes in the group for navigation.

[0006] In a third illustrative embodiment, a computer-implemented method includes determining a route context associated with a received destination based on features of the destination. The method further includes retrieving user-defined attributes that define user route selection preferences stored in association with the context. The method further includes presenting a list of selectable, pre-defined routes selected from a plurality of routes based on presented routes having attribute values that exhibit the closest correlation with the preferences; and navigating to the destination using the selected route. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An illustrative vehicle computing system is shown;

[0008] Figure 2 An illustrative example of a trip review and presentation process is shown;

[0009] Figure 3 An illustrative example of an attribute ranking process is shown;

[0010] Figure 4 A series of illustrative display windows are shown; and

[0011] Figure 5 An illustrative route presentation display is shown. DETAILED DESCRIPTION

[0012] As needed, detailed embodiments are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative and may be incorporated in various and alternative forms. The drawings are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be construed as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

[0013] Figure 1 An exemplary block topology of a vehicle-based computing system 1 (VCS) for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computing system may contain a visual front-end interface 4 located in the vehicle. If the interface has, for example, a touch screen display, the user can also interact with the interface. In another illustrative embodiment, the interaction occurs via button presses, a spoken dialogue system with automatic speech recognition, and speech synthesis.

[0014] In Figure 1In the illustrative Example 1 shown, the processor 3 controls at least a portion of the operation of the vehicle-based computing system. The processor provided within the vehicle allows for on-board processing of commands and routines. Additionally, the processor is connected to a non-persistent memory 5 and a persistent memory 7. In this illustrative example, the non-persistent memory is a random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or a flash memory. Generally, persistent (non-transitory) memory can include all forms of memory that maintain data when a computer or other device is powered down. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid state drives, portable USB drives, and any other suitable form of persistent memory.

[0015] The processor is also equipped with a number of different inputs, allowing the user to interface with the processor. In this illustrative example, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which can be a touch screen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The inputs from the microphone and the auxiliary connector are converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, many vehicle components and auxiliary components that communicate with the VCS can use a vehicle network (such as, but not limited to, a CAN bus) to transfer data to and from the VCS (or its components).

[0016] The output of the system can include, but is not limited to, a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives an amplifier signal from the processor 3 via a digital-to-analog converter 9. Output can also be transmitted to a remote Bluetooth device such as a PND 54 or a USB device such as a vehicle navigation device 60 along the bi-directional data streams shown at 19 and 21, respectively.

[0017] In one illustrative example, the system 1 uses a Bluetooth transceiver 15 to communicate 17 with a user's roaming device 53 (e.g., a cellular phone, a smart phone, a PDA, or any other device having a wireless remote network connection). The roaming device (hereinafter referred to as the ND) 53 can then be used to communicate 59 with a network 61 external to the vehicle 31, for example, via communication 55 with a cellular tower 57. In some embodiments, the tower 57 can be a Wi-Fi access point.

[0018] An exemplary communication between the ND 53 and the Bluetooth transceiver 15 is represented by signal 14.

[0019] Pairing of the ND 53 and the Bluetooth transceiver 15 can be indicated by a button 52 or a similar input. Thus, it is indicated that the on-board Bluetooth transceiver of the CPU will pair with the Bluetooth transceiver in the roaming device.

[0020] Data can be communicated between the CPU 3 and the network 61 using, for example, a data plan, voice-over-data, or DTMF tones associated with the ND 53. Alternatively, it may be desirable to include a vehicle modem 63 having an antenna 18 to communicate 16 data between the CPU 3 and the network 61 via the voice band. Then, the ND 53 can be used to communicate 59 with the network 61 external to the vehicle 31, for example, via communication 55 with a cellular tower 57. In some embodiments, the modem 63 can establish communication 20 with the tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem, and the communication 20 can be cellular communication.

[0021] In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communicating with the modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as those found in roaming devices). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. The IEEE 802 LAN (Local Area Network) protocol includes Wi-Fi and has a fair amount of cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another means of communication that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0022] In another embodiment, the ND 53 includes a modem for voice band or broadband data communication. In a voice-over-data embodiment, a technique called frequency division multiplexing can be implemented when the owner of the roaming device can talk on the device while transmitting data. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing may be common for analog cellular communication between a vehicle and the Internet and is still in use, it has largely been replaced by a hybrid of code division multiple access (CDMA), time division multiple access (TDMA), and space division multiple access (SDMA) for digital cellular communication. If the user has a data plan associated with the roaming device, the data plan may allow broadband transmission, and the system can use a wider bandwidth (to accelerate data transfer). In yet another embodiment, the ND 53 is installed in place of a cellular communication device (not shown) of the vehicle 31. In yet another embodiment, the ND 53 can be a wireless local area network (LAN) device capable of communicating via, for example, (but not limited to) an 802.11g network (i.e., Wi-Fi) or a Wi-Max network.

[0023] In one embodiment, input data may be passed through the roaming device via voice-carried data or a data plan, through the vehicle Bluetooth transceiver and into the vehicle's internal processor 3. In the case of certain transient data, for example, the data may be stored on the HDD or other storage medium 7 until the data is no longer needed.

[0024] Additional sources that may interface with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an in-vehicle GPS device 24, or a remote navigation system (not shown) having a connection to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony) and Lynx TM (Texas Instruments)), EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of the device-device serial standards. Most of the protocols can be implemented for either electrical or optical communication.

[0025] In addition, the CPU may communicate with a variety of other auxiliary devices 65. These devices may be connected via wireless 67 or wired 69 connections. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless health devices, portable computers, and the like.

[0026] Moreover, or alternatively, the CPU may connect to a vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) 71 transceiver. This may allow the CPU to connect to a remote network within the range of the local router 73.

[0027] In addition to having the exemplary processes executed by a vehicle computing system located in a vehicle, in some embodiments, the exemplary processes may be executed by a computing system in communication with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., without limitation, mobile phones) or remote computing systems (e.g., without limitation, servers) connected via a wireless device. These systems may be collectively referred to as vehicle-related computing systems (VACS). In some embodiments, specific components of the VACS may perform specific parts of the processes according to the specific implementation of the system. By way of example and not limitation, if a process has a step of sending or receiving information using a paired wireless device, it is likely that the wireless device is not performing that part of the process, as the wireless device will not use its own "send and receive" information. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0028] In each of the illustrative embodiments discussed herein, an exemplary non-limiting example of a process that may be executed by a computing system is shown. With respect to each process, for the limited purpose of executing the process, it is possible for the computing system executing the process to be configured as a dedicated processor to execute the process. All processes need not be executed in their entirety and are understood to be examples of the types of processes that may be executed to implement the elements of the present invention. Additional steps may be added or removed from the exemplary processes as needed.

[0029] With respect to the illustrative embodiments described in the figures showing illustrative process flows, it should be noted that, for the purpose of executing some or all of the exemplary methods shown in these figures, a general-purpose processor may be temporarily enabled as a dedicated processor. When executing code that provides instructions to perform some or all of the steps of the method, the processor may temporarily change to act as a dedicated processor until the method is completed. In another example, to the extent appropriate, firmware acting on a pre-configured processor may cause the processor to act as a dedicated processor provided for the purpose of executing the method or some reasonable variation thereof.

[0030] The illustrative embodiments contemplate highly configurable travel scouting that can always analyze travel data, present the information most relevant to the user, and enable the user to define, share, and use other user-defined travel attributes to analyze their own (frequent) travel. As a result, the user will be able to learn more about a route from different customizable perspectives (post-trip and pre-trip preview) and make choices that best suit the user's needs and preferences.

[0031] The initial set of basic properties that can be considered by the navigation "scouting" process (so-called because it "scouts" various routes based on user-specified parameters) can include properties such as the following: time and distance (traditional properties of a navigation route), as well as the predicted required fuel quantity, the expected average fuel economy, and the severity and duration of determined traffic stops. Many existing navigation systems can provide the above properties by referring to present values at remote locations (e.g., there is a traffic jam twenty miles down the road right now). However, typically, this information does not reflect the expected situation when the user arrives (e.g., there is a traffic jam twenty miles down the road right now, but the expected / predicted traffic jam will clear by the time the user arrives, so the current traffic is largely irrelevant to the user).

[0032] In addition, the user can specify or make selections from an extended list of properties. Usually, these properties will correspond to some data that can be confirmed by the navigation system, but the properties are not always explicitly related to navigation. For example, the user can specify that the route passes by a park or a lake or a landscape, and as long as the navigation system can confirm those features of the terrain in some way, the said properties can be taken into account.

[0033] The scouting process can also access selectable advanced navigation-related features. This may include, for example:

[0034] Number of left turns - Since left turns generally will involve stopping the vehicle for variable durations, this can have a negative impact on the total travel time and fuel economy (except for hybrid and electric vehicles, which benefit from regenerative braking).

[0035] Low-speed time / idle time / moving time - If the trip has an average speed distribution with respect to time, then the smoothness of the vehicle movement for that trip can be quantified. The partitioning (slow / stop / fast) may be finer to involve different speeds, but at least this can capture whether the vehicle is stalled (in a traffic jam or under traffic control), moving slowly, or moving freely. This can provide a granularity of the travel time and show the user routes with a high frequency of fast-moving segments, even if that route is not the shortest route.

[0036] Road type - It can provide information on whether suburban, regular local roads, or highway driving is part of the proposed route. When the user changes the settings in the navigation to adopt a certain preference, the user can find out that they are driving near a community, which may be something the user is trying to avoid to reduce risks to children and pets.

[0037] Weather changes ahead - A look-ahead type can be a useful and appropriate integration for showing or notifying the user about the weather, especially when traveling along a longer route. When traveling along a longer route, only a portion of that route may be affected by bad weather or other disruptions that may make the journey inconvenient (e.g., road works). If creating too much content with the details of the entire route, a simple rule of showing only "less than ideal" conditions or certain specific conditions can be implemented.

[0038] Points of interest (POIs) along the way - Integrating multiple trips is one of the best ways to save on the total cost associated with personal mobility. This kind of planning can be facilitated by integrating the user's calendar and / or by using a learned location model. A prediction model can provide a list of potential locations that the user may visit in the near future given a particular context (number of days, time, and current location). Additionally, a list of the most frequently visited locations overall can also be used for the same purpose. Providing such information during trip planning gives the user the opportunity to create a multi-stop trip that includes locations the user expects but may have forgotten.

[0039] Finding cheap gas stations / gas refueling services and deals along the way - Personal mobility scouting can also evaluate the vehicle's operating requirements to ensure the vehicle runs healthily and that the energy needed for subsequent trips is replenished accordingly. If the expected fuel is below a defined minimum value, the integration of refueling services can include this data as part of the trip plan. This can also take into account the user's preference for branded fuel. If the fuel level is not dangerously low, the user's preference may prominently influence the fuel demand. On the other hand, if the fuel level is dangerously low, refueling in the near future may supersede the user's brand preference. Depending on the likely duration of stay at the current or next location, on-demand refueling services (bringing fuel to the driver) may be of concern, especially if service providers are running promotions in the area or the duration of the stay is long enough for these service providers to offer discounts for non-emergency refueling.

[0040] Usage in the past X days - This value represents the number of times a specific route has been selected in the past X days. This data shows the user how many times they have used a certain route compared to other alternative routes.

[0041] Figure 2An illustrative example of a trip sharing and presentation process is shown. In this illustrative example, the process receives 201 the user destination and collects 203 any current user input regarding variables that affect immediate travel. For example, if the user is entering a destination, the user can select "travel speed" during entry even if fast travel is not typically important to the user. This data is combined 205 with any pre-defined user preference data, and the process determines 207 different groups of route options that differ from each other by at least one attribute value. The specific attributes considered may vary from user to user, so one user may be concerned with travel time and fuel, while another user may only be concerned with routes with less parking and the scenery near the route (such as parks and lakes).

[0042] Then, the process presents 209 the optional route options, and if the user selects one of the options in 211, the process can use the selected travel 221 as the preferred travel. Depending on which attributes dominate the selected route (e.g., whether the route is the "best" choice regarding certain attributes), the process can also update 223 the user data to reflect the selected option. This update can be used to predict the user's preferred routes and may result in more routes that focus on the preferred attributes when presenting routes next time. The predictive nature can depend on the context (day of the week, date, time, weather, etc.) or may generally only use the data predictably (e.g., every time any routes are presented).

[0043] If no route is selected, the user can prioritize 213 a certain attribute (e.g., travel time) or disable 217 a certain attribute (e.g., fuel economy). The user can prioritize an attribute to view a new group of route options that mainly focus on the prioritized attribute. In a similar manner, the user can disable an attribute so that the process reconsiders the routes without considering the disabled attribute. Prioritizing one or more attributes results in re-weighting 215 these attributes, and disabling an attribute results in removing 219 the attribute from consideration. Then, the process derives new possible routes and presents these routes for selection.

[0044] Figure 3 An illustrative example of an attribute sorting process is shown. This process can occur when a series of route options are presented to the user and the user selects, deselects, or re-orders the weights of the preferences. Personal preferences (attributes) can be presented as optional options, and the selection of an option can provide the user with the choice to move the option up or down in the preference list.

[0045] Process 301 presents the attributes as part of the displayed route group or, in another example, as a separate ordered list based on the current ranking. The user can select 303 the attributes for re-ranking, and the user can input 305 a new ranking or weight for the attributes. Then, the process can apply 307 the new weighting, and the process can repeat until all attributes have been re-weighted.

[0046] The weighting of attributes can be relevant because there may technically be thousands of route options between the current location and the destination. By selecting a limited set based on weighted attributes, a discrete number of options that most likely correspond to the user's preferences are presented to the user. Re-weighting the options can result in a partially or completely different route group.

[0047] In another example, the process can start with a user-defined group of attributes and / or an OEM-defined group of attributes. Then, the process can examine the routes the user has traveled and determine which attributes seem more important to the user. This can provide an ordered-ranked group of base attributes for initial route selection. This observation can also lead to including one or more new attributes in the attribute list to account for frequent commonalities on the route that may not be addressed by any currently selected attributes.

[0048] Figure 4 A series of illustrative display windows are shown. This is a purely illustrative concept and is not intended to limit the scope of the invention in any way, but rather to show the possible display of travel attributes in a configurable manner. In this example, the display shows a first set of travel settings 401 that includes various common travel types. These common travel types include, but are not limited to, commuting to work 403, commuting home from work 407, shopping trips 411, and leisure trips 415.

[0049] If a sufficient number of similar trips have been observed to characterize these trips as occurring frequently at certain times, the process includes the start 405 time and end 409 time of the observed trip. For trips that occur more randomly (e.g., shopping, leisure), the process may not set any time 413. Selection of a particular travel type can cause the display to branch 420 to a sub-menu to obtain configurable attributes for that trip.

[0050] In this example, selecting "Commute to Work" will branch to screen 421, which provides an estimated start 423 time and end 425 time. Here, the user can manually adjust the preferences to better capture the timing, which can be particularly useful for accurately reflecting the new commute for a new job if the user changes jobs.

[0051] Since this is an observed frequent trip, the destination 427 attributes may also be known. Thus, if the user enters a destination corresponding to the destination attributes, the process may consider the trip as a commuting trip even if the trip falls outside the normal time for commuting trips. Since a "commute home" trip has the home location as the destination, the process may choose not to always select "commute home" as the trip type when "home" is the destination, since almost every trip of any type will eventually end at home.

[0052] The attributes window also shows the current sorting 429 of the attributes (and the weighting if required), where the current sorting 429 defines the basis for route selection based on the user-preferred sorting. The sorting may also define what data sets to show the user when presenting an ordered list of possible routes (e.g., show the representations of the top 3 attributes). Here, the user can slide the attributes up or down, or even in some examples adjust the direct weighting and / or select certain attributes for display even if the attributes are not among the top N.

[0053] The leisure window 431 is similar to the commute to work window, except that there is no defined regular start or end time for leisure trips. Instead, the destination has a destination category 433 that defines when a trip is leisure. Thus, in this example, if the destination corresponds to a park, golf course, or lake, the trip is considered leisure and leisure parameters 435 are used in determining which routes to show and which attributes to show with each route. Other attributes can be added to the list based on the available route / map data, and attributes can also be removed or disabled from the given list.

[0054] Figure 5 An illustrative route presentation display 501 is shown. In this example, the process shows multiple "commute home" trips, all having a common starting point 503 and destination 505. A simple name 507 for each route is shown, where the simple name 507 can be a user-defined name or, as in this example, represents the main road on which most of the trip occurs.

[0055] In this example, the parameters / attributes shown include the distance per trip 509, the suggested start time 511, the estimated travel time 413, and the average fuel economy 515. Although these are the only parameters shown in this example, the user can, for example, select "scenery" as the highest priority weighting, so the user knows that all nine trips have a scenery component. Even if no parameters or values for the scenery attribute are shown, the multiple trips can be sorted in order from most scenic to least scenic. By allowing the user to define trip characteristics and then showing the possible trips that exhibit those characteristics, as well as showing certain characteristics that allow the user to make a better decision, the user can make an informed choice of the route that is most likely to be enjoyable or meet the user's needs.

[0056] User data and selection options can also be shared among users. An efficient user can share the attribute rankings with others who are interested in driving speed or multi-stop trips, and a relaxed user can share the attribute rankings with others who are interested in "fun" trips, which may be slower in terms of arrival. Additionally, in this example, the selection of any individual attribute can cause the trips to be reordered corresponding to the selected attribute. In one example, the attributes shown are the attributes with the greatest differences across trips, and in another example, the attributes shown correspond to whatever the user specifies for display.

[0057] If the user prefers a visual data set with less numerical information, the user can view each route as a horizontal bar with color changes corresponding to the unfavorable characteristics. The entire bar will represent the entire trip, and the portions of the bar colored with different shapes (e.g., green, yellow, or red) will indicate the areas where the user is likely to experience aspects of the drive that least correspond to the user's preferences. So, if there are a large number but short stops along the route (e.g., a series of stop signs), and the user prefers "motion" above all else, the user can view a bar with frequent and short red areas scattered throughout, and can decide to skip a bar that is mostly green in other locations (meaning closely related to the preference) because of all the stops. Alternatively, the user can select a bar with less green but only one long red area, so the user knows that motion is possible for almost the entire trip and only one impactful delay is expected.

[0058] The foregoing might be the display situation where the user selects "motion" as the display characteristic on the bar, and such data can also be displayed more effectively on a bar graph where the actual stop locations can be visualized, which is different from a chart where numerical values (e.g., "11 stops") may not convey the full impact of the data.

[0059] For a given set of routes, they can be sorted in various ways, such as considering the respective attribute values of each route with respect to a given attribute. For example, if the attribute is "scenery", the attribute value could be the total distance of the route adjacent to "scenery" terrain. If the attribute is fuel economy, the expected fuel economy over the entire route could be the attribute value. As long as the system uses a sortable set of values for a given attribute, it does not matter whether the values are discrete (e.g., a specific number) or less defined (e.g., high, medium, low), because any sorting of the attributes is generally done within the range of the given attributes applied to each route. Thus, even binary (yes / no, or has / does not have) attribute values provide some degree of sorting. If the initial sorting does not result in a fully ordered list (i.e., the binary case where half of the routes are "has" and the other half of the routes are "does not have"), a second layer of sorting (and subsequent sortings) based on the second highest weighted attribute can also be applied.

[0060] While the exemplary embodiments are described above, it is not meant that these embodiments describe all possible forms of the invention. Rather, the words used in this specification are descriptive rather than restrictive words, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of the various implementation embodiments can be combined in a logical manner to produce contextually appropriate variations of the embodiments described herein.

[0061] According to the present invention, a system includes a processor configured to receive a set of user attribute preferences for a trip; determine a plurality of trip routes that have a variation in values of at least one user attribute preference compared to other routes in the set; present the plurality of routes in a selectable manner, including displaying the attribute values associated with each route; and implement navigation for the selected route.

[0062] According to one embodiment, the attribute preferences are weighted relative to each other, and wherein determining the plurality of routes includes determining a predefined number of routes from all possible routes that have the highest correlation with the weighted attribute preferences in terms of attribute values.

[0063] According to one embodiment, the processor is configured to sort the presentation of the plurality of routes based on the most preferred attribute.

[0064] According to one embodiment, the processor is configured to display a predefined number of attribute values associated with each route based on which user attribute in the set of user attributes exhibits the greatest variation in values between the routes.

[0065] According to one embodiment, the processor is configured to display a predefined number of attribute values associated with each route based on user preferences that define which attribute values are to be displayed.

[0066] According to one embodiment, the processor is configured to present the plurality of routes as an ordered list of routes, the ordered list of routes including attribute values associated with each route.

[0067] According to one embodiment, the attribute values include a plurality of attribute values, and wherein the processor is configured to receive a selection of an attribute value and reorder the list based on the selected attribute value.

[0068] According to one embodiment, the processor is configured to present the plurality of routes as a bar chart, each route including an indicator of a different color, the indicator of the different color indicating at which positions attributes from the group of attributes have values corresponding to a predefined non-preferred version of the attribute.

[0069] According to one embodiment, the processor is configured to predict a route type based on the environment and receive a group of attributes corresponding to the route type from a predefined set associated with the type of route stored in a memory.

[0070] According to one embodiment, the context includes a starting location.

[0071] According to one embodiment, the context includes a destination.

[0072] According to one embodiment, the context includes a destination type.

[0073] According to one embodiment, the context includes the time of day and / or day of the week.

[0074] According to the present invention, a system includes a processor configured to receive a group of route attributes; sort the group of attributes based on route features corresponding to attributes of a driving route; determine multiple routes to an input destination; present an ordered predefined number of multiple routes in a list-selectable manner, the multiple routes being sorted and selected based on the sorted group of attributes; and use a selected one of the routes for navigation.

[0075] According to one embodiment, the group of route attributes is user-defined.

[0076] According to one embodiment, the group of route attributes is manufacturer-defined.

[0077] According to one embodiment, at least a part of the group of route attributes is received wirelessly from a user system remote from the processor.

[0078] According to one embodiment, the presentation includes presenting, for a plurality of attributes from the group, the attribute values of each route in the routes corresponding to the attribute values of each route.

[0079] According to the present invention, a computer-implemented method includes: determining a route context associated with a received destination based on characteristics of the destination; retrieving user-defined attributes that define user route selection preferences saved in association with the context; presenting a list of selectable, pre-defined routes, the route list being selected from multiple routes based on routes having attribute values that exhibit the closest correlation with the preferences; and navigating to the destination using the selected route.

[0080] According to the present invention, a method includes sorting a route list based on the attribute values of each route corresponding to the highest weighting of user-defined attributes.

Claims

1. A system for route determination and presentation, the system comprising: A processor configured to: Receive a user-defined set of user attribute preferences for a trip, the user-defined user attribute preferences defining which attributes are to be analyzed along multiple potential routes to a requested destination; Determine multiple trip routes to the requested destination, the multiple trip routes having a change in numerical values for two or more user attribute preferences from the user-defined set of user attribute preferences compared to other routes among the multiple potential routes; Present the multiple trip routes in an optional manner, including displaying at least one attribute value for a given trip route among the multiple presented trip routes, the at least one displayed attribute value corresponding to at least one user attribute preference among the two or more user attribute preferences having a change in numerical value for the given trip route, wherein the at least one attribute value to be displayed is determined based on: the change in numerical value for the at least one of the two or more user attribute preferences between routes being greater than the change in numerical value for other user attribute preferences among the two or more user attribute preferences between routes; And Implement navigation for the selected route.

2. The system according to claim 1, wherein, The attribute preferences are weighted relative to each other, and wherein determining the multiple trip routes includes determining a pre-defined number of routes from all potential routes to the requested destination, the pre-defined number of routes having the highest correlation with the weighted attribute preferences in terms of attribute values.

3. The system according to claim 1, wherein, The processor is further configured to: sort the presentation of the multiple trip routes based on the most preferred attribute and display the attribute value associated with the most preferred attribute.

4. The system according to claim 1, wherein, The processor is further configured to: additionally display a pre-defined number of attribute values associated with each trip route based on user preferences that define which attribute values are to be displayed.

5. The system according to claim 1, wherein, The processor is further configured to: present the multiple trip routes as an ordered list of routes, the ordered list including the attribute values for the attribute preferences associated with each trip route.

6. The system according to claim 5, wherein, The processor is further configured to: display multiple attributes associated with each trip route, receive a selection of an attribute and re-order the list based on the selected attribute such that the route with the preference closest to the selected attribute is presented at the front of the list.

7. The system according to claim 1, wherein, The processor is further configured to: present the multiple trip routes as a bar graph, each trip route including an indicator of a different color, the different color indicators indicating at which locations the attributes from the user attribute preference group have values corresponding to a pre-defined non-preferred version of the attribute.

8. The system according to claim 1, wherein, The processor is further configured to: predict a route type based on context and receive a set of user attribute preferences corresponding to the route type from a pre-defined set associated with the route type stored in a memory.

9. The system according to claim 8, wherein, The context includes a start location or a destination.

10. The system according to claim 8, wherein, The context includes a destination type.

11. The system according to claim 8, wherein, The context includes the time of day and / or day of the week.

12. The system according to claim 1, wherein, The processor is further configured to: Receive a set of route attributes; Sort the route attribute group based on route features corresponding to the attributes of the driving route, where the driving route is a previously traveled route for which the current navigation route is requested, and the sorting places the route attributes that occur more frequently earlier based on the occurrence of a given attribute for the driving route; Determine multiple routes to the input destination; Present an ordered, pre-defined number of multiple routes in a list-selectable manner, where the multiple routes are sorted and selected based on the sorted route attribute group, and the multiple routes are presented as bar graphs, where each bar graph includes multiple indicators of different colors, and the multiple indicators of different colors indicate at which positions the attributes from the route attribute group have multiple values corresponding to a pre-defined non-preferred version of the attribute; And Use one of the selected routes in the route for navigation.

13. The system according to claim 12, wherein, The route attribute group is user-defined.

14. The system according to claim 12, wherein, The route attribute group is manufacturer-defined.

15. The system according to claim 12, wherein, Wirelessly receive at least a portion of the route attribute group from a user system remote from the processor.

16. A method for route determination and presentation, the method comprising: Receive a user-defined user attribute preference group for a trip, where the user-defined user attribute preference defines which attributes are to be analyzed along multiple potential routes to a requested destination; Determine multiple trip routes to the requested destination, where the multiple trip routes have a change in the numerical values of two or more user attribute preferences from the user-defined user attribute preference group compared to other routes among the multiple potential routes; Present the multiple trip routes in a selectable manner, including displaying at least one attribute value for a given trip route among the presented multiple trip routes, where the at least one displayed attribute value corresponds to at least one user attribute preference among the two or more user attribute preferences having a change in numerical value for the given trip route, and where the at least one attribute value to be displayed is determined based on: the change in the numerical value of the at least one of the two or more user attribute preferences between routes is greater than the change in the numerical values of the other user attribute preferences among the two or more user attribute preferences between routes; And Implement navigation for the selected route.

Images