Patent Description:
Therefore, there is need for an approach for generating and using a passenger-based driving profile of a vehicle (e.g., an autonomous vehicle or other vehicle in which a user is not actively driving).

The present invention comprises a method, an apparatus, and computer program code as defined in the claims. Embodiments that do not fall within the scope of the claims are to be interpreted as examples useful for understanding the invention.

According to one embodiment, a computer-implemented method as set out in claim <NUM> is provided.

According to another embodiment, an apparatus as set out in claim <NUM> is provided.

According to another embodiment, a computer program code as set out in claim <NUM> is provided.

Examples of a method, apparatus, and computer program for determining a driving profile of an autonomous vehicle are disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.

Although various embodiments are described with respect to an autonomous vehicle, it is contemplated that the approaches of the various embodiments described herein are applicable to highly-assisted driving (HAD) vehicles as well as to manually driven vehicles. Moreover, although the autonomous vehicles described are autonomous automobiles, it is contemplated that the approaches of the various embodiments described herein are applicable to any type of passenger vehicle (e.g., buses, trains, planes, boats, etc.).

<FIG> is a diagram of a system capable of generating a passenger-based driving profile, according to one example. As noted above, an autonomous vehicle (e.g., a vehicle <NUM>) is capable of driving itself without the input of vehicle passengers or occupants. In some embodiments, the vehicle <NUM> achieves this self-driving capability by using sensor systems (e.g., sensors <NUM>) in combination with, for instance, map data (e.g., three-dimensional map data stored in a geographic database <NUM>) and information received from network-based services and/or other vehicles. With this information, the vehicle <NUM> generally can react to changing situations faster than a typical human driver. As a result, autonomous vehicles are able to safely operate using operational parameters (e.g., vehicle speed, acceleration rate, braking rate, lateral acceleration, etc.) that can often exceed what is a comfortable driving experience for a user.

For example, while in traffic, an autonomous vehicle typically can safely operate at higher speeds (or higher acceleration, faster braking, shorter following distance, greater speed on curves or turns, etc.) than a human driver would normally use. However, this speed or other operational parameter might exceed values that are comfortable for the occupants or passengers. This discomfort may result at least partially from the disparity between what a passenger can see from the vehicle versus what can be sensed by the vehicle. This disparity can then lead, for instance, to a situation where an autonomous vehicle configures itself to drive at faster speeds (e.g., up to a posted speed limit) in situations where a human driver would slow down due to low visibility. Such a conflict can cause discomfort for the passengers and in some cases, lead to one or more of the passengers interfering with the autonomous driving activity (e.g., by hitting a panic button to stop the autonomous driving activity) or otherwise taking manual control, thereby resulting in a poor user experience.

In one example, to provide for a more comfortable driving experience, the system <NUM> can monitor the driving behavior (e.g., speeds, acceleration rates, braking rates, speed on curves, following distances, and/or the like) of a user as the user drives a vehicle. This driving behavior data can then be used to configure the driving style of a vehicle carrying the corresponding user to provide a more "humanized" driving experience (e.g., a driving style that more closely matches the driving behavior of the user). However, in some cases, the user may be comfortable with the user's own driving style while the user is driving, but may be uncomfortable with his or her own driving style while being a passenger. In other words, many users may feel that "the way I drive is not necessarily how I want to be driven.

<FIG> is a diagram illustrating an example of different user reactions to the same driving behavior while driving a vehicle versus riding as a passenger, according to one example. In the example of <FIG>, the driving behavior <NUM> is a following distance <NUM> between a user's vehicle <NUM> and another vehicle <NUM>. In a scenario where the user driving the vehicle <NUM> in the driving position <NUM>, the user has a positive reaction <NUM> (e.g., a smile detected by a facial recognition system of the vehicle <NUM>) that indicates that the user is comfortable with the following distance <NUM>. However, when the user is in the passenger position <NUM> and the vehicle <NUM> is operated autonomously using the same following distance <NUM>, the user has a negative reaction <NUM> (e.g., a scared facial expression detected by a facial recognition system of the vehicle <NUM>). This indicates that the user does not like being driven as a passenger using the following distance <NUM>, but is comfortable with using the following distance <NUM> when the user is driving. This disparity between driving comfort and passenger comfort typically arises because the user feels more in control (and therefore more comfortable) while driving as opposed to while riding as a passenger.

Based on the scenario illustrated above, if the system <NUM> adapts the vehicle <NUM>'s driving style based solely on the user's recorded driving style or driving behavior data when the user is a passenger, the system <NUM> may nonetheless provide a poor user experience. Accordingly, service providers and vehicle manufacturers face significant technical challenges to configure the vehicle <NUM> to provide a comfortable driving experience for a user when the vehicle <NUM> is carrying the user as a passenger.

To address this problem, the system <NUM> of <FIG> introduces a capability to determine the most suitable driving style for a passenger of the vehicle <NUM> (e.g., an autonomous vehicle) using available sensor information (e.g., from sensors <NUM>) and/or other data sources (e.g., mapping data from the geographic database <NUM>, and/or weather or other contextual data from a services platform <NUM> and/or any of its services 109a-109n - such as weather services, traffic services, etc.). For example, while a "regular driver profile" (e.g., a driving behavior profile created by monitoring a user's driving behavior) might faithfully mimic a driver's style, an "aggressive" driver (e.g., operates the vehicle <NUM> at higher speeds, acceleration, etc. while driving) might not be comfortable with an "aggressive" driving style while the user is a passenger instead of a driver. Conversely, a "conservative" driver (e.g., operates the vehicle <NUM> at lower speeds, etc. while driving) might be uncomfortable with such conservative driving and want a more aggressive style when riding as a passenger.

In one example, to determine the level of comfort/discomfort, the system <NUM> can monitor vehicle driving behaviors (e.g., maneuvers, turns, speeds, etc.) and the corresponding reaction of the user to the driving behaviors using sensors <NUM> and/or user feedback input. In one example, if system <NUM> (e.g., via a cloud-based passenger profile platform <NUM> and/or a vehicle-based passenger profile module <NUM>) detects that the user has a positive reaction or comfort level to current driving style or behavior of the monitored vehicle <NUM>, the system <NUM> can store this reaction (e.g., comfort level or tolerance) in the user's passenger profile. The stored positive reaction, for instance, can indicate that the vehicle <NUM> can be driven according to the driving behavior or style corresponding to the reaction, even if the behavior varies from the user's own driving style. If the system <NUM> detects that the user has a negative reaction or discomfort level with a driving behavior, the system <NUM> can update the user's passenger profile with the collected information to specify the driving behavior or elements of the driving behavior (e.g., acceleration patterns, braking patterns, distance to neighboring vehicles, speed in curves, etc.) that corresponds to the negative reaction or discomfort.

In one example, after creating the passenger profile based on the collected driving behavior and user reaction data, the system <NUM> can use the passenger profile data to adapt the driving style of the vehicle <NUM> (e.g., when the vehicle <NUM> is operated in autonomous mode or someone other than the user is driving). In other example, the passenger profile can be used to configure other vehicle-related services such as but not limited to ride-sharing services, vehicle recommendation services, and/or the like. It is noted that the uses of the passenger profile described herein are provided by way of example and not as limitations. It is contemplated that the passenger profile created from vehicle driving behavior data and reaction data from passengers can be used to support any use case where passenger profile data can be used.

In one example, the passenger profile platform <NUM> performs the functions associated with generating and using a passenger profile according to the examples described herein. <FIG> is a diagram of the components of the passenger profile platform <NUM>, according to one example. In one example, the passenger profile module <NUM> of the vehicle <NUM> can perform all or a portion of the functions of the passenger profile platform <NUM> alone or in combination with the passenger profile platform <NUM>. By way of example, the passenger profile platform <NUM> and/or passenger profile module <NUM> include one or more components for determining a passenger driving profile for a vehicle according to the various examples described herein. It is contemplated that the functions of these components may be combined or performed by other components of equivalent functionality. In this example, the passenger profile platform <NUM> and/or passenger profile module <NUM> include a vehicle behavior module <NUM>, passenger reaction module <NUM>, passenger profile generator <NUM>, vehicle configuration module <NUM>, and service interface module <NUM>. The above presented modules and components of the passenger profile platform <NUM> and/or passenger profile module <NUM> can be implemented in hardware, firmware, software, or a combination thereof. Though depicted as separate entities in <FIG>, it is contemplated that the passenger profile platform <NUM> and/or passenger profile module <NUM> may be implemented as a module of any of the components of the system <NUM> (e.g., a component of the vehicle <NUM>, services platform <NUM>, services 109a-109n (also collectively referred to as services <NUM>), etc.). In another example, one or more of the modules <NUM>-<NUM> may be implemented as a cloud-based service, local service, native application, or combination thereof. The functions of the passenger profile platform <NUM>, passenger profile module <NUM>, and modules <NUM>-<NUM> are discussed with respect to <FIG> below.

<FIG> is a flowchart of a process for generating a passenger profile, according to one example. In various examples, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> may perform one or more portions of the process <NUM> and may be implemented in, for instance, a chip set including a processor and a memory as shown in <FIG>. As such, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> can provide means for accomplishing various parts of the process <NUM>, as well as means for accomplishing other processes described herein in conjunction with other components of the system <NUM>. Although the process <NUM> is illustrated and described as a sequence of steps, its contemplated that various exemplars of the process <NUM> may be performed in any order or combination and need not include all of the illustrated steps.

In step <NUM>, the vehicle behavior module <NUM> collects or records vehicle sensor data of a vehicle carrying a user as a passenger. The vehicle sensor data indicates or relates to at least one driving behavior of the vehicle. By way of example, driving behavior or style includes but is not limited to physical measurements or parameters that record how the vehicle is being driven. In one example, the at least one driving behavior includes an acceleration pattern, a braking pattern, a distance to a neighboring vehicle, a vehicle speed on a curved section, a vehicle turning behavior (e.g., how quickly a vehicle turns, the size of vehicle gaps through which a turn can be made, etc.), or a combination thereof. In other words, the driving behavior can be defined according to physical parameters such as but not limited to acceleration patterns (e.g., acceleration rates over time under various contexts such as road type, time of day, traffic level, visibility, weather, etc.), braking patterns (e.g., how quickly or abruptly the vehicle braking system is actuated under different contexts), distance to nearby vehicles (e.g., following or leading distances, gaps between other vehicles when making turns or other maneuvers, etc.), speed in curves, etc. The driving behavior can be an individual parameter or any combination thereof the parameters. In addition, the driving behavior can be fused with a particular context (e.g., a time, location, activity, maneuver, etc.) so that a user reaction can be determined for the driving behavior alone or in combination with one or more contexts.

As shown in <FIG>, in one example, to provide vehicle measurements or data that can be used to characterize a driving style, a vehicle <NUM> can be equipped with a number of sensors to measure driving behavior. These sensors can include but are not limited to location sensors <NUM> (e.g., GPS or other satellite-based receivers), LiDAR sensors <NUM>, radar sensors 505a and 505b, and other sensors <NUM> (e.g., accelerometers, compasses, gyroscopes, etc. as described in further detail below). These sensors <NUM>-<NUM> and/or any other equivalent or similar sensors can be configured to collect data indicating driving behavior such as an acceleration pattern, a braking pattern, a distance to a neighboring vehicle, a vehicle speed on a curved section, a vehicle turning behavior, and/or the like.

In one example, this sensor data is collected when the vehicle behavior module <NUM> detects that the user is a passenger. The user can be considered a passenger of a vehicle when the user is physically present within a vehicle but is not actively driving or operating the vehicle under the user's manual control. Therefore, the vehicle behavior module <NUM> can interface with a vehicle's control system to determine whether it is operating in an autonomous mode (autonomous driving modes are described in further detail below). If the vehicle is in any autonomous mode, the vehicle behavior module <NUM> can assume that the user is a passenger and then begin collecting sensor data to determine a driving behavior of the vehicle. In other examples, the user can be a passenger when riding in a vehicle operated by another human driver. In this case, the vehicle behavior module <NUM> can detect that the user is a passenger by first determining that the vehicle is operating in manual mode and then detecting that the user is not in the driver's position (e.g., detected via sensors in the seating positions, image-based analysis of images of the user's driving position, and/or any other equivalent means). It is noted that the above means for detecting that a user is a passenger in a vehicle is provided by way of illustration and not as limitations.

