WO2016028228A1

WO2016028228A1 - System, method and apparatus for determining driving risk

Info

Publication number: WO2016028228A1
Application number: PCT/SG2015/050265
Authority: WO
Inventors: Eng Hwee Ong
Original assignee: Avennetz Technologies Pte Ltd
Priority date: 2014-08-21
Filing date: 2015-08-18
Publication date: 2016-02-25

Abstract

The disclosure relates to a method of determining a driving risk profile for at least one driver, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the method comprising: determining an identification of the driver; defining a risk score function representing a weighted combination of the plurality of scores; receiving, while the driver is operating a motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating; processing the status data to automatically detect a driving context; determining, from the status data, one or more updated scores for respective risk factors associated with the detected driving context; and based on the updated scores, determining an updated risk score using the risk score function.

Description

System, method and apparatus for determining driving risk

Background It is known that information asymmetry found in insurance or risk management manifests in two fundamental problems, namely, adverse selection and moral hazard. Information asymmetry is commonly understood as a transaction wherein at least one party has relevant information (typically the policyholder) and the other party does not (typically the insurer). Adverse selection occurs when people with higher risk are more likely to buy insurance, and insurer does not have sufficient information about the individual's risk to discriminate them effectively. On the other hand, moral hazard occurs when people are more likely to take risk after they are insured either because the insurer is unable to observe their behavior or the cost associated to the risk may be borne in whole or in part by the insurer.

Consequently, auto insurer uses an underwriting process to evaluate the risk and exposures of potential policyholders to identify and may avoid insuring 'poor' drivers who are perceived to have higher driving risk as compared to 'good' drivers who are perceived to have lower driving risk. In order to address information asymmetries between insurers and policyholders, the cost of auto insurance is determined by different actuarial categories associated to (initial) risk factors derived from static or historical information of the policyholders, such as age, gender, location, driving safety record make of vehicle, previous insurance claims, years of driving experience, of an individual upon application. For example, the premium may be computed by multiplying risk factors to a base rate as, Premium = base rate x (risk factor 1 ) x ... x (risk factor n ), and is primarily based on a flat rate over a given protection period of 6 to 12 months. However, most of these initial risk factors may be poorly correlated with the likelihood of involving in a future accident. In addition, it is a standard practice within the insurance industry to use the estimated annual mileage in the computation of auto insurance premium. The rationale is that a driver who drives more than an average driver will result in higher risk exposure or cost of claims. However, insurers typically classify the annual mileages into non-granular categories in which each category has the same risk factor. As a result, the current pricing of auto insurance is not equitable as low mileage and/or 'good' drivers with lower driving risk typically subsidize insurance costs for high mileage and/or 'poor' drivers with higher driving risk. More specifically, drivers with similar historical information or attributes pay similar premiums, regardless of their usage and driving risk.

Hence, the motivation for usage-based insurance (UBI) is the ability for insurers to better measure the risk associated with the actual operation of the vehicle by means of incorporating driving behavior to reflect a subsequent risk in addition to the initial risk when determining a cost of auto insurance. More importantly, UBI has the potential to reduce risk by providing drivers with a combination of feedback and incentives to instill positive driving behaviors.

Most of the presented UBI solutions today tend to deduce driving behavior by measuring information such as the speed of vehicle, the number of hard accelerations, the number of hard decelerations and the like. While it seems intuitive that such information could reveal telltale signs of safe and unsafe driving behaviors, they need to be analyzed in the context of an associated event in order to be useful. For example, traveling at a speed of 70 km/h along a highway is generally safe, but traveling with the same speed in an enclosed car park will be extremely dangerous. Although some known premium adjustment methods attempt to correlate driving information (e.g. speed, acceleration, g-force dynamics) with environmental information (e.g. weather, time of day, types of road), the proposed methods are either oversimplified or are too computationally intensive for practical application. More specifically, known methods tend to monitor a myriad of data points which do not necessarily relate directly to the risk arising from one's driving behavior. This implies that computational overheads will be incurred unnecessarily and, more importantly, means that there is still a need for methods to relate observed data to driving behavior and the corresponding actuarial risk (and, therefore, the resulting cost of insurance).

Further to that, studies have shown that driver behavior is a key contributor in more than 90% of road accidents. The top five high risk driver behaviors have been observed to be fatigue, speeding, time pressure, distractions, and usage of mobile phones while driving. Existing methods either do not take into account the underlying reasons for these driver behaviors or do not provide a means to quantify these driver behaviors at all, and thus fail to adequately model and quantify the risk profile of drivers in a meaningful manner. This invention seeks to address one or more of the above problems, or at least to provide a useful, pragmatic alternative.

Summary Some embodiments provide a method of determining a driving risk profile for at least one driver, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the method comprising:

determining an identification of the driver;

defining a risk score function representing a weighted combination of the plurality of scores;

receiving, while the driver is operating a motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating;

processing the status data to automatically detect a driving context;

determining, from the status data, one or more updated scores for respective risk factors associated with the detected driving context; and

based on the updated scores, determining an updated risk score using the risk function.

The scores for respective risk factors may be probabilities for the respective risk factors, for example. In other embodiments, the weights of the risk score function may be based on global priorities derived from an analytic hierarchy process (AHP). The global priorities may be determined according to a normalized eigenvector of a pairwise comparison matrix of the AHP or approximated with a sum method.

In some embodiments, the risk score function may be a sum of global priorities for a plurality of sub-criteria and/or criteria in an AHP in which drivers correspond to alternatives, criteria correspond to said risk factors, and sub-criteria correspond to sub- risk factors of said risk factors.

In certain embodiments, the updated risk score is generated in real-time.

The risk score function may be a weighted sum, a weighted average or a weighted product.

Certain embodiments may comprise determining an initial value for the risk score by determining a weighted combination of default values for the plurality of scores using default values for the weights.

The method may comprise receiving updated weights for the respective risk factors associated with the detected driving context, wherein the updated weights are used in the risk score function to generate the updated risk score.

In certain embodiments, a cumulative risk score may be determined based on the updated risk score and one or more previously determined risk scores for the driver. The cumulative risk score may be calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation, for example.

Some embodiments comprise displaying the updated risk score to the driver. In other embodiments, the updated risk score may be displayed simultaneously with at least one further indicator of driver behavior, such as the cumulative risk score for the driver, a ranking relative to other drivers, or an estimated cost of insurance derived from the updated scores and/or the updated risk score.

In certain embodiments, if the updated risk score is higher than the initial value, an alert is signaled to the driver by a haptic feedback device such as a vibrational feedback device. In other embodiments, an alert may be signaled to the driver by a haptic feedback device when the updated risk score is higher than a predetermined threshold. At least one of the risk factors may be based on a dynamic parameter. The updated probability may be obtained using a point estimate and its variability and/or an estimate of a probability density function (PDF) of the dynamic parameter. The point estimate and its variability may be obtained by a bootstrap procedure, for example. Bootstrap replicates in the bootstrap procedure may be calculated by computing the sample median for each corresponding bootstrap data set. If a further PDF is estimated this may be done by recursive Bayesian estimation from the point estimate and its variability. The dynamic parameter may be selected from the group consisting of: vehicle speed; vehicle acceleration; vehicle angular velocity; vehicle geolocation; throttle position; engine RPM; brake booster pressure; steering wheel position; safety distance; sleep pattern; stress level; blood-glucose level; heart rate; heart rate variability; blood-oxygen level; skin conductance; hand grip pressure on steering wheel; blood pressure; skin temperature; sweat level; and eyelid position. One or more of the updated probabilities may be calculated based on a corresponding threshold of the dynamic parameter.

At least one of the risk factors may be based on a static parameter. In this case, the updated probability may be a probability of at least two concurrent events. The probability of at least two concurrent events may be calculated based on one or more conditional probabilities and the corresponding marginal probabilities.

In certain embodiments, one of the risk factors is mobile phone usage whilst the vehicle is operational. The method may comprise determining one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

In certain embodiments, the driving context is detected automatically based on data from one or more of: at least one computing device associated with the vehicle; a sensor internal to the vehicle; an external sensor; and a remote server. The at least one computing device may comprise an on-board device and/or a mobile computing device such as a mobile phone and wearable monitoring device. In some embodiments, there may be a plurality of computing devices, for example an on-board device and at least one mobile computing device, and the at least one mobile computing device may be communicatively coupled with the on-board device and/or with at least one other mobile computing device by an authentication procedure. In some embodiments, a wearable monitoring device may be coupled with the on-board device and/or a mobile phone by an authentication procedure.

In certain embodiments, the weights represent the relative importance of the respective risk factors for actuarial purposes.

The method may further comprise transmitting the identification of the driver, the status data, the detected driving context, and preferably, the updated probabilities, to a remote server.

Some embodiments may comprise maintaining at least one communication path between the vehicle and the remote server using a plurality of communications interfaces. The plurality of communications interfaces may comprise a Multi-RAT interface and/or at least one communications interface of a computing device such as a mobile phone or other mobile computing device. For example, the method may further comprise the selection of the best available radio interface, an appropriate transmit power based in part on an estimated path loss; an appropriate modulation and coding scheme based in part on a prevailing signal-to-noise ratio or feedback messages from the intended receiver; or a combination of the above to enable reliable uplink transmissions associated with the selected radio interface. The method may further comprise the selection of a communication interface of an associated mobile device as the preferred downlink path and the Multi-RAT communications interface as the alternative path. The risk factors may be selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle. Certain embodiments may comprise determining a psychometric assessment of the driver, based on the status data and/or input data received from the driver. The input data may be indicative of responses to a series of questions relating to the driver's mental state, for example. The psychometric assessment may relate to a measurement of driving behavior such as patience, aggression, driving excitement, time pressure, fatigue, stress, or level of distraction of the driver. The psychometric assessment may be at least partly derived explicitly or implicitly from measurements of physiological parameters, or the psychometric assessment may be inferred from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

The method may comprise transmitting update information to a remote server at an update interval. The update information may comprise the updated scores and/or the updated risk score.

In certain embodiments, the update information comprises motion data from computing devices associated with a plurality of vehicles at respective update intervals, the motion data relating to at least one vehicle operating parameter of respective vehicles, and geolocation data relating to positions of the vehicles, and the method may comprise: obtaining map data representing a road map;

receiving the update information;

generating, from the geolocation data and the motion data, a two-dimensional representation of the at least one average vehicle operating parameter as a function of position;

generating a map of traffic conditions by overlaying the two-dimensional representation on the road map; and

transmitting, to the plurality of vehicles, the map of traffic conditions.

The computing devices may comprise on-board devices of the vehicles and/or mobile computing devices, such as mobile phones, associated with the vehicles.

The method may further comprise receiving weather data relating to at least one environmental parameter measured by respective sensors of the computing devices; generating, from the weather data, a two-dimensional representation of the environmental parameter as a function of position; and overlaying the two-dimensional representation of the environmental parameter on the map of traffic conditions.

In certain embodiments, the method comprises receiving weather data indicative of weather conditions as a function of position, determining one or more geolocation- dependent adjusted effective vehicle operating thresholds according to the traffic and/or weather data, and transmitting the one or more geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices. The vehicle operating parameter or environmental parameter may be selected from the group consisting of: average speed; average acceleration; average temperature; average humidity; average atmospheric pressure; and average wiper speed.

In certain embodiments, the two-dimensional representation is a heat map.

In certain embodiments, the two-dimensional representation is transmitted to respective navigation modules of the vehicles, and/or the computing devices.

The method may comprise receiving traffic incident data indicating the nature and location of a traffic incident; and overlaying the traffic incident data on the map of traffic conditions.

In certain embodiments, each update interval is a periodic interval. The periodic interval may be a driver-selected interval. Alternatively, the update intervals may be determined according to an event trigger. The event trigger may be a step change in at least one vehicle operating parameter or environmental parameter.

In certain embodiments, update intervals in a geolocation area are determined according to the number of computing devices associated with vehicles in the geolocation area.

Some embodiments relate to an on-board device for a motor vehicle, comprising:

a data acquisition unit which is configured to: determine an identification of a driver of the motor vehicle; and receive, while the motor vehicle is in operation, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating;

a context identification unit which is configured to: receive, from the data acquisition unit, the status data, and to process the status data to automatically detect that one of a plurality of driving contexts is current; and

a data processing unit which is configured to: define a risk score function representing a weighted combination of a plurality of scores for a plurality of risk factors; determine, from the status data, one or more updated scores for respective risk factors associated with the detected driving context; and determine an updated risk score based on the one or more updated scores using the risk score function.

The on-board device may comprise a data transmission unit which is configured to transmit uplink context information to a remote server. The uplink context information may comprise one or more of: average vehicle data determined based on the operating parameters of the motor vehicle, time, geolocation, the updated scores, the updated risk score, and average weather data determined based on the environmental conditions. In certain embodiments the data transmission unit is configured to receive downlink context information from the remote server. The downlink context information may comprise one or more of: relative weights for use in the risk function, a cumulative risk score determined based on previous updated risk scores received by the remote server, an effective vehicle operating threshold adjusted based on traffic and weather conditions, an update interval calculated for computing device, desired driving context, a ranking of the driver relative to other drivers, estimated cost of insurance, a heat map of traffic and/or weather conditions, and a geolocation of a traffic incident.

The on-board device may comprise a driver feedback unit for communicating the feedback of risk scores to the driver.

The data transmission unit may be configured to communicate with a data transmission unit of an on-board device of at least one other vehicle. The data processing unit may be configured to determine, from response data received from the data transmission unit of the on-board device of the at least one other vehicle, willingness of the at least one other vehicle to give way.

The data transmission unit may be configured to send a give way prompt and/or to transmit the risk profile of the driver to the on-board device of the at least one other vehicle.

The data transmission unit may be configured to receive updated weights for the respective risk factors associated with the detected driving context, and the data processing unit may be configured to use the updated weights in the risk score function to generate the updated risk score.

The scores for respective risk factors may be probabilities for the respective risk factors, for example. In other embodiments, the scores may be global priorities derived from an analytic hierarchy process (AHP). The global priorities may be determined according to a normalized eigenvector of a pairwise comparison matrix of the AHP or approximated with a sum method.

In some embodiments, the risk function may be a sum of global priorities for a plurality of sub-criteria and/or criteria in an AHP in which drivers correspond to alternatives, criteria correspond to said risk factors, and sub-criteria correspond to sub-risk factors of said risk factors.

In certain embodiments, the data processing unit is configured to generate the updated risk score in real-time.

In certain embodiments the data processing unit is configured to determine the initial value by determining a weighted combination of default values for the plurality of scores using default values for the weights. In certain embodiments, the data processing unit may be configured to determine a cumulative risk score based on the updated risk score and one or more previously determined risk scores for the driver. The cumulative risk score may be calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation, for example.

In some embodiments the driver feedback unit is configured to display the updated risk score to the driver. In other embodiments, the updated risk score may be displayed by the driver feedback unit simultaneously with at least one further indicator of driver behavior, such as the cumulative risk score for the driver, a ranking relative to other drivers, or an estimated cost of insurance derived from the updated probabilities and/or the updated risk score.

In certain embodiments, if the updated risk score is higher than the initial value, the driver feedback unit is configured to send an alert signal to a haptic feedback device such as a vibrational feedback device. In other embodiments, the driver feedback unit is configured to send an alert signal to a haptic feedback device if the updated risk score is higher than a predetermined threshold. At least one of the risk factors may be based on a dynamic parameter. The data processing unit may be configured to determine the updated probability using a point estimate and its variability and/or an estimate of a probability density function (PDF) of the dynamic parameter. The data processing unit may be configured to determine the point estimate and its variability by a bootstrap procedure, for example. Bootstrap replicates in the bootstrap procedure may be calculated by computing the sample median for each corresponding bootstrap data set. If a further PDF is estimated this may be done by recursive Bayesian estimation from the point estimate and its variability. The dynamic parameter may be selected from the group consisting of: vehicle speed; vehicle acceleration; vehicle angular velocity; vehicle geolocation; throttle position; engine RPM; brake booster pressure; steering wheel position; safety distance; sleep pattern; stress level; blood-glucose level; heart rate; heart rate variability; blood-oxygen level; skin conductance; hand grip pressure on steering wheel; blood pressure; skin temperature; sweat level; and eyelid position. The data processing unit may be configured to calculate one or more of the updated probabilities based a corresponding threshold of the dynamic parameter.

At least one of the risk factors may be based on a static parameter. In this case, the updated probability may be a probability of at least two concurrent events. The data processing unit may be configured to calculate the probability of at least two concurrent events based on one or more conditional probabilities and the corresponding marginal probabilities. In certain embodiments, one of the risk factors is mobile phone usage whilst the vehicle is operational. The context identification unit may be configured to determine one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone. In certain embodiments, the context identification unit is configured to automatically detect the driving context based on data from one or more of: a mobile computing device located within the vehicle; a sensor internal to the vehicle; an external sensor; and a remote server. In certain embodiments, the weights represent the relative importance of the respective risk factors for actuarial purposes.

The data transmission unit may be configured to transmit the identification of the driver, the status data, the detected driving context, and preferably, the updated probabilities, to a remote server.

In some embodiments the data transmission unit is configured to maintain at least one communication path between the vehicle and the remote server using a plurality of communications interfaces. The plurality of communications interfaces may comprise a Multi-RAT interface of the data transmission unit and/or at least one communications interface of a computing device such as a mobile phone or other mobile computing device. For example, the data transmission unit may be configured to select the best available radio interface, an appropriate transmit power based in part on an estimated path loss; an appropriate modulation and coding scheme based in part on a prevailing signal-to-noise ratio or feedback messages from the intended receiver; or a combination of the above to enable reliable uplink transmissions associated with the selected radio interface. The on-board device may be configured to select a communication interface of an associated mobile device as the preferred downlink path and the Multi-RAT communications interface as the alternative path.

The risk factors may be selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle.

In certain embodiments the data processing unit may be configured to determine a psychometric assessment of the driver, based on the status data and/or input data received from the driver. The input data may be indicative of responses to a series of questions relating to the driver's mental state, for example. The psychometric assessment may relate to a measurement of driving behavior such as patience, aggression, driving excitement, time pressure, fatigue, stress, or level of distraction of the driver. The psychometric assessment may be at least partly derived explicitly or implicitly from measurements of physiological parameters, or the psychometric assessment may be inferred from a combination of data obtained from wearable monitoring devices, data obtained from vehicle parameters, and data obtained from local and/or external devices.

Some embodiments relate to a method of providing a map of traffic conditions to a plurality of vehicles, the method comprising:

obtaining map data representing a road map;

receiving motion data from the plurality of vehicles at respective update intervals, the motion data relating to at least one vehicle operating parameter of respective vehicles, and geolocation data relating to positions of the vehicles; generating, from the geolocation data and the motion data, a two-dimensional representation of the at least one average vehicle operating parameter as a function of position;

transmitting, to the plurality of vehicles, the map of traffic conditions.

