Patent Description:
Some vehicles include self-driving systems that make and implement driving decisions for the driver with little or no input from the driver. In a typical self-driving system, a variety of sensors monitor the environment surrounding the vehicle and the vehicle itself. Based on the resulting sensor data, a self-driving model makes driving decisions and causes the vehicle to implement the driving decisions via at least one control mechanism. The effect of a self-driving system is that the self-driving model drives the vehicle instead of the driver. Importantly, self-driving models can improve overall driving safety and the overall driving experience. For example, self-driving models can improve driving safety when a driver is inexperienced or distracted by reducing the number of driving mistakes and accidents caused by human error. However, in order for self-driving models to improve driving safety, the drivers have to actually use the self-driving models.

Currently, many drivers do not use self-driving models, even when available, because the drivers do not trust the ability of self-driving models to make appropriate driving decisions. In particular, because self-driving models do not usually take into account how different driving actions affect users (e.g., drivers and passengers), self-driving models can repeatedly make certain types of driving decisions that discourage some users from using self-driving models. For example, if a self-driving model repeatedly caused a vehicle to execute turns at high speeds that made a particular user feel uncomfortable or not in control, then the user could insist on manually driving the vehicle even under adverse conditions, such as when the user were tired, inebriated, etc..

To improve the overall performance of self-driving models, many providers of self-driving models periodically update or modify the self-driving models based on feedback received from users. For example, if a provider of a self-driving model were to receive feedback indicating that the self-driving model routinely caused vehicles to execute turns at high speeds that made users feel uncomfortable or not in control, then the provider could modify the self-driving model to ensure that turns are navigated within a more acceptable range of speeds.

One drawback of modifying a self-driving model based on feedback from users is that collecting the user feedback and modifying the self-driving model based on that feedback can take a long time. Meanwhile, in the interim period, some users could decide to stop using the self-driving model altogether, and, in more extreme cases, some users could even become opponents of the movement towards self-driving vehicles. Another drawback of modifying a self-driving model based on feedback from users is that usually only a subset of users provides feedback and the preferences of other users and potential users may not be considered when the provider modifies the self-driving model. Furthermore, different users typically have different driving styles, different driving preferences, and so forth. Because modifications to the self-driving model usually reflect average driving styles and preferences instead of personalized driving styles and preferences, the modifications may actually decrease the perceived performance of the self-driving model for some users.

In <CIT>, a method for customizing motion characteristics of an autonomous vehicle for a user is described.

As the foregoing illustrates, what is needed in the art are more effective techniques for implementing self-driving models.

One embodiment of the invention sets forth a computer-implemented method for modifying a self-driving model based on data associated with at least one user of a vehicle. The method includes computing at least one value for a psychological metric based on first sensor data that is associated with a user of the vehicle and is acquired while the self-driving model operates the vehicle; determining a description of the user over a first time period based on the at least one value for the psychological metric; generating a first dataset based on the description and second sensor data that is associated with the vehicle and is acquired over the first time period; and performing at least one machine learning operation on the self-driving model based on the first dataset to generate a modified self-driving model.

At least one technical advantage of the disclosed embodiments of the invention relative to the prior art is that measured physiological data is used to automatically modify self-driving models to account for the impact different driving actions have on users. In particular, self-driving models can be efficiently re-trained to disfavor driving actions that are likely to have negative psychological impacts on users. Furthermore, self-driving models can be personalized to account for different user preferences and can therefore increase overall trust in self-driving systems across a wide variety of users. These technical advantages provide at least one technological advancement over prior art approaches.

So that the manner in which the above recited features of the various embodiments can be understood in detail, a more particular description of the inventive concepts, briefly summarized above, may be had by reference to various embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of the inventive concepts and are therefore not to be considered limiting of scope in any way, and that there are other equally effective embodiments.

In the following description, numerous specific details are set forth to provide a more thorough understanding of the various embodiments. However, it will be apparent to one skilled in the art that the inventive concepts may be practiced at least one of these specific details.

<FIG> is a conceptual illustration of a system <NUM> configured to implement at least one aspect of the various embodiments. The system <NUM> includes, without limitation, a vehicle <NUM>, and compute instances <NUM>. For explanatory purposes, multiple instances of like objects are denoted with reference alphanumeric characters identifying the object and parenthetical alphanumeric characters identifying the instance where needed.

In alternate embodiments, the system <NUM> may include any number of compute instances <NUM>, any number of vehicles <NUM>, and any number of additional components (e.g., applications, subsystems, modules, etc.) in any combination. Any number of the components of the system <NUM> may be distributed across multiple geographic locations or implemented in at least one cloud computing environment (i.e., encapsulated shared resources, software, data, etc.) in any combination.

The vehicle <NUM> may be any type of ground-based or non-ground-based machine that transports at least one human occupant. For instance, the vehicle <NUM> may be, among other things, a car, a motorcycle, a sport utility vehicle, a truck, a bus, an all-terrain vehicle, a snowmobile, a commercial construction machine (e.g., a crane, an excavator, etc.), an airplane, a helicopter, a boat, a submarine, an electric vertical takeoff and landing vehicle, or a spaceship. Furthermore, the vehicle <NUM> may be a taxi, an Uber vehicle, a Lyft vehicle, etc. The vehicle is occupied by a person who sits in the driver seat and is referred to herein as "driver" and any number of other persons who sit in passenger seats and are referred to herein as passengers. The driver and all such other persons that occupy the vehicle <NUM> are referred to herein as "users.

As shown, each of the compute instances <NUM> includes, without limitation, a processor <NUM> and a memory <NUM>. The processor <NUM> may be any instruction execution system, apparatus, or device capable of executing instructions. For example, the processor <NUM> could comprise a central processing unit, a graphics processing unit, a controller, a micro-controller, a state machine, or any combination thereof. The memory <NUM> stores content, such as software applications and data, for use by the processor <NUM> of the compute instance <NUM>. In alternate embodiments, each of any number of compute instances <NUM> may include any number of processors <NUM> and any number of memories <NUM> in any combination. In particular, any number of the compute instances <NUM> (including one) may provide a multiprocessing environment in any technically feasible fashion.

The memory <NUM> may be at least one of a readily available memory, such as random-access memory, read-only memory, floppy disk, hard disk, or any other form of digital storage, local or remote. In some embodiments, a storage (not shown) may supplement or replace the memory <NUM>. The storage may include any number and type of external memories that are accessible to the processor <NUM>. For example, and without limitation, the storage may include a Secure Digital Card, an external Flash memory, a portable compact disc read-only memory, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Each of the compute instances <NUM> is configured to implement at least one software application or subsystems of software applications. For explanatory purposes only, each software application is depicted as residing in the memory <NUM> of a single compute instance <NUM> and executing on the processor <NUM> of the single compute instance <NUM>. However, in alternate embodiments, the functionality of each software application may be distributed across any number of other software applications that reside in the memories <NUM> of any number of compute instances <NUM> and execute on the processors <NUM> of any number of compute instances <NUM> in any combination. Further, the functionality of any number of software applications or subsystems may be consolidated into a single software application or subsystem.