In step <NUM>, the passenger reaction module <NUM> collects or records user sensor data, user input data, or a combination thereof indicating a reaction of the user to the at least one driving behavior. In one example, the reaction can include a level of discomfort or discomfort that the user is experiencing in response to the corresponding driving behavior. As shown in <FIG>, the user sensor data, for instance, can be collected from one or more sensors of the vehicle <NUM>. In addition or alternatively, the user sensor data can be collected from a device (e.g., a smartphone, wearable device, etc.) associated with the user that is equipped with the same or similar sensors illustrated in <FIG>. By way of example, the one or more sensors illustrated in <FIG> include but are not limited to at least one of: (<NUM>) a camera sensor <NUM> configured to detect a facial movement, an eye movement, a body movement, or a combination thereof of the user that is indicative of the reaction; (<NUM>) a biometric sensor <NUM> such as a heart rate sensor configured to detect a heart rate, a change in the heart rate, or a combination thereof of the user that is indicative of the reaction; (<NUM>) a touch sensor <NUM> configured to detect a touch of a vehicle component by the user that is indicative of the reaction; and (<NUM>) a microphone <NUM> in combination with a speech recognition module configured to sample a recognition speech or sound from the user that is indicative of the reaction.

In one example, the passenger reaction module <NUM> processes the collected user sensor data corresponding to a driving behavior determines a user reaction (e.g., a comfort level, a discomfort level, or a combination thereof) of the user based on the detected reaction to the driving behavior. For example, camera detection can be used to identify facial movements, eye movements, or body movements that have been previously associated with a given user reaction (e.g., comfort level or discomfort level). As shown in the example of <FIG>, a camera sensor <NUM> can be used to capture an image of a user while the user is a passenger in the vehicle <NUM> operating under a corresponding driving behavior. The resulting image data can be processed to identify one of a number of possible user facial expressions <NUM> that have been associated with a user comfort level or discomfort level. For example, a detected facial expression 621a indicating a large smile by the user can be correlated with a high comfort level, and a detected facial expression 621b with a medium smile can be correlated with a medium comfort level. Similarly, a detected facial expression 621c with a large frown can be correlated with a high discomfort level, and a detected facial expression 621d with a medium frown can be correlated with a medium discomfort level.

Similar correlations can be determined for the other sensor types associated with detecting user reactions. For example, heart rate monitoring via biometric sensors <NUM> use different heart rates to determine a magnitude of a reaction. A higher detected heart rate can indicate a higher level of comfort or discomfort, which a lower heart rate can indicate a lower level of comfort or discomfort. Touch sensors <NUM> located on various buttons, controls, seats, handles, etc. can provide sensor data indicate a how hard (e.g., a grasping intensity) the passenger is holding on to a monitored surface, handle, or touchable object in the vehicle <NUM>. Higher grasping intensity (e.g., a grasping intensity above a threshold value), for instance, can be correlated with higher levels of discomfort. Similarly, the microphone <NUM> sensor can be used to capture words or other utterances (e.g., screams, laughter, etc.) that can be processed using speech recognition or other audio processing. The words and/or utterances can be compared against a dictionary previously associated with various comfort or discomfort levels. In one example, silence or things not being said (e.g., detected gaps in conversation, etc.) can also be indicators of a comfort or discomfort level.

In one example, the passenger reaction module <NUM> can use any combination of one or more of the sensors to determine a user reaction to a corresponding driving behavior. For example, the passenger reaction module <NUM> can use machine learning models (e.g., neural networks, support vector machines, regression models, random forest, decision trees, etc.) that have been trained to accept the user reaction sensor data as an input for classification into one or more reactions or comfort/discomfort levels.

In one example, the passenger reaction module <NUM> can also request and receive user input data via a user interface device of the vehicle to indicate the vehicle behavior and/or the user's reaction to the corresponding driving behavior. In this way, the user can more explicitly indicate the driving behavior and/or reaction, as well as edit any behaviors and/or reactions automatically detected by the passenger profile platform <NUM>. The process for providing a user interface to determine user reaction data and/or vehicle driving behavior data is described in more detail below with respect to <FIG>.