The motion data may be received from respective computing devices associated with the vehicles. The computing devices may be on-board devices substantially in accordance with any of the above-mentioned embodiments, and/or mobile computing devices, such as mobile phones, associated with the vehicles.

The method may further comprise receiving weather data relating to at least one environmental parameter measured by respective sensors of one or more of the computing devices; generating, from the weather data, a two-dimensional representation of the environmental parameter as a function of position; and overlaying the two-dimensional representation of the environmental parameter on the map of traffic conditions. The vehicle operating parameter or environmental parameter may be selected from the group consisting of: average speed; average acceleration; average temperature; average humidity; average atmospheric pressure; and average wiper speed.

In certain embodiments, the two-dimensional representation is a heat map.

Some embodiments relate to a system for determining a driving risk profile for at least one driver, the at least one driver being associated with a motor vehicle, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the system comprising:

at least one computing device associated with the motor vehicle; and a remote server having at least one processor and a communications interface for communicating with the at least one computing device;

the at least one computing device and/or the at least one processor being configured to:

determine an identification of the driver;

define a risk score function representing a weighted combination of the plurality of scores;

receive, while the driver is operating the motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating;

process the status data to automatically detect a driving context;

determine, from the status data, one or more updated scores for respective risk factors associated with the detected driving context; and

based on the updated scores, determine an updated risk score using the risk score function.

The at least one computing device may comprise an on-board device according to any of the above embodiments and/or a mobile computing device such as a mobile phone and wearable monitoring device. In certain embodiments, the at least one computing device may comprise an on-board device, and a mobile phone and/or wearable monitoring device communicatively coupled with the on-board device and/or with at least one other mobile computing device by an authentication procedure. In some embodiments, a wearable monitoring device may be coupled with the on-board device and/or a mobile phone by an authentication procedure.

The scores for respective risk factors may be probabilities for the respective risk factors, for example. In other embodiments, the scores may be global priorities derived from an analytic hierarchy process (AHP). The global priorities may be determined according to a normalized eigenvector of a pairwise comparison matrix of the AHP or approximated sum method.

In certain embodiments, the at least one computing device may be configured to generate the updated risk score in real-time. The risk score function may be a weighted sum, a weighted average or a weighted product.

In certain embodiments the at least one computing device and/or the at least one processor may be configured to determine an initial value for the risk score by determining a weighted combination of default values for the plurality of scores using default values for the weights.

In certain embodiments the at least one computing device may be configured to receive, from the remote server, updated weights for the respective risk factors associated with the detected driving context, and the computing device may be configured to generate the updated risk score using the updated weights in the risk score function. In certain embodiments, the at least one computing device and/or the at least one processor may be configured to determine a cumulative risk score based on the updated risk score and one or more previously determined risk scores for the driver. The cumulative risk score may be calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation, for example.

In some embodiments the computing device may be configured to display the updated risk score to the driver. In other embodiments, the updated risk score may be displayed simultaneously with at least one further indicator of driver behavior, such as the cumulative risk score for the driver, a ranking relative to other drivers, or an estimated cost of insurance derived from the updated probabilities and/or the updated risk score.

In certain embodiments, if the updated risk score is higher than the initial value, the computing device may be configured to signal an alert to the driver by a haptic feedback device such as a vibrational feedback device. In other embodiments, an alert may be signaled to the driver by a haptic feedback device when the updated risk score is higher than a predetermined threshold. At least one of the risk factors may be based on a dynamic parameter. The computing device and/or the at least one processor may be configured to determine the updated probability using a point estimate and its variability and/or an estimate of a probability density function (PDF) of the dynamic parameter. The point estimate and its variability may be obtained by a bootstrap procedure, for example. Bootstrap replicates in the bootstrap procedure may be calculated by computing the sample median for each corresponding bootstrap data set. If a further PDF is estimated this may be done by recursive Bayesian estimation from the point estimate and its variability.

The dynamic parameter may be selected from the group consisting of: vehicle speed; vehicle acceleration; vehicle angular velocity; vehicle geolocation; throttle position; engine RPM; brake booster pressure; steering wheel position; safety distance; sleep pattern; stress level; blood-glucose level; heart rate; heart rate variability; blood-oxygen level; skin conductance; hand grip pressure on steering wheel; blood pressure; skin temperature; sweat level; and eyelid position. The computing device and/or the at least one processor may be configured to calculate one or more of the updated probabilities based on a corresponding threshold of the dynamic parameter.

In certain embodiments, one of the risk factors is mobile phone usage whilst the vehicle is operational. The computing device and/or the at least one processor may be configured to determine one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

In certain embodiments, the computing device and/or the at least one processor may be configured to automatically detect the driving context based on data from one or more of: the computing device; a sensor internal to the vehicle; an external sensor; and a remote server.

The computing device may be configured to transmit the identification of the driver, the status data, the detected driving context, and preferably, the updated probabilities, to the remote server.

In some embodiments the computing device is configured to maintain at least one communication path between the vehicle and the remote server using a plurality of communications interfaces. The plurality of communications interfaces may comprise a Multi-RAT interface and/or at least one communications interface of a computing device such as a mobile phone or other mobile computing device. For example, the computing device may be configured to select of the best available radio interface, an appropriate transmit power based in part on an estimated path loss; an appropriate modulation and coding scheme based in part on a prevailing signal-to-noise ratio or feedback messages from the intended receiver; or a combination of the above to enable reliable uplink transmissions associated with the selected radio interface. The computing device may be configured to select a communication interface of an associated mobile device as the preferred downlink path and the Multi-RAT communications interface as the alternative path. The risk factors may be selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle. The at least one computing device may be configured to transmit update information to the remote server at an update interval. The update information may comprise the updated scores and/or the updated risk score.

The update information may comprise motion data from computing devices of a plurality of vehicles at respective update intervals, the motion data relating to at least one vehicle operating parameter of respective vehicles, and geolocation data relating to positions of the vehicles and the remote server may be configured to:

obtain map data representing a road map;

receive the update information;

generate, from the geolocation data and the motion data, a two-dimensional representation of the at least one average vehicle operating parameter as a function of position;

generate a map of traffic conditions by overlaying the two-dimensional representation on the road map; and

transmit, to the plurality of vehicles, the map of traffic conditions.

The remote server may be configured to receive weather data relating to at least one environmental parameter measured by respective sensors of the computing devices; generate, from the weather data, a two-dimensional representation of the environmental parameter as a function of position; and overlay the two-dimensional representation of the environmental parameter on the map of traffic conditions.

In certain embodiments, the remote server may be configured to receive weather data indicative of weather conditions as a function of position, determine one or more geolocation-dependent adjusted effective vehicle operating thresholds according to the traffic and/or weather data, and transmit the one or more geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices. The vehicle operating parameter or environmental parameter may be selected from the group consisting of: average speed; average acceleration; average temperature; average humidity; average atmospheric pressure; and average wiper speed.

In certain embodiments, the two-dimensional representation is a heat map.

In certain embodiments, the remote server is configured to transmit the two- dimensional representation to respective navigation modules of the vehicles, and/or the computing devices. The remote server may be configured to receive traffic incident data indicating the nature and location of a traffic incident; and overlay the traffic incident data on the map of traffic conditions.

In certain embodiments, the remote server is configured to determine update intervals in a geolocation area according to the number of computing devices associated with vehicles in the geolocation area.

The system may comprise a data store for storing data received from the plurality of computing devices in relation to a plurality of drivers, and respective risk profiles for the plurality of drivers calculated based on the data received from the plurality of computing devices.

The at least one processor may be configured to compute, for a driver of the plurality of drivers, a ranking of the risk profile for the driver relative to the other drivers; and the remote server may be configured to transmit, to a computing device associated with the driver, the computed ranking.

In certain embodiments the at least one processor may be configured to determine a psychometric assessment of the driver, based on the status data and/or input data received from the driver. The input data may be indicative of responses to a series of questions relating to the driver's mental state, for example. The psychometric assessment may relate to a measurement of driving behavior such as patience, aggression, driving excitement, time pressure, fatigue, stress, or level of distraction of the driver. The psychometric assessment may be at least partly derived explicitly or implicitly from measurements of physiological parameters, or the psychometric assessment may be inferred from a combination of data obtained from wearable monitoring devices, data obtained from vehicle parameters, and data obtained from local and/or external devices.

In any of the above embodiments, a mobile phone and/or wearable monitoring device may be registered in a database which is in communication with a remote server.

Some embodiments relate to a remote server for determining a risk profile of at least one driver, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the remote server comprising:

at least one processor; and

at least one communications interface for communicating with at least one computing device associated with the motor vehicle;

wherein the at least one processor is configured to:

determine an identification of the driver;

receive from said at least one computing device, while the driver is operating the motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating;

process the status data to automatically detect a driving context;

based on the updated scores, determine an updated risk score using the risk score function. Further embodiments provide a remote server for determining a risk profile of at least one driver of a motor vehicle, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the remote server comprising:

at least one processor; and

at least one communications interface configured to communicate with at least one computing device associated with the motor vehicle;

wherein the at least one processor is configured to:

determine an identification of the driver;

receive, from said at least one computing device, one or more updated scores for respective risk factors associated with driving context detected by the at least one computing device, and/or an updated risk score computed by the at least one computing device based on the updated scores for the respective risk factors; and/or

receive, from said at least one computing device, uplink context information, wherein the uplink context information comprises one or more of: average vehicle data determined based on operating parameters of the motor vehicle, time, geolocation, the updated scores, the updated risk score, and average weather data determined based on the environmental conditions; and/or

transmit, to said at least one computing device, downlink context information, wherein the downlink context information comprises one or more of: relative weights for use in the risk function, a cumulative risk score determined based on previous updated risk scores received by the remote server, an effective vehicle operating threshold adjusted based on traffic and weather conditions, an update interval calculated for computing device, desired driving context, a ranking of the driver relative to other drivers, estimated cost of insurance, a heat map of traffic and/or weather conditions, and a geolocation of a traffic incident; and

based on the updated risk score and/or the updated scores, determine a cumulative risk score.

The at least one computing device may comprise an on-board device according to any of the above embodiments and/or a mobile computing device such as a mobile phone and wearable monitoring device. In certain embodiments, the at least one computing device may comprise an on-board device, and a mobile phone and/or wearable monitoring device communicatively coupled with the on-board device and/or with at least one other mobile computing device by an authentication procedure. In some embodiments, a wearable monitoring device may be coupled with the on-board device and/or a mobile phone by an authentication procedure. In some embodiments, the at least one processor is in communication with a data store, the data store comprising risk scores for a plurality of other drivers; and the at least one processor is configured to compare the updated risk score and/or the cumulative risk score for the at least one driver to the risk scores of the other drivers. The scores for respective risk factors may be probabilities for the respective risk factors, for example. In other embodiments, the scores may be global priorities derived from an analytic hierarchy process (AHP). The global priorities may be determined according to a normalized eigenvector of a pairwise comparison matrix of the AHP or approximated with a sum method.

The risk score function may be a weighted sum, a weighted average or a weighted product. In certain embodiments the at least one processor may be configured to determine the initial value by determining a weighted combination of default values for the plurality of scores using default values for the weights. In certain embodiments, the at least one processor may be configured to determine a cumulative risk score based on the updated risk score and one or more previously determined risk scores for the driver. The cumulative risk score may be calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation, for example.

At least one of the risk factors may be based on a dynamic parameter. The at least one processor may be configured to determine the updated probability using a point estimate and its variability and/or an estimate of a probability density function (PDF) of the dynamic parameter. The point estimate and its variability may be obtained by a bootstrap procedure, for example. Bootstrap replicates in the bootstrap procedure may be calculated by computing the sample median for each corresponding bootstrap data set. If a further PDF is estimated this may be done by recursive Bayesian estimation from the point estimate and its variability. The dynamic parameter may be selected from the group consisting of: vehicle speed; vehicle acceleration; vehicle angular velocity; vehicle geolocation; throttle position; engine RPM; brake booster pressure; steering wheel position; safety distance; sleep pattern; stress level; blood-glucose level; heart rate; heart rate variability; blood-oxygen level; skin conductance; hand grip pressure on steering wheel; blood pressure; skin temperature; sweat level; and eyelid position. The at least one processor may be configured to calculate one or more of the updated probabilities based on a corresponding threshold of the dynamic parameter.

In certain embodiments, one of the risk factors is mobile phone usage whilst the vehicle is operational. The at least one processor may be configured to determine one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the associated mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

In certain embodiments, the at least one processor may be configured to automatically detect the driving context based on data from one or more of: the computing device; a sensor internal to the vehicle; an external sensor; and a remote server.

In certain embodiments the at least one processor may be configured to determine a psychometric assessment of the driver, based on the status data and/or input data received from the driver. The input data may be indicative of responses to a series of questions relating to the driver's mental state, for example. The psychometric assessment may relate to a measurement of driving behavior such as patience, aggression, driving excitement, time pressure, fatigue, stress, or level of distraction of the driver. The psychometric assessment may be at least partly derived explicitly or implicitly from measurements of physiological parameters, or the psychometric assessment may be inferred from a combination of data obtained from wearable monitoring devices, data obtained from vehicle parameters, and data obtained from local and/or external devices. The at least one processor may be configured to select a communication interface of a mobile device associated with the computing device as the preferred downlink path and a Multi-RAT communications interface of the computing device as the alternative path. The remote server may be configured to receive update information from the at least one computing device at an update interval. The update information may comprise the updated scores and/or the updated risk score.

The update information may comprise motion data from computing devices of a plurality of vehicles at respective update intervals, the motion data relating to at least one vehicle operating parameter of respective vehicles, and geolocation data relating to positions of the vehicles, and the at least one processor may be configured to:

obtain map data representing a road map;

receive the update information;

transmit, to the plurality of vehicles, the map of traffic conditions.

The at least one processor may be configured to receive weather data relating to at least one environmental parameter measured by respective sensors of the computing devices; generate, from the weather data, a two-dimensional representation of the environmental parameter as a function of position; and overlay the two-dimensional representation of the environmental parameter on the map of traffic conditions.

In certain embodiments, the remote server may be configured to receive weather data indicative of weather conditions as a function of position, determine one or more geolocation-dependent adjusted effective vehicle operating thresholds according to the traffic and/or weather data, and transmit the one or more geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices. The vehicle operating parameter or environmental parameter may be selected from the group consisting of: average speed; average acceleration; average temperature; average humidity; average atmospheric pressure; and average wiper speed. In certain embodiments, the two-dimensional representation is a heat map.

In certain embodiments, the remote server is configured to transmit the two- dimensional representation to respective navigation modules of the vehicles, and/or the computing devices of the vehicles.

The at least one processor may be configured to receive traffic incident data indicating the nature and location of a traffic incident; and overlay the traffic incident data on the map of traffic conditions. In certain embodiments, each update interval is a periodic interval. The periodic interval may be a driver-selected interval. Alternatively, the update intervals may be determined according to an event trigger. The event trigger may be a step change in at least one vehicle operating parameter or environmental parameter. In certain embodiments, the at least one processor is configured to determine update intervals in a geolocation area according to the number of computing devices associated with vehicles in the geolocation area.

The remote server may be in communication with a data store for storing data received from a plurality of computing devices in relation to a plurality of drivers, and respective risk profiles for the plurality of drivers calculated based on the data received from the plurality of computing devices.

In any of the above embodiments, a mobile phone and/or wearable monitoring device may be registered in a database which is in communication with a remote server. Advantageously, embodiments provide the ability to incorporate driving behavior information, which is translated from pertinent observed data, to determine a subsequent driving risk, and methods to provide a fair cost of auto insurance. The notion of fair cost can be understood from the fact that, presently, auto insurance is charged based on initial risk at the time of application which typically lasts for a period of one year, whereas embodiments of the method proposed herein are able to take into account the proper quantification of subsequent risk associated with driving behavior which may be lower than the initial risk, for example. In addition, embodiments of the proposed method also take into account the prevailing mileage which may be lower than the estimated annual mileage which is typically used for the determining the cost of auto insurance, for example.

In particular, embodiments of the proposed method are able to determine a real-time risk and a cumulative risk associated with a driver behavior based on context information. The psychometric assessment of the driver may be determined based on physiological measurements of a driver, pertinent operating data of a vehicle, external information regarding a specific environment or geolocation, and sensor information from portable or mobile devices and the said vehicle. The ability to compute real-time risk also allows us to channel this as instant feedback to drivers through a user interface such as a mobile application or display unit. This provides a more effective way to keep driving behavior in check, and is pivotal in providing opportunities for drivers to alter their driving patterns in a timelier manner. On the other hand, the cumulative risk may be used to update the driving behavior of the driver by combining historical information with current information to obtain a more accurate information regarding the driving behavior.

Embodiments also provide the ability to maintain at least one robust communication path between the vehicle and a remote server for the purpose of transferring context information during the operation of the vehicle by selecting the best communication path in terms of reliability or latency that is available between the vehicle and the remote server. Brief Description of the Drawings

Embodiments of the invention will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which:

Figure 1 (a) is a block diagram of an on-board device according to embodiments of the invention;

Figure 1 (b) shows the on-board device of Figure 1 (a) connected to an interface of a vehicle;

Figure 2(a) is a block diagram of a data acquisition process of the device of Fig. 1 (a) and Fig. 1 (b);

Figure 2(b) is a block diagram of a context identification process;

Figure 3 is a block diagram of a system according to embodiments of the invention; Figure 4 is a flow diagram of data processing implemented in the device of Fig. 1 (a) and Fig. 1 (b);

Figure 5 is a block diagram of a bootstrap procedure implemented in the device of Fig. 1 (a) and Fig. 1 (b);

Figure 6(a) schematically illustrates probability density functions (PDFs) estimated by a statistical inference procedure implemented in the device of Fig. 1 (a) and Fig. 1 (b); Figure 6(b) illustrates a process for determining a speed limit based on vehicle operating parameters and environmental parameters;

Figure 7 schematically illustrates PDFs estimated at various stages of operation of a vehicle;

Figure 8 is a block diagram of a driver feedback unit of the device of Fig. 1 (a) and Fig. 1 (b);

Figure 9(a) is a block diagram of a system according to embodiments of the invention; Figure 9(b) is a block diagram of a server of the system of Figure 9(a);

Figure 10 is a block diagram of a process for maintaining a communication path between a vehicle and a remote server;

Figure 1 1 is a block diagram of a communications system according to embodiments of the invention;

Figure 12 is a block diagram of communication between vehicles;

Figure 13 shows a data structure used for communication between vehicles; Figure 14(a) is another example of a data structure used for communication between vehicles;

Figure 14(b) is a further example of a data structure used for communication between vehicles;

Figure 15(a) schematically depicts transmission of risk profiles between vehicles carrying on-board devices as shown in Fig. 1 (a) and Fig. 1 (b);

Figure 15(b) illustrates an ad hoc connection between a pair of vehicles;