More specifically, the compute instances <NUM> are configured to implement a self-driving model <NUM> that operates the vehicle <NUM> with little or no human intervention when the vehicle <NUM> is in a self-driving mode. As described previously herein, in one conventional approach to improving the performance of a self-driving model, a provider periodically modifies the self-driving model based on feedback received from users. One drawback of relying on feedback received from users is that collecting the user feedback can take a long time. Furthermore, the modifications to the conventional self-driving model typically reflect average driving styles and preferences for the subset of users who manually provide feedback. As a result, the modifications may actually decrease the perceived performance of the self-driving model for users that have atypical driving styles and preferences.

To more efficiently and reliably increase the quality of the driving experience as perceived by the users, the compute instances <NUM> are configured to implement, without limitation, a self-driving modeling subsystem <NUM> and a feedback application <NUM>. As described in detail below, the self-driving modeling subsystem <NUM> generates the self-driving model <NUM> that operates the vehicle <NUM> while the vehicle <NUM> is in the self-driving mode. As the vehicle <NUM> operates, the feedback application <NUM> automatically evaluates the mental states of the users to generate feedback that enables the self-driving modeling subsystem <NUM> to generate a new self-driving model <NUM> that is better aligned with the driving styles and preferences of the users. For example, the feedback application <NUM> could generate feedback indicating that the users became agitated when the self-driving model <NUM> caused the vehicle <NUM> to execute a left turn during an eight second gap in the oncoming traffic. The self-driving modeling subsystem <NUM> could then use the feedback to generate a new self-driving model <NUM> that does not initiate a left turn unless there is at least a nine second gap in oncoming traffic.

Note that the techniques described herein are illustrative rather than restrictive and may be altered without departing from the broader spirit and scope of the embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments and techniques. Further, in various embodiments, any number of the techniques disclosed herein may be implemented while other techniques may be omitted in any technically feasible fashion.

Notably, and for explanatory purposes only, the system <NUM> is described in the context of the self-driving model <NUM> that is a machine learning model trained by the self-driving modeling subsystem <NUM>. The self-driving modeling subsystem <NUM> uses the feedback generated by the feedback application <NUM> to re-train the self-driving model <NUM>, thereby improving the performance of the self-driving model <NUM> as perceived by the users. In alternate embodiments, the self-driving model <NUM> may implement any number and type of algorithms (e.g., heuristics, rules, etc.) and the self-driving modeling subsystem <NUM> may modify the algorithms based on any type of feedback generated by the feedback application <NUM> in any technically feasible fashion.

To enable the self-driving model <NUM> to safely maneuver the vehicle <NUM> and the feedback application <NUM> to evaluate the users, the vehicle <NUM> includes, without limitation, vehicle sensors <NUM>, outward-facing sensors <NUM>, and user sensors <NUM>. The vehicle sensors <NUM>, the outward-facing sensors <NUM>, and the user sensors <NUM> may be distributed across any number of locations. For instance, in some embodiments, each of the user sensors <NUM> is attached to the vehicle <NUM> (e.g., built into a steering wheel, headrest, etc.) or worn by a user of the vehicle <NUM>.

Although not shown, the vehicle <NUM> additionally includes, without limitation, any number of primary vehicle components that can be used to operate the vehicle <NUM>. Some examples of primary vehicle components include, without limitation, a braking system, a powertrain, a transmission, a steering system, and a headlight control system. In at least one embodiment, the vehicle <NUM> may also include, without limitation, any number and type of secondary vehicle components that can be used to monitor the primary driving task and/or perform any number of secondary tasks. For example, the vehicle <NUM> could include, without limitation, am instrument cluster (e.g., a temperature control subsystem, an analog speedometer, a digital dashboard, etc.) and a head unit that interfaces to an infotainment system and a navigation system.

The vehicle sensors <NUM> and the outward-facing sensors <NUM> monitor the vehicle <NUM> itself and the area surrounding the vehicle <NUM>, respectively, in real-time. As the vehicle <NUM> operates, a vehicle observation subsystem <NUM> processes signals received from the vehicle sensors <NUM> and the outward-facing sensors <NUM> to generate a vehicle state <NUM>. The vehicle observation subsystem <NUM> resides in the memory <NUM>(<NUM>) of the compute instance <NUM>(<NUM>) and executes on the processor <NUM>(<NUM>) of the compute instance <NUM>(<NUM>). In at least one alternate embodiment, the vehicle observation subsystem <NUM> is implemented in a compute instance <NUM> that is included in the vehicle <NUM>.

As shown, the vehicle observation subsystem <NUM> includes, without limitation, a driver vehicle input module <NUM>, a vehicle recording module <NUM>, and an outside scene module <NUM>. The driver vehicle input module <NUM> processes sensor signals received from any number of the vehicle sensors <NUM> to generate driver input data (not shown) that is included in the vehicle state <NUM>. The driver input data specifies inputs determined by a driver while the vehicle <NUM> is not operating in the self-driving mode, such as the current steering wheel angle, the accelerator pedal position, the brake pedal position, and so forth.

The vehicle recording module <NUM> processes sensor signals received from any number of the vehicle sensors <NUM> and any number of the outward-facing sensors <NUM> to generate vehicle telemetry data (not shown) that is included in the vehicle state <NUM>. The vehicle telemetry data specifies characteristics of the vehicle <NUM>, such as the speed, lateral acceleration, direction, position, engine revolutions per minute ("RPM"), battery charge state, and so forth.

The outside scene module <NUM> processes sensor signals received from any number of the outward-facing sensors <NUM> (e.g., a forward-facing camera that is mounted on the vehicle <NUM>, a light detection and ranging sensor, etc.) to generate environmental data (not shown) that is included in the vehicle state <NUM>. The outside scene module <NUM> may perform any number and type of operations (e.g., tracking operations) on the sensor signals in any technically feasible fashion to generate any amount and type of environmental data.

For instance, in at least one embodiment, the outside scene module <NUM> includes, without limitation, a segmentation and classification machine learning model. The outside scene module <NUM> inputs exterior scene images received via the sensor signals into the segmentation and classification model. In response, the segmentation and classification model segments regions in the exterior scene images, classifies the regions into types (e.g., road, vehicle, road sign, pedestrian, etc.), tracks the movement of the classified regions over time, and outputs tracking data (not shown). As the segmentation and classification model generates the tracking data, the outside scene module <NUM> adds the tracking data to the environmental data.