In step <NUM>, the passenger profile generator <NUM> creates a passenger profile using the collected vehicle sensor data and the user reaction data. For example, the passenger profile generator <NUM> can fuse the user reaction data with the collected information on the corresponding vehicle driving behavior (e.g., based on the car's vehicle sensor data). In other words, the passenger profile generator <NUM> can create a data structure that relates a given driving behavior with the user's detected reaction to the driving behavior while the user is riding as a passenger of a monitored vehicle. This association or data structure represents stores data on the driving behaviors that are preferred (e.g., indicated by positive reactions or higher comfort levels) and/or not preferred (e.g., indicated by negative or lower comfort levels) by the user.

In one example, the passenger profile generator <NUM> can provide for greater granularity in the passenger profile by further fusing the driving behavior with additional contextual data. For example, the passenger profile generator <NUM> can map match the driving behavior to the portions of the street network or map data (e.g., as stored in the geographic database <NUM>) on which the driving behavior occurred. Other contextual parameters or data can also be fused such as but not limited to weather, traffic conditions, and/or any other detectable contexts inside or outside the vehicle.

In one example, the passenger profile generator <NUM> includes or excludes the at least one driving behavior in a passenger profile for the user based on the reaction of the user (e.g., a determined comfort or discomfort level). Alternatively, the passenger profile generator <NUM> can include all driving behaviors and their corresponding reactions in the passenger profile. In one example, the passenger profile generator <NUM> processes one or more features of the at least one driving behavior, the reaction, the vehicle, the contextual parameter, or a combination thereof using a machine learning model to determine one or more driving scenarios to include or exclude in the passenger profile. The features, for instance, can include any of the characteristics or values determined from the vehicle or user sensor data, the vehicle or user sensor data itself, related contextual parameters, characteristics of the user/vehicle/sensors, and/or the like.

In one example, the passenger profile can be generated to include only driving behaviors that are associated with positive or comfortable reactions (e.g., reactions indicating a comfort level above a threshold value). In this case, the passenger profile would be a "white-list" profile of driving behaviors or maneuvers preferred or otherwise acceptable to a user when riding as a passenger. In another embodiment, the passenger profile can be generated to include only driving behaviors that are associated with negative or uncomfortable reactions (e.g., reactions indicating a discomfort level above a threshold value). In this case, the passenger profile would be a "black-list" profile of driving behaviors or maneuvers to avoid when carrying a user as passenger. By way of example, such a black-list passenger profile can be created by monitoring reactions to drivers who drive poorly or are known to create discomfort for their passengers. In other examples, the passenger provide can include a combination of both the white-list and black-list profiles.

<FIG> is a diagram illustrating an example structure of a passenger profile, according to one example. In the example of <FIG>, the passenger profile <NUM> stores data records for vehicle behaviors 703a-703n (also collectively referred to as vehicle behaviors <NUM>). Each vehicle behavior <NUM> can be fused with one or more contexts 705a-<NUM> (also collectively referred to as contexts <NUM>). As described above, each context <NUM> can be based one or more contextual parameters that corresponds to a detected driving behavior. In other words, the at least one driving behavior can be included in the passenger profile with respect to a contextual parameter such as but not limited to a road link/segment in street network, a weather condition, a traffic condition, an in-vehicle context, an external context, a user activity, or a combination thereof. As other examples, the contextual parameters can include a visibility of oncoming traffic, a line-of-sight of the user, and/or any other detectable or reported contextual parameter.

The passenger profile generator <NUM> then associates the detected user reaction (e.g., comfort and/or discomfort level) with each corresponding vehicle driving behavior <NUM> and/or each context <NUM> in the passenger profile <NUM>. The resulting passenger profile <NUM> can then be stored in the cloud (e.g., the passenger profile platform <NUM>) and/or the locally at the vehicle or user device (e.g., the passenger profile module <NUM>) for future use.

<FIG> is a diagram illustrating an example driving behavior or scenario that can be included in a passenger profile, according to one example. The example of <FIG> illustrates a common scenario in which a driver of a vehicle <NUM> is required to turn left onto a cross street <NUM> with oncoming traffic <NUM>. Sometimes, this requires the driver of the vehicle <NUM> to make the turn with limited visibility, e.g., taking a go/no-go decision with limited visibility and suddenly deciding to go with a distance <NUM> to the oncoming traffic <NUM>. Depending on length of the distance <NUM>, the sudden maneuver by the driver can lead to having the oncoming traffic <NUM> brake or slow down to the vehicle <NUM> make the left turn. While the driver may be comfortable with making the turn at the distance <NUM> to do this type of "forcing" maneuver when he or she is driving, he or she may not be comfortable having someone else or an autonomous vehicle do this type of maneuver or make the maneuver at the same distance <NUM>. Instead, when riding as a passenger, he or she may prefer or be comfortable a longer distance <NUM> than the distance <NUM> to the oncoming traffic <NUM> to make a similar left turn.

As a result, if a driving profile is developed based only on the user's own driving behavior, the system <NUM> may not capture discrepancies arising from different preferences of the same user when driving versus when riding as a passenger. Accordingly, in one example, the passenger profile platform <NUM> can compute or generate a driver profile (e.g., based on a user's own driving behavior) as well a passenger profile (e.g., as generated according to the example described herein) for each user. The passenger profile platform <NUM> can also monitor the user's reactions to as a passenger over time (e.g., over years) to capture evolving preferences. For example, a user may be more comfortable with faster or more aggressive autonomous driving as the user gains more experience and builds more trust in the driving decision made by autonomous vehicles.

As discussed above, the passenger profile platform <NUM> can use machine models to train a predictive model based on the detected driving behaviors scenarios, user reactions, and/or other contextual data to determine which driving behaviors/scenarios are preferred by a user when riding as a passenger. It is noted that although the various examples described herein are discussed with respect to the user being a passenger in an automobile, it is contemplated that the examples described herein are also applicable to any form of transportation in which the user can be a passenger (e.g., public transportation, planes, ships, trains, etc.).

<FIG> is a flowchart of a process for providing a user interface for collecting vehicle driving behavior and/or user reaction data, according to one example. In various examples, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> may perform one or more portions of the process <NUM> and may be implemented in, for instance, a chip set including a processor and a memory as shown in <FIG>. As such, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> can provide means for accomplishing various parts of the process <NUM>, as well as means for accomplishing other processes described herein in conjunction with other components of the system <NUM>. Although the process <NUM> is illustrated and described as a sequence of steps, its contemplated that various exemplars of the process <NUM> may be performed in any order or combination and need not include all of the illustrated steps.

As discussed above with respect to the process <NUM> of <FIG>, the passenger profile platform <NUM> can collect driving behavior and user reaction data to generate a passenger profile that stores information on what driving behaviors that the user is comfortable and/or uncomfortable with while riding in a vehicle as a passenger (in contrast to being a driver of the vehicle). The examples of the process <NUM> as described herein one example but not exclusive means for obtaining user input for indicating and/or editing driving behavior and user reaction data.

In step <NUM>, the passenger profile platform <NUM> (e.g., via the vehicle behavior module <NUM> and/or the passenger reaction module <NUM>) provides a user interface on a device to present vehicle sensor data, user sensor data, or a combination thereof collected from one or more sensors of vehicle carrying a user as a passenger. By way of example, the device can include but is not limited to a vehicle-embedded device, a mobile device, wearable device, or a combination thereof. Other examples of a device for presenting the examples of the user interface described herein include any type of embedded terminal, mobile terminal, fixed terminal, or portable terminal including a vehicle control unit, a head unit, a portable navigation device (PND), a mobile handset, station, unit, device, multimedia computer, multimedia tablet, Internet node, communicator, desktop computer, laptop computer, notebook computer, netbook computer, tablet computer, personal communication system (PCS) device, personal navigation device, personal digital assistants (PDAs), audio/video player, digital camera/camcorder, positioning device, television receiver, radio broadcast receiver, electronic book device, game device, or any combination thereof, including the accessories and peripherals of these devices, or any combination thereof. It is also contemplated that the device can support any type of interface to the user such as "wearable" circuitry, speech-control circuity, button/switch/dial circuitry, and/or the like.

In one example, the vehicle sensor data that is presented in the user interface refers to sensor data collected about a vehicle and/or its context (e.g., location, movement, speed, acceleration, braking, lateral acceleration, etc.) as it operates while carrying a user as a passenger. In other words, the vehicle sensor data indicates at least one driving behavior of the vehicle while carrying a passenger. As the passenger profile platform <NUM> monitors and processes the vehicle sensor data collected from the vehicle, it can detect the individual driving behaviors (e.g., acceleration rate, braking rate, distance to neighboring vehicles, speed on curves, turning speed, obeying traffic lights/signs, etc.) and/or maneuvers (e.g., left/right turns, passing other vehicles, lane changes, etc.). The detected driving behaviors/maneuvers can then be presented to the user in a user interface.

<FIG> illustrates an example of a user interface (UI) <NUM> for presenting detected driving behaviors, according to one example. In the example of <FIG>, the passenger profile platform <NUM> processes collected vehicle sensor data to detect that a monitored vehicle has made a left turn while carrying a user (e.g., shown as the driving behavior <NUM> in the UI <NUM>). In one example, the vehicle sensor data also either indicates or is fused with external data sources (e.g., map data) to indicate contextual parameters (e.g., collectively shown as context <NUM>) associated with the driving behavior <NUM> such as the type of road link on which the driving behavior was detected (e.g., "residential street" queried from the geographic database <NUM>), traffic conditions (e.g., "light traffic" determined from a traffic service such as any of the services 109a-109n of the services platform <NUM>), weather conditions (e.g., "clear weather" determined from a weather service such as any of the services 109a-109n of the services platform <NUM>), posted speed limit on road link (e.g., "<NUM> MPH" as queried from the geographic database <NUM>), and location (e.g., "Intersection of <NUM>st and <NUM>nd streets" queried from the geographic database <NUM>).

In one example, the UI <NUM> can provide a UI element <NUM> for the user to provide an input indicating the user's reaction to the detected driving behavior. In this example, the UI element <NUM> provides toggle controls for indicating whether the user is comfortable or uncomfortable with the presented driving behavior <NUM>. In some examples, the UI element <NUM> can be presented on a wearable device <NUM> or other secondary device (e.g., a user's personal device) to receive the user input indicating a user reaction to the driving behavior while the user is a passenger. For example, the user input can indicate a comfort level, a discomfort level, or a combination thereof with the at least one driving behavior.