Figure 16 is a flow diagram of a process for transmitting vehicle operating data to a remote server;

Figure 17 is a flow diagram of a process for analyzing traffic conditions;

Figure 18 is a block diagram of an analytic hierarchy process;

Figure 19 is a block diagram of an exemplary set of weightings derived using the process of Fig. 18; and

Figure 20 is a flow chart of an exemplary risk determination and insurance cost calculation.

Detailed Description of Embodiments

A key concept of preferred embodiments is the introduction of statistical methods such as resampling techniques, Bayes' rules, and conditional probability to acquire and quantify observed data formally so that data representing a plurality of parameters may be used to infer and characterize a risk profile of drivers in a fair and unbiased manner. The risk may be computed in real-time and be used as a feedback to steer driving behavior in a timely manner.

Furthermore, embodiments may incorporate one of several novel aspects such as psychometric assessment, detection of usage of mobile phone while driving, and willingness to give way to other road users, which can be used as primary context information, in conjunction with driving data regarding driving behavior (e.g. acceleration, braking, and cornering) and driving environment (e.g. weather, traffic conditions, and road conditions) to characterize the risk profile more appropriately by accounting for the primary high risk driver behaviors. Referring to Figure 1 (a) and Figure 1 (b), there is shown an embodiment of an on-board diagnostic (OBD) module 100. The on-board device 100 comprises a central processing unit (CPU) 105, which may be a programmable microprocessor or microcontroller, functioning primarily as a data acquisition unit (DAU) 1 10, data processing unit (DPU) 120, and data transfer unit (DTU) 140, as well as transferring of data or information between a memory module 150, clock module 190, driver feedback unit (DFU) 130 and multiple radio access technology (Multi-RAT) transceiver 142 through an I/O interface 170. The OBD module 100 also comprises a satellite navigation module (comprising of global navigation satellite system (GNSS) receivers compatible with systems such as global positioning system (GPS), globalnaya navigatsionnaya sputnikovaya sistema (GLONASS), Galileo, and BeiDou satellite navigation system (BDS)) 160, 6-axis motion sensing module (comprising sensors such as a 3-axis accelerometer and 3-axis gyroscope) 180, atmospheric sensing module (comprising of sensors such as a thermometer, hygrometer and barometer) 165, and the I/O interface 170 which can communicate with local devices 175 (from modules 160, 180, and 165), CPU 105, and an industry standard connector known as SAE J1962 or OBD interface 195 (e.g. OBD-I, OBD-II or OBD-III in future). It is appreciated that 6-axis motion sensing module may also be a 9-axis motion sensing module (comprising sensors such as a 3-axis accelerometer, 3-axis gyroscope and 3- axis magnetometer).

The current OBD-II interface is compatible with five signaling protocols, namely, SAE J 1850 PWM (proprietary standard of Ford™), SAE J 1850 VPW (proprietary standard of General Motors™), ISO 9141 -2 (used primarily in Chrysler™, European and Asian vehicles), ISO 14230 KWP2000, and ISO 15765-4 CAN (developed by Bosch™ and mandated in all cars sold in United States from 2008). The OBD interface 195 provides access to data from a plurality of electronic control units (ECU) for subsystems, such as engine control module, transmission control module, and brake control module, wherein a rich list of parameters may be addressed by using an appropriate parameter identifier (PID) as specified in SAE J 1979. Vehicle manufacturers have the flexibility to implement a subset of the PIDs specified in SAE J1979 or additional proprietary PIDs. In general, PIDs may consist of real-time sensor data (e.g. vehicle speed, throttle position, engine revolutions per minute (RPM), and engine torque), diagnostic trouble codes which indicate malfunctions in powertrain, chassis, body or network, status monitoring data relating to fuel system, misfire, catalyst, and oxygen sensor, for example, and vehicle information such as the 17-character, ACSII-encoded vehicle identification number (VIN). It is appreciated that the OBD module 100 may be a black box which may not be equipped with the OBD interface 195.

A system according to certain embodiments is shown in Figure 3. The various system components of Figure 3, namely the OBD module 100, a registered mobile phone 350, a remote server 900 for use with the OBD module 100 and mobile phone 350, and systems and processes which use the OBD module 100, mobile phone 350 and/or the remote server 900 for quantifying and ranking of risk profiles, and calculation of the resulting insurance cost are further described below.

Data Acquisition Unit (DAU) 110

The DAU 1 10 may be primarily responsible for the acquisition of data, for example by collection and measurement of physical quantities, and subsequently deriving information from multiple sources as depicted in Figure 2(a). According to preferred embodiments of the invention, the data sources may comprise one or more external devices 240 (e.g. mobile phone, camera, remote server, and wearable monitoring device), local devices 175 (e.g. accelerometer, gyroscope, GNSS, thermometer, hygrometer, and barometer), and vehicle parameters 250 (e.g. vehicle speed, throttle position, engine RPM, brake switch, brake booster pressure, wiper switch, anti-lock braking system (ABS) signal, and turn signal) which may be used to derive one or more of: measurements of physiological parameters or other physical characteristics 220 of a driver, for example, through a wearable monitoring device, operating condition 230 of the vehicle, for example, based on vehicle parameters 250 received by the OBD module via I/O interface 170, and environment condition 210, for example, derived from local atmospheric sensors from block 165 and/or remote servers. The remote servers may be located (at least temporarily) physically nearby the vehicle, such as a road-side infrastructure server, which may broadcast traffic, speed limit or hazard information, or may be located far from the vehicle but be able to communicate information, such as weather forecast, with it using wireless infrastructure. The local atmospheric sensors, which may comprise a thermometer, hygrometer, and barometer, may be used to predict local weather conditions along the traveled route of a vehicle, and may be used in combination with the weather forecast obtained from remote servers to improve the accuracy.

More specifically, physiological data may be obtained through measurements recorded by wearable monitoring devices, which may contain biomedical sensors, such as FitBit™, Jawbone™, Nike Fuelband™, Basis™, Airo™, Empatica E3™, and the like. These wearable monitoring devices may have stored thereon information relating to sleep pattern (or quality of sleep as inferred by measurements of the autonomic nervous system to identify deep sleep, light sleep, and REM sleep), stress level (using optical light to measure blood flow which is related to heart rate variability to monitor micro-fluctuations in stress throughout the day), emotional state or arousal level (as inferred by measuring skin conductance which may vary depending on the amount of sweat-induced moisture on the skin to identify excitement and anger, for example), blood-oxygen level (using transmissive or reflectance pulse oximetry to measure the changes in light absorption of two different wavelengths emitted from a red and an infrared LEDs which may correspond to a ratio of oxygenated hemoglobin to deoxygenated hemoglobin), nutrition (for example, calorific intake measured based on wavelength of light in bloodstream, or manually input by the driver), heart rate, blood pressure, skin temperature, weight, and sweat level, as well as new technologies such as medical sensing of blood-glucose level via tears from contact lens (by using natural user interfaces) and detection of driver's anger (by using facial recognition camera mounted in steering wheel), and driver fatigue (by monitoring the percentage of eyelid closure, blood-oxygen level, and hand grip pressure on steering wheel). It is appreciated that the above physiological data may be used in combination to determine the levels of fatigue and stress of a driver. In certain embodiments, wearable monitoring device may contain non-biomedical sensors, such as accelerometer, magnetometer, gyroscope, ambient light sensor, and proximity sensor, as well as display such as prism projector, for example. According to preferred embodiments, a psychometric assessment which may refer to a measurement of driving behavior such as patience, aggression, driving excitement, time pressure, fatigue, stress, or level of distraction of the driver under evaluation may be obtained through a series of questionnaires answered by the driver, or the psychometric assessment may be derived explicitly or implicitly from measurements of physiological parameters, or the psychometric assessment may be inferred from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

In some embodiments, the stress level and fatigue may be inferred from information gathered from a calendar and from a measured driving duration, respectively. For example, the stress level of a driver may increase when driving under time pressure to reach a destination before a certain time or having a short "time to destination" as recorded in the driver's calendar, and the driver may be more fatigued when exposed to longer driving duration. It is obvious that such inference may be used in combination with inference from derived from measurements recorded in wearable monitoring devices as described earlier.

In some embodiments, the risk of an individual may comprise of driving risk and other dependent risks such as health and wellness risk. In this respect, behavioral patterns consisting of driving pattern, consumption pattern (e.g. diet, alcohol, cigarettes), physical activity pattern, sleep pattern may be measured by the DAU 1 10 and wearable monitoring devices, and subsequently used to derive a correlation coefficient that may be used to infer or quantify the collective risk of an individual.

Table 1. Translation of acquired data to behavior information

Context of Environment Vehicle Physiological Behavior

Interest Parameter/Data Parameter/Data Parameter/Data Information

Driving below • Time of day • Vehicle speed • Questionnaire • Patience speed limit • Type of roads • Longitude/latitude • Sleep pattern • Conscious

• Speed limit • Driving duration • Stress level of hazards

• Weather • Steering wheel • Nutrition • Fatigue

• Road works, • Fuel consumption • Heart rate • Distraction

Driving above hazards • Vehicle speed • Heart rate • Impatience speed limit • Bends, • Longitude/latitude variability • Aggression corners • Wiper • Blood pressure • Confidence

• Controlled • Throttle position • Weight • Stress

Intersections • Acceleration • Skin

• Uncontrolled • Deceleration temperature

intersections • Jerk • Skin

• School zones • Brake switch conductance

• Pedestrian • Safety distance • Sweat level

crossings • High beam • Blood-oxygen

• Rumble strips • Horn level

• Traffic • Steering wheel • Blood-glucose conditions level

• Engine RPM

• Traffic lights • Percentage of

• Actual Engine

• Road signs Eyelid closure

Torque

• Emergency • Time to

• Driver's Demand

vehicles destination

Engine Torque

• Vehicles with • Driving

• Gear position

vulnerable duration

• Fuel consumption

passengers

Cornering, lane • Vehicle speed • Thrill changing, • Longitude/latitude seeking acceleration, • Wiper • Distraction braking • Throttle position • Impulsive

• Acceleration • Stress

• Deceleration • Willingness

• Jerk to give way

• Brake switch

• Turn signal

• G-force dynamics

• Engine RPM

• Actual Engine

Torque

• Driver's Demand

Engine Torque

• Gear position

• Fuel consumption

Incident • Vehicle speed • Impatience

(Stopping in • Longitude/latitude • Egocentric yellow box, • Mobile phone • Distraction running red activities

light, usage of

mobile phone),

Accident In addition, the DAU 1 10 is responsible for the translation of the acquired status data, consisting of environment, vehicle, and physiological parameters, to behavior information as shown in Table 1 in relation to a driving context or context of interest (COI). Suppose, for example, if we are interested to know if a driver has a habit or tendency of performing high-speed cornering, then the act of "cornering" is referred to as the context of interest, "speed" is the acquired vehicle data 230 (or more specifically the measurand in this case), which may be measured using the OBD module 100, satellite navigation module 160 and/or distance measuring instrument (DMI) such as a wheel sensor, and together "high-speed cornering" may be translated to a behavior information suggesting that the driver either likes driving excitement (thrill seeking), is aggressive, or is stressed, these inferred behaviors in turn being usable to infer the risk of the driver. According to some embodiments, the COI may be selected by an insurer for use in establishing a risk profile of a specific driver, and such risk profile may be further refined with the consideration of environment data 210, vehicle data 230, and/or physiological data 220 to determine the corresponding behavior information or psychometric assessment. For example, a driver with thrill seeking behavior may have a tendency of performing high-speed cornering even at night or when traffic conditions are heavy. Similarly, a driver who is aggressive may perform frequent acceleration and/or braking while driving above speed limit, and may have frequent usage of high beam and horn, for example. Table 1 presents some non-limiting examples of COI, environment parameter/data, vehicle parameter/data, physiological parameter/data, and the translated behavior information.

In preferred embodiments, a context identification unit (CIU) 1 12 of DAU 1 10 is used to automatically detect a COI. Referring to Figure 2(b), the CIU 1 12 may receive data acquired by the DAU 1 10, comprising environment data 210, physiological data 220, and/or vehicle data 230 to detect at least one COI 300. The CIU 1 12 may positively identify or detect the COI from data concerning the environment 210, physiological state of the driver 220, and vehicle 230 by using built-in sensors of portable or mobile devices (e.g. accelerometers, proximity sensors, ambient light sensors, gyroscopes, magnetometers, barometers, thermometers, hygrometers, fingerprint sensors, heart rate sensors, Hall effect sensors, geomagnetic sensors, infrared gesture sensors, capacitive sensors, and touchscreen sensors for keypad input of a mobile computing device), internal sensors of vehicle (e.g. turn signal, steering wheel sensors, wiper switch, load sensors for measuring occupant weight, GNSS receivers, onboard cameras, and rangefinders), external sensors from mountable devices (e.g. external cameras such as surveillance, red light cameras, speed cameras, navigation systems, infrared detectors, LIDAR systems, and ultrasound sensors), wearable monitoring device (e.g. accelerometer, magnetometer, gyroscope, ambient light sensor, proximity sensor, pulse oximeter, optical blood-flow sensor, galvanic skin sensor, and temperature sensor), and remote servers (e.g. a mapping server, traffic monitoring server, weather monitoring server, and roadside infrastructure). For example, the ClU 1 12 may use a combination of environment data 210, such as the knowledge of the existence of a bend or corner derived from digital map data or geographic information system (GIS), and vehicle data 230, such as a turn signal and/or g-force dynamics derived from the accelerometer, as combined inputs to reliably detect a "cornering" COI.

As another example, the ClU 1 12 may use a combination of environment data 210, such as the knowledge of a speed limit derived from city ordinance, digital map data, geocoded information map, and/or GIS, and vehicle data 230, such as speed data received by the OBD module 100 from the vehicle or measured by satellite navigation module 160, as combined inputs to detect a "driving above speed limit" COI. In certain embodiments, the speed limit may be derived using image recognition on road signs, based on weather conditions, or from an average vehicle speed that has been reported back to a remote server from a given geolocation area as illustrated in Figure 6(b).

The selection of each COI 300 may be determined by an insurer, and transmitted to the OBD module 100 via DTU 140. The ClU 1 12 may trigger the DPU 120 to derive a point estimate and its variability and/or an estimated probability density function (PDF) of the acquired data or measurand, e.g. vehicle speed when at least one COI concerning the vehicle speed such as "driving above speed limit" is detected (block 310). Otherwise, ClU 1 12 may continue to monitor the data acquired from the DAU 1 10 when no COI is detected. It can be appreciated that ClU 1 12, COI 300 and block 310 may be implemented in the remote server 900 in other embodiments. In some embodiments, the DAU 1 10 may gather processed data from an onboard camera or an external camera with wireless connectivity such as Bluetooth or Wi-Fi. The processed data may be derived by means of image recognition or signal processing techniques and may comprise information extracted from an identified road sign, such as a speed limit (unconditional speed limit) sign or warning sign associated to a school zone, weather conditions, or road works such as caution, reduce speed and a lower speed limit (conditional speed limit) which may not be readily or accurately available from city ordinance, digital map data, geocoded information map, and/or GIS. Optionally, the processed data may be obtained by an appropriate image recognition algorithm implemented as part of the DAU 1 10.

In certain embodiments, the DAU 1 10 may be used to determine positive authentication of the driver who is operating the vehicle. Previously, it has been known to use biometric interfaces such as fingerprint recognition, voice recognition, and a login interface for a driver to enter their user identification and password. However, such interfaces fail to ensure that the user who has been successfully authenticated is the actual driver during operation of the vehicle. In order to ensure that the UBI is robust, embodiments of this invention leverages unique signatures of the driver such as their body weight, mirror adjustments, and driving habit from parameters such as throttle position, brake booster pressure, hand position and grip pressure on steering wheel, or gear shifting and throttle position patterns when moving off from a stationary position in a traffic junction so that the driver may be authenticated even when the vehicle is in operation. It is appreciated that such a feature may be useful to ensure that the subsequent risk of operating the vehicle is attributed to a specific insured driver, which is important in instances where there may be a change of driver due to long distance driving, for example. In such embodiments, the DAU 1 10 may continuously receive data from sensors within the vehicle, for example, one or more load sensors in the driver seat, and one or more sensors associated with and configured to measure positions of the steering wheel, gear box, and throttle (accelerator or gas pedal), hand position and grip pressure on steering wheel, and foot pressure on brake booster. It can be appreciated that a positive association or authentication between a registered mobile phone 350 and the OBD module 100 and/or the remote server 900 may be used to identify a driver. The registered mobile phone 350 and the driver may be located in close proximity to each other and that the presence of the registered mobile phone 350 may be assumed to correspond to the presence of the driver. For example, the identification of the driver may used to differentiate among a list of drivers who may be sharing the same vehicle so the individual risk profiles may be determined according to embodiments of this invention. In certain embodiments, the DAU 1 10 may be used to determine a positive association or authentication between the registered mobile phone 350 and the OBD module 100. Referring to Figure 3, the DAU 1 10 and a registered mobile phone 350 may be configured to receive a one-time password (OTP) that may be in form of a numeric or alphanumeric sequence. The registered mobile phone 350 may be understood as the mobile phone belonging to the driver and is registered with a service provider, e.g. an insurer. The OTP may be generated in an authenticator 940 of a remote server 900, by using a code generator and a cryptographic algorithm. The same OTP may be subsequently sent to DTU 140, comprising of Multi-RAT transceiver 142, and the wireless wide area network (WWAN) transceiver 354 of registered mobile phone 350 over a WWAN 330. An example of the WWAN 330 may be a wireless network based on technologies such as GSM, UMTS, CDMA2000, WiMAX, LTE, IEEE 802.1 1 ah, and IEEE 802.1 1 af. The DTU 140 upon receiving the OTP may store it in the memory module 150 for retrieval by the DAU 1 10. The driver may retrieve the OTP from the registered mobile phone 350 and use it along with an appropriate short-range radio 352, such as Wi-Fi, Bluetooth, near field communication (NFC), and the like, to communicate with the OBD module 100.