Each of the driver vehicle input module <NUM>, the vehicle recording module <NUM>, and the outside scene module <NUM> operates continuously and automatically. As a result, the vehicle observation subsystem <NUM> updates the vehicle state <NUM> in real-time. In alternate embodiments, any number of components included in the vehicle observation subsystem <NUM> may generate corresponding portions of the vehicle state <NUM> based on any type of trigger (e.g., every ten seconds), and each component may be associated with a different trigger.

As shown, the user sensors <NUM> include, without limitation, body sensor(s) <NUM>, head sensor(s) <NUM>, eye sensor(s) <NUM>, skin sensor(s) <NUM>, audio sensor(s) <NUM>, and neural sensor(s) <NUM>. Each of the user sensors <NUM> is configured to detect and relay physiological data (e.g., measurements) associated with any number of the users of the vehicle <NUM> in real-time. In alternate embodiments, the user sensors <NUM> may include, without limitation, any number and type of devices that detect and relay any quantifiable aspect of a human being in any technically feasible fashion.

The body sensor(s) <NUM> include, without limitation, any number and combination of optical sensors via which the gesticulation and/or posture of a human being can be determined, musculature sensors via which the muscle contractions of a human being can be determined, breathing sensors via which the breathing rate of a human being can be determined, heart rate sensors via which of electrocardiogram readings of a human being can be determined, weight sensors during which the weight distribution of any number of human beings can be determined, or any other technically feasible type of physiological sensor via which any quantifiable aspects of the body of a human being (e.g., a body position, a body orientation, etc.) can be determined.

The head sensor(s) <NUM> include, without limitation, any number and combination of optical sensors, magnetic sensors, blood flow sensors, muscle contraction sensors, thermal sensors, radar sensors, and any other technically feasible type of physiological sensor via which the position and/or orientation of the head of a human being (i.e., a head position and/or a head orientation, respectively) can be determined. The eye sensor(s) <NUM> include, without limitation, any number and combination of an eye gaze direction module, a vergence sensor, a pupillometry sensor, an optical depth sensor, or any other technically feasible type of physiological sensor via which the gaze direction and/or eye convergence distance of a human being can be determined. The skin sensor(s) <NUM> include, without limitation, any number and combination of a galvanic skin response sensor, a skin conduction sensor, a skin texture sensor, or any other technically feasible type of physiological sensor via which at least one attribute of the skin of a human being (e.g., a skin conductivity) can be quantified.

The audio sensor(s) <NUM> include, without limitation, any number and type of a microphone, microphone array, or any other technically feasible type of sensor via which words and sounds associated with a human being can be determined. The neural sensor(s) <NUM> include, without limitation, any number and combination of a neural activity measurement device (e.g., an electroencephalogram sensor), a functional magnetic resonance imaging unit, an optogenetics module, or any other technically feasible type of physiological sensor via which any form of human neural activity can be quantified.

As the vehicle <NUM> operates, a user monitoring subsystem <NUM> acquires sensor data from the user sensors <NUM> and processes the sensor data to generate a user state <NUM>. The user state <NUM> includes, without limitation, any amount and type of emotional data, any amount and type of cognitive load data, and any amount and type of identification data associated with any number of the users. The user monitoring subsystem <NUM> resides in the memory <NUM>(<NUM>) of the compute instance <NUM>(<NUM>) and executes on the processor <NUM>(<NUM>) of the compute instance <NUM>(<NUM>). In at least one alternate embodiment, the user monitoring subsystem <NUM> is implemented in a compute instance <NUM> that is included in the vehicle <NUM>.

As shown, the user monitoring subsystem <NUM> includes, without limitation, an emotion classifier <NUM>, a cognitive load module <NUM>, and an identify classifier <NUM>. The emotion classifier <NUM> generates the emotional data included in the user state <NUM> based on any amount and type of sensor data received from any number of the user sensors <NUM>. The emotional data specifies the emotion of any number of the users as expressed via any type of physiological cues (e.g., visual cues, audio cues, etc.) along any number of emotional dimensions. For instance, in some embodiments, the visual emotion classification includes, without limitation, a discrete emotion classification that specifies emotions such as surprise, joy, fear, sadness, anger, distrust, etc. In the same or other embodiments, the visual emotion classification includes, without limitation, values for a two-dimensional parametrized emotion metric or a three-dimensional parameterized emotion metric. For example, the visual emotion classification could include values for a two-dimensional parametrized emotion metric having the dimensions of valence and arousal or a three-dimensional parameterized emotion having the dimensions of valence, arousal, and dominance.

The emotion classifier <NUM> may determine the emotional data in any technically feasible fashion. For instance, in at least one embodiment, the emotion classifier <NUM> includes, without limitation, a machine learning model that is trained to use any number and/or combination of visible light camera images, infrared light camera images, and/or thermal images of the face of the driver to determine a corresponding visual emotion classification. In the same or other embodiments, the emotion classifier <NUM> includes, without limitation, a machine learning model that is trained to use the speech of a human being to determine a corresponding auditory emotion classification.

The cognitive load module <NUM> generates the cognitive load data included in the user state <NUM> based on any amount and type of sensor data received from the user sensors <NUM>. The cognitive load data includes, without limitation, the cognitive loads of any number of the users. As referred to herein, the cognitive load of a user at a given point in time correlates to the total amount of mental activity imposed on the user and is an indication of how hard the user is concentrating. The cognitive load data may specify the cognitive load in any technically feasible fashion and at any level of granularity. For instance, in at least one embodiment, the cognitive load data includes, without limitation, one of three values (low, medium, or high) of a cognitive load metric for each of the users.

The cognitive load module <NUM> may determine the cognitive load data in any technically feasible fashion. For instance, in some embodiments, the cognitive load module <NUM> may determine the cognitive load data based on sensor data that specifies, without limitation, any number of brain activity, heart rate, skin conductance, steering-wheel grip force, muscle activity, skin/body temperature, and so forth. In the same or other embodiments, the cognitive load module <NUM> includes, without limitation, a machine learning model that is trained to estimate a pupil-based metric that reflects the cognitive load of a human being based on the sizes and/or levels of reactivity of the pupils of the human being. The cognitive load module <NUM> may measure the sizes and/or levels of reactivity of the pupils in any technically feasible fashion. For instance, in some embodiments, the cognitive load module <NUM> may measure the sizes and/or levels of reactivity of the pupils directly based on pupil information obtained via infrared camera images. In the same or other embodiments, the cognitive load module <NUM> may measure the sizes and/or levels of reactivity of the pupils indirectly using deep-learning eye movement tracking based on visible light camera images. In some alternate embodiments, the cognitive load module <NUM> includes, without limitation, a cognitive load classifier (not shown) that generates a value for a cognitive load metric and/or a value for a stress metric based on eye motion data. The eye motion data may include, without limitation, the eye gaze direction. and/or derivatives of eye gaze data patterns in the temporal direction, such as eye saccades and eye fixations, and/or any number and/or types of other derivates of the eye motion data.