In addition or as alternate to explicit user input, the passenger profile platform <NUM> can automatically detect a user reaction to a corresponding driving behavior using collected user sensor data. As described above, the user sensor data are collected via one or sensors configured to monitor for user reactions. In one example, the one or more sensors include but is not limited to a camera sensor configured to detect a facial movement, an eye movement, a body movement, or a combination thereof of the user that is indicative of the reaction. The body movement corresponds, for instance, to a driving-related motion performed by the user as the passenger. The one or more sensors can also include a heart rate sensor configured to detect a heart rate, a change in the heart rate, or a combination thereof of the user that is indicative of the reaction. In yet another example, the one or more sensors can include a microphone in combination with a speech recognition module configured to sample a recognition speech or sound from the user that is indicative of the reaction. The one or more sensors can also include a touch sensor configured to detect a touch of a vehicle component by the user that is indicative of the reaction. The touch can be detected, for instance, as a grasping intensity of the user that is above a threshold value.

In step <NUM>, the passenger profile platform <NUM> presents a UI element associated with the UI to receive a user input for providing, modifying, and/or interacting with the vehicle sensor data, the user sensor data, or a combination thereof. In other words, the passenger profile platform <NUM> can present a UI to convey any automatically detected driving behavior and/or user reaction data with respect to a vehicle carrying the user as a passenger, and provide means (e.g., the UI element) for the user to review, specify, correct, and/or otherwise edit the presented information.

<FIG> illustrates an example of a UI <NUM> that presents detected driving behavior data <NUM> in combination with automatically detected user reaction data <NUM>. As shown, the driving behavior <NUM> is an acceleration rate of the vehicle on a highway (e.g., detected at <NUM>/s<NUM> based, for instance, on vehicle sensor data) when carrying the user as a passenger. The passenger profile platform <NUM> has also detected the user's reaction based on collected user sensor data (e.g., heart rate data, detected facial expression, detected words or utterances, etc.). The user sensor data can be analyzed (e.g., using a trained machine learning model) to predict the user reaction or comfort level. In this example, the passenger profile platform <NUM> computes that user sensor data indicates that the user is comfortable with the detected driving behavior (e.g., the detected acceleration rate) with a <NUM> confidence (e.g., confidence output by the machine learning model). The passenger profile platform <NUM> can then generate and present a UI element <NUM> as a representation of the detected reaction <NUM> (e.g., a sliding scale representation with <NUM> marked using a line), and a UI element <NUM> as a representation of the detected behavior <NUM> (e.g., a slide scale representation with <NUM>/s<NUM> marked using a line). Both the UI elements <NUM> and <NUM> are interactive elements that enable the user to change or modify the respective detected data values (e.g., by sliding the value lines to indicate a new value). For example, the user can interact with the user element <NUM> to alter the comfort level from the initially detected value of <NUM> (e.g., by dragging to the right to indicate a higher confidence or comfort level, or dragging to the left to indicate a lower confidence or comfort level). The detected driving behavior (e.g., acceleration rate) can also be similarly modified.

In step <NUM>, the passenger profile generator <NUM> generates a passenger profile for the user based on the vehicle sensor data, the user sensor, or a combination thereof after the providing, the modifying, the interacting with, or a combination of the vehicle sensor data, the user sensor data, or a combination thereof via the user interface element. For example, the passenger profile platform <NUM> can determine the provided or modified values for either the detected driving behavior or user reaction after the user's interaction with the presented UI. The passenger profile platform <NUM> then recomputes the passenger profile based on the updated values according to the examples, described with respect to the process <NUM> of <FIG>.

<FIG> is a flowchart of a process for using a passenger profile to configure a vehicle and/or service, according to the invention method. In various embodiments, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> may perform one or more portions of the process <NUM> and may be implemented in, for instance, a chip set including a processor and a memory as shown in <FIG>. As such, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> can provide means for accomplishing various parts of the process <NUM>, as well as means for accomplishing examples of other processes described herein in conjunction with other components of the system <NUM>.

After creating passenger profiles as described above, the system <NUM> can use the stored profiles for any number purposes including but not limited to configuring a vehicle or service to operate or function according to the preferences indicated in the passenger profiles. To initiate this use, the vehicle configuration module <NUM> detects an identity of a user of a vehicle and/or service, as well as any other passengers or co-users of the service (step <NUM>). The passenger profile platform <NUM> can use any means to detect the identity of user and/or other passengers including but not limited to manual user input (e.g., entering user credentials or account information)) and/or automated means (e.g., biometric detection, face recognition, voice recognition, etc.).

In step <NUM>, the vehicle configuration module <NUM> determines whether the vehicle is carrying one or more other passengers in addition to the user. If there are no other passengers, the vehicle configuration module <NUM> proceeds to step <NUM> to initiate single user processing. More specifically, the vehicle configuration module <NUM> retrieves a passenger profile of the user based on the determined identity of the user. In one embodiment, the passenger profile is generated based on sensor data indicating a reaction of the user to at least one vehicle driving behavior previously experienced by the user as a vehicle passenger. Examples of the process for generating passenger profiles is described in more detail above with respect to the process <NUM> of <FIG>.

If the vehicle configuration module <NUM> detects that there are multiple passengers in the vehicle in step <NUM>, the vehicle configuration module <NUM> proceeds to step <NUM> to initiate multiple passenger processing by retrieving passenger profiles for the one or more other passengers in addition to the detected user's profile. In step <NUM>, the vehicle configuration module <NUM> determines a common denominator driving behavior from among the passenger profile and the one or more other passenger profiles. As used herein, a common denominator driving behavior is a driving behavior that is comfortable to the multiple passengers based on their respective passenger profiles. For example, if the passenger profile platform <NUM> detects that there are three passengers in a vehicle, with the one passenger comfortable with a maximum speed of <NUM> mph, a second passenger with a maximum speed of <NUM> mph, and a third passenger comfortable with a maximum speed of <NUM> mph, the common denominator driving behavior is <NUM> mph. The common denominator driving behavior can be determined with respect to all passengers or a subset of the passengers. In cases where no common denominator driving behavior can be determined (e.g., when one passenger profile indicates that a passenger is only comfortable with speeds over <NUM> mph, and another passenger's profile indicates the other passenger is only comfortable with speeds below <NUM> mph), the passenger profile platform <NUM> alerts the passengers and of the incompatibility. In some examples, the passenger profile platform <NUM> can recommend alternate passenger groupings or alternate transportation means to resolve the incompatibility.

After retrieving the passenger profile or profiles, the vehicle configuration module <NUM> configures the vehicle and/or service based on the single user passenger profile or the multiple user profiles (e.g., the common denominator driving behavior) (step <NUM>). Configuring of the vehicle comprises adapting a driving style of a vehicle based on the passenger profile. For example, adapting the driving style of the vehicle comprises configuring the vehicle to operate using the preferred driving parameters (e.g., acceleration, braking, distance to other vehicles, speed on curves, turning speeds, acceptable maneuvers, etc.) indicated in the retrieved passenger profile data. In an autonomous vehicle use case, the driving style is adapted when the vehicle is operating in an autonomous driving mode. In the autonomous use case, the vehicles autonomous control and navigation system can be configured using the passenger profile to use a driving style that is comfortable to the user and/or avoid any driving behaviors that are uncomfortable to the user. In another use case where the vehicle is a ride-share vehicle or other vehicle driven by a human driver other than the user or passengers evaluated by the passenger profile platform <NUM>, the vehicle configuration module <NUM> can present or provide data for presenting a user interface to the driver of the ride-share vehicle to indicate a driving style preferred by the user based on the passenger profile.

<FIG> is an example of using a passenger profile to adapt a driving style of a vehicle, according to one embodiment. In the example of <FIG>, the vehicle <NUM> is a ride-share vehicle operated by a driver and carrying a user as a passenger. The passenger profile platform <NUM> identifies the user as the passenger and retrieves the user passenger profile. As the vehicle drives, the passenger profile platform <NUM> monitors for potential driving behaviors that are covered or included in the user's passenger profile. As shown, the passenger profile platform <NUM> detects that the vehicle <NUM> is approaching a curve and determines that the user's passenger profile indicates that the user is comfortable with a maximum speed of <NUM> mph on such curves. Accordingly, the passenger profile platform <NUM> initiates or provide data for the vehicle <NUM> to present an alert <NUM> to the driver of the vehicle <NUM> that the vehicle <NUM> is approaching a curve and that the "passenger prefers to take this curve at no more than <NUM> mph.

It is noted that configuration the operational parameters of a vehicle (e.g., configuring the acceleration, braking, speed, etc.) is only one example of configuring a vehicle based on a passenger profile. In other examples, the configuring of the vehicle comprises selecting a driver for the vehicle based on the passenger profile. For example, the passenger profile of the user can be matched against the driving profiles of candidate drivers to find the compatible driving behaviors (e.g., driving behaviors of the candidate drivers that are associated with a positive or comfortable reaction in the passenger profile).