For example, the driver may use Wi-Fi radio, configured as a station, of the registered mobile phone 350 to send a authenticate request message along with the received OTP to the Multi-RAT transceiver 142 of DTU 140, configured as the Wi-Fi access point (a.k.a. Wi-Fi interface of the DTU 140), over a communication link 360. The DAU 1 10 may then compare the received OTP from the registered mobile phone 350 with the stored OTP in memory 150. Subsequently, the Wi-Fi interface of the DTU 140 may send an authentication response message with a status value of "successful" when there is a positive match. Otherwise, an authentication response message with a status value other than "successful" may be sent. Upon successful authentication, the Wi-Fi radio of registered mobile phone 350 (station) may then send a further association request message to the Wi-Fi interface of the DTU 140 (access point). Upon successful association with the DTU 140, the registered mobile phone 350 may maintain the communication link 360 with DTU 140 for further data transfer between the registered mobile phone 350 and DTU 140 of the OBD module 100 until the registered mobile phone 350 is eventually disassociated and/or deauthenticated from the DTU 140, for example, after the completion of a trip. Alternatively, the authentication and association procedures may be automated, without driver intervention, by configuring the registered mobile phone 350 to trigger an authentication request message upon receiving the OTP, followed by an association request message to the Wi-Fi interface of the DTU 140 upon successful authentication. In some embodiments, the registered mobile phone 350 may perform the authentication procedure by transmitting the OTP automatically to the OBD module 100 when in its proximity using appropriate techniques such as NFC, radio frequency identification (RFID), and Bluetooth communication. In some embodiments, the registered mobile phone 350 may send identifiers such as its international mobile station equipment identity (IMEI) and/or medium access control (MAC) address instead of the OTP to the OBD module 100 for authentication purpose. Subsequently, the registered mobile phone 350 may then perform the association procedure using the Wi- Fi or Bluetooth communication protocol. In some embodiments, the registered mobile phone 350 may be a registered wearable monitoring device, and the authentication procedure may be performed by transmitting the MAC address of said wearable monitoring device using short-range radio 352 over communication link 360 to the OBD module 100 for comparison with the registered MAC address of said wearable monitoring device. In some other embodiments, a registered wearable monitoring device may be associated with the registered mobile phone 350 which is in turn associated with the OBD module 100 by using MAC address and/or OTP for the authentication procedures.

In certain embodiments, the OBD module 100 may contain the code generator and cryptographic algorithm that are synchronized in time or counter value with an authenticator 940, which generates the OTP using the same code generator and cryptographic algorithm, at the remote server 900. A secret key that is known between the OBD module 100 and the authenticator 940 may be pre-configured in the OBD module 100 and updated through the DTU 140, when necessary. In the former, the current time may be converted into a numeric format and combined with the secret key by using the cryptographic algorithm to generate a unique OTP. In the latter, an increasing counter value may be combined with the secret key by using the cryptographic algorithm to generate the unique OTP. In certain embodiments, token-based authentication may be used to determine a positive association or authentication between a registered mobile phone 350 and the remote server 900. More specifically, the registered mobile phone 350 may issue a request with username and password. The remote server 900 may then validate the credentials and provide a signed token back to the registered mobile phone 350. The registered mobile phone 350 may store that token and send it along with every subsequent requests to the remote server 900. The remote server 900 may then response with relevant data once the token has been verified. Such token-based authentication is stateless as the information of about the registered mobile phone 350 is not stored on the server during a session.

It is appreciated that the registered mobile phone 350 when successfully associated to the OBD module 100 is referred hereinafter as the "associated mobile phone". The associated mobile phone 350 may be used in conjunction with the OBD module 100 to determine risk profile of the driver. Similarly, the successful association of the wearable monitoring device to either the OBD module 100 or associated mobile phone 350 may be used in conjunction with the OBD module 100 and/or associated mobile phone 350 to determine the risk profile of the driver. Any unsuccessful authentication and/or association to the OBD module 100 may be recorded as an event, and such event may be taken into consideration when determining the risk profile and the related cost of insurance. For example, the associated mobile phone 350 may give insights on whether the driver is distracted by mobile phone usage when driving.

In certain embodiments, the DAU 1 10 may be configured to automatically retrieve recorded data from an onboard recording device such as a camera, voice recorder, video recorder or recordings from any audio, video and sensory devices upon the onset of an incident or accident. The retrieval process may be configured to retrieve the whole recorded data from the memory unit of the recording device or a portion of the data which may be more relevant to the incident or accident. For example, only recorded data corresponding to 5 minutes of lapsed time before and after the incident or accident may be automatically retrieved, stored in a memory module and/or transmitted via the DTU 140 to a remote server for archival purposes. It is appreciated that such duration can be set according to the preference of the driver. In certain embodiments the DAU 1 10 may be used to identify other drivers or motorists whose driving behaviors may pose a risk to the driver of the vehicle having OBD module 100 installed, and/or who may pose a risk to other road users. For example, the DAU 1 10 may be configured to capture images or video recordings of other drivers or motorists who abruptly steered their vehicle into the lane of the driver associated with OBD module 100 or another driver, store the captured data in a memory module 150 and/or upload to a remote server for archival purposes. In some embodiments, the DAU 1 10 may be configured to identify and store the registration number of the risk- generating vehicle or any other identifiers such as VI N which may comprise chassis and engine numbers via the DTU 140 which may be used to identify the driver of the risk-generating vehicle subsequently.

In the above embodiments, the DAU 1 10 may be configured to start and stop the data acquisition process based on the vehicle ignition status, vehicle speed, door position history, vehicle position history, or a combination of these parameters.

Data Processing Unit (DPU) 120

Statistical inference concerns learning from experience, i.e. we observe a random sample x = (x_l7x₂, ...,x_n ) and wish to infer properties of the complete distribution

X = (X₁,X₂, ...,X_n ) from which the sample is yielded. On the other hand, probability theory does exactly the opposite to deduce the properties of a random sample x , and of statistics calculated from x , from the composition of a population X . The DPU 120 makes use of each of these principles to quantify risk factors and any sub-risk factors, which consist of status data derived from a plurality of environment, vehicle, and physiological parameters, in probabilities corresponding to the respective risk factors and any sub-risk factors, in a process 400 as illustrated in Figure 4.

The DPU 120, as depicted in Figure 4, first determines at block 410 whether the detected COI 300 relates to a static or dynamic parameter. Static parameters may be characterized by their values which vary on a longer timescale, and are typically independent of traffic conditions, e.g. time of day, type of road, speed limit, turn signal, wiper switch, horn, high beam, mobile phone activities, such as texting and talking, sleep quality, etc. On the other hand, dynamic parameters may be characterized by their values which vary on a shorter timescale, typically much shorter than a driving session, and are dependent on prevailing traffic conditions, e.g. vehicle speed, acceleration, deceleration, angular velocity, throttle position, geolocation, etc.

For example, if the detected COI relates to static parameters such as activation of turn signal during lane change or usage of mobile phone while driving, the DPU 120 may perform measurement of data such as occurrence(s) of activating turn signal and detecting mobile phone usage, respectively (block 420). The DPU 120 then utilizes probability theory to determine, from the measured data, updated probabilities for one or more risk factors and any sub-risk factors (block 450). More specifically, the probability of an event, a risk factor or sub-risk factor is the proportion of times it occurs over a predefined observation time.

Thus, for example, a driver may have a previously calculated probability for the risk factor "does not indicate when changing lanes", the previously calculated probability being based on a particular time window T . During a subsequent trip, the DPU 120, when the lane change COI is detected, increments a counter for the number of times that the driver changes lanes and a counter for the number of times that the driver simultaneously activates the turn signal. The DPU 120 then calculates an updated probability based on the most recent {T - t) hours of data from the previously recorded window and the t hours of data from the current trip.

On the other hand, if the detected COI 300 relates to dynamic parameters such as vehicle speed, acceleration/deceleration, angular velocity, geolocation, throttle position, brake booster pressure, the DPU 120 focuses on using statistical inference techniques to estimate the PDF of an observed or measured random variable or sample (e.g. vehicle speed). First, a sampling distribution is computed for each dynamic parameter (block 430). Next, a posterior distribution is computed based on the sampling distribution (block 435). The DPU 120 may also, when appropriate, perform retrieval of thresholds (block 440) from the DAU 1 10, corresponding to the dynamic parameters, such as speed limits, acceleration/deceleration thresholds, and angular velocity thresholds, to quantify risk factors and any sub-risk factors in terms of updated probabilities (block 450). In certain embodiments, these thresholds may be updated automatically according to weather conditions (e.g rain, storm, and snow) which may result in low visibility and slippery roads. The weather conditions may be determined from weather forecast obtained via remote server 900, predicted by the atmospheric sensing module 165 of OBD module 100, or a combination of both weather forecast and prediction by the atmospheric sensing module 165 which may be disseminated by the remote server 900.

Although vehicle speed is used an example for illustration, the statistical inference techniques may be applied to other random variables such as those obtained from environment data 210, physiological data 220, and vehicle data 230. In some embodiments, a random sample may be acquired by using simple random sampling, systematic sampling, stratified sampling, bootstrap method, and the like while parameter estimation may be derived based on maximum-likelihood estimation or Bayesian parameter estimation.

Bootstrap Method

In one preferred embodiment, the bootstrap method is used at block 430. The bootstrap is a computer-based, non-parametric approach in which no assumptions are made on the underlying population where the samples are acquired. In one example, the bootstrap is used to infer the average vehicle speed denoted as Θ from the measured vehicle speed which constitutes the unknown distribution F . The measured vehicle speed is assumed as i.i.d. during the short data acquisition phase as an approximation to the actual conditions. The bootstrap method for the one-sample case can then be described by the following procedure as shown in Figure 5. Step 1 : Obtain the original data set X = (x_l7x₂, ...,x_n) from unknown distribution F through online data acquisition (by DAU 1 10) to form the discrete empirical distribution F by assigning a probability mass of 1/n on each x then perform offline bootstrap processing (at DPU 120) from step 2 through 5.

Step 2: Obtain the smooth bootstrap data set Y^* = (y ,y₂ ^*, ...,y_n ^* ) , each of n data values, from the smoothed empirical distribution F_s by sampling with replacement and adding a small amount of random noise to each bootstrap data set X^* = Step 3: Calculate the bootstrap replicates 6_b ^* by computing the sample median for each corresponding bootstrap samples obtained in step 2.

Step 4: Repeat step 2 through 3 B times. Step 5: Use the distribution of B bootstrap replicates Θ^* as parameter estimates to the distribution of Θ .

Accordingly, B bootstrap replicates provide an estimate of the Θ distribution, which is the bootstrap estimates of the average vehicle speed, and its standard deviation is the bootstrap estimates of standard error for Θ . The number of bootstrap replicates may be in the range from 50 to 200.

In general, the bootstrap method provides an attractive means to derive real-time computation of risk profiles based on a relatively small number of samples, e.g. n = 10 , which is insufficient to be considered as a large sample size (where « > 30 ) with respect to Central Limit Theorem (CLT). In addition, CLT holds for sample mean, but not for sample median which may be a more robust estimator of average values for any density functions, in particular, heavy-tailed distributions. It is important to note that the distribution of bootstrap replicates can be shown to exhibit asymptotic normality as a result of employing smooth bootstrap in which F_s is continuous. This asymptotic normality property can be used to simplify the subsequent Bayesian parameter estimation.

Recursive Bayesian Estimation

In another preferred embodiment (in block 435 of Figure 4), the bootstrap estimates of average vehicle speed are used to build a posterior distribution by applying Bayes' rule recursively as p{s_k I y_k) ^α p{y_k i

I Λ_Ι ) (1 ) where

Q_k = bootstrap estimates of average vehicle speed at time k ,

y_k = a new observation of bootstrap estimates of average vehicle speed at time k , p(d_k \ y_k__l) = prior distribution before y_k is observed,