In at least one alternate embodiment, the cognitive load module <NUM> may determine the cognitive load data based, at least in part, on audio data received from any number of microphones included in the user sensors <NUM>. For instance, the cognitive load module <NUM> may implement any number of algorithms that analyze the audio data to detect conversational context, conversational turn taking, voice tone and affect, auditory distractions, and the like. For example, and without limitation, the cognitive load module <NUM> could detect that two of the users are engaged in conversation, determine that one of the users is drowsy based on the tone of the user, and so forth.

The identity classifier <NUM> generates the identification data included in the user state <NUM> based on any amount and type of sensor data received from the user sensors <NUM>. The identification data may specify any amount and type of data (e.g., classifications) that identifies and/or classifies any number of the users at any level of granularity. For example, for each user, the identification data could specify a person, a group of people, or a characteristic that identifies the user or a group to which the user belongs. The identity classifier <NUM> may compute the identification data in any technically feasible fashion. For instance, in at least one embodiment, the identity classifier <NUM> includes, without limitation, a machine learning model that is trained to estimate an identification classification for a human being. In at least one other embodiment, the identity classifier <NUM> implements any number and type of heuristics to estimate an identification classification for each user.

In at least one alternate embodiment, the identity classifier <NUM> determines the identity classification based on the sensor data received from the user sensors <NUM> in conjunction with additional information associated with the users and/or the vehicle <NUM>. For instance, in some alternate embodiments, the identity classifier <NUM> receives driver vehicle input data generated by the driver vehicle input module <NUM>. The identity classifier <NUM> analyzes the driver vehicle input data to generate at least one behavioral characterization for the actions of the associated user. The identity classifier <NUM> then determines the identification data for the user based on the behavior characterization(s) in conjunction with the sensor data received from the user sensors <NUM>.

Each of the emotion classifier <NUM>, the cognitive load module <NUM>, and the identify classifier <NUM> operates continuously and automatically. As a result, the user monitoring subsystem <NUM> updates the user state <NUM> in real-time. In alternate embodiments, any number of components included in the user monitoring subsystem <NUM> may generate corresponding portions of the user state <NUM> based on any type of trigger (e.g., every ten seconds), and each component may be associated with a different trigger.

In at least one alternate embodiment, the user state <NUM> may include, without limitation, any number of values for any number of psychological metrics instead of or in addition to the emotional data, the cognitive load data, and the identification data. As referred to herein, a "psychological metric" is any type of measurement of any emotional aspect, cognitive aspect, or other mental aspect of a human being. In the same or other alternate embodiments, the user state <NUM> may include, without limitation, collective data or average data instead of or in addition to per-user data. For instance, in at least one alternate embodiment, the user state <NUM> may include, without limitation, an average cognitive load and an average emotional load. In at least one alternate embodiment, the user state <NUM> may represent a subset of the users (e.g., the users sitting in the front seats).

A self-driving application <NUM> enables the vehicle <NUM> to operate in the self-driving mode. The self-driving mode may be activated in any technically feasible fashion. In at least one embodiment, the self-driving mode may be activated via a remote control that is associated with the vehicle <NUM>. In the same or other embodiments, the self-driving mode may be activated via a control mounted on the steering wheel of the vehicle <NUM> or the dashboard of the vehicle <NUM>. In at least one embodiment, the self-driving application <NUM> resides in the memory <NUM>(<NUM>) of the compute instance <NUM>(<NUM>) and executes on the processor <NUM>(<NUM>) of the compute instance <NUM>(<NUM>). In at least one alternate embodiment, the self-driving application <NUM> is implemented in a compute instance <NUM> that is included in the vehicle <NUM>.

As shown, the self-driving application <NUM> includes, without limitation, the self-driving model <NUM>. When the self-driving mode is activated, the self-driving application <NUM> determines self-driving actions <NUM> based on the self-driving model <NUM> and transmits corresponding self-driving signals <NUM> in real-time to at least one component associated with the vehicle <NUM>. The self-driving actions <NUM> specify any number of actions associated with performing at least a portion of the primary driving task, and the self-driving signals <NUM> control any number of operational aspects of the vehicle <NUM> to affect the self-driving actions <NUM>.

In at least one embodiment, the self-driving signals <NUM> control, without limitation, at least one of the steering, the braking, the acceleration, the signals, or the headlights of the vehicle <NUM> at any given time. Each of the self-driving signals <NUM> may control any number of associated components of the vehicle <NUM> in any technically feasible fashion. For instance, in at least one embodiment, any number of the self-driving signals <NUM> are brake control signals, and the self-driving application <NUM> transmits the brake control signals to actuators that control the brakes of the vehicles <NUM>.

The self-driving application <NUM> may determine the self-driving actions <NUM> and the self-driving signals <NUM> in any technically feasible fashion. In at least one embodiment, the self-driving application <NUM> receives the vehicle state <NUM> and inputs at least a portion of the vehicle state <NUM> into the self-driving model <NUM>. In response, the self-driving model <NUM> outputs the self-driving actions <NUM>. The self-driving application <NUM> then converts the self-driving actions <NUM> into corresponding self-driving signals <NUM> and transmits the self-driving signals <NUM> to at least one component associated with the vehicle <NUM>. In at least one embodiment, the self-driving application <NUM> transmits the self-driving actions <NUM> to the feedback application <NUM>.

As depicted with a dotted arrow, in at least one alternate embodiment, the self-driving model receives the user state <NUM> in addition to the vehicle state <NUM> and inputs at least a portion of the vehicle state <NUM> and at least a portion of the user state <NUM> into the self-driving model <NUM>. In response, the self-driving model <NUM> outputs the self-driving actions <NUM>. In at least one alternate embodiment, the self-driving application <NUM> may perform any number and type of preprocessing operations to generate inputs for the self-driving model <NUM> based, at least in part, on the vehicle state <NUM> and, optionally, the user state <NUM>. In the same or other alternate embodiments, the self-driving application <NUM> may perform any number and type of postprocessing operations based, at least in part, on the output of the self-driving model <NUM> to generate the self-driving actions <NUM>.

In at least one alternate embodiment, the self-driving application <NUM> may interact with any number (including none) of advanced driver assistance systems ("ADAS") features associated with the vehicle <NUM> n any technically feasible fashion. Each ADAS feature is intended to increase driving safety when the vehicle <NUM> is operating. Some examples of ADAS features include, without limitation, anti-lock braking, blind spot detection, collision avoidance, lane keeping assist, hill descent control, autonomous parking, etc..