In another embodiment, the configuring of the vehicle can comprise computing a navigation route for the vehicle based on the passenger profile. For example, the passenger profile platform <NUM> can provide passenger profile data to a vehicle navigation system so that road links or routes associated driving behaviors or maneuvers that have a positive user reaction can be favored while the road links or routes associated with driving behaviors or maneuvers that have a negative user reaction can reduced or deprioritized. For example, if a passenger profile indicates that a user is uncomfortable with making left turns in heavy traffic, the passenger profile platform <NUM> can interact with the navigation to configure the vehicle to avoid routes with left turns when traffic is heavy.

In one example, the routing based on the comfort levels can also be linked with an estimated time of arrival (ETA) or other user navigation preference or option. For example, if the system <NUM> generates a route that meets the user's desired comfort level but the route would result in an increased ETA that conflicts with a user's scheduled appointment, the system <NUM> can provide data or a user interface to inform the user that the user will not be on time for the appointment if the system <NUM> respects the user's comfort level for the entire route. In response, the system <NUM> can present the user with a user interface to select whether the user prefers being a bit late (e.g., arriving at the destination after the scheduled appointment time) or accepting at least a portion of the route that does not meet the user's determined comfort level. In one example, the user interface for selecting the option can also present alternate routes for user selection. For example, a first route may be generated and presented in which the travel time is <NUM> minutes with maximum comfort level, a second route may be generated and presented with a travel time of <NUM> minutes with minimum but acceptable comfort level, a third route may be generated and presented with the fastest travel time of <NUM> but with <NUM>% of the route not meeting the user's minimum comfort level, etc..

In yet another embodiment, the configuration of the vehicle can comprise determining a vehicle seating position for the user based on the passenger profile. For example, the passenger profile may include seating position as one contextual parameter in the passenger profile. This is because seating position can potentially have an effect on the comfort level or discomfort level of a user with the same driving behavior. For example, a user may be comfortable with closer following distances when sitting in the back seat because the user may not be able to see the next vehicle as clearly as when sitting one of the front seats. Similarly, sitting in the driver position as a passenger (e.g., when the vehicle is operating autonomously) may provide different comfort levels than when sitting in the front passenger seat. Accordingly, in one example, the passenger profile platform <NUM> can recommend different seating positions to optimize compatibility with other passenger profiles to achieve a target level of driving performance (e.g., recommend the user sit in the back seat, so that the vehicle can be operated higher speeds to reach a destination at a requested time).

In addition to configuring a vehicle, the passenger profile can also be used to configure services for which passenger profile data is relevant. An example of such a service includes but is not limited to ride-sharing services, car recommendation services, etc. In one example, the configuring of a service includes selecting options, parameters, actions, functions, etc. of the service based on the retrieved passenger profile data. For example, in a ride-sharing service, the service interface <NUM> (e.g., an application programming interface (API) or equivalent) can provide the passenger profile data to the ride-sharing service to select one or more other passengers to group with the user in a vehicle. The selection of the other passengers can be based, for instance, on a similarity of the passenger profile and one or more other passenger profiles of the one or more other passengers. The similarity can be based on finding on ability to find common denominator driving behaviors among the passenger profiles.