p(d_k \ y_k^j = posterior distribution after y_k is observed,

p(y_k \ 0_k, y_k_^j = likelihood function.

Since the measured vehicle speed is assumed to be i.i.d. , the bootstrap estimates also be independent and the likelihood function can be simplified to p(y_k \ 6_k .

Moreover, further simplification can be derived through the use of conjugate prior distribution since the likelihood function data comprising of the bootstrap estimates are normally distributed and that the estimation is performed recursively.

Further, 6_k \s parameterized as , and it is assumed that the sampling variance of observation y_k , which corresponds to the squared of the bootstrap estimates of standard error, is constant. Without loss of generality, the posterior distribution that is the Bayes estimate of the average vehicle speed can be expressed as

where At = (½-i ²-i + yJo¹ )/( + ι/σ² ) ,

It is important to note that the above closed-form expression is a merit of bootstrap method which ensures that bootstrap estimates are normally distributed. One may understand the above as updating of belief (prior) 610 to reflect an improved knowledge of the prevailing average vehicle speed (posterior) 614 by acquiring new information in the form of bootstrap estimates (measurement) 612 as illustrated in Figure 6(a).

According to some embodiments, the Bayes estimate of average vehicle speed, i.e. Y_k = p^_k \ o², y_k^j may be quantified in terms of a probability of driving above speed limit by calculating its cumulative distribution function (CDF) with respect to a speed limit threshold, i.e. P(Y_k≤x^j as

F_Yt (x) = <t>[(x - fi_k)/a_k] (3) where

(χ) = CDF of a standard normal distribution.

In some embodiments, referring to Figure 6(b), the speed thresholds 650 may be obtained from a digital map 655 with geocoded speed limit, an image recognition algorithm 665 of the DAU 1 10, an appropriate speed limit according to weather conditions 670, and/or a lower speed limit as determined by the flow of traffic 660, particularly, when traffic is heavy. The information concerning weather conditions and flow of the traffic may be disseminated by the remote server 900, and subsequently received by the DTU 140 of OBD module 100 and/or associated mobile phone 350. The usage of a lower speed limit according to the weather conditions and flow of prevailing traffic is useful for comparing the speed of the concerned driver with the "norm" or average speed derived from a plurality of drivers. It can be appreciated that the appropriate speed limits obtained from blocks 660 and/or 670 may be an adjusted effective vehicle operating thresholds for a given geolocation area. Figure 7 illustrates a driving route from an origin to a destination in which a vehicle operated by the insured driver is traveling. It also depicts the speed limits in different segments of the road derived and/or detected according to the DAU 1 10. The PDF of the average vehicle speed as derived from the Bayes estimate may be quantified in terms of probability of driving above the different speed limits as disclosed above while the vehicle is traveling in a real-time manner. More specifically, the PDF represents the relative likelihood of a given average vehicle speed, the variance of the PDF represents the degree of uncertainty, and the integral of the PDF over a particular range of values or area under the curve over that range represents the probability of the average vehicle speed over the said range. Hence, it may be understood by visual inspection that the car has likely been speeding in segment A and likely to be driving within the speed limit in segment C, for example. Similarly it may be understood that the car has likely been traveling with the slowest speed in segment B given the lowest speed limit, but with a high variability of speed values which may be due to the terrain of the road.

Conditional probability

In some embodiments, the concept of conditional probabilities may be used to quantify the occurrence of at least 2 events. For example the tendency of using turn signal (event A) when turning or changing lane (event B) may be determined by the probability that two events A and B occur given by the multiplication rule as

P(A (1 B) = P(A I B).P(B) = P(B I A).P(A) . (4) For example, the joint probability of activating turn signal (event A) and vehicle is turning or changing lane (event B), denoted Ρ(Α Πβ) , may be computed by the conditional probability of activating turn signal given that the vehicle is turning or changing lane denoted by P (A \ B^ multiplied by the marginal probability that the vehicle is turning or changing lane denoted by P(B) . Accordingly, P(A l fi) and P(B^) may be obtained from the DPU 120 by measuring the number of their occurrences over a predefined observation period, e.g. a trip duration, 24-hour period, and a specific driving history, e.g. the last 30 days. In both cases, the conditional and marginal probabilities may be updated by using a moving average estimation, such as an exponentially weighted moving average (EWMA) estimation as ^ak ⁼ Wk + ( - fy^ak-i for £ = 1,2, ..., w (5) where a_k is the updated probability, ¾ is the observed probability at time k , n is the number of observations to be monitored, and λ is a geometric decay factor in the interval [0, 1] that determines the rate at which historical data influences the updated probability. A small value of λ gives more weight to historical data, and a large value of λ gives more weight to recent observations. The default values for the conditional probability and marginal probability may be zero or based on prior values from historical data concerning a specific driver.

In some embodiments, it is first determined whether event A and event B are independent events. For example, receiving an incoming call while driving may be understood as independent events. In other words, the tendency of receiving an incoming call while driving may be determined by the probability of two independent events A and B as P(A (1 B) = P(A).P(B) where P(A I B) = P(A) and P(B I A) = P(B) . (6)

However, the action of answering the incoming call while driving may be viewed as a distraction and the probability of which may be determined by considering then as dependent events as discussed earlier. Suppose answering a call is denoted as event A and driving a vehicle is denoted as event B. In this case, the joint probability F(AnS) of answering a call and when driving may be computed by multiplying the conditional probability Ρ(Α Ι β) with the marginal probability P(B) . Hence, the DPU

120 may measure the occurrences of answering a call over a predefined observation period (e.g. trip duration, 24 hour-period and last 30 days) when vehicle speed is above a speed threshold, e.g. 20 km/h to arrive at Ρ(Α Ι β) , and the frequency of driving above the same speed threshold over the same observation period to arrive at P(B^) . Similarly, the conditional and marginal probabilities may be updated by using a moving average, for example, by using the EWMA estimation.

As another example, the tendency of using mobile phone (e.g. texting, placing a call, and web browsing) while driving may be dependent on the speed of vehicle (event A), one (right) hand on steering wheel (event B), and the other (left) hand interacting with the phone (event C) may be determined by the probability that three events A, B and C all occur by extending the multiplication rule as P(AnBnC) = P[(A(lB)nc] = P(C\ AnB).P(AnB) (7) since P(A(1B) = P(B\ A).P(A) .

Therefore, P(AilBnC) = P(C\ A(1B).P(B\ A).P(A) . Similarly, the probabilities of these events may be obtained from their occurrences as previously described.

Following the above example, it is possible to determine the probability of at least two concurrent events, comprising of at least one COI such as those given in Table 1, by generalizing the multiplication rule for any event A₁,A₂,...,A_N as

Ρ(Α_Ι ΠΑ₂ Π...ΠΑ_Η) =

P( ).P(A I AHA I A n 4)· · - A Ι4^η4^η···^η4-ι)- (β)

In some embodiments, the tendency of causing distractions to driver (event A) arising from the usage of mobile phone under hypotheses H_L may be derived by using the law of total probability as

P(A) = P(A I H_I ).P(H₁ ) + ... + P(A\H_L ).P(H₁ ) for i = 1,2, .. (9) provided that the hypotheses form partitions of a sample space which are mutually exclusive, and their union is the sample space. The hypotheses may comprise of texting while driving, talking while driving, and usage while stationary, for example. It is obvious that the marginal probability P(A is the weighted average of the conditional probabilities P(A \ H_i) with weights P(H_t) .

According to certain embodiments, usage of the associated mobile phone 350 while driving may be detected (for example, by ClU 1 12) based on the knowledge of whether the driver is right or left hand dominant, a signal derived from the built-in accelerometer of the associated mobile phone 350, and the prevailing vehicle speed. This may be understood from the fact that the raw accelerometer values may differ distinctly when the mobile phone is being held by either a left or right hand for the same action, such as answering a call, for example. Further, it may be reasonable to assume that the driver is likely to use the dominant hand for controlling the steering wheel and, in this case, surely to use the non-dominant hand in attempt to use the associated mobile phone 350 when driving. In some embodiments, the detection of usage of the associated mobile phone 350 while driving may depend on: (i) whether the keypad and/or audio inputs have been received; (ii) whether the ambient light sensor has detected a sharp reduction of illuminance, measured in Lux; (iii) whether the phone is used with a single hand or both hands which may be detected by the speed of text inputs, touchscreen, accelerometer, and/or capacitive sensors along both sides of the associated mobile phone; (iv) whether the scrolling actions or text inputs are performed by left thumb, right thumb or index fingers which may be detected by using gyroscope and touchscreen to detect different grip styles. It may also be possible to infer whether the scrolling action or text inputs are made from either thumb by estimating the functional area of the thumb that is naturally constrained by the placement of fingers behind the phone; (v) whether the vehicle has other passengers which may be detected using load sensors beneath each seat; and (vi) whether the associated mobile phone is held closely to the steering wheel which may be detected by proximity sensing techniques where RFID or NFC tags may be embedded in the steering wheel; or with a combination of (i) to (vi) while the vehicle is traveling above a lower speed threshold, e.g. 20 km/h.

In some embodiments, some functionalities of the associated mobile phone 350 may be recalibrated, disabled, or enabled upon detecting the usage of the said mobile phone while driving. For example, the detection of keypad inputs while driving may suggest that the driver is texting or surfing, which is extremely dangerous, and the associated mobile phone 350 may be configured to rescale or reposition the keypad to incapacitate the ability to text. In another example, the associated mobile phone 350 may also be configured to enable the flight mode function or disable the speaker and/or audio functions when the vehicle is traveling above a higher speed threshold, e.g. 70 km/h. In such circumstances, the mobile phone may additionally configure to respond to a caller or sender an automatic text response such as "I'm driving at the moment."

Driver Feedback Unit (DFU) 130

In some embodiments, the DFU 130 may be used to communicate risk profiles to a driver so as to provide an opportunity for them to alter their driving patterns in a timely manner. The risk profiles may be communicated to the driver through display units such as LCD or LED screen, display screen of mobile phone such as thin-film transistor (TFT)-LCD or active-matrix organic light-emitting diode (AMOLED), LED indicator, head-up display (HUD), audible tones or playback message generated from speaker units found in mobile phone or car audio or infotainment systems, as well as other sensory feedback such as vibration signals from wearable monitoring devices such as FitBit™, Jawbone™, Nike Fuelband™, Basis™, Airo™, Google Glass™, and the like. The DFU 130 may receive the real-time risk score from CPU 105 via I/O interface 170 using a wired connection or Multi-RAT transceiver 142 of DTU 140 using wireless local area connectivity such as Wi-Fi (e.g. 802.1 1 a, 802.1 1 b, 802.1 1 e, 802.1 1 g, 802.1 1 η, 802.1 1 ac), Wi-Fi Direct, or Bluetooth (e.g. Bluetooth 2.1 , Bluetooth 3.0, Bluetooth 4.0 or Bluetooth low energy (BLE)). As illustrated in Figure 8, the risk profiles may comprise of a real-time risk 810 of the driver for prevailing trip, and a cumulative risk 820 of the driver since the usage of OBD module or apparatus 100. In some embodiments, the ranking of the driver 830 as compared to other drivers, in terms of their risk profiles, using the same OBD module or apparatus 100, and the estimated cost of insurance 840 derived based on the risk profile may be displayed together with the real-time risk score 810 and cumulative risk score 820. It is envisioned that the knowledge of one's risk profile (real-time and cumulative), ranking of one's risk profile in comparison with others, and the estimated cost of insurance may provide strong motivations for drivers to steer their driving behavior towards the ideal safety conscious state through realization, gamification or incentivization. Particularly, the knowledge of one's real-time risk profile provides an opportunity for the driver to perform corrective actions in a timely manner and may result in the reduction of accident rates. Advantageously, embodiments of the present invention provide a real-time risk profile and cumulative risk profile which are a normalized metric ranging from 0 to 1 , or alternatively, 0 to 100 that summarizes the major risk factors of the driver in the prevailing trip and since inception, respectively. Such metric will be easier for drivers to comprehend without creating distractions to review and appreciate the notable driving events. In addition, this invention seeks to provide feedback to the driver in a least distracted manner, such as through vibration signals of wearable monitoring devices and message notification when predetermined thresholds are exceeded, so that driver is aware of the risk, but yet not distracted by interacting with display screens. Data Transfer Unit (DTU) 140

The primary role of the DTU 140 is to manage the communications of information: (i) between the OBD module 100 and peripheral devices 910 within a vehicle; (ii) between the OBD 100 and a remote server 900; and (iii) between two or among more OBD modules 100.

The DTU 140, as shown in Figure 9(a), comprises a Multi-RAT transceiver 142 that may consist of a WWAN interface (e.g. GSM, UMTS, CDMA2000, WiMAX, and LTE), a wireless local area network (WLAN) interface (e.g. 802.1 1 a, 802.1 1 b, 802.1 1 e, 802.1 1 g, 802.1 1 i, 802.1 1 η, 802.1 1 ac, 802.1 1 ad, 802.1 1 ai, 802.1 1 ah, and 802.1 1 p) capable of supporting Wi-Fi Direct, extensible authentication protocol (EAP) found in Wi-Fi protected access (WPA), WPA2 and their variants, as well as Wi-Fi protected setup (WPS), and advanced encryption standard (AES)-based encryption protocol such as counter cipher mode with block chaining message authentication code protocol (CCMP), for example, a White-Fi or Super Wi-Fi interface (e.g. 802.1 1 af and Weightless), a Bluetooth interface (e.g. Bluetooth 2.1 , Bluetooth 3.0, and Bluetooth 4.0 or BLE) capable of supporting serial port profile (SPP), health device profile (HDP), health device profile low energy (HDPLE), ISO/IEEE 1 1073 and the like, a proximity communication interface (e.g. NFC and RFID), and/or 802.15.4-based interface for communication with ZigBee devices. It is noted that ISO/IEEE 1 1073 Medical/Health Device Communication Standards addresses the interoperability of medical devices to exchange and evaluate vital signs data between different medical, health, and wellness devices. One key aspect of the DTU 140 is that it may be used to maintain at least one communication path between the vehicle, by means of the Multi-RAT transceiver 142 of OBD module 100 and/or the WWAN transceiver 354 of associated mobile phone 350, and the remote server 900 for the purpose of transferring context information, specifically, uplink context information 2022 and downlink context information 2040 during the operation of the vehicle. Note that the remote server 900 includes network connectivity devices 392 as illustrated in Figure 9(b). In a non-limiting example, the DTU 140 may, based on the measured received signal strength (RSS) from pilot or beacon signal, determine: (i) an estimated path loss, and an appropriate transmit power within the regulatory limits; and (ii) an appropriate modulation and coding scheme (MCS) based on either a signal-to-noise ratio (SNR) or explicit/implicit messages from the intended receiver; or a combination of (i) and (ii) so that its uplink transmissions may be received at the remote server 900 with high reliability or lowest latency depending on estimated link conditions and quality of service (QoS) requirements of the data to be transmitted.

For example, upon receiving a valid pilot or beacon signal from an access point or a base station of a given radio access technology, the DTU 140 may estimate the path loss between itself and the access point or base station that has transmitted the pilot or beacon signal as

L_path (dB) = (10)

where

L _path = path loss in dB, p_t = transmit power of the pilot or beacon signal in watts,

p_r = receive power of the pilot or beacon signal in watts. Alternatively, if the distance between the access point or base station and the DTU 140 is known by performing a timing advance procedure, for example, then the path loss may be estimated as

L_path(dB) = (1 1)

where

λ = wavelength associated with the carrier frequency,

d = distance between the access point or base station and DTU 140,

n = path loss exponent that may be varied by the DTU 140 according to the surrounding topographical environment, e.g. n = 2 for rural areas and n = 4 for urban areas.

Subsequently, the DTU 140 may adjust the transmit power of subsequent uplink messages so that it can be received by the remote server 900 with high reliability by selecting a transmit power based on the estimated path loss plus a certain SNR as

P = min P max ,'L pat _th_h + SNR req + C (12) where

C = SNR_req - SNR ,

P_t = transmit power of subsequent uplink messages by DTU 140 in dBm,

P = maximum transmit power according to regulatory limits,

SNR req = req ¹uired SNR in dB, '

SNR= prevailing (measured or estimated) SNR in dB.

The selection of an appropriate MCS is typically based on the achievable SNR that determines a corresponding data rate for a desired bit error rate (BER) or packet error rate (PER). For example, a link adaptation procedure may be used to select the optimal MCS according to the prevailing SNR, based on the BER/PER vs. SNR information, to maintain a desired BER or PER. The link adaption procedure may also use explicit or implicit messages such as negative or missed acknowledgements from the intended receiver to select the optimal MCS.

An exemplary process 1000 for maintaining a communication path is shown in Figure 10. At block 1010 the DTU 140 obtains the RSS values from the plurality of interfaces of Multi-RAT transceiver 142. Next, at block 1020, the DTU 140 determines whether any of the measured RSS values is greater than the RSS threshold. The RSS threshold or receiver sensitivity may be determined by first calculating the noise floor N = KTB for the bandwidth of interest in dBm where K is the Boltzmann constant of 1.38x l0^-23 , T is the temperature in Kelvin, and B is the bandwidth in Hertz, and subsequently adding a noise figure of the receiver which typically ranges from 8 to 10 dB, a fade margin of typically 9 dB, and a minimum SNR in dB that corresponds to a particular MCS. Note that the required SNR may be understood as the minimum SNR plus the fade margin. For example, a transmission with a higher order MCS, e.g. 16- QAM may require the SNR of 25 dB at the receiver in order for it to decode the message correctly. Conversely, a transmission with a lower order MCS, e.g. QPSK may only require the SNR of 15 dB at the receiver in order for it to decode the message correctly. If not, the process 1000 loops back to block 1010. If at least one value meets the threshold, DTU 140 selects, from each interface passing the threshold, the interface which exceeds the threshold by the greatest amount (block 1030).

Based on the selected interface, the DTU 140 then determines the optimal transmit power and/or modulation and coding scheme based on the estimated link conditions (e.g. path loss, SNR, and feedback messages from an intended receiver) and QoS requirements (e.g. low latency achievable with high data rate and high reliability achievable with low packet loss rate). Next, at block 1040, the DTU 140 determines whether a prevailing SNR, which may be the measured SNR or estimated SNR, is available. If the prevailing SNR is not available, the DTU 140 may calculate the transmit power according to expression (12) by using a default value of 15 dB for the required SNR, for example, and clearing C to zero (block 1080). Otherwise, the prevailing SNR is available and the DTU may check (block 1050) if C, which is the difference between required SNR and prevailing SNR, is more than zero. When C > 0, it implies that the link condition is "poor" as the prevailing SNR is lower than the required SNR. The DTU 140 may increase the transmit power correspondingly to maintain the required SNR, and/or transmit with a lower order MCS to maintain a target BER (block 1060). Otherwise, when C≤ 0, the link condition is perceived as "good", and the DTU 140 may reduce the transmit power correspondingly to reduce power consumption and minimize interference to others, and/or transmit with a higher order MCS to increase data rate for a given BER (block 1070).

In some embodiments, when the associated mobile phone 350 is detected, the DTU 140 may be configured to consider the communication paths available via the said mobile phone in conjunction with the process 1000. More specifically, the measured RSS from the WWAN transceiver 354 of associated mobile phone 350 may be transmitted to OBD module 100 via short-range communication link 360 as previously described, and made available at block 1010 for evaluation. In some other embodiments, the DTU 140 may be configured to transmit uplink context information 2022 to remote server 900 via the associated mobile phone 350, without invoking process 1000. It is also obvious that the process 1000 may be implemented in the registered mobile phone 350 when the OBD module 100 is not available. In some embodiments, the DTU 140 and associated mobile phone 350 may be configured to transmit the same or complementary uplink context information 2022 to the remote server 900.

For downlink transmissions, the DTU 140 may be configured to receive downlink context information 2040 from the remote server 900 when the associated mobile phone 350 is not detected. Otherwise, the associated mobile phone 350 may be configured by default to receive downlink context information 2040 from the remote server. In some embodiments, the DTU 140 and associated mobile phone 350 may be configured to receive the same or complementary downlink context information 2040 from the remote server 900.

In some embodiments, the DTU 140 may function as an access point or aggregator to provide local connectivity to peripheral devices 910, as illustrated in Figure 1 1. It is appreciated that peripherals 910 such as sensors and wearable monitoring devices are typically equipped with low-power, local area connectivity such as Bluetooth, ZigBee or Wi-Fi. Hence, the access point or aggregator will be able to facilitate the communication of information (acquired data) 1 1 10 from these peripherals 910 to the remote server 900 by providing the backhaul connectivity that may be through the WWAN 330 which may be a wireless network based on technologies such as GSM, UMTS, CDMA2000, WiMAX, LTE, IEEE 802.1 1 ah, and IEEE 802.1 1 af, for example. Such backhaul connectivity may be used to channel health and wellness information from wearable monitoring device of the driver together with useful information obtained from the DAU 1 10 and DPU 120, such as vehicle data, traffic conditions, and weather conditions, back to the remote server 900. In some embodiments, it may possible for the remote server 900 to disseminate information (commands) 1 120 to peripherals 910 which may contain an actuator to cause an actuation. Alternatively, the registered mobile phone 350 may function as the access point or aggregator to provide connectivity with peripheral devices 910 in absence of the OBD module 100.

According to certain embodiments, the DTU 140 may function as a Wi-Fi access point or station to enable the detection of willingness to give way between the driver A and another driver B under at least one COI as shown in Table 1. For example, as shown in Figure 12, the DTU 1210 of driver A may trigger an active scanning or handshaking procedure 1200 to transmit a probe request message 1212 containing data indicating the intention of the driver A to change lane (e.g. activation of turn signal), geolocation of driver A's vehicle, and the maximum relative distance requirement between car position of driver A and car position of responder. In addition, the service set identifier (SSID) element in the probe request message is the wildcard SSID, basic service set identification (BSSID) field in the probe request message is the wildcard BSSID, and the destination address (DA) field in the probe request message is the broadcast address. The other concerned vehicle with the same type of OBD module 100, i.e. DTU 1220 of driver B, upon detecting the wildcard SSID, wildcard BSSID, and broadcast address in probe request message 1212, may respond with a probe response message 1214 containing information such as the vehicle registration number or VIN, speed, acceleration, deceleration, left turn signal, right turn signal, throttle position, brake switch signal, horn status, high beam switch signal back to the DTU 1210 of driver A upon, additionally, satisfying the maximum relative distance requirement. It is possible that the DTU 1230 of driver C or other drivers within the vicinity may also receive the probe request message 1222 from DTU 1210 of driver A. However, the DTU 1230 of driver C or other drivers may not respond with a probe response message as the relative distance between the car of driver A and driver C or other drivers may exceed the maximum distance requirement that was transmitted as part of the probe request message 1212. This simple two-way handshake, which may occur in a predefined in-band or out-of-band channel disseminated by the remote server 900, for example, allows the determination of whether the other concerned driver B has the intention to slow down or accelerate given that driver B is aware that driver A is trying to perform a lane change. Such information may be stored in a memory module 150 and/or upload to the remote server 900 for processing and archival purposes.

Figure 13 shows the structure of an information element 1300 to be included in the probe request message (1212 and 1222) for implementing the willingness to give way concept. The information element 1300 contains an ID field for identifying the information element. The length field is for indicating the length of the information element 1300 and may be set to either 13 or 21 octets, depending on the number of fields that are included in the information element 1300.

The Intent field is 1 octet in length, and represents the context for triggering the handshaking procedure. The encoding of the Intent field is specified below.

The X field contains the X-coordinate that has a 4-octet single precision floating point value. The Y field contains the Y-coordinate that has a 4-octet single precision floating point value.

The Maximum Relative Distance field has a 4-octet single precision floating point value that specifies the maximum relative distance between the requesting station and the responding access point which may be referred to as the requesting DTU 1210 of the driver who intends to perform a lane change and the other responding DTU (1220 and 1230) of another driver, respectively. This serves as a criterion to restrict the responding access point to within the specified distance.

The Z and Radius fields are optional. Each of the Z field and Radius field contains a 4- octet single precision floating point value. The additional Z field contains the Z- coordinate to form a 3-dimension location value of requesting DTU 1210 geolocation. The additional Radius field forms the circle location value of requesting DTU 1210 geolocation. The additional Z-coordinate and Radius fields form the sphere location value of requesting DTU 1210 geolocation.

Upon receiving the probe request message 1212 with the geolocation of the requesting DTU 1210, the responding DTU / (1220 and 1230) may calculate their relative distance to the requesting DTU 1210 by using, for example, the below expressions:

The top expression in Eq. (13) may be used to find the distance between two points in a 2-D plane and the bottom expression may be used to find the distance between two points in a 3-D space. Note that the above expression is based on the Cartesian coordinates. Similar computation can be carried out for Geodetic coordinates such as WGS-84. Figure 14(a) shows an information element 1400 to be included in the probe response message 1214 for implementing the willingness to give way concept. The information element 1400 contains the ID field for identifying the information element 1400. The length field is for indicating the length of the information element 1400 and may be set to 29 octets. The VI N field contains a 20-octet ASCII-coded value that may be left-padded with null characters. It is defined in ISO 3779 or the like and is a unique 17-character code used by the automotive industry to identify motor vehicles. The Speed field contains a 4-octet single precision floating point value that records the prevailing speed (m/s, km/h, or mi/h) of the vehicle in which the responding DTU 1220 is within the specified maximum relative distance of the requesting DTU 1210.

The Acceleration/Deceleration field contains a 4-octet single precision floating point value that records the prevailing acceleration or deceleration (m/s²) of the vehicle in which the responding DTU 1220 is within the specified maximum relative distance of the requesting DTU 1210. It is noted that deceleration may be interpreted as negative acceleration. The Status field is 1 octet in length, and is encoded as LT: left turn signal, RT: right turn signal, TR: throttle position, BR: brake switch signal, HO: Horn status, and HB: high beam switch signal. Each bit when set to "1 " indicates a positive action or trigger, and when cleared to "0" indicates no action or trigger. One exception is that the TR bit is set when the change in throttle position has a positive value and cleared to "0" when it has a negative value. The remaining 2 bits (marked 'X') are reserved for future use.

In some embodiments, the Multi-RAT transceiver 142 of DTU 140, configured as the Wi-Fi access point (a.k.a. Wi-Fi interface of the DTU 140) may be configured to operate in an infrastructure mode or operate with peer-to-peer communication by using an ad- hoc mode or Wi-Fi Direct to transmit the risk profile of the driver who is operating the vehicle to other drivers using a broadcast message such as a beacon message. It is appreciated that the transmission of risk profile from a source OBD module 100 to other like OBD modules 100 as described above may serve to highlight risk of new, young, elderly, handicapped, or reckless drivers to other road users, for example. It is noted that such information is conventionally communicated through the display of appropriate plates such as a provisional or probationary license plate.

Figure 14(b) shows an information element 1450 to be included in the broadcast message for implementing the broadcast of risk profile and give way message. The information element 1450 contains the ID field for identifying the information element 1450. The length field is for indicating the length of the information element 1450 and may be set to either 2 or 3 octets, depending on the number of fields that are included in the information element 1450.

The Cumulative Risk Profile field is 1 octet in length, and is defined as the cumulative driving risk, normalized to 255, exhibited by the driver who is operating the vehicle with the installed OBD module 100 and/or associated mobile phone 350. In other words, the value of the Cumulative Risk Profile field is obtained by multiplying the computed cumulative R-Score with the interval [0,1 ] by 255.

The Give Way field is 1 octet in length, and is encoded as EV: emergency vehicle, VP: vulnerable passenger(s) on board, PD: provisional or probationary driver, HD: handicapped driver, and ED: elderly driver. Each bit when set to "1" indicates the context for the give way message, and when all bits are cleared to "0" indicate that give way action is not required. The remaining 3 bits (marked 'X') are reserved for future use.

The Real-Time Risk Profile field is optional, and is 1 octet in length. It is defined as the real-time driving risk, normalized to 255, exhibited by the driver who is operating the vehicle with the installed OBD module 100 and/or associated mobile phone 350. In other words, the value of the Real-Time Risk Profile field is obtained by multiplying the computed real-time R-Score with the interval [0, 1] by 255. The information element 1450 may also be appended to probe response message, authentication response message, or association response message to communicate the risk profile and give way message.

For example, as illustrated in Figure 15(a), a first vehicle 1510 has a first DTU 1512, a second vehicle 1520 has a second DTU 1522, and a third vehicle 1530 has a third DTU 1532. The vehicles 1510 and 1530 may broadcast their risk profiles by appending information element 1450 in the broadcast message. In this case, the vehicle 1520 may receive the risk profiles of drivers of vehicles 1510 and 1530, which are dependent on the transmission power of DTU 1512 and DTU 1532 as denoted by coverage radius 1514 and coverage radius 1534, respectively, as well as the receiver sensitivity of the DTU 1522 that is not shown.

It is also appreciated that emergency vehicles (e.g. ambulance, fire engines, and law enforcement) or vehicles with baby and elderly onboard may also transmit a broadcast message using information element 1450 from the requesting DTU which may be decoded by other responding DTUs as described earlier as a give way message and the driver will be prompted to give way. For example, the give way message may be projected to the usual driver's viewpoint using a HUD, directed into the eye of a Google Glass wearer, or may be effected in the form of an audible output and/or vibration signal from a wearable monitoring device to minimize distractions to the driver. In some embodiments, the willingness to give way in such situations may also be determined according to the handshaking procedure as described earlier given that events such as lane change has occurred. The proposed new information elements 1300 and 1400 related to the handshaking procedure may also be implemented as part of the generic advertisement service (GAS) protocol as defined in IEEE 802.1 1 u by using the initial request and initial response messages, protocol for transmission of data messages outside the context of a BSS as defined in IEEE 802.1 1 p to enable fast communication exchanges between mobile stations (or DTUs in the context of the presently described embodiments), as well as fast initial link setup protocol as defined by IEEE 802.1 1 ai and Wi-Fi Direct protocol as specified in Wi-Fi Alliance; both by using the same probe request message (1212 and 1222) and probe response message 1214. The proposed new information element 1450 may be implemented as part of the beacon message of all IEEE 802.1 1 amendments.

In some other embodiments, as shown in Figure 15(b), the Wi-Fi interface of the DTU 1562 of an affected vehicle 1550 may be configured for peer-to-peer communication by using an ad-hoc mode, Wi-Fi Direct, or protocol for transmission of data messages outside the context of a BSS as defined in IEEE 802.1 1 p to retrieve still images or stream 'live' video feed from onboard camera of other vehicle 1570, which may be obstructing the view of the driver in the affected vehicle 1550, to the DFU 1564 of the affected vehicle 1550. The external camera 1554 may be connected directly to the DAU (1566 and 1586) using a wired connection or wireless connection via multi-RAT transceiver 1562 of the OBD module 1560. Alternatively, the external camera 1574 may be connected with the associated mobile phone 1572. In this case, the associated mobile phone 1572 may function as a Wi-Fi access point to relay data from external camera 1574 to the multi-RAT transceiver 1582. The driver of the affected vehicle 1550 may use the handshake procedure as described earlier to request for a footage such as still image or 'live' video feed from the other vehicle 1570 by setting the Intent field of the information element 1300 to a value of 5 or 6, respectively. The DTU 1582 of the other vehicle upon receiving the probe request message may response with a standard probe response message containing at least the SSID so that the DTU 1562 of the affected vehicle may subsequently authenticate and/or associate with the DTU 1582 of the other vehicle, and receive a further data message from the DTU 1582 of the other vehicle containing the requested footage. The maximum frame body size of the MAC frame is determined by the maximum MAC service data unit (MSDU) size of 2304 octets plus any overhead from security encapsulation of typically 20 octets. The maximum MSDU size of 2304 octets is large enough to accommodate high quality video compression formats such as MPEG-4 or H.264. As a result of the requested footage by DTU 1562 of the affected vehicle 1550, the DFU 1564 of the affected vehicle 1550 may display either the still image or 'live' video feed 1565.

In certain embodiments, one or more functionalities of the DTU 140 may be implemented in the registered mobile phone 350, and hence may operate independently of the OBD module 100.

Remote Server 900

In some embodiments, the remote server 900 may refer to a database server, central database server, application server, web server, file server, mail server, print server or the like. The key purposes of the remote server are to: (i) communicate with the OBD module 100 that is installed in the vehicle and/or the associated mobile phone 350 so that context information relating to driving behavior (e.g. risk profile related to driving behavior), traffic conditions (e.g. congestion, accident), weather conditions (e.g. visibility, rain), road conditions (e.g. roadworks, hazards), for example, may be transferred to or received from the OBD module 100 and/or the associated mobile phone 350; (ii) compute traffic conditions based on parameters containing at least a geocoded average speed derived from the bootstrap method implemented in the DPU 120 over different timescales which may be described as short-term traffic conditions within the last 15 mins block, medium-term traffic conditions within the last 30 mins block, and long-term traffic conditions beyond the last one hour. Long-term traffic conditions may be further classified into hourly, daily, weekly, and monthly timescales for trending purposes; (iii) compute weights for each of the observed risk factor (e.g. fatigue, speeding, time pressure, distractions, and usage of mobile phones while driving, willingness to give way) and dissemination of such weights to the OBD module 100 and/or the associated mobile phone; (iv) compute a ranked risk profile for a plurality of drivers; (v) compute a cost of insurance based on a computed risk score; and (vi) compute a cumulative risk score of a driver.

Figure 9(b) illustrates a computer system 900 suitable for use as a remote server 900 in one or more embodiments disclosed herein. The computer system 900 and remote server 900 are used interchangeably to refer to the same. The computer system 900 includes a processor 382 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 384, read only memory (ROM) 386, random access memory (RAM) 388, input/output (I/O) devices 390, and network connectivity devices 392. The processor 382 may be implemented as one or more CPU chips. It is understood that by programming and/or loading executable instructions onto the computer system 900, at least one of the CPU 382, the RAM 388, and the ROM 386 are changed, transforming the computer system 900 in part into a particular machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA), because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an application specific integrated circuit that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC or a new FPGA is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus. Additionally, after the computer system 900 is turned on or booted, the CPU 382 may execute a computer program or application. For example, the CPU 382 may execute software or firmware stored in the ROM 386 or stored in the RAM 388. In some cases, on boot and/or when the application is initiated, the CPU 382 may copy the application or portions of the application from the secondary storage 384 to the RAM 388 or to memory space within the CPU 382 itself, and the CPU 382 may then execute instructions that the application is comprised of. In some cases, the CPU 382 may copy the application or portions of the application from memory accessed via the network connectivity devices 392 or via the I/O devices 390 to the RAM 388 or to memory space within the CPU 382, and the CPU 382 may then execute instructions that the application is comprised of. During execution, an application may load instructions into the CPU 382, for example load some of the instructions of the application into a cache of the CPU 382. In some contexts, an application that is executed may be said to configure the CPU 382 to do something, e.g., to configure the CPU 382 to perform the function or functions promoted by the subject application. When the CPU 382 is configured in this way by the application, the CPU 382 becomes a specific purpose computer or a specific purpose machine.

The secondary storage 384 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 388 is not large enough to hold all working data. Secondary storage 384 may be used to store programs which are loaded into RAM 388 when such programs are selected for execution. The ROM 386 is used to store instructions and perhaps data which are read during program execution. ROM 386 is a non-volatile memory device which typically has a small memory capacity relative to the larger memory capacity of secondary storage 384. The RAM 388 is used to store volatile data and perhaps to store instructions. Access to both ROM 386 and RAM 388 is typically faster than to secondary storage 384. The secondary storage 384, the RAM 388, and/or the ROM 386 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.

I/O devices 390 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.

The network connectivity devices 392 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 392 may enable the processor 382 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 382 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using processor 382, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.

Such information, which may include data or instructions to be executed using processor 382 for example, may be received from and outputted to the network, for example, in the form of a computer data baseband signal or signal embodied in a carrier wave. The baseband signal or signal embedded in the carrier wave, or other types of signals currently used or hereafter developed, may be generated according to several methods well-known to one skilled in the art. The baseband signal and/or signal embedded in the carrier wave may be referred to in some contexts as a transitory signal.

The processor 382 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 384), flash drive, ROM 386, RAM 388, or the network connectivity devices 392. While only one processor 382 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors. Instructions, codes, computer programs, scripts, and/or data that may be accessed from the secondary storage 384, for example, hard drives, floppy disks, optical disks, and/or other device, the ROM 386, and/or the RAM 388 may be referred to in some contexts as non-transitory instructions and/or non-transitory information.

In an embodiment, the computer system 900 may comprise two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the computer system 900 to provide the functionality of a number of servers that is not directly bound to the number of computers in the computer system 900. For example, virtualization software may provide twenty virtual servers on four physical computers. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. Cloud computing may be supported, at least in part, by virtualization software. A cloud computing environment may be established by an enterprise and/or may be hired on an as- needed basis from a third party provider. Some cloud computing environments may comprise cloud computing resources owned and operated by the enterprise as well as cloud computing resources hired and/or leased from a third party provider. In an embodiment, some or all of the functionality disclosed above may be provided as a computer program product. The computer program product may comprise one or more computer readable storage medium having computer usable program code embodied therein to implement the functionality disclosed above. The computer program product may comprise data structures, executable instructions, and other computer usable program code. The computer program product may be embodied in removable computer storage media and/or non-removable computer storage media. The removable computer readable storage medium may comprise, without limitation, a paper tape, a magnetic tape, magnetic disk, an optical disk, a solid state memory chip, for example analog magnetic tape, compact disk read only memory (CD-ROM) disks, floppy disks, jump drives, digital cards, multimedia cards, and others. The computer program product may be suitable for loading, by the computer system 900, at least portions of the contents of the computer program product to the secondary storage 384, to the ROM 386, to the RAM 388, and/or to other non-volatile memory and volatile memory of the computer system 900. The processor 382 may process the executable instructions and/or data structures in part by directly accessing the computer program product, for example by reading from a CD-ROM disk inserted into a disk drive peripheral of the computer system 900. Alternatively, the processor 382 may process the executable instructions and/or data structures by remotely accessing the computer program product, for example by downloading the executable instructions and/or data structures from a remote server through the network connectivity devices 392. The computer program product may comprise instructions that promote the loading and/or copying of data, data structures, files, and/or executable instructions to the secondary storage 384, to the ROM 386, to the RAM 388, and/or to other non-volatile memory and volatile memory of the computer system 900.

In some contexts, the secondary storage 384, the ROM 386, and the RAM 388 may be referred to as a non-transitory computer readable medium or a computer readable storage media. A dynamic RAM embodiment of the RAM 388, likewise, may be referred to as a non-transitory computer readable medium in that while the dynamic RAM receives electrical power and is operated in accordance with its design, for example during a period of time during which the computer system 900 is turned on and operational, the dynamic RAM stores information that is written to it. Similarly, the processor 382 may comprise an internal RAM, an internal ROM, a cache memory, and/or other internal non-transitory storage blocks, sections, or components that may be referred to in some contexts as non-transitory computer readable media or computer readable storage media.

According to certain embodiments, the remote server 900 may receive an average vehicle speed derived from the bootstrap method implemented in the DPU 120 and the geolocation of the vehicle at a periodic or non-periodic interval from the OBD module 100 and/or associated mobile phone 350. An exemplary process 1600 for determining update interval configuration for the remote server 900 is shown in Figure 16. For a periodic update, it is appreciated that the update interval for average vehicle speed by the OBD module 100 and/or associated mobile phone 350 to the remote server 900 may be determined by a preset value or constant value as selected by the driver (block 1610) prior to being recorded at the OBD module 100 and/or associated mobile phone 350 (block 1620). For non-periodic update, the updating of average vehicle speed by the OBD module 100 and/or associated mobile phone 350 may be triggered by an event (block 1630). The update interval may be determined to be variable or non- variable (block 1640). For non-variable interval, it may be purely event-triggered, such as a step change in average vehicle speed which may be detected by using appropriate change detection mechanisms such as cumulative sum (CUSUM), for example (block 1650). For variable interval, the remote server 900 may alternatively determine that a less frequent update is required when there are more OBD modules 100 and/or associated mobile phones 350 performing updates in a given geolocation area. Conversely, a more frequent update is necessary when there are fewer OBD modules 100 and/or associated mobile phones 350 performing updates in the given geolocation area. Thus, for example, the update interval may be determined as 1/(frequency of received updates per geolocation area), at block 1660, and the update interval then recorded at the OBD module 100 and/or associated mobile phone 350 (block 1620). It is appreciated that such variable interval as scheduled by the remote server may be transmitted to the OBD module 100 and/or associated mobile phone 350 over the air to regulate the number of updates or intensity of uplink transmissions per geolocation area to avoid congestion of radio resources, and to reduce power consumption of OBD module 100 and/or associated mobile phone 350. It is obvious that other scheduling methods may also be applied in the remote server to determine an appropriate variable update interval.

Through these real-time updates of average vehicle speed (and/or other vehicle operating parameters) by the OBD modules 100 and/or associated mobile phones 350, the remote server 900 may generate a traffic heat map and transmit such information back to the OBD modules 100 and/or associated mobile phones 350 for visualization on a display device, mobile phone display screen or navigation system. In some embodiments, the OBD modules 100 and/or associated mobile phones 350 may transmit average temperature, average humidity, and average atmospheric pressure, which are derived by atmospheric sensing module 165 and processed by the bootstrap method implemented in DPU 120, to the remote server 900. The remote server 900 may then generate a weather heat map based on the weather forecast obtained from weather stations and the received weather data from the OBD modules 100 and/or associated mobile phones 350. The remote server 900 may then transmit a modified threshold associated to a dynamic parameter based on at least the updated weather information to the OBD modules 100 and/or associated mobile phones 350 so that risk profile may be characterized according to prevailing weather conditions. For example, the speed limits, acceleration/deceleration thresholds, and angular velocity thresholds may be reduced in response to bad weather conditions such as reduced visibility and heavy rain or snow.

For example, as shown in Figure 17, a traffic analysis process 1700 comprises receiving, at the remote server 900, updated point estimates of vehicle speed (and/or other vehicle operating parameters), and geolocation data, for each vehicle carrying an OBD module 100 and/or associated mobile phone 350 (block 1710). The remote server 900 may be configured to generate, from the point estimates and geolocation data, a traffic heat map with geocoded average vehicle speed (block 1720). At block 1730, the generated heat map is broadcast from the remote server 900 to OBD modules 100 and/or associated mobile phones 350 within one or more specific geolocation areas, for example to one or more areas representing "hot spots" on the map. The broadcast map once received by the OBD module 100 and/or associated mobile phone 350 may be displayed to the driver via the DFU 130. It is appreciated such real-time traffic information may be useful for drivers or a navigation system to determine a more optimal route (block 1740) by considering realtime traffic conditions. In some embodiments, the traffic heat map may also indicate the location and severity of incidents or accidents by extracting (at block 1720) such information from other online databases or information servers. In some embodiments, the OBD modules 100 and/or associated mobile phone may also receive the location and severity of incidents (e.g. planned roadworks, hazards, and obstructions) or accidents from roadside infrastructures which may broadcast such information over a predetermined in-band or out-of-band channel (block 1750). In some other embodiments, roadside infrastructures with wireless connectivity such as Wi-Fi may be positioned at traffic junctions to broadcast information and warnings to approaching drivers and/or acquire information of drivers who committed traffic offences; both via the DTU 140 of the OBD module 100 and/or associated mobile phone 350. For example, the roadside infrastructure may be configured to announce the remaining time in seconds before an amber light turns red or may be configured to capture the registration number of the vehicle that committed an offence (e.g. running a red light and causing an accident) or any other identifiers such as VI N which may comprise of chassis and engine numbers which may be used to identify the driver of the said vehicle. In cases where a traffic offence is committed such as running a red light and an accident has occurred, the roadside infrastructure may be configured to relay pertinent information relating to the offence and accident back to the remote server 900. Such pertinent information may be used to moderate the risk score. In some embodiments, the average vehicle speed for a plurality of vehicles passing through a given geolocation area can be used to determine an effective speed limit for that geolocation area. For example, the legally mandated speed limit may be 60 km/h, but the effective speed limit based on historical data may be 55 km/h, due to practical considerations (e.g. large number of bends in the road and thus need to frequently decelerate). Accordingly, probabilities for speeding-related risk factors may be determined using the effective speed limit, rather than the legally mandated speed limit, providing a more accurate assessment of risk. The effective speed limit may be determined by using, for example, the bootstrap method in conjunction with recursive Bayes estimation performed on the vehicle speeds for the plurality of vehicles in the geolocation area. It can be appreciated that the effective speed limit may be adjusted effective vehicle operating threshold for a given geolocation area.

In some embodiments, the remote server 900 may be configured as a central database from which the derived risk profiles may be accessed by participating third party institutions such as insurance companies for the purpose of generating a fair insurance quote for their existing customers or prospective customers. Moreover, the central database may comprise risk profile and driving behavior of a plurality of drivers which may be ranked within an insurance company and/or among different insurance companies, and communicated to the OBD module 100 and/or associated mobile phone 350 or accessed by the driver through a web interface for post event comparison and analysis. Furthermore, the central database may be used to identify high risk factors and any sub-risk factors for an individual or group of drivers have similar traits or driving similar make of vehicle over time and use such information to reprioritize the weights for different risk factors. The reprioritize weights may be subsequently transmitted from the remote server 900 to the OBD module 100 and/or associated mobile phone 350 to provide a more accurate assessment of risk.

Weights of Risk Factors

The weights assigned to each risk factor may be used to reflect the qualitative preferences in how an insurer may associate each risk factor to a corresponding actuarial category. In some embodiments, the weights of different risk factors may be determined by mapping a set of insurer preferences to each risk factor with a lookup table as determined by the insurer. In this way, a specific set of weights corresponding to each risk factor, including any sub-risk factors, may be inherited when the OBD module 100 and/or associated mobile phone 350 starts its operation.

In some embodiments, an analytic hierarchy process (AHP) as shown in Figure 18 may be used to prioritize the insurer's preferences into a set of weights to reflect the requirements from the insurer perspective. AHP is a multi-criteria decision making technique typically used by a decision maker, which may be understood as the insurer in this case, to analyze a complex problem based on the following procedure.

Step 1 Problem decomposition into hierarchy of goal, criteria, and alternatives. Step 2: Pairwise comparisons of criteria at each level of the hierarchy with respect to the element above, e.g. the goal or global priorities. Step 3: Compute the relative weights (or priorities) of criteria and alternatives, as well as check for consistency in pairwise comparisons.

Step 4: Synthesize the relative weights of criteria and alternatives to obtain a global ranking of each alternative with respect to the goal.

For example, the insurer may decide that the key risk factors for determining a subsequent risk when operating a vehicle are speeding, fatigue, time pressure, and distraction which may correspond to the COIs of "driving above speed limit" and "cornering", "driving below speed limit", "lane changing", and "incident (usage of mobile phone while driving)", respectively, as shown in Table 1 . Now, the insurer may utilize the AHP as described in Step 1 above to determine the relative weights of the four risk factors (which correspond to the criteria) with respect to the risk profile (which corresponds to the goal). Next, the insurer may perform pairwise comparisons of the four risk factors, namely, speeding, fatigue, time pressure, and distraction according to Step 2. The pairwise comparison in AHP is based on the judgment, preference and/or experience of the insurer according to a typical scale as shown in Table 2 below.

Table 2. Scale for pairwise comparison

Consider the n x n pairwise comparison matrix A of n criteria at the same hierarchy level. The insurer's preference of criterion i over criterion j is reflected as a_tj and the insurer's preference of criterion j over criterion i is a_jl =

by the reciprocal property. If the insurer has consistent preferences, then all elements a_tj = w_i/w_j where w_l is the weight of criterion i and w_y is the weight of criterion y . and a_ij.a_jk = a_ik for all i , j and k by the transitivity property. This means that there is a unique set of weights from any column of A , multiplied by a constant. However, the pairwise comparison matrix A is derived from subjective preferences which are usually inconsistent, i.e. ^aij /^wj ■ Since weights are not unique for inconsistent pairwise comparison matrix, we may employ prioritization techniques such as the eigenvector method to determine the relative weights as

AW = W (14) where

λ = eigenvalue of the pairwise comparison matrix A ,

W = corresponding right eigenvector.

In order to ensure that the pairwise comparison matrix A is sufficiently consistent, a consistency index (CI) may be computed as CI = (k_max - n)/(n - l) (15) where

A_max = maximum or principal eigenvalue of the pairwise comparison matrix A , n = order of the n x n pairwise comparison matrix.

Further, a consistency ratio (CR) may be computed as

where

RI = random index as given in Table 3 which are obtained as an average over a large number of reciprocal matrices of the same order whose entries are random. Table 3. Random Index

It is noted that CR = 0 denotes that the pairwise comparison matrix has perfect consistency. On the other hand, CR > 0.1 suggests large inconsistency, and adjustments to the pairwise comparison matrix are required. In other words, CR of up to 0.1 is generally acceptable, and the estimate of relative weight can be accepted.

An example of the pairwise comparison matrix can be found in Table 4. The relative weights, which can be found in the last column, may be computed according to Step 3 by normalizing the eigenvector of the pairwise comparison matrix. The eigenvector is normalized by dividing each number by the sum of all numbers in the eigenvector. Accordingly, the weights represent their relative importance with respect to the risk profile, which is the goal in this example, and will have a sum of 1 . Note that the pairwise comparison matrix is sufficiently consistent as CR < 0.1 Hence, one may interpret that distraction is the most important risk factor followed by speeding while fatigue and time pressure, which are equally important, comes after speeding.

Table 4. Relative weights of risk factors, CI = 0.019, CR = 0.021

In some embodiments, another approximation technique known as the sum method may be used to derive the relative weights instead of computing the eigenvector of the pairwise comparison matrix. For example, the approximation may be carried out by first normalizing each column of the pairwise comparison matrix, and then calculate the average of each row in the normalized pairwise comparison matrix as the estimate of the relative weights or priority for its corresponding criterion or alternative as where i = \ 2 ... n (17a)

*kj

k=l

In addition, the CI may be approximated as

In some other embodiments, other prioritization techniques such as least squares method, logarithmic least squares method, geometric mean method, Chi squares method, and singular value decomposition method may be used to derive a set of weights for a corresponding set of risk factors.

Risk Profiling, Ranking, and its Associated Cost

In some embodiments, the relative weights derived from AHP, representing a subjective or qualitative measure of insurer preference, may be used to compute a risk score (R-Score) together with the objective or quantitative measure of risk factors and any sub-risk factors by applying simple additive weighting as

R - Score_{i k} = (18)

where

w¹ = normalized weight of risk factor j and = 1 , p_i ^J _k = risk probabilities metric for driver i in connection with risk factor or sub-risk factor j at time k . In this manner, the R-Score, which essentially represents the risk profile, may be determined based on the most favorable tradeoff between insurer preference and prevailing driving behavior. It is appreciated that the R-score is a normalized metric which has a range from 0 to 1 . It is also clear that the complement of the R-Score may be understood as the safety score (S-Score) of the driver. The R-Score may be computed in the DPU 120 of the OBD module 100 or, alternatively, at the remote server 900 provided the necessary context information are available. In preferred embodiments, the R-Score, when computed in DPU 120 of the OBD module 100, is referred as a real-time R-Score. On the other hand, the R-Score when computed in remote server 900 is referred as a non-real-time R-Score.

Further, a cumulative R-Score may be determined using a moving average of the previous R-Scores either received from DTU 140 of OBD module 100 and/or associated mobile phone 350 (i.e. real-time R-Score), or computed by the remote server 900 (i.e. non-real-time R-Score). For example, the cumulative R-Score may be determined by using the EWMA estimation as

¾ = Aft ₊ (l- A)«_H for k = 1,2, .. , n (19) where a_k is the cumulative R-Score, β_Ιζ is the observed (updated) R-Score at time k , n is the number of observations to be monitored, and λ is a geometric decay factor in the interval [0,1 ] that determines the rate at which historical data influences the cumulative R-Score. A small value of λ gives more weight to historical data, and a large value of λ gives more weight to recent observations. In one embodiment, a smaller value of λ may be chosen for drivers with higher risk profile and a higher value of λ may be chosen for drivers with lower risk profiles.

Alternatively, the cumulative R-Score may be computed by using the bootstrap method in conjunction with the recursive Bayesian estimation technique as previously described. The advantage with this approach, compared to EWMA, is that the variability of the R-Score may also be captured in addition to the mean R-Score.

Next, by further ranking the R-Score, a ranked risk profiles for a plurality of drivers may be obtained, and a relative insurance cost may be obtained based in part on the ranked risk profiles. This may be seen as an intuitive and a fair way to determine the insurance cost. As an example, the premium may be expressed as P = B x a_x x ... x a_n x β ₊

(20)

1, (d - d) < 0

(21 )

0, (d - d)≥0

where

P = premium of insurance cost,

B = base rate or a typical parameter in an insurance rate formula,

a_n = initial risk factor based on n historical information or attributes such as age, gender, and location,

β = subsequent driving risk (i.e. R-Score),

d = mileage of a driver in kilometers or miles,

d = average mileage of a group of drivers in kilometers or miles,

η = usage rate or cost per kilometer or mile,

p = an indicator to determine whether mileage of a driver is less or more than the average mileage of a group of drivers by the insurer. It may be implemented by using a unit step function U[n such that p = l when mileage of the driver is less than the average mileage of a group of drivers, and p = 0 otherwise.

Essentially, β or R-Score may be understood as a discount function for initial risk factors used by actuaries for tariff classification, and usage rate for high mileage drivers. Similarly, l + (l - J) may be understood as a reward function, in which (l is the S-Score, for low mileage driver with safe driving behavior. Note that the reward function has a range of [1 ,2] while the discount function has a range of [0, 1 ]. The rationale is that the risk for low mileage driver with safe driving behavior may be much lower than a high mileage driver with the same driving behavior. Hence, the rebate from premium for low mileage drivers, i.e. (J- J) < 0 , is dominantly influenced by usage, and the surcharge to premium for high mileage drivers, i.e. (J- J) > 0 , is dominantly influenced by driving behavior or history.

Additionally, the usage rate may be scaled by a ratio of the mileage of the driver to the average mileage of a group of drivers or other appropriate ratios for low mileage drivers such that the amount of rebate and surcharge per unit distance may be different, and the amount of rebate per unit distance may be less than the amount of surcharge per unit distance. Collectively, such premium pricing may incentivize driver to regulate their usage and driving behavior according to an acceptable premium. It is also appreciated that the initial risk factors and subsequent risk of expression (20) may be easily weighted to reflect their relative importance. In some other embodiments, Step 4 of the AHP may be used to determine the R-Score based on the global ranking of each alternative with respect to the goal, which may correspond to drivers and their risk profiles, respectively. Referring to Figure 19, each of the previously mentioned four criteria (which correspond to the risk factors) may be further decomposed into three sub-criteria (which correspond to the sub-risk factors) so that drivers (who correspond to the alternatives) may be evaluated in terms of the sub- criteria which may form the underlying reasons for their driving behaviors. In cases when sub-criteria exist, the relative weights related to the sub-criteria are termed as local priorities, and are derived in the same manner as previously shown in Table 4. Particularly, the local priorities for sub-criteria (shown without parentheses in Figure 19) within each criterion sum up to 1 , and the global priorities for the sub-criteria (shown in parentheses in Figure 19) are obtained by multiplying the local priority of each sub- criterion by their parent's (or criterion's) global priority. In other words, the global priorities of child elements always sum up to the global priority of their parent within a hierarchy, and the local priorities of child elements always sum up to 1. It is noted that the criteria has the same local and global priorities because the goal, which is the parent of each of the criteria, has a global priority of 1. Table 5 presents the summary of global priorities for each of the drivers. More specifically, each driver has global priorities corresponding to the insurer's judgment on the risk factors of speeding, fatigue, time pressure and distraction, as well as sub-risk factors of thrill seeking, confidence, impatience, sleep quality, proper rest interval, 5 driving duration, stress level, willingness to give way, time to destination, texting while driving, usage while stationary, and talking while driving. It may be understood that the global priority of each alternative is the sum of global priorities of each alternative with respect to its sub-criteria and/or criteria, and that the global priority of each alternative is the R-Score of each driver. Hence, the R-Score of Driver 1 is 0.335 and Driver 2 is

10 0.665, and Driver 2 may be deemed as the driver with a higher risk as compared to Driver 1 . The numerals in brackets correspond to priority of the goal, the numerals in parentheses correspond to the global priorities of the criteria, and the numerals highlighted in italics correspond to the global priorities of the sub-criteria. Essentially, Table 5 illustrates an alternative representation of the corresponding hierarchy found in

15 Figure 19.

Tables 6 and 7 illustrate by example the local and global priorities for sub-criteria with respect to speeding (criteria), as well as for the local and global priorities for alternatives with respect to thrill seeking (sub-criteria), respectively, for the purpose of 20 population Table 5. The local and global priorities of other sub-criteria and alternatives may be obtained in the same manner.

Table 5. Global priorities for each of the driver under comparison

25 Table 6. Local and global priorities for sub-criteria with respect to speeding

Table 7. Local and global priorities for alternatives with respect to thrill seeking

Example

Figure 20 is a flow diagram depicting an embodiment of an overall process 2000 for computing a risk profile of a driver and interacting with a remote server 900 for the purposes of adjusting relative weights for a corresponding set of considered risk factors and sub-risk factors, and dissemination of real-time traffic information to the OBD module 100 and/or associated mobile phone 350, or navigation system, and subsequently notifying the driver in an appropriate manner.

More specifically, on the OBD module 100 side, upon the detection of at least one COI (by CIU 1 12) at block 2010, the DPU 120 may determine that the acquired data belongs to either a static or dynamic parameter. The former may be associated with an event, such as activation of turn signal and use of a mobile phone, for example, whereas the latter may be associated with random variables such as vehicle speed and g-force dynamics. For data belonging to a static parameter, measurement of its occurrence over a predefined observation period is performed to arrive at an updated probability of that event or risk factor. For data belonging to a dynamic parameter, statistical processing techniques comprising the bootstrap method and recursive Bayesian estimation (as described above) are used to derive point estimates and parameter estimates, and to determine updated probabilities for the risk factor(s) associated with the dynamic parameter. Updated probabilities are determined by the DPU 120 in process 400 as described earlier with reference to Figure 4.

For example, point estimates may be transmitted (at 1) together with the time and geolocation information 2020 via the DTU 140 of the OBD module 100 (a.k.a. DTU 140) and/or associated mobile phone 350 to the remote server 900. The transmitted information 2020 may be used by the remote server 900 for the purpose of generating a real-time traffic and/or weather heat map. The heat map 2035 may indicate average vehicle speed, average temperature, average humidity, and/or average atmospheric pressure in major roads and highways. The heat map 2035, once generated, may be transmitted (at 2) to the OBD module 100 and/or associated mobile phone 350 as previously described. On the other hand, parameter estimates such as the PDFs of the average vehicle speed, acceleration (e.g. forward acceleration, lateral acceleration or g-force), and angular velocity (e.g. rate of pitch, roll, and yaw) as derived from the Bayes estimates may be quantified in terms of updated probabilities such as probability of driving above different speed limits, probability of accelerating or cornering above different thresholds, and probability of pitch, roll, or yaw rate above different thresholds, respectively, while the vehicle is traveling in a real-time manner.

Accordingly, the risk factors, including any sub-risk factors, may be quantified by using the above techniques and/or conditional probabilities to quantify the occurrence of at least two events such as probability of using turn signal while performing lane change and probability of using mobile phone while driving. It is appreciated that the quantified risk factors by means of using probabilities are inherently normalized. Next, the realtime R-Score may be computed by the CPU 105 (block 2025) using the weighted sum (using relative weights 2030 received from the remote server 900) of the quantified risk factors. The insurer may choose to update at least one relative weight associated with the considered risk factors and sub-risk factors to reflect their prevailing preferences. The refined relative weights may be derived based in part on the comparison across a plurality of drivers accessible from the remote server 900. Subsequently, the real-time R-Score may be fed back to the driver through an appropriate display device such as the driver's mobile phone or navigation system. The DTU 140 and/or associated mobile phone 350 may then transmit the real-time R-Score, including any information related to the risk factors and sub-risk factors such as their probabilities of occurrence, and any recorded data and identifiers 2012 (e.g. vehicle data, physiological data, weather data from atmospheric sensing module 165, sensor data, driver authentication data, data from associated mobile phone 350, image, and video recordings), as part of the uplink context information 2022, back to the remote server 900 for further processing and archival. On the remote server side, the remote server 900 may store and process data or information (block 2045), concerning the real-time traffic conditions such as average vehicle speed, as well as the probabilities of occurrence for the considered risk factors and sub-risk factors such as the probability of speeding or driving under distraction. Based on these received data or information, the remote server may be able to determine (block 2055) at least one new relative weight based in part on the comparison across a plurality of driver records stored in a local or central database. The remote server 900 may be configured to moderate the received real-time R-Score computed by OBD module 100 or its own computed non-real-time R-Score with at least an updated probability, related to the considered risk factors and sub-risk factors, when compared with a plurality drivers operating in the vicinity. For example, the concerned driver may have either committed a traffic offence or may be driving below a legal speed limit, but relatively higher speed in comparison with a plurality drivers in the vicinity, and hence may be deemed as more aggressive or impatience. The remote server 900 may further compute the cumulative R-Score based on the received realtime R-Scores or its computed non-real-time R-Scores. The remote server 900 may also generate the real-time traffic and/or weather heat map (block 2050) with indication of locations of incident and/or accident which may be accessible from a web interface 2060 or transmitted over the air to be received by the DTU 140 and/or associated mobile phone 350. The transmitted information may be a hyperlink or uniform resource locator (URL) pointing to the real-time traffic and/or weather heat map 2035, for example.

In addition, the remote server 900 may be able to compare (block 2065) the risk profiles for a plurality of drivers accessible from the local database belonging to the insurer or the central database that may be connected to a plurality of insurers. In the former, the insurer may be able to compute a fair cost of insurance (block 2070) for their insured drivers based on the ranked risk profile as described earlier. The cost of insurance and the ranked risk profile may be transmitted along with the cumulative R- Score, relative weights, traffic heat map, and processed information 2047 (e.g. weather forecast, weather heat map, locations of incident or accident, selected COIs, secret key for OTP generation, thresholds associated with dynamic parameters such as speed and acceleration, channel number of operating frequency to perform handshaking procedure, update interval for scheduling transmissions from OBD modules 100 and/or associated mobile phones 350, and actuation command), as part of the downlink context information 2040, (at 2) to the DTU 140 and/or associated mobile phone 350. Similarly, in the latter, the insurer may be able to compute a fair cost of quotation for their prospective customers (block 2075).

It is obvious to one of ordinary skill in the art that the exemplary functionalities, processes, and methods of DAU 1 10, CIU 1 12, DPU 120, DFU 130, DTU 140, and Multi-RAT transceiver 142 may be implemented in different combinations across one or more computing devices such as on-board device and mobile phone, or entirely in any one of the computing devices.

It can be appreciated that the DTU 140 and/or the remote server 900 may comprise the selection of a communication interface of an associated mobile phone 350 as the preferred communication path and the Multi-RAT communications interface as the alternative communication path. The communication path may comprise the downlink path and/or the uplink path.

It can be further appreciated that some biomedical sensors may also be available in the associated mobile phone 350. In these cases, the biomedical sensors from the associated mobile phone 350 and/or the wearable monitoring device may be used to acquire the necessary physiological data 220 either independently or in combinations.

It is obvious that the detection of usage of the associated mobile phone 350 while driving may also depend on whether the associated mobile phone 350 is removed from a specific location, e.g. a phone holder or a certain position on within a vehicle which may be detected by proximity sensing techniques where RFID and NFC tags may be applied onto any surfaces corresponding to the specific location.

It is also obvious that the relative weight 2030 for a corresponding set of considered risk factors and sub-risk factors may be predetermined and stored in the OBD module 100 and/or the associated mobile phone 350. In such cases, it may not be necessary to receive and/or adjust the relative weight 2030 from the remote server 900. The key advantages of embodiments of this invention include the following:

• Multi-modal context information concerning a driver to perform real-time psychometric assessment to determine behavior such as patience, aggression, time pressure, fatigue, distraction, willingness to give way, distraction from usage of mobile phone while driving, and attribution of risk to the party at fault will characterize a corresponding risk profile more accurately.

• The proposed statistical methods provide a lightweight approach to characterize and rank risk profile of drivers reliably and consistently, and provide a fair mechanism to determine cost of insurance.

• Feedback of real-time risk profile to drivers provides an opportunity for them to alter their driving patterns in a timely manner as opposed to post event processing and analysis.

• The central database provides insurance companies to retrieve risk profile of drivers who may not have an existing relationship with them for the purpose of generating quotations.

• The remote server provides real-time information (traffic and weather heat maps, as well as locations of incident or accident) based in part on the context information gathered from the OBD modules that are attached to the vehicles and/or associated mobile phone.

• The multi-radio onboard device serves as an aggregator for all device-to- device communications within the car environment. Such data aggregation will reduce the amount of signaling loads to existing cellular and wireless networks.

• R-Score may be used as a pricing or incentivization mechanism for non- insurance applications such as fleet management and car sharing.

List of abbreviations

ABS: Anti-lock braking system

AES: Advanced encryption standard

BDS: BeiDou satellite navigation system

BER: Bit error rate

BLE: Bluetooth Low Energy

BSSID: Basic service set identification CCMP: Counter cipher mode with block chaining message authentication code protocol

CDF: Cumulative distribution function

CI: Consistency index

CIU: Context identification unit

CLT: Central limit theorem

COI: Context of interest

CR: Consistency ratio

CUSUM: Cumulative sum

DAU: Data acquisition unit

DFU: Driver feedback unit

DMI: Distance measuring instrument

DPU: Data processing unit

ECU: Electronic control unit

EWMA: Exponentially weighted moving average

GIS: Geographic information system

GLONASS: Globalnaya navigatsionnaya sputnikovaya sistema

GNSS: Global navigation satellite system

GPS: Global positioning system

HDP: Health device profile

HDPLE: Health device profile low energy

HUD: Head-up display

IMEI: International mobile station equipment identity

MAC: Medium access control

MSDU: MAC service data unit

Multi-RAT: Multiple radio access technology

NFC: Near field communication

OBD: On-board diagnostic

OTP: One-time password

PER: Packet error rate

PDF: Probability density function

PID: Parameter identifier

QoS: Quality of service

REM: Rapid eye movement

RFID: Radio frequency identification RPM: Revolutions per minute R-Score: Risk score

S-Score: Safety score

SNR: Signal-to-Noise Ratio

SPP: Serial port profile

SSID: Service set identifier

UBI: Usage-based insurance URL: Uniform resource locator VIN: Vehicle identification number WLAN: Wireless local area network WPA: Wi-Fi protected access WPS: Wi-Fi protected setup

WWAN: Wireless Wide Area Network

Claims

1. A method of determining a driving risk profile for at least one driver, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the method comprising:

determining an identification of the driver;

receiving, while the driver is operating a motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating; processing the status data to automatically detect a driving context;

based on the updated scores, determining an updated risk score using the risk score function.

2. A method according to claim 1 , wherein the updated risk score is generated in real- time.

3. A method according to claim 1 or 2, wherein the scores for respective risk factors are probabilities for the respective risk factors.

4. A method according to any one of the preceding claims, wherein the weights in the risk score function are based on global priorities derived from an analytic hierarchy process (AHP).

5. A method according to claim 4, wherein the global priorities are determined according to a normalized eigenvector of a pairwise comparison matrix of the AHP or approximated with a sum method.

6. A method according to claim 5, wherein the risk score function is a sum of global priorities for a plurality of sub-criteria and/or criteria in an AHP in which drivers correspond to alternatives, criteria correspond to said risk factors, and sub-criteria correspond to sub-risk factors of said risk factors.

7. A method according to any one of the preceding claims, comprising receiving updated weights for the respective risk factors associated with the detected driving context, wherein the updated weights are used in the risk score function to generate the updated risk score.

8. A method according to any one of the preceding claims, wherein at least one of the risk factors is based on a dynamic parameter.

9. A method according to claim 8, wherein the updated probability is obtained using a point estimate and its variability, and/or an estimate of a probability density function (PDF) of the dynamic parameter.

10. A method according to claim 9, wherein the point estimate and its variability are obtained by a bootstrap procedure.

1 1 . A method according to claim 9 or 10, wherein the estimate of the PDF is obtained by recursive Bayesian estimation from the point estimate and its variability.

12. A method according to any one of the preceding claims, wherein at least one of the risk factors is based on a static parameter.

13. A method according to claim 12, wherein the updated probability is a probability of at least two concurrent events.

14. A method according to claim 13, wherein the probability of at least two concurrent events is calculated based on one or more conditional probabilities and the corresponding marginal probabilities.

15. A method according to any one of the preceding claims, wherein a cumulative risk score is determined based on the updated risk score and one or more previously determined risk scores for the driver.

16. A method according to claim 15, wherein the cumulative risk score is calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation.

17. A method according to any one of the preceding claims, comprising transmitting update information to a remote server at an update interval.

18. A method according to claim 17, wherein the update information comprises the updated scores and/or the updated risk score.

19. A method according to claim 17 or 18, wherein the update information comprises motion data from computing devices of a plurality of vehicles at respective update intervals, the motion data relating to at least one vehicle operating parameter of respective vehicles, and geolocation data relating to positions of the vehicles, the method further comprising:

obtaining map data representing a road map;

receiving the update information;

transmitting, to the plurality of vehicles, the map of traffic conditions.

20. A method according to claim 19, comprising receiving traffic incident data indicating the nature and location of a traffic incident; and overlaying the traffic incident data on the map of traffic conditions.

21 . A method according to claim 19 or 20, comprising receiving weather data indicative of weather conditions as a function of position; determining one or more geolocation-dependent adjusted effective vehicle operating thresholds according to the traffic and/or weather data; and transmitting the geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices.

22. A method according to any one of claims 17 to 21 , wherein the update interval(s) are determined according to an event trigger, such as a step change in at least one vehicle operating parameter or environmental parameter.

23. A method according to any one of claims 17 to 22, wherein update interval(s) in a geolocation area are determined according to the number of computing devices associated with vehicles in the geolocation area.

24. A method according to any one of the preceding claims, wherein a ranking of the risk profile for the driver relative to other drivers is computed for a driver of the plurality of drivers.

25. A method according to any one of the preceding claims, comprising providing feedback to the driver regarding the updated risk score and the cumulative risk score, and optionally, a ranking of the driver relative to other drivers and/or an updated cost of insurance.

26. A method according to any one of the preceding claims, wherein the updated risk score is communicated to the driver in real-time.

27. A method according to any one of the preceding claims, wherein risk factors are selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle.

28. A method according to any one of the preceding claims, wherein one of the risk factors is usage of a mobile phone, and wherein the method comprises determining one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

29. A method according to any one of the preceding claims, wherein one of the risk factors is related to the sleep quality, stress level, emotional state, arousal level, sweat level, and/or blood-oxygen level.

30. A method according to any one of the preceding claims, wherein the driving context is detected automatically based on data from one or more of: at least one computing device associated with the vehicle; a sensor internal to the vehicle; an external sensor; and a remote server.

31 . A method according to any one of the preceding claims, comprising determining a psychometric assessment of the driver based on measurement of physiological parameters and/or from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

. A method according to any one of the preceding claims, comprising maintaining at least one communication path between the vehicle and a remote server using a plurality of communications interfaces.

. An on-board device for a motor vehicle, comprising:

a context identification unit which is configured to: receive, from the data acquisition unit, the status data, and to process the status data to automatically detect that one of a plurality of driving contexts is current;

34. An on-board device according to claim 33, wherein the data processing unit is configured to generate the updated risk score in real-time.

35. An on-board device according to claim 33 or 34, wherein the data acquisition unit is configured to communicate with one or more sensors of the motor vehicle and/or wearable monitoring devices of the driver, and to determine the identification of the driver using data received from the one or more sensors.

36. An on-board device according to claim 35, wherein the data relate to one or more of: measured body weight; mirror adjustment patterns; throttle position; hand position and pressure on a steering wheel of the motor vehicle; gear shifting patterns; throttle position patterns; sleep pattern; sleep pattern; stress level; blood- glucose level; heart rate; blood pressure; skin temperature; and sweat level.

37. An on-board device according to any one of claims 33 to 36, further comprising a data transmission unit which is configured to transmit uplink context information to a remote server and/or to receive downlink context information from the remote server.

38. An on-board device according to claim 37, wherein the uplink context information comprises one or more of: average vehicle data determined based on the operating parameters of the motor vehicle, time, geolocation, the updated scores, the updated risk score, and average weather data determined based on the environmental conditions.

39. An on-board device according to claim 37, wherein the downlink context information comprises one or more of: relative weights for use in the risk function, a cumulative risk score determined based on previous updated risk scores received by the remote server, an effective vehicle operating threshold adjusted based on traffic and weather conditions, an update interval calculated for computing device, desired driving context, a ranking of the driver relative to other drivers, estimated cost of insurance, a heat map of traffic and/or weather conditions, and a geolocation of a traffic incident.

40. An on-board device according to any one of claims 37 to 39, wherein the data transmission unit is configured to communicate with a data transmission unit of an on-board device of at least one other vehicle.

41 . An on-board device according to claim 40, wherein the data processing unit is configured to determine, from response data received from the data transmission unit of the on-board device of the at least one other vehicle, willingness of the at least one other vehicle to give way; and/or wherein the data transmission unit is configured to send a give way prompt to the at least one other vehicle and/or to transmit the risk profile of the driver to the on-board device of the at least one other vehicle.

42. An on-board device according to any one of claims 37 to 41 , wherein the data transmission unit is configured to receive updated weights for the respective risk factors associated with the detected driving context.

43. An on-board device according to claim 42, wherein the data processing unit is configured to use the updated weights in the risk score function to generate the updated risk score.

44. An on-board device according to any one of claims 33 to 43, wherein the data processing unit is configured to determine a cumulative risk score based on the updated risk score and one or more previously determined risk scores for the driver.

45. An on-board device according to claim 44, wherein the cumulative risk score is calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation.

46. An on-board device according to any one of claims 33 to 45, further comprising a driver feedback unit for communicating the feedback of risk scores to the driver.

47. An on-board device according to claim 46, wherein the driver feedback unit is configured to provide feedback to the driver regarding the updated risk score and the cumulative risk score, and optionally, a ranking of the driver relative to other drivers and/or an updated cost of insurance.

48. An on-board device according to claim 46 or 47, wherein the driver feedback unit is configured to communicate the updated risk score to the driver in real-time.

An on-board device according to any one of claims 33 to 48, wherein risk factors are selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle.

50. An on-board device according to any one of claims 33 to 49, wherein one of the risk factors is usage of a mobile phone, and wherein the method comprises determining one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

51 . An on-board device according to any one of claims 33 to 50, wherein one of the risk factors is related to the sleep quality, stress level, emotional state, arousal level, sweat level, and/or blood-oxygen level.

52. An on-board device according to any one of claims 33 to 51 , wherein the context identification unit is configured to automatically detect the driving context based on data from one or more of: a mobile computing device associated with the vehicle; a sensor internal to the vehicle; an external sensor; and a remote server.

53. An on-board device according to any one of claims 33 to 52, wherein the data processing unit is configured to determine a psychometric assessment of the driver based on measurement of physiological parameters and/or from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

An on-board device according to any one of claims 33 to 53, wherein the data transmission unit is configured to maintain at least one communication path between the vehicle and the remote server using a plurality of communication interfaces.

55. A system for determining a driving risk profile for at least one driver, the at least one driver being associated with a motor vehicle, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the system comprising:

at least one computing device associated with the motor vehicle; and

a remote server having at least one processor and a communications interface for communicating with the at least one computing device;

the computing device and/or the at least one processor being configured to: determine an identification of the driver;

receive, while the driver is operating the motor vehicle, status data representing current values of a plurality of input parameters, the input parameters comprising: physiological measurements of the driver, and/or operating parameters of the motor vehicle, and/or environmental conditions in which the motor vehicle is operating; process the status data to automatically detect a driving context;

56. A system according to claim 55, wherein the at least one computing device is configured to generate the updated risk in real-time.

57. A system according to claim 55 or 56, wherein the at least one computing device is configured to receive, from the remote server, updated weights for the respective risk factors associated with the detected driving context.

58. A system according to claim 57, wherein the computing device is configured to generate the updated risk score using the updated weights in the risk score function.

59. A system according to any one of claims 55 to 58, wherein the at least one computing device and/or the at least one processor is configured to determine a cumulative risk score based on the updated risk score and one or more previously determined risk scores for the driver.

60. A system according to claim 59, wherein the cumulative risk score is calculated using an exponentially weighted moving average or bootstrap procedure in conjunction with recursive Bayesian estimation.

61 . A system according to any one of claims 55 to 60, wherein the computing device is configured to provide feedback to the driver regarding the updated risk score and the cumulative risk score, and optionally, a ranking of the driver relative to other drivers and/or an updated cost of insurance.

62. A system according to any of claims 55 to 61 , wherein the at least one computing device is configured to communicated the updated risk score to the driver in realtime.

63. A system according to claim 55, wherein the at least one computing device comprises an on-board device according to any one of claims 33 to 54, a mobile phone, and/or a wearable monitoring device.

64. A system according to claim 63, comprising an on-board device according to any one of claims 33 to 54 and a mobile phone, wherein the mobile phone and/or wearable monitoring device are communicatively coupled with the on-board device and/or with each other by an authentication procedure.

65. A system according to claim 63 or 64, wherein the mobile phone and/or wearable monitoring device are registered in a database which is in communication with the remote server.

66. A system according to any one of claims 55 to 65, wherein the remote server is configured to determine one or more geolocation-dependent adjusted effective vehicle operating thresholds according to traffic and/or weather data, and transmit the one or more geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices.

67. A system according to any one of claims 55 to 66, comprising a data store for storing data received from the plurality of computing devices in relation to a plurality of drivers, and respective risk profiles for the plurality of drivers calculated based on the data received from the plurality of computing devices.

68. A system according to claim 67, wherein the at least one processor is configured to compute, for a driver of the plurality of drivers, a ranking of the risk profile for the driver relative to the other drivers; and the remote server is configured to transmit, to a computing device associated with the driver, the computed ranking.

69. A system according to any one of claims 55 to 68, wherein risk factors are selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle.

70. A system according to any one of claims 55 to 69, wherein one of the risk factors is usage of the mobile phone, and wherein the computing device and/or the at least one processor is configured to determine one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

71 . A system according to any one of claims 55 to 70, wherein one of the risk factors is related to the sleep quality, stress level, emotional state, arousal level, sweat level, and/or blood-oxygen level.

72. A system according to any one of claims 55 to 71 , wherein the computing device and/or the at least one processor is configured to automatically detect the driving context based on data from one or more of: the computing device associated with the vehicle; a sensor internal to the vehicle; an external sensor; and a remote server.

73. A system according to any one of claims 55 to 72, wherein the at least one processor is configured to determine a psychometric assessment of the driver based on measurement of physiological parameters and/or from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

74. A system according to any one of claims 55 to 73, wherein the computing device and/or the at least one processor is configured to maintain at least one communication path between the vehicle and a remote server using a plurality of communications interfaces.

75. A remote server for determining a risk profile of at least one driver of a motor vehicle, the risk profile comprising a risk score based on a plurality of scores for a plurality of risk factors, the remote server comprising:

at least one processor; and

wherein the at least one processor is configured to:

determine an identification of the driver; receive, from said at least one computing device, one or more updated scores for respective risk factors associated with driving context detected by the at least one computing device, and/or an updated risk score computed by the at least one computing device based on the updated scores for the respective risk factors; and/or

A remote server according to claim 75, wherein the at least one processor is in communication with a data store, the data store comprising risk scores for a plurality of other drivers; and wherein the at least one processor is configured to compare the updated risk score and/or the cumulative risk score for the at least one driver to the risk scores of the other drivers.

A remote server according to claim 75 or 76, wherein the at least one computing device is registered in a database which is in communication with the remote server.

78. A remote server according to any one of claims 75 to 77, wherein the at least one processor is configured to determine one or more geolocation-dependent adjusted effective vehicle operating thresholds according to traffic and/or weather data, and transmit the one or more geolocation-dependent adjusted effective vehicle operating thresholds to the computing devices.

79. A remote server according to any one of claims 75 to 78, wherein the at least one processor is in communication with a data store for storing data received from the plurality of computing devices in relation to a plurality of drivers, and respective risk profiles for the plurality of drivers calculated based on the data received from the plurality of computing devices.

80. A remote server according to claim 79, wherein the at least one processor is configured to compute, for a driver of the plurality of drivers, a ranking of the risk profile for the driver relative to the other drivers; and the remote server is configured to transmit, to a computing device associated with the driver, the computed ranking.

81 . A remote server according to any one of claims 75 to 80, wherein the at least one processor is configured to determine update interval(s) according to an event trigger, such as a step change in at least one vehicle operating parameter or environmental parameter.

82. A remote server according to any one of claims 75 to 81 , wherein the at least one processor is configured to determine update interval(s) in a geolocation area according to the number of computing devices associated with vehicles in the geolocation area.

83. A remote server according to any one of claims 75 to 82, wherein risk factors are selected from the group consisting of: thrill seeking; confidence; impatience; poor sleep quality; proper rest interval; driving duration; stress level; willingness to give way; time to destination; and mobile computing device usage while operating a motor vehicle.

84. A remote server according to any one of claims 75 to 83, wherein one of the risk factors is usage of the mobile phone, and wherein the computing device and/or the at least one processor is configured to determine one or more of: whether scrolling actions or text inputs are performed on the mobile phone by left thumb, right thumb or index fingers; whether an ambient light sensor of the mobile phone has detected a sharp reduction of illuminance; whether the vehicle has other passengers; whether the mobile phone is held closely to the steering wheel; whether the mobile phone is held in the driver's non-dominant hand; whether the mobile phone is held in a single hand; and whether keypad and/or audio inputs are received by the mobile phone.

85. A remote server according to any one of claims 75 to 84, wherein one of the risk factors is related to the sleep quality, stress level, emotional state, arousal level, sweat level, and/or blood-oxygen level.

86. A remote server according to any one of claims 75 to 85, wherein the at least one processor is configured to automatically detect the driving context based on data from one or more of: the computing device; a sensor internal to the vehicle; an external sensor; and the remote server.

87. A remote server according to any one of claims 75 to 86, wherein the at least one processor is configured to determine a psychometric assessment of the driver based on measurement of physiological parameters and/or from a combination of data obtained from wearable monitoring device, data obtained from vehicle parameters, and data obtained from local and/or external devices.

88. A remote server according to any one of claims 75 to 87, wherein the at least one processor is configured to select a communication interface of a mobile device associated with the computing device as the preferred communication path.