Together, the self-driving application <NUM> and the self-driving model <NUM> may implement, without limitation, any number and type of algorithms based on the vehicle state <NUM> and, optionally, the user state <NUM> to generate the self-driving actions <NUM> and the corresponding self-driving signals <NUM>. For instance, in at least one embodiment, each of the self-driving application <NUM> and the self-driving model <NUM> may implement, without limitation, any number and type of rules, any number and type of heuristics, and any number and type of machine learning techniques in any combination. In at least one alternate embodiment, the self-driving application <NUM> is omitted from the system <NUM> and the self-driving model <NUM> acquires input data directly from the vehicle observation subsystem <NUM> and, optionally, the user monitoring subsystem <NUM> and generates the self-driving actions <NUM> and/or the self-driving signals <NUM>. In the same or other alternate embodiments, the self-driving model <NUM> transmits the self-driving actions <NUM> to the feedback application <NUM> and/or transmits the self-driving signals <NUM> to any number of the components of the vehicle <NUM>.

In at least one embodiment, the self-driving application <NUM> acquires the self-driving model <NUM> from the self-driving modeling subsystem <NUM>. The self-driving modeling subsystem <NUM> resides in the memory <NUM>(<NUM>) of the compute instance <NUM>(<NUM>) and executes on the processor <NUM>(<NUM>) of the compute instance <NUM>(<NUM>). In at least one embodiment, the compute instance <NUM>(<NUM>) is included in a cloud computing environment or a distributed computing environment.

As shown, the self-driving modeling subsystem <NUM> includes, without limitation, a label set <NUM>, a training database <NUM>, a training application <NUM>, and the self-driving model <NUM>. The label set <NUM> includes, without limitation, labels <NUM>(<NUM>)-<NUM>(L), where each of the labels <NUM> corresponds to a different psychological characterization of at least one user. In at least one embodiment, each of the labels <NUM> is also referred to herein as a "description" of at least one user. For instance, in some embodiments, the labels <NUM> may include, without limitation, "fearful," "frustrated," "high cognitive load," "joyful," and so forth. In alternate embodiments, the label set <NUM> may include, without limitation, a single label <NUM>(<NUM>).

The training database <NUM> includes, without limitation, any number of labeled datasets <NUM> and is associated with any number of vehicles <NUM> and any number of users. Each labeled dataset <NUM> is associated with a different combination of time period and vehicle <NUM>. For a given vehicle <NUM>, each labeled dataset <NUM> includes, without limitation, one of the labels <NUM> that characterizes the users during the associated time period, the vehicle states <NUM> during the associated time period, and the self-driving actions <NUM> during the associated time period. For example, one of the labeled datasets <NUM> could include, without limitation, the vehicle states <NUM> indicating that the vehicle <NUM> performed a left turn during an eight second gap in the oncoming traffic, the self-driving actions <NUM> associated with the left turn, and the label <NUM> of fearful.

The training database <NUM> may be initially generated in any technically feasible fashion. For instance, the training database <NUM> may be manually or automatically generated based on any number of driving scenarios (not shown in <FIG>) and default driving preferences instead of measured data associated with actual vehicle <NUM> and users. Some examples of driving preferences include, without limitation, preferences regarding a maximum speed, a maximum deceleration, a maximum acceleration, a minimum distance from other vehicles and objects, a minimum level of politeness to other road users, a minimum level of adherence to road rules, and so forth.

The training application <NUM> implements any number and type of machine learning operations to generate the self-driving model <NUM> based on the training database <NUM>. To generate the initial self-driving model <NUM>, the training application <NUM> trains any type of untrained machine learning model or incompletely trained machine learning model using the training database <NUM>. The self-driving modeling subsystem <NUM> then provides (e.g., transmits, copies to a known location, etc.) the self-driving model <NUM> to at least one instance of the self-driving application <NUM>.

As described in greater detail below, as the vehicle <NUM> operates, the feedback application <NUM> generates new labeled dataset(s) <NUM> and adds the new labeled dataset(s) <NUM> to the training database <NUM>. Subsequently, based on any type of trigger (e.g., every day), the self-driving modeling subsystem <NUM> re-executes the training application <NUM>. When the training application <NUM> is re-executed, the training application <NUM> re-trains the self-driving model <NUM> using the updated training database <NUM>. The self-driving modeling subsystem <NUM> then provides (e.g., transmits, copies to a known location, etc.) the updated self-driving model <NUM> to the self-driving application <NUM> associated with the vehicle <NUM>.

In at least one alternate embodiment, the self-driving application <NUM> may acquire an up-to-date self-driving model <NUM> at any point in time and in any technically feasible fashion. Accordingly, the performance of the self-driving model <NUM> as perceived by the users is incrementally improved over time. For example, the self-driving model <NUM> may become better aligned with the preferences of the users regarding a maximum speed, a maximum deceleration, a maximum acceleration, a minimum distance from other vehicles and objects, a minimum level of politeness to other road users, a minimum level of adherence to road rules, and so forth.

As persons skilled in the art will recognize, the techniques described herein may be used to modify any number of self-driving models <NUM> based on any number of vehicles <NUM> and any number of users to reflect any granularity of customization. For instance, in at least one embodiment, the system <NUM> includes, without limitation, a different self-driving model <NUM> for each of any number of vehicles <NUM>. For each of the vehicles <NUM>, an associated instance of the feedback application <NUM> generates new labeled datasets <NUM> that the training application <NUM> uses to re-train the associated self-driving model <NUM>. As a result, each of the self-driving models <NUM> is iteratively and automatically customized over time to reflect the preferences of the users of a different vehicle <NUM>. Similarly, in at least one alternate embodiment, the techniques described herein may be modified to iteratively and automatically customize a different self-driving model <NUM> for each user across any number of vehicles <NUM>.

In at least one alternate embodiment, a single self-driving model <NUM> is associated with multiple vehicles <NUM>. For each of the vehicles <NUM>, an associated instance of the feedback application <NUM> generates new labeled datasets <NUM> and then adds the new labeled datasets <NUM> to a shared training database <NUM>. The training application <NUM> uses the shared training database <NUM> to re-train the self-driving model <NUM>. As a result, the self-driving model <NUM> is iteratively and automatically customized over time to reflect the collective preferences of the users across the vehicles <NUM>.

As the vehicle <NUM> operates, the feedback application <NUM> generates new labeled dataset(s) <NUM> in real-time based on the vehicle states <NUM>, the user states <NUM>, the self-driving actions <NUM>, and the label set <NUM>. As described previously herein, each of the labeled datasets <NUM> includes, without limitation, one of the labels <NUM> that characterizes the users during an associated time period, the vehicle states <NUM> during the associated time period, and the self-driving actions <NUM> during the associated time period. Generating the labeled dataset <NUM> that includes, without limitation, the label <NUM> and any amount and/or type of data is also referred to herein as "labeling the data.