<FIG> is an example of using a passenger profile to configure a vehicle-related service (e.g., a ride-share service. In the example of <FIG>, a user initiates a ride-share application <NUM> on a device <NUM>, and requests a carpooling ride that is shared among multiple users. The ride-share application <NUM> can interact with the service interface <NUM> of the passenger profile platform <NUM> to identify the user (e.g., via a login using the ride-share application <NUM>) and retrieve the user's passenger profile. The passenger profile can then be matched against other potential passengers requesting carpool rides at the same time. The passengers whose passenger profiles are most compatible with the user's passenger profile (e.g., passengers who prefer or are comfortable with similar driving behaviors as indicated in their respective profiles) are then presented in the UI element <NUM>. In one embodiment, the ride-share application <NUM> can also interact with the passenger profile platform <NUM> to determine available ride-share drivers who are also compatible with the user and the other identified potential co-passengers. The compatible drivers are those driver's whose driving profiles (e.g., recorded driving behaviors) indicate driving behaviors or maneuvers that are associated with positive user reactions as indicated in the user's passenger profiles. According to the invention, the passenger profiles of the user and any other candidate passengers can be processed to determine a common denominator driving profile or behavior comfortable to all or a subset of the passengers. This common denominator driving profile can then be compared against the driving profiles of candidate drivers to select or recommend compatible drivers. In the example of <FIG>, the compatible drivers are shown in the UI element <NUM>.

It is noted that ride-sharing is only one type of service or application that can use the passenger profiles generated according to the examples described herein. It is contemplated that any type of service or application can interface with the passenger profile platform <NUM> to obtain passenger profile data. For example, another type of service is a car recommendation as described below.

<FIG> is a flowchart of a process for selecting or recommending a vehicle or other vehicle related item based on a passenger profile, according to one example. In various examples, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> may perform one or more portions of the process <NUM> and may be implemented in, for instance, a chip set including a processor and a memory as shown in <FIG>. As such, the passenger profile platform <NUM>, passenger profile module <NUM>, and/or any of the modules <NUM>-<NUM> can provide means for accomplishing various parts of the process <NUM>, as well as means for accomplishing other processes described herein in conjunction with other components of the system <NUM>. Although the process <NUM> is illustrated and described as a sequence of steps, its contemplated that various exemplars of the process <NUM> may be performed in any order or combination and need not include all of the illustrated steps.

In step <NUM>, the service interface <NUM> retrieves a passenger profile of a user. As described above, the passenger profile is generated based on sensor data indicating a reaction of the user to at least one vehicle driving behavior previously experienced by the user as a vehicle passenger.

In step <NUM>, the service interface <NUM> processes the passenger profile to select or to recommend a vehicle to the user. In one example, the vehicle is selected from a plurality of vehicles by comparing the passenger profile against vehicle capability data of a plurality of vehicles. As described above, in one example, the passenger profile includes an acceleration pattern, a braking pattern, a distance to a neighboring vehicle, a vehicle speed on a curved section, or a combination thereof preferred by the user. The vehicle capability data can include but is not limited to a horse power level, an acceleration capability, a braking capability, a lateral acceleration capability, or a combination thereof. The vehicle capability data, for instance, can be determined or queried from the services platform <NUM>, any of the services 109a-109n of the services platform <NUM>, the content providers 117a-<NUM>, and/or any other equivalent data source.

The vehicle capability data can then be compared against the acceleration pattern, the braking pattern, the distance to a neighboring vehicle, the vehicle speed on the curved section, and/or any other driving behaviors/parameters stored in the user's passenger profile to select or to recommend the vehicle. In this way, the vehicle that is selected or recommended has the vehicle capability data that indicates the vehicle can achieve the acceleration pattern, the braking pattern, the distance to the neighboring vehicle, the vehicle speed on the curved section, or a combination thereof in the passenger profile with a minimum of excess vehicle capability among the plurality of vehicles.

In one example, the user can specify additional criteria for selecting a vehicle including but not limited to brand, price, model (e.g., coupe, sedan, SUV, truck, etc.), features/equipment (e.g., seating material, options, etc.). These additional criteria can then be further considered when making a vehicle selection or recommendation. For example, if the user's passenger profile includes a contextual parameter that indicates the user prefers a particular brand or make of vehicle, the passenger profile platform <NUM> can make a selection or recommendation from among the models offered by the brand or make. If no vehicles are compatible with the passenger profile (e.g., vehicles have capabilities capable of achieving the driving behavior or maneuvers preferred by the user), then models for other makes can be next considered. Similarly, if the user specifies a maximum price, then the passenger profile platform <NUM> can select the cars that are compatible with the user's passenger profile that are below the maximum price. In another example, the user may request the least expensive car compatible with the user's passenger profile, and the passenger profile platform <NUM> can make the selection or recommendation accordingly.

In one example, the service interface <NUM> of the passenger profile platform <NUM> can select or recommend multiple vehicles from among the plurality of vehicles based on determining that a single vehicle from among the plurality of vehicles is not capable of achieving the acceleration pattern, the braking pattern, the distance to the neighboring vehicle, the vehicle speed on the curved section, and/or other driving behaviors in the passenger profile. For example, the user passenger profile may indicate that the user prefers to less aggressive driving style when operating in urban environments, but then prefers more aggressive high-speed travel on rural highways. The passenger profile platform <NUM> may determine that a single is not able to achieve the preferred urban driving style and the preferred high-speed driving style in rural areas within the budget constraints of the user. As a result, the service interface <NUM> can recommend to the car recommendation service or application one car for urban driving and another car for rural driving, with both cars being within the user's budget constraint (if any).

In one example, if no single car can achieve the preferred driving style indicated in the user's passenger profile, the service interface <NUM> can deprioritize at least one of the acceleration pattern, the braking pattern, the distance to the neighboring vehicle, the vehicle speed on the curved section, and/or other driving behavior in the passenger profile for selecting or recommending the vehicle. The deprioritization can be performed according to a default order or sequence (e.g., acceleration first, braking second, etc.) until a car can recommended. Alternatively, the user can specify a preferred deprioritization order. In one embodiment, deprioritization comprises decreasing the weight applied to the corresponding driving behavior, eliminating the driving behavior, increasing window for determining when a vehicle capability satisfies a driving behavior (e.g., if a preferred acceleration rate is <NUM>/s<NUM> the matching window can be expanded from +/- <NUM>% to +/- <NUM>%, and/or the like).

In one example, the vehicle is further selected based on contextual data associated with the user, the vehicle, an expected route, a trip objective, or a combination thereof. For example, contextual parameters about the user can include but are not limited to height or stature, family size, degree of mobility, disabilities, etc. Contextual parameters about the vehicle can include but are not limited to brand, color, fuel efficiency, options, etc. Contextual parameters about the expected route can include but are not limited to functional class of road links on the route, speed limits on the route, road type (e.g., paved streets, off-road, etc.), urban vs. rural, etc. Contextual parameters about the trip objective include but are not limited to destination (e.g., work, home), planned activity (e.g., shopping, tourism, work, etc.). The contextual parameters described herein a provided by way of illustration and not as limitations.

In step <NUM>, the service interface presents or provides data for presenting the vehicle in a user interface of a device of the user. For example, as shown in the example of <FIG>, a user is requesting a car recommendation <NUM> from a service via a user device <NUM>. The user also specified contextual information (e.g., a trip purpose <NUM> - "Shopping with Family" and a preferred car brand - "Brand A") for the recommendation <NUM>. Based on the request, the service (e.g., a ride-share service, car buying service, etc.) retrieves the user's passenger profile and vehicle capability information for vehicles available from the specified brand. The cars that are compatible with the passenger profile and the contextual information is then determined according to the examples described herein and presented in the UI element <NUM> (e.g., listing recommended vehicles SUV A and SUV B). The user can then select a vehicle from the UI element <NUM>. In one embodiment, the vehicle that is selected or recommended can then be configured to operate using the passenger profile and/or specified contextual information (e.g., according to the process <NUM> of <FIG> described above).

Returning to <FIG>, in one example, the passenger profile platform <NUM> has connectivity over a communication network <NUM> to the services platform <NUM> (e.g., an OEM platform) that provides one or more services <NUM> (e.g., sensor data collection services). By way of example, the services <NUM> may also be other third-party services and include ride-share services, vehicle recommendation services, gaming services, mapping services, navigation services, travel planning services, notification services, social networking services, content (e.g., audio, video, images, etc.) provisioning services, application services, storage services, contextual information determination services, location-based services, information-based services (e.g., weather, news, etc.), etc. In one example, the services platform <NUM> uses the output of the passenger profile platform <NUM> (e.g., passenger profile data) to provide various services and/or applications. In other examples, the services platform <NUM> and/or services <NUM> can provide contextual or other information for generating passenger profiles according to the various examples described herein.

In one example, the passenger profile platform <NUM> may be a platform with multiple interconnected components, and may include multiple servers, intelligent networking devices, computing devices, components and corresponding software for generating passenger profiles. In addition, it is noted that the passenger profile platform <NUM> may be a separate entity of the system <NUM>, a part of the one or more services <NUM>, a part of the services platform <NUM>, or included within the vehicle <NUM> (e.g., a passenger profile module <NUM>).

In one example, content providers 117a-<NUM> (collectively referred to as content providers <NUM>) may provide content or data (e.g., including geographic data, contextual data, vehicle capability data, etc.) to the geographic database <NUM>, the passenger profile platform <NUM>, the services platform <NUM>, the services <NUM>, and/or the vehicle <NUM>. The content provided may be any type of content, such as map content, textual content, audio content, video content, image content, etc. In one example, the content providers <NUM> may provide content that may aid in the detecting and classifying of VRUs or other related characteristics (e.g., physical dividers). In one example, the content providers <NUM> may also store content associated with the geographic database <NUM>, passenger profile platform <NUM>, services platform <NUM>, services <NUM>, and/or vehicle <NUM>. In another example, the content providers <NUM> may manage access to a central repository of data, and offer a consistent, standard interface to data, such as a repository of the geographic database <NUM>.

By way of example, the passenger profile module <NUM> can be any type of embedded system, mobile terminal, fixed terminal, or portable terminal including a built-in navigation system, a personal navigation device, mobile handset, station, unit, device, multimedia computer, multimedia tablet, Internet node, communicator, desktop computer, laptop computer, notebook computer, netbook computer, tablet computer, personal communication system (PCS) device, personal digital assistants (PDAs), audio/video player, digital camera/camcorder, positioning device, fitness device, television receiver, radio broadcast receiver, electronic book device, game device, or any combination thereof, including the accessories and peripherals of these devices, or any combination thereof. It is also contemplated that the passenger profile module <NUM> can support any type of interface to the user (such as "wearable" circuitry, etc.). In one example, the Passenger profile module <NUM> may be associated with the vehicle <NUM> or be a component part of the vehicle <NUM>.

In one example, the vehicle <NUM> is configured with various sensors for generating or collecting vehicular sensor data indicating driving behavior, user sensor data indicating user reactions to driving behaviors, related contextual data, geographic/map data, etc. In one embodiment, the sensed data represent sensor data associated with a geographic location or coordinates at which the sensor data was collected. In this way, the sensor data can be map matched to a street network or digital map of the geographic database <NUM>. By way of example, the sensors may include a radar system, a LiDAR system, a global positioning sensor for gathering location data (e.g., GPS), a network detection sensor for detecting wireless signals or receivers for different short-range communications (e.g., Bluetooth, Wi-Fi, Li-Fi, near field communication (NFC) etc.), temporal information sensors, a camera/imaging sensor for gathering image data, an audio recorder for gathering audio data, velocity sensors mounted on steering wheels of the vehicles, switch sensors for determining whether one or more vehicle switches are engaged, and the like.

Other examples of sensors of the vehicle <NUM> may include light sensors, orientation sensors augmented with height sensors and acceleration sensor (e.g., an accelerometer can measure acceleration and can be used to determine orientation of the vehicle), tilt sensors to detect the degree of incline or decline of the vehicle along a path of travel, moisture sensors, pressure sensors, etc. In a further example, sensors about the perimeter of the vehicle <NUM> may detect the relative distance of the vehicle to a lane or roadway, the presence of other vehicles, pedestrians, traffic lights, potholes and any other objects, or a combination thereof. In one scenario, the sensors may detect weather data, traffic information, or a combination thereof. In one example, the vehicle <NUM> may include GPS or other satellite-based receivers to obtain geographic coordinates from satellites for determining current location and time. Further, the location can be determined by visual odometry, triangulation systems such as A-GPS, Cell of Origin, or other location extrapolation technologies. In yet another example, the sensors can determine the status of various control elements of the car, such as activation of wipers, use of a brake pedal, use of an acceleration pedal, angle of the steering wheel, activation of hazard lights, activation of head lights, etc..

In one example, the communication network <NUM> of system <NUM> includes one or more networks such as a data network, a wireless network, a telephony network, or any combination thereof. It is contemplated that the data network may be any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), a public data network (e.g., the Internet), short range wireless network, or any other suitable packet-switched network, such as a commercially owned, proprietary packet-switched network, e.g., a proprietary cable or fiber-optic network, and the like, or any combination thereof. In addition, the wireless network may be, for example, a cellular network and may employ various technologies including enhanced data rates for global evolution (EDGE), general packet radio service (GPRS), global system for mobile communications (GSM), Internet protocol multimedia subsystem (IMS), universal mobile telecommunications system (UMTS), etc., as well as any other suitable wireless medium, e.g., worldwide interoperability for microwave access (WiMAX), Long Term Evolution (LTE) networks, code division multiple access (CDMA), wideband code division multiple access (WCDMA), wireless fidelity (Wi-Fi), wireless LAN (WLAN), Bluetooth®, Internet Protocol (IP) data casting, satellite, mobile ad-hoc network (MANET), and the like, or any combination thereof.

By way of example, the passenger profile platform <NUM>, services platform <NUM>, services <NUM>, vehicle <NUM>, and/or content providers <NUM> communicate with each other and other components of the system <NUM> using well known, new or still developing protocols. In this context, a protocol includes a set of rules defining how the network nodes within the communication network <NUM> interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model.

<FIG> is a diagram of a geographic database, according to one example. In one example, the geographic database <NUM> includes geographic data <NUM> used for (or configured to be compiled to be used for) mapping and/or navigation-related services. In one example, geographic features (e.g., two-dimensional or three-dimensional features) are represented using polygons (e.g., two-dimensional features) or polygon extrusions (e.g., three-dimensional features). For example, the edges of the polygons correspond to the boundaries or edges of the respective geographic feature. In the case of a building, a two-dimensional polygon can be used to represent a footprint of the building, and a three-dimensional polygon extrusion can be used to represent the three-dimensional surfaces of the building. It is contemplated that although various examples are discussed with respect to two-dimensional polygons, it is contemplated that the examples are also applicable to three-dimensional polygon extrusions. Accordingly, the terms polygons and polygon extrusions as used herein can be used interchangeably.

