Driver profile analysis and recognition

Abstract

Embodiments of automatic driver identification are disclosed. In one example, an onboard computing system of a vehicle includes: a sensor interface communicatively coupled to one or more data collection devices; a processor; and a storage device storing instructions executable by the processor to: generate a two-dimensional current driver profile matrix for a current driver of the vehicle, the current driver profile matrix indicating vehicle operating states based on driving parameter pairs at sampling times during a current vehicle trip; and determine a probability that the current driver is one of a plurality of known drivers by comparing the current driver profile matrix to one or more stored driver profile matrices associated with the plurality of known drivers.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Russian Patent Application No. 2018114981, entitled “DRIVER PROFILING AND IDENTIFICATION”, filed on April 23, 2018. The entire contents of the above-listed applications are hereby incorporated by reference for all purposes. Technical Field

[0003] The present disclosure relates to identifying a driver in a vehicle based on monitored driving information. Background Art

[0004] User identification can be performed in a variety of situations to control access to a system or to personalize the user experience. For example, a user can log into a security system by entering user credentials (e.g., a username and password) or by performing a biometric scan (e.g., facial or retinal recognition, fingerprint scan, etc.). In each of these situations, the user is identified based on information that is directly entered and used only for identification purposes. Summary of the invention

[0005] In a vehicle environment, directly inputting user information to identify the vehicle driver may interfere with the driving experience and utilize valuable computing resources. Furthermore, decoupling the input of user identification information from the act of driving may result in a vulnerability in which the driver may be incorrectly identified for a particular vehicle trip (e.g., where a first user enters identification information prior to starting a trip, while a second user actually drives the vehicle during the trip).

[0006] The present disclosure provides a driver identification system that utilizes driving behavior information to infer the identity of the driver. An implementation scheme of an onboard computing system of a vehicle is disclosed. In one example, an onboard computing system includes: a sensor interface that is communicatively coupled to one or more data collection devices; a processor; and a storage device that stores instructions executable by the processor to perform the following operations: generate a two-dimensional current driver profile matrix of the current driver of the vehicle, the current driver profile matrix indicating the vehicle operating state according to driving parameter pairs at sampling times during the current vehicle trip; and determine the probability that the current driver is one of the multiple known drivers by comparing the current driver profile matrix with one or more stored driver profile matrices associated with multiple known drivers.

[0007] Also disclosed is an embodiment of a method for inferring the identity of a driver of a vehicle using a driver identification system. In one example, a method includes adjusting a vehicle parameter in response to automatic identification of a driver of a vehicle from a finite number of drivers, the automatic identification based on a probabilistic correlation of at least two driving parameters repeatedly sampled over time during a current vehicle trip with stored data associated with the finite number of drivers based on one or more prior drives.

[0008] An embodiment of a driver identification system for a vehicle is also disclosed. In one example, the driver identification system includes: a display; a sensor interface, the sensor interface being communicatively coupled to one or more data collection devices; a processor; and a storage device, the storage device storing instructions executable by the processor to receive driving data from the one or more data collection devices via the sensor interface, the driving data including an indication of a parameter of a vehicle operating state during vehicle travel, and generate a current driver profile matrix for a current driver of the vehicle, the current driver profile matrix using the driving data to map a value of a first parameter of the vehicle operating state to a value of a second parameter of the vehicle operating state. The instructions are also executable to compare the current driver profile matrix with one or more stored driver profile matrices, each of the one or more stored driver profile matrices being associated with a corresponding known driver; for each corresponding known driver, determining a probability that the current driver is the corresponding known driver; and outputting an indication of a driver identifier associated with a selected known driver via the display, wherein the probability that the current driver is the selected known driver is higher than the probability that the current driver is any other driver among the corresponding known drivers. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The present disclosure may be better understood by reading the following description of non-limiting embodiments with reference to the accompanying drawings, in which:

[0010] Figure 1 A block diagram illustrating an exemplary driver identification system according to one or more embodiments of the present disclosure is shown;

[0011] Figure 2 A flowchart illustrating an exemplary method for operating a driver identification system in a training phase according to one or more embodiments of the present disclosure is shown;

[0012] Figure 3 shows an exemplary visualization of a driver profile matrix according to one or more embodiments of the present disclosure;

[0013] Figure 4A flowchart illustrating an exemplary method for operating a driver identification system in an identification phase according to one or more embodiments of the present disclosure;

[0014] Figure 5 A flow chart illustrating an exemplary method of determining a probability calculation for identifying a current driver according to one or more embodiments of the present disclosure;

[0015] Fig. 6A and Figure 6B shows an exemplary screen of a user interface for a driver identification system according to one or more embodiments of the present disclosure;

[0016] Figure 7 shows an exemplary user interface for a driver identification system according to one or more embodiments of the present disclosure;

[0017] Figure 8 shows an exemplary partial view of a vehicle compartment according to one or more embodiments of the present disclosure; and

[0018] Fig. 9 A block diagram of an in-vehicle computing system is shown, according to one or more embodiments of the present disclosure. DETAILED DESCRIPTION

[0019] In both commercial and private environments, vehicles may be driven by multiple drivers. For example, drivers of a commercial transportation company or other business entity may be assigned to different vehicles based on vehicle availability, capabilities, and other parameters. Similarly, vehicles owned or otherwise used by a family unit or other household arrangement may be driven by multiple drivers (e.g., parents and school-age children). As yet another example, vehicles used for rental or car-sharing programs are driven by multiple drivers. For each multi-driver scenario, identifying the vehicle driver for a given driving trip may help provide responsibility for the trip, provide a targeted user experience during the trip, and / or otherwise increase statistics related to a given vehicle and / or driver.

[0020] In some systems, the driver can directly input a driver identifier (e.g., log in, provide voice, facial or other biometric input) or provide (e.g., through a radio frequency identifier chip or other detectable device) a mechanism that allows the vehicle to directly identify the driver before or during a trip. However, such driver identification mechanisms are time-consuming, easily forgotten, and / or manipulated to provide an inaccurate account of the driver during a specific trip (e.g., a user who is not the driver of a specific trip may provide an input of a biometric scan, thereby being incorrectly associated with the specific trip). Therefore, the present disclosure provides a mechanism for identifying the driver of the vehicle trip using driving behavior recorded during the vehicle trip. Relative to mechanisms using direct user input and / or data from numerous on-board sensors, the disclosed mechanism can utilize a reduced number / amount of sensors and computing resources. For example, as will be disclosed in more detail below, a driver profile associated with each of a plurality of drivers can be formed by one or more two-dimensional matrices having rows corresponding to values ​​of a first parameter and columns corresponding to values ​​of a second parameter, wherein the first parameter and the second parameter are related to vehicle operating parameters (e.g., vehicle speed, vehicle acceleration, throttle pedal position, engine RPM, etc.). Each cell of each matrix may include a counter that is incremented each time the vehicle is observed to operate with the first and second parameter values ​​associated with the cell (e.g., during a calibration / training / learning phase for a selected driver). Examples of matrices are described in more detail below.

[0021] During the identification phase, the observed vehicle operation can be compared with the matrix of the driver profile, so as to determine the probability that the profile of the current driver matches the driver associated with each driver profile. If the driving behavior of the current driver is calculated to have a probability of matching the selected driver profile higher than a threshold value and higher than the probability of matching any other driver profile, the current driver can be identified as the driver associated with the selected driver profile. In some examples, the indication of the name or other identifiers of the driver identified only by the system and / or the probability that the current driver matches the identified driver can be displayed to the user (for example, via an on-board display or a display connected to a back-end / network server storing information from a driver identification system). In other examples, additional information can be displayed to the user (for example, via an on-board display or a display connected to a back-end / network server storing information from a driver identification system), such as a graphical representation of the driver profile and the driving behavior of the current driver, to provide the use of the confirmation and / or monitoring related vehicles to identification. The matrix-based approach for driver identification described herein can improve the efficiency of a computing system performing identification by reducing the storage footprint of tracking information and reducing the search time to match vehicle behavior observed in the identification phase with vehicle behavior observed in the training phase (e.g., relative to other mechanisms that utilize inputs from different sensors and / or store raw observation data). For example, each driver profile can be approximately 100 kilobytes in size, which is smaller than raw sensor data (such as image sensor data) that can be used to directly identify a driver.

[0022] As described above, the driver identification disclosed herein may utilize fewer sensors than other systems that may rely on direct user input mechanisms (e.g., image sensors, touch screens, microphones, buttons or other user-actuable elements, etc.) or a large number of vehicle sensors. Figure 1As shown, the present disclosure provides a driver identification system 100 that can use only two data collection devices 102—an on-board diagnostic II (OBD-II) device 104 and one or more inertial measurement units (IMU) 106 (such as accelerometers and / or gyroscopes)—to perform driver identification of a driver of a vehicle. The OBD-II device 104 can be a stand-alone dongle (e.g., an ELM-327 dongle) that is coupled to the vehicle via a physical or wireless connection (e.g., a universal serial bus [USB], RS-232, Bluetooth, Wi-Fi, etc.) to provide an interface for receiving OBD data from the vehicle. In some examples, the OBD-II device can be implemented by an application executed on a mobile device (e.g., a smart phone, a tablet, or a laptop computer) that is connected to the vehicle via a physical or wireless connection. The OBD-II device can be coupled to a vehicle's onboard computing system 108, which can include or be included in the vehicle's head unit and / or telematics unit. In other examples, an OBD-II device may be included in the vehicle computing system 108, and / or the OBD data may be read by the vehicle's telematics unit or head unit. The OBD-II device may collect data including vehicle speed, engine RPM, accelerator pedal position, gear shift timing, etc.

[0023] The IMU 106 may include one or more micro-electromechanical systems (MEMS) accelerometers and / or MEMS gyroscopes. The IMU 106 may optionally be integrated with the OBD-II device 104, or may be a separate sensor independent of the OBD-II device. In some examples, the IMU 106 may be included in an onboard computing system and / or a telematics unit or head unit of the vehicle. One or more IMUs 106 may measure acceleration information, including forward acceleration, reverse acceleration, and lateral acceleration (acceleration in a direction perpendicular to the forward and reverse acceleration measurements, such as turning acceleration / motion).