The feedback application <NUM> may generate the new labeled dataset(s) <NUM> in any technically feasible fashion. For instance, in at least one embodiment, the feedback application <NUM> includes, without limitation, label criteria <NUM>(<NUM>)-<NUM>(L), baseline criteria <NUM>(<NUM>)-<NUM>(L), a historical database <NUM>, a current label <NUM>, and the labeled datasets <NUM>(<NUM>)-<NUM>(N). For explanatory purposes only, the label criterion <NUM>(x) and the baseline criterion <NUM>(x) correspond to the label <NUM>(x), where x is an integer from <NUM> to L. In at least one alternate embodiment, the number of label criteria <NUM> and the number of baseline criteria <NUM> may differ from the number of labels <NUM> included in the label set <NUM>. In the same or other alternate embodiments, the feedback application <NUM> generates a single labeled dataset <NUM>.

The label criterion <NUM>(x) specifies, without limitation, any number of conditions, rules, etc., that the feedback application <NUM> evaluates based on a current user state <NUM> to determine whether the label <NUM>(x) is applicable to a surrounding time period. In a complimentary fashion, the baseline criterion <NUM>(x) specifies, without limitation, any number of conditions, rules, etc., that the feedback application <NUM> evaluates based on previous user states <NUM> and subsequent user states <NUM> to define the surrounding time period.

For instance, and as described in greater detail in conjunction with <FIG>, in at least one embodiment, each of the user states <NUM> includes, without limitation, a fear level and the label <NUM>(<NUM>) is equal to fearful. The label criterion <NUM>(<NUM>) specifies that when the current fear level is greater than an upper fear threshold, the label <NUM>(<NUM>) applies to a surrounding time period. The baseline criterion <NUM>(<NUM>) specifies that the surrounding time period is bounded by the closest previous time at which the fear level is less than a lower fear threshold and the closest subsequent time at which the fear level is less than a lower fear threshold.

The feedback application <NUM> may determine the label criteria <NUM> and the baseline criteria <NUM> in any technically feasible fashion. For example, and without limitation. the label criteria <NUM> and the baseline criteria <NUM> may be hard-coded, provided via an application programming interface, or provided via graphical user interface, In alternate embodiments, the feedback application <NUM> may generate any number of the label criterion <NUM> and/or any number of the baseline criteria <NUM> dynamically based on any amount and type of historical data (e.g., the historical database <NUM>). For example, the feedback application <NUM> may set the baseline criteria <NUM> for the label <NUM>(<NUM>) of fearful equal to a moving average of a fear level.

The feedback application <NUM> may evaluate the label criteria <NUM> and the baseline criteria <NUM> in any technically feasible fashion. For instance, in at least one embodiment, the feedback application <NUM> sets the current label <NUM> equal to an empty label to initiate a new evaluation interaction. While the current label <NUM> is equal to the empty label, the feedback application <NUM> receives and stores the user states <NUM>, the vehicle states <NUM>, and the self-driving actions <NUM> in the historical database <NUM> in real-time.

Whenever the user state <NUM> changes while the current label <NUM> is equal to the empty label, the feedback application <NUM> performs any number and type of evaluation operations based on the label criteria <NUM> and the new user state <NUM> to determine whether any of the labels <NUM> applies to a surrounding time period. If the feedback application <NUM> determines that the label criteria <NUM>(x) applies to a surrounding time period, then the feedback application <NUM> sets the current label <NUM> equal to the label <NUM>(x) and generates a new labeled dataset <NUM> that includes, without limitation, the current label <NUM>.

The feedback application <NUM> then performs any number and type of evaluation operations based on the baseline criterion <NUM>(x) and the previous user states <NUM> stored in the historical database <NUM> to determine a start time. For the portion of the historical database <NUM> that is associated with times that lie between the start time and the current time, inclusive, the feedback application <NUM> copies the vehicle states <NUM> and the self-driving actions <NUM> to the new labeled dataset <NUM>.

While the current label <NUM> is equal to one of the labels <NUM>(x), the self-driving application <NUM> receives and adds the vehicle states <NUM> and the self-driving actions <NUM> to the associated labeled dataset <NUM>. Whenever the user state <NUM> changes while the current label <NUM> is equal to the label <NUM>(x), the feedback application <NUM> performs any number and type of evaluation operations based on the baseline criterion <NUM>(x) and the user state <NUM> to determine whether the current label <NUM> is still applicable.

If the feedback application <NUM> determines that the current label <NUM> is no longer applicable, then the feedback application <NUM> adds the new labeled dataset <NUM> to the training database <NUM>. The feedback application <NUM> may add the new labeled dataset <NUM> to the training database <NUM> in any technically feasible fashion. The feedback application <NUM> then sets the current label <NUM> equal to the empty label to initiate a new evaluation iteration. The feedback application <NUM> continues to execute new evaluation iterations and therefore generate new labeled datasets <NUM> until the vehicle <NUM> ceases to operate or the feedback application <NUM> is terminated (e.g., via an exit command, etc.).

In alternate embodiments, the feedback application <NUM> may add each of the new labeled dataset(s) <NUM> to the training database <NUM> at any given time. For instance, in at least one alternate embodiment, the feedback application <NUM> stores the new labeled datasets <NUM> until the vehicle <NUM> ceases to operate or the feedback application <NUM> is terminated (e.g., via an exit command, etc.). The feedback application <NUM> then transmits the new labeled datasets <NUM> to the training database <NUM>.

As depicted with a dashed line, in at least one alternate embodiment, when the self-driving application <NUM> updates the current label <NUM>, the self-driving application <NUM> also transmits the current label <NUM> to the self-driving application <NUM>. In the same or other alternative embodiments, the current label <NUM> or data derived from the current label <NUM> is an input to the self-driving model <NUM>. In at least one alternate embodiment, the self-driving application <NUM> may perform any number and type of preprocessing operations and/or postprocessing operations based on the current label <NUM> and any amount and type of additional data.

Advantageously, taking into account the current label <NUM> when determining the self-driving actions <NUM> enables the self-driving application <NUM> to dynamically adapt the driving style based on the psychological states of the users. For example, if the user(s) enter the car while in relatively relaxed states, then the feedback application <NUM> could set the current label <NUM> to the label <NUM> of "relaxed. " In response, the self-driving model <NUM> could select self-driving actions <NUM> that reflect a relatively gentle driving style. In another example, if the user(s) enter the car while in relatively stressed states and an associated calendar indicates the user(s) are late for a dinner reservation, then the self-driving application <NUM> could select self-driving actions <NUM> that reflect a relatively aggressive driving style to reduce the time required to reach the restaurant.

In at least one alternate embodiment, before adding a new labeled dataset <NUM> to the training database <NUM>, the feedback application <NUM> may interact with at least one of the users in any technically feasible fashion in an attempt to confirm and/or improve an initial description specified via the current label <NUM>. For example, suppose that the labeled dataset <NUM> included, without limitation, the label <NUM>(<NUM>) of fearful based on the portion of the user state <NUM> associated with the user named Ava and the self-driving actions <NUM> associated with a right turn. In at least one alternate embodiment, the feedback application <NUM> could cause a speaker system included in the vehicle <NUM> to ask the question "Ava, should I take that right turn slower next time?" Based on the verbal response from Ava, the self-driving application <NUM> could update the label <NUM>(<NUM>) specifying the initial description to a more accurate label <NUM>, such as "exhilarated" specifying an improved description.