In one example, the following terminology applies to the representation of geographic features in the geographic database <NUM>.

In one example, the geographic database <NUM> follows certain conventions. For example, links do not cross themselves and do not cross each other except at a node. Also, there are no duplicated shape points, nodes, or links. Two links that connect each other have a common node. In the geographic database <NUM>, overlapping geographic features are represented by overlapping polygons. When polygons overlap, the boundary of one polygon crosses the boundary of the other polygon. In the geographic database <NUM>, the location at which the boundary of one polygon intersects they boundary of another polygon is represented by a node. In one example, a node may be used to represent other locations along the boundary of a polygon than a location at which the boundary of the polygon intersects the boundary of another polygon. In one example, a shape point is not used to represent a point at which the boundary of a polygon intersects the boundary of another polygon.

As shown, the geographic database <NUM> includes node data records <NUM>, road segment or link data records <NUM>, POI data records <NUM>, passenger profile data records <NUM>, other records <NUM>, and indexes <NUM>, for example. More, fewer or different data records can be provided. In one example, additional data records (not shown) can include cartographic ("carto") data records, routing data, and maneuver data. In one example, the indexes <NUM> may improve the speed of data retrieval operations in the geographic database <NUM>. In one example, the indexes <NUM> may be used to quickly locate data without having to search every row in the geographic database <NUM> every time it is accessed. For example, in one embodiment, the indexes <NUM> can be a spatial index of the polygon points associated with stored feature polygons.

In examples, the road segment data records <NUM> are links or segments representing roads, streets, or paths, as can be used in the calculated route or recorded route information for determination of one or more personalized routes. The node data records <NUM> are end points corresponding to the respective links or segments of the road segment data records <NUM>. The road link data records <NUM> and the node data records <NUM> represent a road network, such as used by vehicles, cars, and/or other entities. Alternatively, the geographic database <NUM> can contain path segment and node data records or other data that represent pedestrian paths or areas in addition to or instead of the vehicle road record data, for example.

The road/link segments and nodes can be associated with attributes, such as geographic coordinates, street names, address ranges, speed limits, turn restrictions at intersections, and other navigation related attributes, as well as POIs, such as gasoline stations, hotels, restaurants, museums, stadiums, offices, automobile dealerships, auto repair shops, buildings, stores, parks, etc. The geographic database <NUM> can include data about the POIs and their respective locations in the POI data records <NUM>. The geographic database <NUM> can also include data about places, such as cities, towns, or other communities, and other geographic features, such as bodies of water, mountain ranges, etc. Such place or feature data can be part of the POI data records <NUM> or can be associated with POIs or POI data records <NUM> (such as a data point used for displaying or representing a position of a city).

In one example, the geographic database <NUM> can also include passenger profile records <NUM> for storing passenger profiles and related data generated for one or more users. The passenger profile data records <NUM> can also include collected vehicle sensor data, user sensor data, detected driving behaviors, associated user reactions (e.g., comfort level, discomfort level). In one embodiment, the passenger profile data records <NUM> and/or the detected driving behaviors and passenger reactions can be associated with segments of a road link (as opposed to an entire link). It is noted that the segmentation of the road for the purposes of detecting driving behaviors and/or reactions data can be different than the street network or road link structure of the geographic database <NUM>. In other words, the segments can further subdivide the links of the geographic database <NUM> into smaller segments (e.g., of uniform lengths such as <NUM>-meters). In this way, the driving behaviors included in the passenger profiles can be represented at a level of granularity that is independent of the granularity or at which the actual road or road network is represented in the geographic database <NUM>. In one example, the passenger profile data records <NUM> can be associated with one or more of the node records <NUM>, road segment records <NUM>, and/or POI data records <NUM>; or portions thereof (e.g., smaller or different segments than indicated in the road segment records <NUM>, individual lanes of the road segments, etc.) to generate passenger profile data for autonomous operation and routing of vehicles.

In one example, the geographic database <NUM> can be maintained by the content provider <NUM> in association with the services platform <NUM> (e.g., a map developer). The map developer can collect geographic data to generate and enhance the geographic database <NUM>. There can be different ways used by the map developer to collect data. These ways can include obtaining data from other sources, such as municipalities or respective geographic authorities. In addition, the map developer can employ field personnel to travel by vehicle along roads throughout the geographic region to observe features (e.g., VRU attributes, VRU patterns, etc.) and/or record information about them, for example. Also, remote sensing, such as aerial or satellite photography, can be used.

In one example, the geographic database <NUM> include high resolution or high definition (HD) mapping data that provide centimeter-level or better accuracy of map features. For example, the geographic database <NUM> can be based on Light Detection and Ranging (LiDAR) or equivalent technology to collect billions of 3D points and model road surfaces and other map features down to the number lanes and their widths. In one embodiment, the HD mapping data capture and store details such as the slope and curvature of the road, lane markings, roadside objects such as sign posts, including what the signage denotes. By way of example, the HD mapping data enable highly automated vehicles to precisely localize themselves on the road, and to determine road attributes (e.g., learned speed limit values) to at high accuracy levels.

In one example, the geographic database <NUM> is stored as a hierarchical or multilevel tile-based projection or structure. More specifically, in one example, the geographic database <NUM> may be defined according to a normalized Mercator projection. Other projections may be used. By way of example, the map tile grid of a Mercator or similar projection is a multilevel grid. Each cell or tile in a level of the map tile grid is divisible into the same number of tiles of that same level of grid. In other words, the initial level of the map tile grid (e.g., a level at the lowest zoom level) is divisible into four cells or rectangles. Each of those cells are in turn divisible into four cells, and so on until the highest zoom or resolution level of the projection is reached.

In one example, the map tile grid may be numbered in a systematic fashion to define a tile identifier (tile ID). For example, the top left tile may be numbered <NUM>, the top right tile may be numbered <NUM>, the bottom left tile may be numbered <NUM>, and the bottom right tile may be numbered <NUM>. In one example, each cell is divided into four rectangles and numbered by concatenating the parent tile ID and the new tile position. A variety of numbering schemes also is possible. Any number of levels with increasingly smaller geographic areas may represent the map tile grid. Any level (n) of the map tile grid has <NUM>(n+<NUM>) cells. Accordingly, any tile of the level (n) has a geographic area of A/<NUM>(n+<NUM>) where A is the total geographic area of the world or the total area of the map tile grid <NUM>. Because of the numbering system, the exact position of any tile in any level of the map tile grid or projection may be uniquely determined from the tile ID.

In one example, the system <NUM> may identify a tile by a quadkey determined based on the tile ID of a tile of the map tile grid. The quadkey, for example, is a one-dimensional array including numerical values. In one example, the quadkey may be calculated or determined by interleaving the bits of the row and column coordinates of a tile in the grid at a specific level. The interleaved bits may be converted to a predetermined base number (e.g., base <NUM>, base <NUM>, hexadecimal). In one example, leading zeroes are inserted or retained regardless of the level of the map tile grid in order to maintain a constant length for the one-dimensional array of the quadkey. In another example, the length of the one-dimensional array of the quadkey may indicate the corresponding level within the map tile grid <NUM>. In one example, the quadkey is an example of the hash or encoding scheme of the respective geographical coordinates of a geographical data point that can be used to identify a tile in which the geographical data point is located.

For example, geographic data is compiled (such as into a platform specification format (PSF) format) to organize and/or configure the data for performing navigation-related functions and/or services, such as route calculation, route guidance, map display, speed calculation, distance and travel time functions, and other functions, by a navigation device, such as by the vehicle <NUM>, for example. The navigation-related functions can correspond to vehicle navigation, pedestrian navigation, or other types of navigation. The compilation to produce the end user databases can be performed by a party or entity separate from the map developer. For example, a customer of the map developer, such as a navigation device developer or other end user device developer, can perform compilation on a received geographic database in a delivery format to produce one or more compiled navigation databases.

The processes described herein for generating a passenger-based driving profile may be advantageously implemented via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware or a combination thereof. Such exemplary hardware for performing the described functions is detailed below.

<FIG> illustrates a computer system <NUM> upon which an embodiment of the invention may be implemented. Computer system <NUM> is programmed (e.g., via computer program code or instructions) to generate a passenger-based driving profile as described herein and includes a communication mechanism such as a bus <NUM> for passing information between other internal and external components of the computer system <NUM>. Information (also called data) is represented as a physical expression of a measurable phenomenon, typically electric voltages, but including, in other examples, such phenomena as magnetic, electromagnetic, pressure, chemical, biological, molecular, atomic, sub-atomic and quantum interactions. For example, north and south magnetic fields, or a zero and non-zero electric voltage, represent two states (<NUM>, <NUM>) of a binary digit (bit). Other phenomena can represent digits of a higher base. A superposition of multiple simultaneous quantum states before measurement represents a quantum bit (qubit). A sequence of one or more digits constitutes digital data that is used to represent a number or code for a character. In some examples, information called analog data is represented by a near continuum of measurable values within a particular range.