[0024] The onboard computing system 108 includes a processor 109 and a memory 110. Although schematically shown as part of the processor 109, it should be understood that the various modules of the processor (e.g., modules 112-120 described below) may include instructions stored in the memory that are executable by the processor to perform associated actions. For example, the processor 109 may include a sampler 112 configured to receive data from the data collection device 102 and parse the received data into samples that are passed to the matrix updater 114. For example, OBD data may be collected from the OBD-II device 104 at a frequency of 2 Hz, and data from the IMU 106 may be collected at a frequency of 10 Hz.

[0025] The matrix updater 114 may be configured to increment a counter in one or more cells of one or more driver profile matrices (e.g., one or more matrices in the driver profile matrix 116) based on sampled data. For example, the sampled data may include values ​​of multiple vehicle parameters (such as speed and acceleration at a given time). In such examples, the matrix updater 114 may increment a counter in a cell corresponding to the sampled speed and acceleration values ​​in a speed / acceleration matrix associated with the current driver. For example, the row of a cell may be determined by a sampled value of a first parameter (e.g., speed), and the column of a cell may be determined by a sampled value of a second parameter (e.g., acceleration). In the training phase, the current driver may be a known driver, such as one of driver 1 to driver N (in the presence of N stored driver profiles). In the recognition phase, the current driver may be an unknown driver, whose matrix is ​​stored as the current driver profile matrix, and then compared with the stored driver profile matrices of driver 1 to N. The current driver profile matrix can be implemented as a buffer such that information is stored only until a given identification phase is completed (e.g., an identification phase trip ends due to a vehicle shutdown event or other triggering factor, and / or the current driver is identified by comparison with the stored profile matrices of drivers 1 to N) and / or until a new identification phase begins (e.g., due to a vehicle startup event or other triggering factor). In other examples, a predetermined number of current driver profile matrices can be stored such that the current driver profile matrix is ​​only overwritten when each of the predetermined number of current driver profile matrices has been used. In such examples, the matrices can be overwritten in a first-in, first-out manner (e.g., the current driver profile matrix with the oldest data stored therein is overwritten first).

[0026] Statistical modeling of driving behavior using multiple driver profile matrices reduces the memory size of the driver profile, reduces the search / update time for building the driver profile, and reduces the driver identification time (e.g., the time to compare the current driver profile with other stored driver profiles). The driver profile matrix can also be configured to characterize the driver by the driver's most common behavior (e.g., most common acceleration and deceleration, hard and soft turns, preferably accelerator pedal position, etc.). An exemplary representation of the matrix of speed versus acceleration of the driver profile is shown in Table 1 below:

[0027]

[0028] Table 1

[0029] It should be understood that Table 1 is truncated to show different parts of the exemplary matrix, and each matrix for each driver profile can be much larger. An exemplary matrix size can be 150 rows by 100 columns. For example, for a speed versus acceleration profile, the number of rows can be calculated based on the speed value and can vary in the range of 0 to 149 (from 0 to 149 km / h). The number of columns can be calculated based on the vehicle acceleration (or deceleration) and can vary in the range of 0 to 99, where the acceleration in column 0 is -5 m / s 2 And the acceleration of the 99th column is 5m / s 2 In some examples, the number of rows and columns may be selected based on the parameters modeled by the matrix and / or the range of data present in the matrix (e.g., the range of data received during a training phase). It should be understood that speed as used herein refers to vehicle speed unless otherwise indicated, and RPM as used herein refers to engine RPM unless otherwise indicated.

[0030] The values ​​in the cells of the example matrix may be counters representing multiple matches of the associated speed and acceleration (e.g., rounded up, rounded down, or rounded to the closest value pair represented in the matrix). In the exemplary scenario where the matrix of Table 1 is associated with a stored profile of driver 1, 1 km / h and -4.9 m / s 2 The value "245" in the corresponding cell indicates that driver 1 is monitored to be moving at -4.9 m / s 2 The speed of 1 km / h is decelerated 245 times and / or for 245 of the received data samples (eg, because the driver profile of driver 1 has been initialized). Each driver profile of each driver may have multiple matrices.

[0031] As described above, the driver profile matrix may include stored matrices for a plurality of drivers (e.g., derived during a training phase in which data regarding one or more vehicle trips in which the vehicle was driven by an associated driver is collected) and a current driver matrix (e.g., derived during an identification phase for the current driver). The driver identifier module 118 may be configured to compare the individual matrices for the current driver profile with the corresponding matrices for the driver profiles of drivers 1 to N to determine the likelihood that the current driver is a respective one of drivers 1 to N. Figure 4 and Figure 5 An exemplary driver identification method is described.

[0032] The user interface module 120 may be configured to control presentation of information regarding driver identification via the display 122 or other output device (e.g., vehicle speakers, a connected mobile device, etc.) that is integrated with and / or remote from and coupled to the onboard computing system 108. The user interface module 120 may generate and control presentation of a graphical representation of one or more of the driver profile matrices 116 and / or an indication of the likelihood that the current driver matches a driver associated with one or more of the driver profile matrices 116.

[0033] The user interface module 120 may also be configured to receive and process input from one or more user input devices 124 (e.g., a touch screen, an actuatable element such as a button or dial, a microphone for capturing voice commands, one or more cameras for detecting gestures or other vision-based inputs, etc.), which may be integrated with the onboard computing system 108 and / or remote from and coupled to the onboard computing system 108. The user interface module 120 may use the user input to control interaction with the presented information. For example, user input may be provided to the user interface module 120 to scroll through graphical representations of different driver profile matrices.

[0034] Figure 2 A method for operating a driver identification system (eg, Figure 1 Flowchart of an exemplary method 200 of a driver identification system 100). For example, as described above with respect to Figure 1As described with respect to the components of the present invention, method 200 may be performed by executing stored instructions with a processor using observed data collected by one or more sensors. At 202, the method includes determining whether a vehicle trip has begun. Determining whether a vehicle trip has begun may include detecting a vehicle start / ignition on event (e.g., activation of a vehicle and / or one or more components of a vehicle system such as an onboard computing system and / or a driver identification system), detecting that the vehicle has been started for a threshold period of time, detecting that the vehicle has moved or engaged an out-of-park gear (e.g., switched from a park gear to another drive gear) after the ignition on event, and / or another automatic detection. The start of a vehicle trip may additionally or alternatively be determined by detecting an input requesting the start of a vehicle trip (e.g., a user input to the onboard computing system requesting the start of a training phase).

[0035] The start trip determination at 202 may include determining whether a vehicle trip corresponding to a training phase (as opposed to a vehicle trip corresponding to a non-training phase, such as a vehicle trip corresponding to a driver identification phase) has begun. The determination that the vehicle trip corresponds to a training phase may be determined based on user input (e.g., requesting to start a training phase, or providing information indicating that the vehicle trip should be attributed to the training phase, such as a driver ID). In other examples, the vehicle trip may be determined to automatically correspond to the training phase unless conflicting input is received or determined (e.g., a request not to attribute the vehicle trip to the training phase, a request to attribute the vehicle trip to another phase (such as the identification phase), a lack of information for the training phase, such as a failure to receive a driver ID, etc.).