In the same or other alternate embodiments, the self-driving application <NUM> may add any amount and type of information to the training database <NUM> or a preference dataset (not shown) based on interactions with the users, For example, the self-driving application <NUM> could update a preference dataset to indicate that Ava would like the vehicle <NUM> to execute a specific right turn or right turns in general at a slower speed. The self-driving application <NUM> and/or the self-driving model <NUM> may take the preference dataset into account when determining the self-driving actions <NUM> in any technically feasible fashion.

It will be appreciated that the system shown herein is illustrative and that variations and modifications are possible. The connection topology, including the location and arrangement of the vehicle <NUM>, the compute instances <NUM>, the user monitoring subsystem <NUM>, the vehicle observation subsystem <NUM>, the feedback application <NUM>, the self-driving application <NUM>, the self-driving model <NUM>, and the self-driving modeling subsystem <NUM> may be modified as desired. In certain embodiments, at least one component shown in <FIG> may not be present. For instance, in some alternate embodiments, any amount of the functionality of the user monitoring subsystem <NUM> and/or the vehicle observation subsystem <NUM> may be subsumed into the feedback application <NUM>.

Note that the techniques described herein are illustrative rather than restrictive and may be altered without departing from the scope defined by the claims. In at least one embodiment, any number of the techniques disclosed herein may be implemented while other techniques may be omitted in any technically feasible fashion. Further, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments and techniques and the techniques described herein are modified accordingly. For instance, in at least one embodiment, the labeled datasets <NUM> may include any amount and type of data derived based, at least in part, on any amount and type of sensor data, any portion (including none) of the vehicle state <NUM>, any portion (including none) of the user state <NUM>, any number (including none) of the self-driving actions <NUM>, and/or any amount (including none) of additional data. In the same or other embodiments, each of the labeled datasets <NUM> may be associated with multiple labels <NUM> and/or overlap with any number (including none) of the other labeled datasets <NUM>.

<FIG> is an exemplary labeled dataset <NUM>(<NUM>) generated by the feedback application <NUM> of <FIG>, according to various embodiments. More precisely, <FIG> depicts an exemplary labeled dataset <NUM>(<NUM>) that the feedback application <NUM> generates during a driving scenario <NUM> in which the vehicle <NUM> moves into a blind spot of a truck <NUM>.

As depicted in the driving scenario <NUM>, the vehicle <NUM> is initially at a relative position <NUM>(<NUM>) that is behind the truck <NUM>. A relative motion <NUM>(<NUM>) that occurs when the vehicle <NUM> accelerates more rapidly than the truck <NUM> causes the vehicle <NUM> to enter a blind spot that is along the side of the truck <NUM>. Subsequently, a relative motion <NUM>(<NUM>) that occurs when the vehicle <NUM> again accelerates more rapidly than the truck <NUM> causes the vehicle <NUM> to move in front of the truck <NUM>.

For explanatory purposes only, the user state <NUM> includes, without limitation, a fear level <NUM>, the label <NUM>(<NUM>) is fearful, the label criterion <NUM>(<NUM>) is that the fear level <NUM> is greater than an upper fear threshold <NUM>, and the baseline criterion <NUM>(<NUM>) is that the fear level <NUM> is less than a lower fear threshold <NUM>. A fear graph <NUM> depicts the fear level <NUM> along a time axis <NUM> that spans the time period during which the vehicle <NUM> transmits from the relative position <NUM>(<NUM>) to the relative position <NUM>(<NUM>). The fear graph <NUM> also depicts the upper fear threshold <NUM> and the lower fear threshold <NUM>.

At an initial time that is denoted "T1," the current label <NUM> (not shown in <FIG>) is equal to the empty label, the vehicle <NUM> is in the relative position <NUM>(<NUM>), and the fear level <NUM> is below the lower fear threshold <NUM>. As described previously herein in conjunction with <FIG>, because the current label <NUM> is equal to the empty label, the feedback application <NUM> stores the user states <NUM>, the vehicle states <NUM> and the self-driving actions <NUM> in the historical database <NUM> until the fear level <NUM> is greater than the upper fear threshold <NUM>. As the relative motion <NUM>(<NUM>) moves the vehicle <NUM> into the relative position <NUM>(<NUM>) that lies in the blind spot of the truck <NUM>, the user(s) exhibit increasing physiological signs of fear and, consequently, the fear level <NUM> gradually increases. At a time that is denoted "T2," the fear level <NUM> increases past the lower fear threshold <NUM>, and at time that is denoted "T3," the fear level <NUM> increases past the upper fear threshold <NUM>.

When the fear level <NUM> increases past the upper fear threshold <NUM> at the time T3, the feedback application <NUM> sets the current label <NUM> equal to the label <NUM>(<NUM>) of fearful. The feedback application <NUM> also generates a new labeled dataset <NUM>(<NUM>) that initially includes, without limitation, the label <NUM>(<NUM>) of fearful, the vehicle states <NUM> for the time period from T2-T3 (inclusive), and the self-driving actions <NUM> for the time period from T2-T3 (inclusive).

As described previously herein in conjunction with <FIG>, because the current label <NUM> is equal to the label <NUM>(<NUM>), the feedback application <NUM> subsequently stores the vehicle states <NUM> and the self-driving actions <NUM> in the labeled dataset <NUM>(<NUM>) until the fear level <NUM> decreases past the lower fear threshold <NUM>. While the vehicle <NUM> is in the relative position <NUM>(<NUM>), the fear level <NUM> remains higher than the upper fear threshold <NUM>. As the relative motion <NUM>(<NUM>) moves the vehicle <NUM> out of the blind spot of the truck <NUM> and into the relative position <NUM>(<NUM>), the user(s) exhibit decreasing physiological signs of fear and, consequently, the fear level <NUM> gradually decreases. At a time that is denoted "T4," the fear level <NUM> decreases past the lower fear threshold <NUM>.

At the time T4, the feedback application <NUM> adds the final labeled dataset <NUM>(<NUM>) to the training database <NUM>. As shown, the final labeled dataset <NUM>(<NUM>) includes, without limitation, the label <NUM>(<NUM>) of fearful, the vehicle states <NUM> for the time period from T2-T4 (inclusive), and the self-driving actions <NUM> for the time period from T2-T4 (inclusive). The feedback application <NUM> then sets the current label <NUM> equal to the empty label. Advantageously, in at least one embodiment, when the training application <NUM> subsequently re-trains the self-driving model <NUM> based on the labeled dataset <NUM>(<NUM>), the self-driving model <NUM> learns to preferentially reduce the amount of time that the vehicle <NUM> spends in the proximity of blind spots of trucks.