A processor <NUM> performs a set of operations on information as specified by computer program code related to generating a passenger-based driving profile. The computer program code is a set of instructions or statements providing instructions for the operation of the processor and/or the computer system to perform specified functions. The code, for example, may be written in a computer programming language that is compiled into a native instruction set of the processor. The code may also be written directly using the native instruction set (e.g., machine language). The set of operations include bringing information in from the bus <NUM> and placing information on the bus <NUM>. The set of operations also typically include comparing two or more units of information, shifting positions of units of information, and combining two or more units of information, such as by addition or multiplication or logical operations like OR, exclusive OR (XOR), and AND. Each operation of the set of operations that can be performed by the processor is represented to the processor by information called instructions, such as an operation code of one or more digits. A sequence of operations to be executed by the processor <NUM>, such as a sequence of operation codes, constitute processor instructions, also called computer system instructions or, simply, computer instructions. Processors may be implemented as mechanical, electrical, magnetic, optical, chemical or quantum components, among others, alone or in combination.

Computer system <NUM> also includes a memory <NUM> coupled to bus <NUM>. The memory <NUM>, such as a random access memory (RAM) or other dynamic storage device, stores information including processor instructions for generating a passenger-based driving profile. Dynamic memory allows information stored therein to be changed by the computer system <NUM>. RAM allows a unit of information stored at a location called a memory address to be stored and retrieved independently of information at neighboring addresses. The memory <NUM> is also used by the processor <NUM> to store temporary values during execution of processor instructions. The computer system <NUM> also includes a read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information, including instructions, that is not changed by the computer system <NUM>. Some memory is composed of volatile storage that loses the information stored thereon when power is lost. Also coupled to bus <NUM> is a non-volatile (persistent) storage device <NUM>, such as a magnetic disk, optical disk or flash card, for storing information, including instructions, that persists even when the computer system <NUM> is turned off or otherwise loses power.

Information, including instructions for generating a passenger-based driving profile, is provided to the bus <NUM> for use by the processor from an external input device <NUM>, such as a keyboard containing alphanumeric keys operated by a human user, or a sensor. A sensor detects conditions in its vicinity and transforms those detections into physical expression compatible with the measurable phenomenon used to represent information in computer system <NUM>. Other external devices coupled to bus <NUM>, used primarily for interacting with humans, include a display device <NUM>, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), or plasma screen or printer for presenting text or images, and a pointing device <NUM>, such as a mouse or a trackball or cursor direction keys, or motion sensor, for controlling a position of a small cursor image presented on the display <NUM> and issuing commands associated with graphical elements presented on the display <NUM>. In some examples, in which the computer system <NUM> performs all functions automatically without human input, one or more of external input device <NUM>, display device <NUM> and pointing device <NUM> is omitted.

In the illustrated example, special purpose hardware, such as an application specific integrated circuit (ASIC) <NUM>, is coupled to bus <NUM>.

Computer system <NUM> also includes one or more instances of a communications interface <NUM> coupled to bus <NUM>. Communication interface <NUM> provides a one-way or two-way communication coupling to a variety of external devices that operate with their own processors, such as printers, scanners and external disks. In general the coupling is with a network link <NUM> that is connected to a local network <NUM> to which a variety of external devices with their own processors are connected. For example, communication interface <NUM> may be a parallel port or a serial port or a universal serial bus (USB) port on a personal computer. In some examples, communications interface <NUM> is an integrated services digital network (ISDN) card or a digital subscriber line (DSL) card or a telephone modem that provides an information communication connection to a corresponding type of telephone line. In some examples, a communication interface <NUM> is a cable modem that converts signals on bus <NUM> into signals for a communication connection over a coaxial cable or into optical signals for a communication connection over a fiber optic cable. As another example, communications interface <NUM> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN, such as Ethernet. For wireless links, the communications interface <NUM> sends or receives or both sends and receives electrical, acoustic or electromagnetic signals, including infrared and optical signals, that carry information streams, such as digital data. For example, in wireless handheld devices, such as mobile telephones like cell phones, the communications interface <NUM> includes a radio band electromagnetic transmitter and receiver called a radio transceiver. In certain examples, the communications interface <NUM> enables connection to the communication network <NUM> for generating a passenger-based driving profile.

<FIG> illustrates a chip set <NUM> upon which an embodiment of the invention may be implemented. Chip set <NUM> is programmed to generate a passenger-based driving profile as described herein and includes, for instance, the processor and memory components described with respect to <FIG> incorporated in one or more physical packages (e.g., chips). By way of example, a physical package includes an arrangement of one or more materials, components, and/or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and/or limitation of electrical interaction. It is contemplated that the chip set can be implemented in a single chip.

In one example, the chip set <NUM> includes a communication mechanism such as a bus <NUM> for passing information among the components of the chip set <NUM>.

The processor <NUM> and accompanying components have connectivity to the memory <NUM> via the bus <NUM>. The memory <NUM> includes both dynamic memory (e.g., RAM, magnetic disk, writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, etc.) for storing executable instructions that when executed perform the inventive steps described herein to generate a passenger-based driving profile. The memory <NUM> also stores the data associated with or generated by the execution of the inventive steps.

<FIG> is a diagram of exemplary components of a mobile terminal (e.g., handset) capable of operating in the system of <FIG>, according to one example. Generally, a radio receiver is often defined in terms of front-end and back-end characteristics. The front-end of the receiver encompasses all of the Radio Frequency (RF) circuitry whereas the back-end encompasses all of the base-band processing circuitry. Pertinent internal components of the telephone include a Main Control Unit (MCU) <NUM>, a Digital Signal Processor (DSP) <NUM>, and a receiver/transmitter unit including a microphone gain control unit and a speaker gain control unit. A main display unit <NUM> provides a display to the user in support of various applications and mobile station functions that offer automatic contact matching. An audio function circuitry <NUM> includes a microphone <NUM> and microphone amplifier that amplifies the speech signal output from the microphone <NUM>. The amplified speech signal output from the microphone <NUM> is fed to a coder/decoder (CODEC) <NUM>.

In one example, the processed voice signals are encoded, by units not separately shown, using a cellular transmission protocol such as global evolution (EDGE), general packet radio service (GPRS), global system for mobile communications (GSM), Internet protocol multimedia subsystem (IMS), universal mobile telecommunications system (UMTS), etc., as well as any other suitable wireless medium, e.g., microwave access (WiMAX), Long Term Evolution (LTE) networks, code division multiple access (CDMA), wireless fidelity (WiFi), satellite, and the like.

The MCU <NUM> receives various signals including input signals from the keyboard <NUM>. The keyboard <NUM> and/or the MCU <NUM> in combination with other user input components (e.g., the microphone <NUM>) comprise a user interface circuitry for managing user input. The MCU <NUM> runs a user interface software to facilitate user control of at least some functions of the mobile station <NUM> to generate a passenger-based driving profile. The MCU <NUM> also delivers a display command and a switch command to the display <NUM> and to the speech output switching controller, respectively. Further, the MCU <NUM> exchanges information with the DSP <NUM> and can access an optionally incorporated SIM card <NUM> and a memory <NUM>. In addition, the MCU <NUM> executes various control functions required of the station. The DSP <NUM> may, depending upon the implementation, perform any of a variety of conventional digital processing functions on the voice signals. Additionally, DSP <NUM> determines the background noise level of the local environment from the signals detected by microphone <NUM> and sets the gain of microphone <NUM> to a level selected to compensate for the natural tendency of the user of the mobile station <NUM>.

Claim 1:
A computer-implemented method comprising:
detecting (<NUM>) an identity of a user of a vehicle (<NUM>);
retrieving (<NUM>) a passenger profile of the user based on the identity, wherein the passenger profile is generated based on sensor data indicating a reaction of the user to at least one vehicle driving behavior previously experienced by the user as a vehicle passenger, wherein the passenger profile includes at least one driving behavior and a corresponding reaction of the user; and
configuring (<NUM>) the vehicle (<NUM>) based on the passenger profile of the user when the vehicle is carrying the user as a passenger, wherein the configuring of the vehicle (<NUM>) comprises adapting a driving style of the vehicle (<NUM>) based on the passenger profile; wherein the method further comprises
determining (<NUM>) whether the vehicle (<NUM>) carries one or more other users as passengers in addition to the user; and when it is determined that the vehicle (<NUM>) carries one or more other users as passengers in addition to the user
retrieving (<NUM>) one or more other passenger profiles of the one or more other users;
determining (<NUM>) a common denominator driving behavior from among the passenger profile and the one or more other passenger profiles, the common denominator driving behavior being a driving behavior that is comfortable to the user and to said one or more other users based on their respective passenger profiles, wherein the driving style of the vehicle (<NUM>) is adapted based on the common denominator driving behavior; and
when a common denominator driving behavior from among the passenger profile and the one or more other passenger profiles cannot be determined, alerting the users of the incompatibility of passenger profiles.