[0036] If the vehicle trip has not started (e.g., "No" at 202), the method returns to continue monitoring the start of the vehicle trip. If the vehicle trip starts (e.g., "Yes" at 202), the method includes receiving a driver ID, as shown at 204. For example, the vehicle driver can directly enter the driver ID, or the onboard computing system (e.g., upon detecting the driver's entry or the start of the vehicle trip) can automatically obtain the driver ID using any suitable input mechanism (e.g., a touch screen, a biometric scanner, a camera, a microphone, etc.), and the onboard computing system receives the driver ID from the user input mechanism. The driver ID can be a unique identifier, such as a string of one or more characters (e.g., letters, numbers, alphanumerics, symbols, and / or any combination thereof), one or more gestures, and / or one or more biometric markers (e.g., fingerprints, facial features, eye features, etc.). The driver ID can uniquely distinguish the driver from all other drivers of the associated vehicle, and / or can uniquely distinguish the driver from all other drivers of a centralized database of multiple vehicles (e.g., including the associated vehicle).

[0037] At 206, the method includes collecting data from one or more data collection devices (e.g., Figure 1 The received driving data may include engine speed (e.g., RPM), vehicle speed, and / or information from an OBD-II device (e.g., Figure 1 As shown at 210, the received driving data may additionally or alternatively include data from an accelerometer, gyroscope, or other inertial measurement unit (e.g., Figure 1 The acceleration data of the IMU 106) can be obtained as described above. Figure 1 The sampler module 112 samples the driving data, wherein each sample includes at least two values ​​of vehicle operating state with respect to at least two parameters (e.g., an indication of vehicle acceleration related to vehicle speed, wherein the vehicle is observed to have an indicated acceleration when traveling at the indicated speed).

[0038] At 212, the method includes constructing and / or updating one or more profiles of the driver associated with the driver ID (received at 204) based on the data received at 206. As shown at 214, the driver profiles each include a matrix mapping driving parameters. For example, the driver ID can be associated with a plurality of matrices (e.g., acceleration at different speeds, gear engaged at different speeds, etc.) that model driving parameter pairs. Figure 1 The driver profile matrix 116 including the driver 1 matrix, the driver N matrix, etc. is associated with the driver profile matrix 116. Figure 1 As discussed above with respect to the driver profile matrix 116 of FIG. 1 , each of the plurality of matrices for a driver ID may include a counter for each parameter pair modeled by the matrix. The counter for each given parameter pair is incremented in each of the following cases: the received driving data indicates that the vehicle is operating according to the given parameter pair. For example, a counter is positioned in a row associated with a speed of 1 km / h and in a row associated with an acceleration of 0.1 m / s 2 The cells in the associated column may be for a cell having an indication that when the vehicle is traveling at a speed of 1 km / h, the vehicle is traveling at a speed of 0.1 m / s 2Each sample of the accelerated driving data is incremented. If the sample of the driving data includes the value of the parameter pair that has not been modeled by the existing matrix of the associated (e.g., the driver ID associated with the driver received at 204), then a new matrix can be generated / constructed for the data pair. The matrix can have a predefined format (e.g., the value range of each parameter, the number of values ​​of each parameter, the interval / spacing between the values ​​of each parameter mapped in the matrix, etc.). In other examples, the matrix can be dynamically configured and / or reconfigured based on the received driving data (e.g., to fit the received driving data). For example, once the driving data for a predetermined amount of the parameter pair has been measured and received, a matrix can be generated for the parameter pair, including the value range of each parameter, the value range at least including the measured value and the buffer around the measured value. The buffer can be a first amount below the lowest measured value and a second amount above the highest measured value, wherein the first amount can be equal to or different from the second amount, and wherein each of the first amount and the second amount can be predetermined or based on the measured value, such as the non-zero percentage of the highest and lowest measured values.

[0039] Each driver profile of each driver may have multiple matrices. Examples of these matrices are hereinafter referred to as Ax, AccX, AccX2, AccY, RPM, Accelerometer, Ax1, Ax2, Gear, Ay, Ay1, Accel'Accel, and Accel'Accel(F). The Ax matrix may be constructed using parameters of instantaneous acceleration and speed. Acceleration may be calculated from OBD data (e.g., using speed and time), and speed may be received or calculated from OBD data. The Ax matrix for a given driver may characterize the typical acceleration and deceleration of a given driver in various speed zones.

[0040] The AccX matrix can be constructed from parameters such as acceleration (forward and reverse acceleration) collected from an accelerometer and / or gyroscope and velocity collected from OBD data. The AccX2 matrix can also be constructed from parameters such as acceleration (collected from an accelerometer and / or gyroscope) and velocity (collected from OBD data). However, the AccX2 matrix can only be constructed for velocity values ​​greater than a threshold value (such as 0.5 m / s 2 ) and other accelerations may be filtered out so that they are not represented by the matrix. The AccY matrix may be similar to the AccX matrix and may map lateral acceleration (e.g., in a direction perpendicular to the forward / reverse acceleration used in the AccX matrix) to velocity. The lateral acceleration data of the AccY matrix may be collected by an accelerometer and / or gyroscope, while the velocity data of the AccY matrix may be collected from OBD data. The AccY matrix may characterize the intensity of cornering at various speed regions.

[0041] The RPM matrix can be constructed from the RPM and vehicle speed parameters using the RPM and speed data collected from the OBD data. The throttle matrix can be constructed using the throttle pedal position data and the vehicle speed data (both collected from the OBD data) as parameters. The Ax1 matrix can use the same parameters as the Ax matrix (e.g., instantaneous acceleration and speed, both collected and / or calculated from the OBD data), and can only count instances of acceleration when the speed has changed from the immediately preceding sample. For example, if at the first sampling time, the vehicle is traveling at 5km / h and the instantaneous acceleration is 0m / s 2 , and at the second sampling time, the vehicle is still traveling at 5km / h, then the difference between 5km / h and 0m / s 2 The cells of the Ax1 matrix associated with the value will be incremented only for the first sampling time and will not be incremented at the second sampling time. 2 The cells of the Ax matrix associated with the value will instead be incremented for both the first and second sampling times. It will be appreciated that the Ax1 matrix or another matrix can provide the same approach (incrementing the counter only if the velocity has changed relative to the immediately preceding sample) using acceleration information collected from an accelerometer.

[0042] The Ax2 matrix can use the same parameters as the Ax matrix (e.g., instantaneous acceleration and velocity, both collected and calculated from OBD data), and only count the average value of acceleration for each acceleration or deceleration interval. For example, an acceleration interval can be defined as the average value from 0 m / s 2 The acceleration starts at 0 m / s 2 The positive acceleration period at the end of acceleration (no deceleration / negative acceleration in between). The deceleration interval can be defined as the period from 0m / s 2 The acceleration starts at 0 m / s 2 A negative acceleration period at the end of an acceleration period (with no positive acceleration in between). In each case, the acceleration value tracked in the Ax2 matrix may correspond to the average (positive or negative, depending on whether the interval is an acceleration or deceleration interval) of the non-zero acceleration values ​​measured between the start and end 0 m / s acceleration.

[0043] The gear matrix can be constructed using engine RPM divided by vehicle speed to calculate the current gear as one parameter and the vehicle speed as another parameter. OBD data can be used to collect RPM and speed. Gear identification can be performed using monitored RPM and speed information and stored / predetermined data such as tire diameter, axle gear ratio, and vehicle's gear ratio to gear mapping. In some examples, the vehicle's controller can determine the gear using the above data and provide the information to the OBD-II device and / or directly to the on-board computing system for constructing the gear matrix during the vehicle trip. In other examples, the on-board computing system can receive an indication of the current gear directly from the engine controller via the CAN bus or other vehicle data source at one or more sampling times.

[0044] The Ay matrix may be constructed using lateral (e.g., sideways) acceleration as one parameter and velocity as another parameter. The lateral acceleration may be calculated from data collected by an accelerometer and / or gyroscope, and the velocity may be collected from OBD data. The Ay1 matrix may be constructed using the same parameters as the Ay matrix, and may not include low lateral accelerations (e.g., lateral accelerations below a threshold), and may filter out other lateral accelerations so that they are not represented by the matrix. In some examples, the threshold of the Ay1 matrix may be the same as the threshold of the AccX2 matrix (e.g., 0.5 m / s 2 ) are the same. In other examples, the threshold of the Ay1 matrix may be different from (eg, lower or higher than) the threshold of the AccX2 matrix.

[0045] The Accel'Accel matrix can be constructed using the accelerator pedal position as one parameter and the first-order derivative of the accelerator pedal position as another parameter, each of which can be collected by OBD data and / or calculated based on OBD data. The Accel'Accel matrix can describe the preferred accelerator position and the related usage intensity of the corresponding driver. The Accel'Accel (F) matrix can be constructed using the same parameters as the Accel'Accel matrix, where the first-order derivative is relaxed by a one-second window. For example, the first-order derivative of the accelerator pedal position can be taken over a one-second window to smooth the data. The first-order derivative can be relaxed by a one-second window to better find the accelerator pedal position, where the derivative is close to zero for a one-second interval, where the accelerator pedal position does not change significantly within one second.

[0046] The above matrices are examples of matrices that may be included in any given driver profile. In some examples, each driver profile of each driver associated with the vehicle may include matrices of the same number and / or type (e.g., all of the above matrices). In other examples, the driver profile may have different matrices, depending on the type of driver or the availability of data. It should be understood that some modifications of the above-mentioned profile modifications (e.g., using the average value of a parameter, using only parameter values ​​above a threshold, etc.) may be applied to other matrices to derive additional matrices. For example, a modified gear matrix may be included in one or more driver profiles, the gear matrix of this modification being constructed using gear to speed data, and may only include data for gears below a threshold gear. In such examples, multiple matrices of the profile may use data related to the same parameter or parameter type; however, different subsets of the data for a given parameter may be used in different matrices in a plurality of matrices.

[0047] Returning to method 200, at 216, the method includes determining whether the vehicle trip has ended. In response to detecting a vehicle shutdown / ignition off, a shift to a park gear (e.g., from another driving gear), a user input to end the vehicle trip, and / or any other suitable triggering factor, it can be determined that the vehicle trip has ended. In some examples, it can be determined that the vehicle trip has ended when a threshold amount of driving data has been received (e.g., a threshold number of counts for one or more matrices in the matrix of the driver profile have been recorded). If the trip has not yet ended (e.g., "No" at 216), the method returns to 206 to continue receiving driving data from one or more data collection devices. In this way, the method can continuously monitor driving behavior and update the driver profile in real time or near real time (e.g., updates can be performed for each driving data sample or a threshold number of driving data samples at a time). If it is determined that the trip has ended (e.g., "yes" at 216), the method includes determining that the data received for the driver ID (e.g., the driver ID received at 204, and the driving data received in all completed training phase trips for that driver ID) is less than a threshold, as shown at 218. The threshold at 218 can be a single threshold for the driver profile, or multiple thresholds, each associated with a different matrix of the driver profile (such that the trip is determined to be ended if at least one of the thresholds is met, or, in an alternative example, the trip is determined to be ended only if all thresholds are met). The threshold can include a threshold amount of values ​​in each matrix (e.g., the total number of counts in each cell of the matrix) and / or a threshold amount of received data samples.

[0048] If the data received for the driver ID is not less than the threshold (e.g., greater than or equal to the threshold, "No" at 218), the method optionally includes setting a fill indicator for the driver profile associated with the driver ID at 220. The indicator can be used to indicate that the driver profile associated with the driver ID has sufficient data for comparison to identify the unidentified driver in a subsequent vehicle trip. The method can also optionally include outputting a visualization of the driver profile (e.g., one or more matrices of the driver profile), as shown at 222.

[0049] exist Figure 3 An exemplary graphical visualization 300 of a speed versus acceleration matrix for a driver profile is shown in . The graphical visualization 300 shows multiple instances during one or more vehicle trips at which each associated speed and acceleration value pair is observed (e.g., multiple samples that result in an associated counter being incremented). In the example shown, common speed / acceleration values ​​for the associated driver fall into two regions. Figure 3 The most common speed / acceleration pairing, represented by peak 302 in the example of , occurs at substantially lower speeds and moderate accelerations (e.g., positive acceleration from a stop). Visualization of the driver profile, e.g. Figure 3 The visualizations shown in may be stored on a backend server and / or as part of a web application to be used (e.g., viewed on a suitable display) by an administrator or vehicle / fleet owner to monitor vehicle usage.

[0050] return Figure 2 , if the data received for the driver ID is less than a threshold value (e.g., "yes" at 218), the method may optionally set an incomplete indicator for the driver profile associated with the driver ID, as shown at 224, and then return to wait for the next vehicle trip. In some examples, an indication of the level of completion of the driver profile and / or one or more matrices of the driver profile may be presented to the user. An indication of the amount of driving data that will complete the driver profile (e.g., cause the received driver profile data to be above a threshold value), which may be represented by driving distance, may be presented to the user to help the user complete the training phase of the driver profile.

[0051] Now go to Figure 4 , showing a method for operating a driver identification system (e.g., Figure 1 An exemplary method 400 for inferring a driver's identity (e.g., by automatically identifying a driver from a limited number of drivers) using a driver identification system 100 of the present invention. For example, the method 400 may be performed by executing stored instructions with a processor using observation data collected by one or more sensors, as described above with respect to Figure 1The driver identification performed via method 400 may identify the driver using observed driving behavior monitored during and throughout the vehicle trip without using a direct driver identification mechanism (e.g., without using a camera / imaging sensor, without using a biometric scanner, without using direct user input of a driver identifier). The driver identification of method 400 (which may include also relating to the following) Figure 5 The process described in method 500 of ) may include performing automatic identification of a driver of the vehicle from a limited number of (e.g., known) drivers. The automatic identification may be based on a probabilistic correlation of at least two driving parameters repeatedly sampled over time during a current vehicle trip and stored data associated with the limited number of drivers based on one or more previous drivings (e.g., one or more previous vehicle trips of the vehicle and / or one or more previous vehicle trips of another vehicle driven by one or more of the limited number of drivers). For example, the stored data may include a probability correlation in response to a Figure 2 Data stored in response to execution of method 200. In some examples, vehicle parameters may be adjusted in response to automatic identification.

[0052] At 402, the method includes determining whether a vehicle trip of the vehicle has started. The determination of the start of the trip may include detecting the above-mentioned Figure 2 The conditions discussed in the determination at 202 of . The determination at 402 may utilize the mechanisms described above (e.g., detecting the start of the vehicle, user input indicating the start of a trip, etc.) to determine whether the vehicle trip will be used as the identification phase of the driver identification method. For example, if a trip begins and no indication of a driver ID is provided to the driver identification system, the trip may be attributed to the identification phase. If the trip is not determined to be started (e.g., "No" at 402, which may include determining a trip that is not attributed to the identification phase, such as a trip that is attributed to a training phase or a trip for which a user has provided input to reject driver identification), the method returns to continue monitoring the start of the vehicle trip for the driver identification phase.

[0053] If the trip is determined to be initiated (e.g., "yes" at 402), the method includes receiving driving data from one or more data collection devices, as shown at 404. The data may include RPM, vehicle speed, and throttle pedal data from an OBD-II device, as shown at 406, and / or acceleration data from an accelerometer and / or gyroscope, as shown at 408. At 410, the method includes constructing / updating one or more trip profile matrices using the received data (e.g., the data received at 404). Figure 4 The data receiving and matrix building elements of method 400 may be similar to Figure 2 The relevant elements of method 200. Therefore, it should be understood that Figure 2 The above description of elements 206-214 of method 200 also applies to Figure 4 Elements 404-410 of method 400. In the case of method 400, the trip profile matrix constructed at 410 may be attributed to an anonymous current driver profile, rather than a profile associated with a specific known driver ID.

[0054] At 412, the method optionally includes determining whether the vehicle trip started at 402 has ended. The determination of whether the vehicle trip has ended is optional, as the method may instead continuously compare the received data (or compare a threshold amount of received data at a time) to generate a real-time report of the driver identification, which may become more accurate as more data is received. If the determination at 412 is performed, the method may return to 404 to continue receiving driving data if the trip has not ended (e.g., "No" at 412).

[0055] If the determination at 412 is not performed, or if the determination at 412 is performed and the trip is determined to be completed (e.g., "yes" at 412), the method includes comparing the received data (e.g., the driving data received at 404, as included in the profile matrix at 410) to each driver profile associated with the vehicle, as shown at 414. In one example, the comparison of a selected pair of associated profile matrices can include determining differences between corresponding cells of the profile matrix of the current driver and the associated profile matrices of known drivers, and averaging or otherwise aggregating the differences. Figure 5 Additional or alternative examples of comparisons are described. At 416, the method includes determining a probability of matching each driver profile matrix for each driver ID based on the data comparison performed at 414. At 418, the method includes aggregating the determined match probabilities for each driver profile matrix (e.g., for a given driver ID) to determine an overall match probability for each driver associated with the driver ID associated with the vehicle.

[0056] Temporary turn Figure 5, an exemplary method 500 for performing the above-mentioned probability determination at 414-418 is shown. At 502, the method includes converting each driver profile matrix for each driver ID into a corresponding probability matrix. The probability matrix can be calculated because the amount of data collected during the training phase and the amount of data collected during the identification phase may be different. For example, the amount of data collected during the training phase may be greater than the amount of data collected during the identification phase of an unknown driver, so a given known driver profile matrix may be greater than a given unknown (e.g., current) driver profile matrix. The probability matrix can be calculated to normalize and smooth the collected data. In addition, the probability matrix can make it possible to compare specific parts of the matrix, such as when the unknown driver profile matrix has a data distribution close to the associated known driver profile matrix.

[0057] As indicated at 504, the conversion may include, for each driver profile matrix associated with the driver ID, dividing each cell of the profile matrix by the maximum value of the cells in the same row within the left [X] cells and the right [Y] cells, where X and Y are non-zero integers. The values ​​of X and Y may be the same or different, and may be based on the characteristics of the corresponding matrices (e.g., the number of rows, the number of columns, and / or the cells of the matrix, the spacing between the cell values ​​of the matrix, etc.). In one example, both X and Y may be equal to 10. In this example, the function for determining a given cell value of the probability matrix (P) may be expressed as:

[0058]

[0059] Where i represents the row of the relevant cell, j represents the column of the relevant cell and C represents a matrix, in this example a selected stored driver profile matrix (e.g., a stored driver profile matrix for selected known drivers that maps the same two parameters as the probability matrix). The above calculations can be performed to compare each matrix of the current trip profile with the associated P of the stored driver profile for each known driver. In some examples, a rough calculation of the probability for each driver can be used to reduce or eliminate more complex processing (e.g., calculation of one or more of the functions described herein) of driver profile matrices that are determined to have a probability below a threshold (e.g., 10%) based on the rough calculation.

[0060] To compare the current trip profile matrix with the corresponding matrix collected during the training phase for a given driver ID (e.g., a matrix associated with the same parameters), each cell of the current trip matrix can be multiplied by the probability matrix (C ) from each known driver profile. i，j *P i，j), as shown at 506. To calculate the probability that the current trip driver is the same driver with the profile matrix at 508, the method may include summing the multiplied elements (∑C i，j *P i，j ) divided by the sum of all cells from the current trip matrix (∑C i，j ), as shown at 510. The following function may be used to determine the probability that the driver of the current trip is the same as the driver of the previous recorded trip based on a matrix P associated with known drivers of the previous recorded trip and a matrix C associated with the driver of the current trip, where P and C in the function are matrices with the same parameters (e.g., speed versus acceleration, speed versus gear, etc.):

[0061]

[0062] As shown at 512, the probability calculated for each matrix of a given driver profile can be aggregated to determine the overall / aggregate probability of a given driver profile, which indicates the probability that the current trip driver is a driver associated with a given driver profile. In some examples, aggregation can be performed by averaging the probability of each matrix of a given driver profile. In such examples, averaging can be weighted so that one or more matrices in the average calculation have a greater impact (e.g., are more heavily weighted) than other matrices. Weighting can be predetermined, or can be dynamically determined based on the measured data of a group of drivers associated with the subject vehicle. For example, if it is determined that one or more matrices of the stored driver profile of the subject vehicle have the largest deviation relative to each other (e.g., if one or more matrices are used to more easily identify the driver), aggregation can include one or more matrices that are higher than other matrices of the driver profile to be weighted. In some examples, weighting can be adjusted based on operating conditions (e.g., environmental conditions of the vehicle, current traffic conditions, road conditions, trip length, etc.) and / or based on user input of the weight of specifying one or more matrices.

[0063] The current trip driver may be determined to be the driver associated with the driver profile having the highest aggregation probability. In some examples, the current trip driver may be determined to be the driver associated with the driver profile having the highest aggregation probability only when the highest aggregation probability exceeds a threshold (e.g., 50%). If the highest aggregation probability is below the threshold, the system may present an indication of the highest aggregation probability and a notification requesting more driving data to improve recognition accuracy.

[0064] return Figure 4, method 400 includes outputting an indicator of the overall or aggregated probability of matching with each driver, as shown at 420. Outputting the indicator may be an example of adjusting a vehicle parameter in response to automatic identification of a driver (e.g., identification performed via method 400). Examples of such outputs are shown in Fig. 6A , Figure 6B and Figure 7 Available in. Fig. 6A An exemplary user interface 600a is shown for a first driver profile matrix (eg, an Ax matrix, plotting speed versus instantaneous acceleration), which may be displayed via an in-vehicle display (eg, Figure 1 The display 122 of the vehicle and / or the display (e.g., the display of the mobile device) that is communicatively connected to the vehicle are displayed. The user interface 600a shows a graphical representation of the associated driver profile matrix (e.g., Ax matrix) of the current driver at 602a, a graphical representation of the associated driver profile matrix of the first stored driver (e.g., driver A) at 604a, and a graphical representation of the associated driver profile matrix of the second stored driver (e.g., driver B) at 606a. As shown, in contrast to the probability indicator of driver A shown at 610a, the current driver profile matrix most closely matches the profile matrix of driver B, which is reflected in the associated probability indicator of the driver, as shown at 608a. The probability indicator for each stored driver can display the probability associated with the currently displayed matrix (e.g., the probability of driver B is 0.62 or 62%, and the probability of driver A is 0.42 or 42%), as well as the overall or aggregated probability associated with the driver based on all matrices (e.g., driver B is 0.61 or 61%, and driver A is 0.27 or 27%). The user interface can also indicate the driving distance over which driving data has been collected for each driver (e.g., the current driver, driver A, and driver B).

[0065] There may be actuatable user interface elements in user interface 600a, such as interactive buttons for resetting the current trip as shown at 612a, adding data from the current trip to the relevant profile of driver A as shown at 614a, resetting (e.g., deleting acquired driving data / deleting matrix) driver A profile as shown at 616a, adding data from the current trip to the relevant profile of driver B as shown at 618a, and resetting driver B profile as shown at 620a. The actuatable elements of user interface 600a may be activated by user input to the touch screen, user input to scroll through selectable elements, and / or other suitable user input (e.g., using the above description of the driver A profile). Figure 1 The selection may be made using one or more of the user input mechanisms described for user input device 124 .

[0066] The user interface may also include navigation elements, such as navigation indicators 622a and 624a, which may be used to cycle through different user interface screens. For example, by selecting one of indicators 622a and 624a, a user may control the user interface to display comparison / probability outputs of different matrices. Figure 6B An exemplary user interface 600b is shown that may be displayed in response to selecting one of the indicators 622a and 624a. For example, the user interface 600b is shown as a gear matrix output showing a graphical representation of the speed versus gear matrix of the current driver at 602b, a graphical representation of the speed versus gear matrix of driver A at 604b, and a graphical representation of the speed versus gear matrix of driver B at 606b. The user interface 600b may include an actuatable element, a distance indicator, and a probability indicator, similar to the one shown with respect to FIG. Fig. 6A Those discussed in the user interface 600a of (e.g., elements 608a-624a). In some examples, interactive elements can be provided via an onboard display and / or an onboard dashboard or other user input device to allow a vehicle occupant to view information from the driver identification system. In other examples, only an indication of a driver identification determined to match the current driver and / or the probability of the match can be provided to the vehicle occupant. In such examples, other data generated by the driver identification system (e.g., as presented by exemplary user interfaces 600a and 600b) can be stored on a backend server and / or stored in association with an Internet-based application to be used (e.g., viewed and interacted with) by an administrator and / or vehicle / fleet owner to monitor the use of the vehicle (e.g., determine which driver was identified at a given date / time).

[0067] Figure 7 An example of a user interface 700 showing an Ax2 profile showing a graphical representation of a matrix of speed versus acceleration (using the average acceleration value for each acceleration or deceleration interval) for a current driver (702), a first stored driver A (704), and a second stored driver B (706). The user interface 700 may include actuatable elements, distance indicators, and probability indicators similar to those for Fig. 6A In the exemplary user interface 700, the probability indicator shows only one probability, which may be the probability that the current driver and the driver associated with the corresponding Ax2 profile match using only the Ax2 profile data of the current driver and the stored driver. Fig. 6A , Figure 6B and Figure 7The user interface in shows only two drivers for comparison with the current driver, but it should be understood that any number of stored drivers may be shown (e.g., visible on a single visible screen of the user interface, or visible by performing a scrolling or screen pan input to view additional driver profile matrix representations).

[0068] return Figure 4 , method 400 optionally includes controlling one or more vehicle systems according to settings for the driver with the highest overall or aggregate probability of matching the current driver, as shown at 422. Controlling one or more vehicle systems at 422 is another example of adjusting vehicle parameters in response to automatic identification of the vehicle driver. For example, user preferences for vehicle systems (e.g., climate control, entertainment / radio system settings, vehicle performance settings, seat position settings, etc.) can be defined based on the probability determination of matching the identified driver. Driver identification can be stored with driving data for vehicle trips to provide a history of trips (e.g., for fleet management or other purposes to identify who is driving the vehicle at a particular time / place, to identify whether an unexpected driver is driving the vehicle, etc.), driver scores (e.g., acceleration accuracy, brake use, turning accuracy, fuel efficiency, etc.), and / or other information. In some examples, driver identification can be triggered in response to detecting an accident to identify the responsible driver.

[0069] Method 400 may optionally include updating the driver profile of the driver with the highest total probability or aggregate probability of matching the current driver, as shown at 424. For example, the driving data of the current driver may be added to a matrix associated with the driver with the highest overall probability of matching the current driver (e.g., the driver identified as matching the current driver) to continuously update the driver matrix. In this way, the recognition phase of driver recognition may also be used to train a driver recognition system.

[0070] The above-described mechanism for identifying the driver of a vehicle trip uses driving behavior recorded during the vehicle trip, rather than direct user input or camera imaging mechanisms. In addition, the disclosed driver identification system and method can utilize only on-board diagnostic data and inertial measurement unit data to generate a two-dimensional matrix that occupies very little storage space (e.g., even a smaller storage space size than the storage space available for a single image file) and is efficiently processed. Therefore, relative to mechanisms that use direct user input and / or data from numerous on-board sensors, the disclosed mechanism can have the technical effect of utilizing a reduced number / amount of sensors and computing resources. In addition, relative to systems that transmit raw data (such as raw imaging data for off-board processing of the vehicle to directly identify the driver via image analysis), when transmitting data (such as an indication of the driver identified for a given trip), the data transmission can have a reduced size (thereby using less network bandwidth and being less susceptible to destructive data loss).

[0071] As described above, the disclosed method may be performed at least in part within a vehicle using an onboard computing system for driver identification. Figure 8 An exemplary partial view of one type of environment for a driver identification system is shown: the interior of a cabin 800 of a vehicle 802 in which a driver and / or one or more passengers may be seated.

[0072] As shown, dashboard 806 may include various displays and controls accessible to a driver (also referred to as a user) of vehicle 802. For example, dashboard 806 may include a touch screen 808 for an onboard computing system 809 (e.g., an infotainment system), an audio system control panel, and an instrument cluster 810. Figure 8The exemplary system shown includes audio system controls that may be implemented via a user interface of an onboard computing system 809 (such as a touch screen 808 without a separate audio system control panel), although in other embodiments the vehicle may include an audio system control panel that may include controls for a conventional vehicle audio system (such as a radio, a compact disc player, an MP3 player, etc.). The audio system controls may include features for controlling one or more aspects of the audio output via speakers 812 of the vehicle's speaker system. For example, the onboard computing system or audio system controls may control the volume of the audio output, the distribution of sound between the various speakers of the vehicle's speaker system, the equalization of the audio signal, and / or any other aspect of the audio output (e.g., providing directional alerts, as described above). In other examples, the onboard computing system 809 may adjust radio station selections (e.g., from a radio or CD or MP3), playlist selections, audio input sources, etc. based on user input received directly via the touch screen 808. One or more elements of the dashboard may be used as Figure 1 A user input device 124 or Figure 1 The display 122 may be used to display and / or otherwise interact with the driver identification system described herein.

[0073] In some embodiments, one or more hardware elements of the onboard computing system 809, such as the touch screen 808, the display screen, the various control dials, knobs and buttons, the memory, one or more processors, and any interface elements (e.g., connectors or ports), may form an integrated head unit that is installed in the vehicle's dashboard 806. The head unit may be fixedly or removably attached in the dashboard 806. In additional or alternative embodiments, one or more hardware elements of the onboard computing system may be modular and may be installed in multiple locations in the vehicle.

[0074] The cabin 800 may include one or more sensors for monitoring the vehicle, the user, and / or the environment. For example, the cabin 800 may include one or more microphones to receive user input in the form of voice commands and / or to measure ambient noise in the cabin 800 or outside the vehicle. It should be understood that the above-mentioned sensors and / or one or more additional or alternative sensors may be located in any suitable position of the vehicle. For example, the sensor may be located in the engine compartment, on the outer surface of the vehicle, and / or other suitable locations to provide information about the operation of the vehicle, the environmental conditions of the vehicle, the user of the vehicle, etc. Information about the environmental conditions of the vehicle, the vehicle state, or the driver of the vehicle may also be received from sensors (such as sensors coupled to the external device 850 and / or the mobile device 828) outside the vehicle / separated from the vehicle (i.e., not part of the vehicle system). For example, the data collection device 102 may include the above-mentioned sensors and / or communicate with one or more of the above-mentioned sensors.

[0075] The vehicle compartment 800 may also include one or more user objects stored in the vehicle before, during, and / or after driving, such as a mobile device 828. The mobile device 828 may include a smart phone, an onboard diagnostic device (e.g., an OBD-II dongle), a tablet, a laptop, a portable media player, and / or any suitable mobile computing device. The mobile device 828 may be connected to the onboard computing system via a communication link 830. The communication link 830 may be wired (e.g., via a universal serial bus [USB], a mobile high-definition link [MHL], a high-definition multimedia interface [HDMI], Ethernet, etc.) or wireless (e.g., via Bluetooth, WIFI, WIFI direct, near field communication [NFC], cellular connection, etc.), and is configured to provide two-way communication between the mobile device and the onboard computing system. The mobile device 828 may include one or more wireless communication interfaces for connecting to one or more communication links (e.g., one or more of the exemplary communication links described above). The wireless communication interface may include one or more physical devices, such as one or more antennas or one or more ports coupled to a data line to carry the transmitted or received data, and one or more modules / drivers for operating the physical device according to other devices in the mobile device. For example, the communication link 830 may provide sensor signals and / or control signals from various vehicle systems (such as the vehicle audio system, sensor subsystems, etc.) and the touch screen 808 to the mobile device 828, and may provide control signals and / or display signals from the mobile device 828 to the onboard systems and touch screen 808. The communication link 830 may also provide power to the mobile device 828 from an onboard power source to charge an internal battery of the mobile device.

[0076] The onboard computing system 809 may also be communicatively coupled to additional devices that are operated and / or accessed by a user but are located outside the vehicle 802, such as one or more external devices 850. In the depicted embodiment, although the external devices are located outside the vehicle 802, it should be understood that in alternative embodiments, the external devices may be located inside the vehicle compartment 800. The external devices may include server computing systems, personal computing systems, portable electronic devices, electronic wristbands, electronic headbands, portable music players, electronic activity tracking devices, pedometers, smart watches, GPS systems, etc. The external devices 850 may be connected to the onboard computing system via a communication link 836 (which may be wired or wireless, as discussed with reference to the communication link 830), and are configured to provide two-way communication between the external devices and the onboard computing system. For example, the external device 850 may include one or more sensors, and the communication link 836 may transmit the sensor output from the external device 850 to the onboard computing system 809 and the touch screen 808. The external device 850 may also store and / or receive information regarding navigation map data, image feature mapping data, etc., and may transmit such information from the external device 850 to the onboard computing system 809 and / or the touch screen 808 .

[0077] The onboard computing system 809 can analyze input received from the external device 850, the mobile device 828, and / or other input sources, and provide output via the touch screen 808 and / or the speaker 812, communicate with the mobile device 828 and / or the external device 850, and / or perform other actions based on the assessment. In some embodiments, all or part of the assessment results can be performed by the mobile device 828 and / or the external device 850. In some embodiments, the external device 850 can include an onboard computing device of another vehicle.

[0078] In some embodiments, one or more of the external devices 850 may be indirectly communicatively coupled to the onboard computing system 809 via the mobile device 828 and / or another of the external devices 850. For example, the communication link 836 may communicatively couple the external device 850 to the mobile device 828 such that output from the external device 850 is relayed to the mobile device 828. Data received from the external device 850 may then be aggregated with data collected by the mobile device 828 at the mobile device 828, and the aggregated data then transmitted to the onboard computing system 809 and touch screen 808 via the communication link 830. Similar data aggregation may occur at the server system, and then transmitted to the onboard computing system 809 and touch screen 808 via the communication link 836 / 830.

[0079] Fig. 9901 is a block diagram of an in-vehicle computing system 900 configured and / or integrated within a vehicle 901. The in-vehicle computing system 900 may be Figure 8 An example of an onboard computing system 809 of the vehicle 901 and / or in some embodiments may perform one or more of the methods described herein. In some examples, the onboard computing system may be a vehicle infotainment system configured to provide information-based media content (audio and / or visual media content, including entertainment content, navigation services, etc.) to a vehicle user to enhance the operator's onboard experience. The vehicle infotainment system may include or be coupled to various vehicle systems, subsystems, hardware components, and software applications and systems that are integrated or integrable into the vehicle 901 to enhance the onboard experience of the driver and / or passengers.

[0080] The vehicle computing system 900 may include one or more processors, including an operating system processor 914 and an interface processor 920. The operating system processor 914 may execute an operating system on the vehicle computing system and control input / output, display, playback, and other operations of the vehicle computing system. The interface processor 920 may interface with a vehicle control system 930 via an in-vehicle communication module 922.

[0081] The in-vehicle communication module 922 can output data to other vehicle systems 931 and vehicle control elements 961, while also receiving data input from other vehicle components and systems 931, 961, for example, through the vehicle control system 930. When outputting data, the in-vehicle communication module 922 can provide signals corresponding to any state of the vehicle, the vehicle surroundings (e.g., as measured by one or more microphones or cameras mounted on the vehicle), or output of any other information source connected to the vehicle via the bus. Vehicle data outputs can include, for example, analog signals (such as current speed), digital signals provided by various information sources (such as clocks, thermometers, position sensors (such as global positioning system [GPS] sensors, etc.), and digital signals propagated through vehicle data networks (such as engine controller area network [CAN] buses, through which engine-related information can be transmitted; and / or audio video bridging [AVB] networks, through which vehicle information can be transmitted). For example, the onboard computer system may retrieve from the engine CAN bus (or from an onboard diagnostic device that receives information from the CAN bus) the vehicle's current speed estimated by wheel sensors, the vehicle's current position provided by a GPS sensor, the vehicle's current acceleration provided by one or more inertial measurement sensors, and / or other information indicative of the driver's driving behavior (e.g., actions performed by the driver that affect the way the vehicle operates). Additionally, other interface mechanisms such as Ethernet may be used without departing from the scope of this disclosure.

[0082] A non-volatile storage device 908 may be included in the vehicle computing system 900 to store data such as instructions executable by the processors 914 and 920 in a non-volatile form. The storage device 908 may store application data to enable the vehicle computing system 900 to perform any of the above methods and / or run an application for connecting to a cloud-based server and / or collecting information for transmission to a cloud-based server. The connection to the cloud-based server may be mediated via an off-vehicle communication module 924. The application may retrieve information collected by vehicle systems / sensors, input devices (e.g., a user interface 918), devices communicating with the vehicle computing system (e.g., a mobile device connected via a Bluetooth link), etc. The vehicle computing system 900 may also include volatile memory 916. The volatile memory 916 may be a random access memory (RAM). Non-transitory storage devices (such as non-volatile storage device 908 and / or volatile memory 916) can store instructions and / or code, which when executed by a processor (e.g., operating system processor 914 and / or interface processor 920) controls the onboard computing system 900 to perform one or more of the actions described in the present disclosure.

[0083] A microphone 902 may be included in the onboard computing system 900 to measure ambient noise in the vehicle, to measure ambient noise outside the vehicle, and so on. One or more additional sensors may be included in the sensor subsystem 910 of the onboard computing system 900 and / or communicatively coupled to the sensor subsystem of the onboard computing system. For example, the sensor subsystem 910 may include and / or communicatively couple to a camera, such as a rear-view camera for helping a user park the vehicle, a cabin camera for identifying a user, and / or a forward-view camera for assessing the quality of the road ahead. The sensor subsystem 910 of the onboard computing system 900 may communicate with and receive input from various vehicle sensors, and may further receive user input. Although some vehicle system sensors may communicate with a separate sensor subsystem 910, other sensors may also communicate with the sensor subsystem 910 and the vehicle control system 930, or may communicate indirectly with the sensor subsystem 910 through the vehicle control system 930. The sensor subsystem 910 may serve as an interface (eg, a hardware interface) and / or a processing unit for receiving and / or processing signals received from one or more of the sensors described in the present disclosure.

[0084] The navigation subsystem 911 of the vehicle computing system 900 can generate and / or receive navigation information, such as location information (e.g., information obtained via a GPS sensor and / or other sensors from the sensor subsystem 910), route guidance, traffic information, point of interest (POI) identification, and / or provide other navigation services for the driver. The navigation subsystem 911 may include an inertial navigation system, which may also determine the position, orientation, and speed of the vehicle via motion and rotation sensor inputs. Examples of motion sensors include accelerometers, and examples of rotation sensors include gyroscopes. The navigation subsystem 911 may communicate with motion and rotation sensors included in the sensor subsystem 910. Alternatively, the navigation subsystem 911 may include motion and rotation sensors, and determine motion and rotation based on the outputs of these sensors. The navigation subsystem 911 may send data to a cloud-based server and / or an external navigation service via the off-board communication module 924, and receive data from a cloud-based server and / or an external navigation service.

[0085] The external device interface 912 of the vehicle-mounted computing system 900 may be capable of coupling to and / or communicating with one or more external devices 940 located outside the vehicle 901. Although the external devices are shown as being located outside the vehicle 901, it should be understood that they can be temporarily housed in the vehicle 901, such as when a user operates the external device while operating the vehicle 901. In other words, the external device 940 is not an integral part of the vehicle 901. The external device 940 may include a mobile device 942 (e.g., connected via Bluetooth, NFC, WIFI Direct or other wireless connection) or an alternative Bluetooth-enabled device 952. The mobile device 942 may be a mobile phone, a smart phone, a wearable device and / or a sensor that can communicate with the vehicle-mounted computing system via wired and / or wireless communication, or one or more other portable electronic devices. Other external devices include external services 946. For example, the external device may include an off-vehicle device that is separate from the vehicle and located outside the vehicle. Other external devices include an external storage device 954, such as a solid-state drive, a flash drive, a USB drive, etc. Without departing from the scope of the present disclosure, the external device 940 may communicate with the vehicle-mounted computing system 900 wirelessly or via a connector. For example, the external device 940 may communicate with the vehicle-mounted computing system 900 through the external device interface 912 via a network 960, a universal serial bus (USB) connection, a direct wired connection, a direct wireless connection, and / or other communication links.

[0086] One or more applications 944 can operate on the mobile device 942. As an example, the mobile device application 944 can be operated to monitor the environment of the vehicle (e.g., collect audio and / or visual data of the vehicle environment) and / or process audio and / or visual data received from the vehicle sensor. The collected / processed data can be transmitted to the external device interface 912 by the application 944 via the network 960. Similarly, one or more applications 948 can operate on the external service 946. As an example, the external service application 948 can operate to aggregate and / or analyze data from multiple data sources. For example, the external service application 948 can aggregate data from the on-board computing system (e.g., sensor data, log files, user input, etc.), etc. The collected data can be sent to another device and / or analyzed by the application to identify the driver using cloud-based data (e.g., a driver profile stored outside the vehicle).

[0087] The onboard control system 930 may include controls for controlling various aspects of the various vehicle systems 931 involved in different onboard functions. These may include, for example, controlling various aspects of the vehicle audio system 932 to provide audio output to vehicle occupants. The audio system 932 may include one or more acoustic reproduction devices including electromagnetic transducers (such as speakers). In some examples, the onboard computing system 900 may be the only audio source for the acoustic reproduction device, or there may be other audio sources connected to the audio reproduction system (e.g., external devices such as mobile phones) to produce audio output (such as one or more of the audible alarms described above). The connection of any such external device to the audio reproduction device may be analog, digital, or any combination of analog and digital technologies.

[0088] The vehicle control system 930 may also include controls for adjusting the settings of various vehicle controls 961 (or vehicle system control elements) associated with the engine and / or auxiliary elements within the vehicle cabin, such as steering controls 962, brake controls 963, lighting controls 964 (e.g., cabin lighting, exterior vehicle lighting, light signals). The vehicle controls 961 may also include internal engine and vehicle operating controls (e.g., engine controller modules, actuators, valves, etc.) configured to receive instructions via the vehicle's CAN bus to change the operation of one or more of the engine, exhaust system, transmission, and / or other vehicle systems (e.g., to provide the above-mentioned alarms). The control signals may also control the audio output at one or more speakers of the vehicle's audio system 932.

[0089] The vehicle-mounted computing system 900 may also include an antenna 906, which may be communicatively coupled to the external device interface 912 and / or the off-vehicle communication module 924. The vehicle-mounted computing system may receive positioning signals, such as GPS signals and / or wireless commands, via the antenna 906 or via infrared or other mechanisms through an appropriate receiving device.

[0090] A user may control one or more elements of the vehicle-mounted computing system 900 via the user interface 918. The user interface 918 may include a screen display (such as a touch screen) that displays the Figure 8 The user may also interact with one or more applications of the onboard computing system 900 and the mobile device 942 via the user interface 918. Notifications and other messages (e.g., Fig. 6A , Figure 6B and Figure 7 The driver identification results shown and / or Figure 3 The graphical representation of the driving profile matrix shown) and the navigation assistance can be displayed to the user on the display of the user interface. User preferences / information and / or responses to the presented information can be implemented via user input to the user interface.

[0091] The present disclosure also provides an onboard computing system for a vehicle, the onboard computing system comprising: a sensor interface, the sensor interface being communicatively coupled to one or more data collection devices; a processor; and a storage device, the storage device storing instructions executable by the processor to perform the following operations: generating a two-dimensional current driver profile matrix of a current driver of the vehicle, the current driver profile matrix indicating a vehicle operating state according to a pair of driving parameters at a sampling time during a current vehicle trip; and determining a probability that the current driver is one of the multiple known drivers by comparing the current driver profile matrix with one or more stored driver profile matrices associated with multiple known drivers. In a first example of an onboard computing system, the pair of driving parameters may additionally or alternatively include a speed of the vehicle, and at least one of an acceleration, a gear, an engine RPM, and a throttle pedal position of the vehicle. A second example of an onboard computing system optionally includes the first example, and further includes the onboard computing system, wherein the instructions may also be executed by the processor to generate multiple two-dimensional current driver profile matrices, each current driver profile matrix indicating a vehicle operating state according to a different pair of driving parameters at a sampling time during a current vehicle trip. A third example of an onboard computing system optionally includes one or both of the first and second examples, and further includes the onboard computing system, wherein at least one driving parameter of the driving parameter pair is received from an onboard diagnostic device. A fourth example of an onboard computing system optionally includes one or more of the first to third examples, and further includes the onboard computing system, wherein each driving parameter of the driving parameter pair is received from the onboard diagnostic device, or wherein the first driving parameter of the driving parameter pair is received from the onboard diagnostic device, and the second driving parameter of the driving parameter pair is received from an inertial measurement unit. A fifth example of an onboard computing system optionally includes one or more of the first to fourth examples, and further includes the onboard computing system, wherein the driving parameter pair includes a vehicle speed and a vehicle acceleration, and wherein the instructions are also executable to generate a second current driver profile matrix, the second current driver profile matrix indicating the vehicle operating state according to the vehicle speed at a sampling time during a current vehicle trip and the vehicle acceleration that is only above a non-zero threshold acceleration value. A sixth example of an on-board computing system optionally includes one or more of the first to fifth examples, and also includes the on-board computing system, wherein the instructions are also executable to generate a third current driver profile matrix, the third current driver profile matrix indicating the vehicle operating state based on the vehicle speed and vehicle acceleration at sampling times recorded during the current vehicle trip when the vehicle speed has changed from the corresponding immediately preceding sampling time.The seventh example of the onboard computing system optionally includes one or more of the first to sixth examples, and also includes the onboard computing system, wherein the instructions are also executable to generate a fourth current driver profile matrix, the fourth current driver profile matrix indicating the vehicle operating state according to the vehicle speed and the average vehicle acceleration of each acceleration or deceleration interval of the current trip. The eighth example of the onboard computing system optionally includes one or more of the first to seventh examples, and also includes the onboard computing system, wherein the instructions are also executable to generate a fifth current driver profile matrix, the fifth current driver profile matrix indicating the vehicle operating state according to the vehicle speed and lateral acceleration at the sampling time during the vehicle trip. The ninth example of the onboard computing system optionally includes one or more of the first to eighth examples, and also includes the onboard computing system, wherein the instructions are also executable to generate a sixth current driver profile matrix, the sixth current driver profile matrix indicating the vehicle operating state according to the vehicle speed and lateral vehicle acceleration above the threshold at the sampling time during the vehicle trip. The tenth example of the on-board computing system optionally includes one or more of the first to ninth examples, and also includes the on-board computing system, wherein the instructions are also executable to generate a seventh current driver profile matrix, and the seventh current driver profile matrix indicates the vehicle operating state according to the accelerator pedal position at the sampling time during the vehicle trip and the first-order derivative of the accelerator pedal position. The eleventh example of the on-board computing system optionally includes one or more of the first to tenth examples, and also includes the on-board computing system, wherein the instructions are also executable to determine the probability that the current driver is one of the multiple known drivers by comparing each of the multiple current driver profile matrices with the corresponding one or more stored driver profile matrices associated with the multiple known drivers.

[0092] The present disclosure also provides a method for inferring the identity of a vehicle driver using a driver identification system, the method comprising adjusting vehicle parameters in response to automatic identification of a driver of the vehicle from a limited number of drivers, the automatic identification being based on a probabilistic correlation of at least two driving parameters repeatedly sampled over time during a current vehicle trip with stored data associated with the limited number of drivers based on one or more previous drives. In a first example of the method, one or more previous drives may additionally or alternatively include one or more previous vehicle trips of the vehicle. A second example of the method optionally includes the first example, and further includes the method, wherein the automatic identification comprises generating a two-dimensional current driver profile matrix of the driver of the vehicle using a processor of the driver identification system, the current driver profile matrix indicating a vehicle operating state according to at least two driving parameters repeatedly sampled over time during the current vehicle trip; and for each respective driver of the limited number of drivers, using the driver identification system, determining a probability that the driver is the respective driver by comparing the current driver profile matrix with one or more stored driver profile matrices associated with the respective driver. A third example of the method optionally includes one or both of the first and second examples, and also includes the method, wherein determining the probability that the driver is the corresponding driver among the limited number of drivers includes, for each stored driver profile matrix associated with the corresponding driver, converting the stored driver profile matrix into the corresponding probability matrix by dividing each cell of the stored driver profile matrix by the maximum value of cells within a threshold number of cells to the left and to the right of the cell in the same row as the cell. A fourth example of the method optionally includes one or more of the first to third examples, and also includes the method, which further includes, for each stored driver profile matrix, multiplying each cell of the current driver profile matrix by a corresponding cell of a probability matrix of the stored driver profile matrix to determine a calculated product; summing the calculated products for each cell of the current driver profile matrix to determine a calculated sum; and dividing the calculated sum by the sum of all cells from the current driver profile matrix to determine the probability that the driver is the corresponding driver associated with the stored driver profile matrix; and aggregating the probabilities of each stored driver profile matrix for the stored driver profiles to determine the total probability that the driver is the corresponding driver associated with the stored driver profile.In a fifth example of the method, a plurality of known drivers may be additionally or alternatively associated with a stored driver profile, the stored driver profile comprising a plurality of stored driver profile matrices associated with the respective known drivers; and determining the probability that the current driver is one of the plurality of known drivers may additionally or alternatively comprise converting each of the one or more stored driver profile matrices associated with the plurality of known drivers into a respective probability matrix. A sixth example of the method optionally comprises one or more of the first to fifth examples, and further comprises the method, wherein for each stored driver profile matrix, converting the stored driver profile matrix into the respective probability matrix comprises dividing each cell of the stored driver profile matrix by the maximum value of cells within a threshold number of cells to the left and to the right of the cell in the same row as the cell. The seventh example of the method optionally includes one or more of the first to sixth examples, and also includes the method, the method also includes, for each stored driver profile matrix, multiplying each cell of the current driver profile matrix by the corresponding cell of the probability matrix of the stored driver profile matrix to determine a calculated product; summing the calculated products of each cell of the current driver profile matrix to determine a calculated sum; and dividing the calculated sum by the sum of all cells from the current driver profile matrix to determine the probability that the current driver is the known driver associated with the stored driver profile matrix. The eighth example of the method optionally includes one or more of the first to seventh examples, and also includes the method, the method also includes, for each stored driver profile, aggregating the probabilities of each stored driver profile matrix for the stored driver profile to determine the total probability that the current driver is the corresponding known driver associated with the stored driver profile.

[0093] The present disclosure also provides a driver identification system for a vehicle, the driver identification system comprising a display; a sensor interface, the sensor interface being communicatively coupled to one or more data collection devices; a processor; and a storage device, the storage device storing instructions executable by the processor to perform the following operations: receiving driving data from the one or more data collection devices via the sensor interface, the driving data comprising an indication of a parameter of a vehicle operating state during a vehicle journey; generating a current driver profile matrix for a current driver of the vehicle, the current driver profile matrix using the driving data to map a value of a first parameter of the vehicle operating state to a value of a second parameter of the vehicle operating state; comparing the current driver profile matrix with one or more stored driver profile matrices, each of the one or more stored driver profile matrices being associated with a corresponding known driver; for each corresponding known driver, determining a probability that the current driver is the corresponding known driver; and outputting an indication of a driver identifier associated with a selected known driver via the display, wherein the probability that the current driver is the selected known driver is higher than the probability that the current driver is any other known driver among the corresponding known drivers. In the first example of the driver identification system, the instructions may be additionally or alternatively executed by the processor to output, via the display, an indication of the probability that the current driver is the selected known driver. The second example of the driver identification system optionally includes the first example, and further includes the driver identification system, wherein the instructions are also executable to determine the probability that the current driver is one of the corresponding known drivers by comparing each of a plurality of current driver profile matrices with a corresponding stored driver profile matrix associated with the corresponding known driver for each corresponding known driver, and wherein the instructions are also executable to transmit the indication of the probability that the current driver is the selected known driver to a remote server device external to the vehicle (e.g., a remote server device located away from the vehicle). The third example of the driver identification system optionally includes one or both of the first example and the second example, and further includes the driver identification system, wherein the instructions are also executable by the processor to output, via the display, a visual representation of at least one of the stored driver profile matrices of the current driver profile matrix and the stored driver profile matrices associated with the corresponding known driver.A fourth example of the driver identification system optionally includes one or more of the first to third examples, and further includes the driver identification system, wherein the visual representation of the current driver profile matrix and at least one of the stored driver profile matrices is presented on a user interface, the user interface including an interactive element that can be selected to control the driver identification system to update a selected one of the stored driver profile matrices to include the driving data for the vehicle trip. A fifth example of the driver identification system optionally includes one or more of the first to fourth examples, and further includes the driver identification system, wherein the visual representation of the current driver profile matrix and at least one of the stored driver profile matrices includes an indication of the determined probability that the current driver is the corresponding known driver associated with the at least one of the stored driver profile matrices.

[0094] The description of the embodiments has been presented for the purpose of illustration and description. Suitable modifications and variations of the embodiments may be performed according to the above description or may be obtained by practicing the methods. For example, unless otherwise specified, one or more of the methods described may be performed by suitable devices and / or device combinations (such as those described in reference to Figure 8 and Fig. 9 The method may be performed by executing stored instructions utilizing one or more logic devices (e.g., processors) in combination with one or more additional hardware elements (such as storage devices, memories, hardware network interfaces / antennas, switches, actuators, clock circuits, etc.). The described methods and associated actions may also be performed in parallel and / or simultaneously in various sequences other than the sequence described in this application. The systems are exemplary in nature and may include additional elements and / or omit elements. The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various systems and configurations disclosed, as well as other features, functions, and / or properties.

[0095] As used in this application, an element or step listed in the singular and preceded by the word "a (a, an)" should be understood as not excluding a plurality of said elements or steps, unless such exclusion is indicated. In addition, reference to "one embodiment" or "an example" of the present disclosure is not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the described features. The terms "first", "second" and "third" etc. are used only as labels, without the intention of imposing numerical requirements or specific positional order on their objects. The attached claims specifically point out the subject matter from the above disclosure and are considered to be novel and non-obvious.

Claims

1. An onboard computing system for a vehicle, the onboard computing system comprising: a sensor interface communicatively coupled to one or more data collection devices; processor; as well as A storage device storing instructions executable by the processor to: generating a two-dimensional current driver profile matrix for a current driver of the vehicle, the current driver profile matrix indicating vehicle operating states based on driving parameter pairs at sampling times during a current vehicle trip, each cell of the current driver profile matrix comprising a counter that is incremented each time the vehicle is observed to be operating with a first parameter value and a second parameter value of the driving parameter pair associated with the cell; as well as determining a probability that the current driver is one of the plurality of known drivers by comparing the current driver profile matrix to one or more stored driver profile matrices associated with the plurality of known drivers, Wherein, determining the probability that the current driver is one of the plurality of known drivers comprises, for each stored driver profile matrix associated with a corresponding known driver, converting the stored driver profile matrix into a probability matrix. 2 . The in-vehicle computing system of claim 1 , wherein the pair of driving parameters comprises a speed of the vehicle, and at least one of an acceleration, a gear, an engine RPM, and an accelerator pedal position of the vehicle.

3. An in-vehicle computing system according to claim 1 or 2, wherein the instructions are also executable by the processor to generate a plurality of two-dimensional current driver profile matrices, each current driver profile matrix indicating the vehicle operating state according to different driving parameter pairs at the sampling time during the current vehicle trip. 4 . The on-board computing system of claim 1 , wherein at least one driving parameter of the pair of driving parameters is received from an on-board diagnostic device.

5. The on-board computing system of claim 4 , wherein each driving parameter in the driving parameter pair is received from the on-board diagnostic device, or wherein a first driving parameter in the driving parameter pair is received from the on-board diagnostic device and a second driving parameter in the driving parameter pair is received from an inertial measurement unit.

6. The onboard computing system of claim 1 , wherein the driving parameter pair comprises vehicle speed and vehicle acceleration, and wherein the instructions are further executable to generate a second current driver profile matrix indicating the vehicle operating state based on the vehicle speed and vehicle acceleration only above a non-zero threshold acceleration value at the sampling time during the current vehicle trip.

7. An on-board computing system according to claim 1 or 6, wherein the instructions are also executable to generate a third current driver profile matrix, the third current driver profile matrix indicating the vehicle operating state based on the vehicle speed and vehicle acceleration at sampling times recorded during the current vehicle trip when the vehicle speed has changed from the corresponding immediately preceding sampling time.

8. The in-vehicle computing system of claim 1 or 6, wherein the instructions are further executable to generate a fourth current driver profile matrix, the fourth current driver profile matrix indicating the vehicle operating state based on the vehicle speed and the average vehicle acceleration at each acceleration or deceleration interval of the current trip.

9. The in-vehicle computing system of claim 1 or 6, wherein the instructions are further executable to generate a fifth current driver profile matrix, the fifth current driver profile matrix indicating the vehicle operating state based on the vehicle speed and the lateral acceleration of the vehicle at the sampling time during the vehicle trip.

10. The on-board computing system of claim 1 or 6, wherein the instructions are further executable to generate a sixth current driver profile matrix indicating the vehicle operating state based on vehicle speed and lateral vehicle acceleration being above a threshold at the sampling time during the vehicle trip.

11. The in-vehicle computing system of claim 1 or 6, wherein the instructions are further executable to generate a seventh current driver profile matrix indicating the vehicle operating state based on an accelerator pedal position and a first-order derivative of the accelerator pedal position at the sampling time during the vehicle trip.

12. An in-vehicle computing system according to claim 1 or 6, wherein the instructions are also executable to determine the probability that the current driver is one of the multiple known drivers by comparing each of the multiple current driver profile matrices with the corresponding one or more stored driver profile matrices associated with the multiple known drivers.

13. A method for inferring the identity of a vehicle driver using a driver identification system, the method comprising: adjusting a vehicle parameter in response to automatic identification of a driver of the vehicle from a limited number of drivers, the automatic identification based on a probabilistic correlation of at least two driving parameters repeatedly sampled over time during a current vehicle trip with stored data associated with the limited number of drivers based on one or more previous drives, wherein the automatic identification comprises generating, using a processor of the driver identification system, a two-dimensional current driver profile matrix of the driver of the vehicle, the current driver profile matrix indicating vehicle operating states based on at least two driving parameters repeatedly sampled over time during the current vehicle trip, each cell of the current driver profile matrix comprising a counter that is incremented each time the vehicle is observed to be operating with a first parameter value and a second parameter value of the at least two driving parameters associated with the cell; determining, for each respective driver of the limited number of drivers, using the driver identification system, a probability that the driver is the respective driver by comparing the current driver profile matrix to one or more stored driver profile matrices associated with the respective driver, and Wherein determining the probability that the driver is the corresponding driver among the limited number of drivers includes, for each stored driver profile matrix associated with the corresponding driver, converting the stored driver profile matrix into a corresponding probability matrix. The method of claim 13 , wherein the one or more previous drives comprise one or more previous vehicle trips of the vehicle.

15. The method according to claim 13 also includes converting the stored driver profile matrix into the corresponding probability matrix by dividing each cell of the stored driver profile matrix by the maximum value of cells within a threshold number of cells to the left and right of the cell in the same row as the cell.

16. The method according to claim 13, further comprising: For each stored driver profile matrix, multiplying each cell of the current driver profile matrix by a corresponding cell of a probability matrix of the stored driver profile matrix to determine a calculated product; summing the calculated products for each cell of the current driver profile matrix to determine a calculated sum; as well as dividing the calculated sum by the sum of all cells from the current driver profile matrix to determine a probability that the driver is the corresponding driver associated with the stored driver profile matrix; as well as The probabilities for each stored driver profile matrix of the stored driver profiles are aggregated to determine an overall probability that the driver is the respective driver associated with the stored driver profile.

17. A driver identification system for a vehicle, the driver identification system comprising: monitor; as well as a sensor interface communicatively coupled to one or more data collection devices; processor; as well as A storage device storing instructions executable by the processor to: receiving driving data from the one or more data collection devices via the sensor interface, the driving data comprising an indication of a parameter of a vehicle operating state during a current vehicle trip; as well as generating a two-dimensional current driver profile matrix for a current driver of the vehicle, the two-dimensional current driver profile matrix mapping a first parameter value of a vehicle operating state to a second parameter value of the vehicle operating state using the driving data, each cell of the current driver profile matrix including a counter that is incremented each time the vehicle is observed to operate with the first parameter value and the second parameter value associated with the cell, and the current driver profile matrix indicating the vehicle operating state based on a count of the vehicle operation when at least the first parameter value and the second parameter value are repeatedly sampled over time during the vehicle trip; comparing the two-dimensional current driver profile matrix to one or more two-dimensional stored driver profile matrices, each of the one or more two-dimensional stored driver profile matrices being associated with a respective known driver; For each corresponding known driver, determining the probability that the current driver is the corresponding known driver, outputting, via the display, an indication of a driver identifier associated with a selected known driver, wherein the probability that the current driver is the selected known driver is higher than a probability that the current driver is any other known driver among the corresponding known drivers; as well as A vehicle parameter is adjusted in response to the selected known driver's indication.

18. The driver identification system of claim 17, wherein the instructions are further executable by the processor to output, via the display, an indication of the probability that the current driver is the selected known driver.

19. A driver identification system according to claim 17 or 18, wherein the instructions are also executable to determine the probability that the current driver is one of the corresponding known drivers by comparing each of a plurality of current driver profile matrices with a corresponding stored driver profile matrix associated with the corresponding known driver for each corresponding known driver, and wherein the instructions are also executable to transmit an indication of the probability that the current driver is the selected known driver to a remote server device outside the vehicle.

Images