<FIG> is a flow diagram of method steps for modifying a self-driving model based on data associated with at least one user, according to various embodiments. Although the method steps are described with reference to the systems of <FIG>, persons skilled in the art will understand that any system configured to implement the method steps, in any order, falls within the scope of the embodiments.

As shown, a method <NUM> begins at step <NUM>, where the self-driving application <NUM> acquires an up-to-date self-driving model <NUM> and waits for the vehicle <NUM> to start operating. At step <NUM>, the feedback application <NUM> receives and stores the user states <NUM>, the vehicle states <NUM>, and the self-driving actions <NUM> in the historical database <NUM> until one of the label criteria <NUM> is satisfied or the vehicle <NUM> stops operating.

At step <NUM>, the feedback application <NUM> determines whether the vehicle <NUM> is still operating. If, at step <NUM>, the feedback application <NUM> determines that the vehicle <NUM> is no longer operating, then the method <NUM> terminates. If, however, at step <NUM>, the feedback application <NUM> determines that the vehicle <NUM> is still operating, then the method <NUM> proceeds to step <NUM>.

At step <NUM>, the feedback application <NUM> sets the current label <NUM> equal to the label <NUM> associated with the satisfied label criterion <NUM>, generates a new labeled dataset <NUM> that includes, without limitation, the current label <NUM>, and determines a start time based on the historical database <NUM> and the baseline criterion <NUM> associated with the current label <NUM>. At step <NUM>, the feedback application <NUM> copies the vehicle states <NUM> and the self-driving actions <NUM> for the start time through the current time from the historical database <NUM> to the labeled dataset <NUM>.

At step <NUM>, the feedback application <NUM> receives and stores the vehicle states <NUM> and the self-driving actions <NUM> in the labeled dataset <NUM> until the baseline criterion <NUM> associated with the current label <NUM> is satisfied or the vehicle <NUM> stops operating. At step <NUM>, the feedback application <NUM> optionally interacts with the user(s) to improve the current label <NUM> and, if successful, the feedback application <NUM> updates the labeled dataset <NUM> to include the improved label instead of the current label <NUM>.

At step <NUM>, the feedback application <NUM> adds the labeled dataset <NUM> to the training database <NUM> that is eventually used to re-train the self-driving model <NUM> and sets the current label <NUM> equal to the empty label. At step <NUM>, the feedback application <NUM> determines whether the vehicle <NUM> is still operating. If, at step <NUM>, the feedback application <NUM> determines that the vehicle <NUM> is no longer operating, then the method <NUM> terminates. If, however, at step <NUM>, the feedback application <NUM> determines that the vehicle <NUM> is still operating, then the method <NUM> returns to step <NUM>, where the feedback application <NUM> continues to generate labeled datasets <NUM> based on the user states <NUM>, the vehicle states <NUM>, and the self-driving actions <NUM> until the vehicle <NUM> ceases to operate.

In sum, the disclosed techniques may be used to improve the performance of a self-driving model. In one embodiment, a vehicle observation subsystem, a user monitoring subsystem, a self-driving application, and a feedback application execute while a vehicle operates. The vehicle observation subsystem generates a vehicle state based on data received from vehicle sensors and outward-facing sensors. The user monitoring subsystem generates a user state based on data received from user sensors. The self-driving application generates inputs for a self-driving model based on the vehicle state and the user state and, in response, the self-driving model generates self-driving actions. The self-driving application configures the vehicle to implement the self-driving actions, thereby controlling how the vehicle operates.

The feedback application generates labeled data based on the user state, the vehicle state, the self-driving actions, and any number of labels. Each label corresponds to a psychological characterization of at least one user, such as "fearful," and is associated with training the self-driving model. For each label, the feedback application evaluates the user states to identify any time periods during which the label is applicable. For each identified time period, the feedback application generates a new labeled dataset that includes, without limitation, the applicable label, the vehicle states associated with the tine period, and the self-driving actions associated with the time period. The feedback application transmits the new labeled datasets to a training database that a training application subsequently uses to re-train the self-driving model.

At least one technical advantage of the disclosed techniques relative to the prior art is that the feedback application uses measured physiological data to enable the training application to efficiently re-train a self-driving model to account for the impact different driving actions have on users. In particular, because the feedback application can automatically augment the training database based on driving scenarios that have negative psychological impacts on users, re-training the self-driving model can modify the self-driving model to disfavor driving actions that are associated with the identified driving scenarios that are likely to have negative psychological impacts on users. Furthermore, because the training application can re-train the self-driving model based on different training databases, the training application can automatically generate a different, personalized self-driving model for each of any number of users or groups of users. In this fashion, the feedback application and the training application can increase overall trust in self-driving systems across a wide variety of users. These technical advantages provide at least one technological advancement over prior art approaches.

Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope defined by the claims.

Aspects of the present embodiments may be embodied as a system, method or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module," a "system," or a "computer. " In addition, any hardware and/or software technique, process, function, component, engine, module, or system described in the present disclosure may be implemented as a circuit or set of circuits. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in at least one computer readable medium having computer readable program code embodied thereon.

Any combination of at least one computer readable medium may be utilized. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having at least one wire, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises at least one executable instruction for implementing the specified logical function(s).

Claim 1:
A computer-implemented method for modifying a self-driving model (<NUM>) based on data associated with at least one user of a vehicle (<NUM>), the method comprising:
computing at least one value for a psychological metric based on first sensor data that is associated with a user of the vehicle (<NUM>) and is acquired while the self-driving model (<NUM>) operates the vehicle;
determining a description (<NUM>) of the user over a first time period based on the at least one value for the psychological metric, wherein determining the description (<NUM>) of the user comprises:
comparing the at least one value for the psychological metric with a first threshold for the description (<NUM>) to determine a first time (T3) where the at least one value of the psychological metric exceeds the first threshold;
comparing the at least one value for the psychological metric with a second threshold for the description (<NUM>) to determine a second time (T4) where the least one value for the psychological metric falls below the second threshold, wherein the second threshold is different from the first threshold; and
comparing the at least one value for the psychological metric with the second threshold for the description (<NUM>) to determine a third time (T2) at which the at least one value for the psychological metric exceeded the second threshold, wherein the third time (T2) precedes the first time (T3) and the second time (T4), and wherein said first time period is the time period between the third time (T2) and the second time (T4);
generating a first dataset based on the description (<NUM>), second sensor data that is associated with the vehicle and is acquired over the first time period, and a self-driving action (<NUM>) performed during the first time period;
adding the first dataset to a training database (<NUM>) to generate an updated training database; and
re-training the self-driving model (<NUM>) based on the updated training database to generate a modified self-driving model.