WO2025107063A1

WO2025107063A1 - System and method for detection of sound in usage based insurance

Info

Publication number: WO2025107063A1
Application number: PCT/CA2024/050861
Authority: WO
Inventors: Bertrand Jules Bernard RIVIERE; Christopher Robert CATES
Original assignee: Intact Financial Corp
Current assignee: Intact Financial Corp
Priority date: 2023-11-20
Filing date: 2024-06-26
Publication date: 2025-05-30
Anticipated expiration: 2026-05-20

Abstract

Louder in-car environment may correlate to more insurance claims than a quiet car but recording audio in a call would be difficult from a privacy perspective. The disclosure relates to a system and method for detecting sound in usage-based insurance (UBI) applications. When a driver opens their UBI application, the application records noise level, but does not record the sound. This maintains user privacy while providing an additional metric to be analysed and used in UBI policies.

Description

SYSTEM AND METHOD FOR DETECTION OF SOUND IN USAGE BASED INSURANCE

FIELD OF THE INVENTION

[0001] The present embodiments relate to insurance policies which utilize telematic data to determine if a customer’s data is indicative of risky driving behaviors. More specifically the present embodiments relate to measuring noise levels and correlating noise level data to driver behavior.

DESCRIPTION OF THE PRIOR ART

[0002] Usage-based insurance uses telematic technology to track and document your driving habits. By measuring and recording a number of variables using an app installed on a cell phone, insurance companies can track when and how much you drive, estimate fatigue based on how long you have been driving, estimate risk of distracted driving by tracking your mobile use, and estimate your adherence to the speed limit. Currently usage-based insurance (UBI) can also track smooth driving habits by noting periods of sudden braking or acceleration. Based on this data, insurers can determine a safety rating for the driver and assign an appropriate insurance rate.

[0003] Drivers can be further distracted by noise. Drivers in loud cars cannot hear other vehicles, mechanical issues, emergency sirens, etc. Louder in-car environment may correlate to more claims than a quiet car but recording audio in a call would be difficult from a privacy perspective. There remains a need to monitor noise levels in automobiles without violating a drivers privacy. This innovation would create an additional UBI data point that can be correlated with driving behaviour and outcomes (such as accidents, aggressive driving, hard braking, etc.) to better predict future driver risk.

SUMMARY OF THE INVENTION

[0004] The disclosure relates to a system and method for detecting sound in usage -based insurance (UBI) applications. When a driver opens their UBI application, the application records noise level, but does not record the sound. This maintains user privacy while providing an additional metric to be analysed and used in UBI policies.

[0005] One embodiment relates to a system for detection of sound in usage based insurance comprising a mobile device coupled to a communication network and a database for storing driver metrics. The mobile device is configured to measure and record noise level and send the measurement to the database.

[0006] Another embodiment relates to a method of detection of sound in usage based insurance comprising the steps of measuring noise level in a vehicle and communicating the noise level measurement to a database.

[0007] In yet a further embodiment, the noise level measurement and other metrics collected in the same timeframe are used to determine correlations between noise level and driving behavior.

[0008] In yet a further embodiment, feedback regarding noise level and driving behaviors are provided to the user.

[0009] In yet a further embodiment, users premiums are adjusted based on their overall driving behaviors including noise level in the vehicle.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The features of the invention will become more apparent in the following detailed description in which reference is made to the appended drawings wherein:

[0011] Figure 1 is a block diagram of an exemplary telematic UBI system;

[0012] Figure 2 is a block diagram of some of the components of a mobile device used in then UBI system;

[0013] Figure 3 is a flow chart showing the method 300 of the preferred embodiment;

[0014] Figure 4 is a block diagram of a preferred implementation of the telematic UBI system; and

[0015] Figure 5 is a graph depicting an example correlation between measured Audio level and driving behaviors. DETAILED DESCRIPTION OF THE INVENTION

[0016] Figure 1 illustrates a block diagram of an exemplary telematic UBI system 100 on which the exemplary methods described herein may be implemented. The architecture includes both hardware and software applications as well as various data communication channels for communicated data. At a high-level, information regarding the vehicle 102 and driving habits are collected using a suitable method. In the preferred embodiment, a mobile device such as a smartphone 104 is used as a data collection device. However, other methods of data collection would be known to a person skilled in the art, including but not limited to, a tablet, a smart vehicle controller, an on-board vehicle diagnostic system, sensors within the vehicle, and cameras within the vehicle. Types of metrics typically collected in UBI systems includes but are not limited to, hard braking (sudden deceleration), quick accelerations, hard turning, mobile device use, speed, trip duration, time of day, driving location, etc.

[0017] At a high level, the system uses a mobile device 104 or other collection device known to a person skilled in the art, 104 for metric collection. Metrics are commutated via a communications network 106, preferably a cellular communications network, to a computer means, such as a server 108. The server 108 may include at least one database 110 which is adapted to store data related to one or more driver profdes. In the context of this application, the word database may be used to refer to a single database to the structured data storage, or to multiple databases, multiple structured data storage or a combination thereof. Database 110 is used to store the metric collected by the mobile device 104. As would be known to a person skilled in the art, the sever 108 may further include a processor 112 and memory 114, among other components typically used in UBI systems.

[0018] Figure 2 illustrates a block diagram of some of the components of a mobile device 104 utilized in the preferred embodiment. The mobile device 104 has, installed thereon, a UBI application 202. When the UBI application 202 is running, it collects data using a variety of different sensors within the mobile device 104, including, but not limited to, accelerometer, gyroscope, magnetometer, and GPS sensors. In the present embodiment, the UBI application 202 also utilizes a microphone 204 within the mobile device 104 to collect sound data. The mobile device 104 further includes a processor 206 to process the data, temporary storage 208 to store the data short term and long-term storage 210 to store data collected for longer period of time, for example if someone has been driving out of cellular range. A communication module 212 is also present within the mobile device 104 for communication the collected data via the network 106 to the database 110. The communication module 212 is further capable of receiving data from the server 108 to present to the user on via the UBI application 202.

[0019] Figure 3 is a flow chart showing the method 300 of the preferred embodiment. When a user of UBI application enters a vehicle to drive, they open their UBI application 202 on their mobile device 104 (step 302). This cues the application to begin recording driving metrics using the sensors in the mobile device. The application accesses the microphone and begins recording the ambient noise in the vehicle 304. However, the application does not record the noise in the car, but rather converts the noise to a sound level (for example by measuring decibels) at step 306. It should be appreciated that the UBI application 202 could be configured to measure sound level directly rendering step 306 moot. The noise level metric will then be sent (step 308) via the mobile network 106 to the database 110.

[0020] The noise data, along with the other driving metrics can be used to create correlations between noise level and driving behaviors (step 310). This data can be useful in many ways. As a starting point, most insurance companies have not been measuring noise level or recording noise at all as it is extremely invasive for drivers. This new data will allow insurance companies to first determine if there are any correlations between noise level and driving behaviors which can then be used to determine if premiums should be adjusted (step 314). Furthermore, feedback can be provided back to the user via the UBI application 202 to suggest that they try to reduce ambient noise within their vehicle (step 312).

[0021] The collection of noise levels is yet another metric that could contribute a driver’s safe driving profile. It is known, for example, that a driver will have difficulty hearing other noises when the ambient noise level exceeds 100 decibels. If a driver is consistently driving with loud ambient noise, they can not hear emergency vehicles or other sounds typically encountered while operating a vehicle, making them a potential risk on the road.

[0022] By measuring noise level as opposed to recording sound, insurance companies can gain valuable driving metrics without encountering any issues surrounding privacy and ethics. Simply the noise level is measured, however any details of the conversations or where the noise originated is omitted, retaining the user’s privacy. Furthermore, less memory and cellular data is required to store and transmit noise levels as opposed to sound recordings. This is advantageous in that the UBI application 202 will use less data to communicate with the server 108. This helps make UBI policies more attractive to users with limited data plans. From the insurance company perspective, storing and analyzing noise level data takes less memory and processing power than a sound recording, saving time and resources.

Example of a Preferred Embodiment

[0023] In a preferred embodiment shown in figure 4, the system 100 comprises a vehicle 102, a mobile app 202 and a server 108. The server is preferably under the control of the insurance company. The vehicle 102 is driven by a user 101. In this embodiment, two types of additional correlations are collected. The first pertains to individual negative observable driving behaviors and the second pertains to overall trip outcomes.

[0024] Individual Observable Driving Behaviors

[0025] To collect correlations with respect to individual negative observable driving behaviors (for example, hard breaking, sudden acceleration, etc.), the mobile device senses any observable driving behaviors as well as measuring noise level. The observable behaviors are compared to the noise level at the time of the behavior to see if there is a correlation between the observable behavior and a high noise level. These individual events are preferably stored in a first user specific database 402.

[0026] Figure 5 shows an example chart showing correlated events. The chart depicts audio level via line 452 and observable driving behaviors, which are listed down the left side. The “X”s 454 mark the occurrence of a negative observable driving behavior. It can then be determined if the noise level in the car was a factor that may be correlated with the occurrence of the negative driving behavior. In this depiction of data collected during a trip, the audio level is relatively low at the start of the trip 456 and raises as the trip proceeds towards the end of the trip 458. There are several negative observable driving behaviors 454 recorded during the trip. A correlated event is determined when a negative observable driving behavior such as hard breaking, sudden acceleration, speeding, etc. occurs at the same time as an increase in or high sound level in the vehicle. In figure 5, three different correlated events 450a, 450b and 450c are shown. The first correlated event 450a correlates a high- volume level with hard breaking and heavy acceleration. Speeding and heavy acceleration are correlated with a high noise level in the second correlated event 450b and finally, hard breaking is correlated with a high noise level in correlated event 450c.

[0027] Overall Trip Outcomes

[0028] In some cases, there may be no negative observable driving behaviors, but the trip may still have a negative trip outcome, for example, an accident. The noise data leading up to and at the point of the negative trip outcome can also be used to determine if there is a correlation between noise level and negative trip outcomes.

[0029] With reference to figure 4, once the trip has ended, the application determines if there has been a negative outcome (i.e. and accident) that is correlated to increased noise level. This correlation data is preferably stored on the user’s mobile device 104 in a second database 404. However, it can be appreciated that the overall trip correlated events could also be stored in the first database 402. Alternatively, both the observable driving behavior correlated events 450a-c and overall trip correlated events 460 could be sent to the server 108 for storage and possible later retrieval by the mobile device 104. Both the correlated events 450a-c and the overall trip correlated events 460 are further stored in a server database 406 which contains all of the observable driving behavior correlated events and overall trip correlated events of all drivers enrolled in the program.

[0030] How the Correlations Relate to Risk Scores

[0031] The overall correlated events of the user 101 are included in a collection of driving data collected from all drivers in the program (stored in database 406). The noise level, in combination with other factors, such as observable driving behaviors, are used to determine the user’s risk of a negative trip outcome at 408 of figure 4 (for example, risk of an accident). This is typically in the form of a risk rating, for example on a scale of 1 to 100, although other methods of determining a user’s risk would be known to a person skilled in the art. The risk rating for the user is tracked in a database 410, preferably at the server, although it could also be calculated at the server and then communicated and stored at the mobile device. The risk ratings calculated over multiple trips and time periods are used to determine an appropriate premium for an individual driver. The risk score can also be used in combination with, or as a means of modifying, other rating variables. For example, sound- based risk score may be used to increase or decrease the weight of other known/traditional rating variables. For example if there is a known correlation between traditional variables such as distraction and claims, a high sound-score could increase the weight of those traditional variables in the risk rating calculation. For example, a high “sound score” paired with an age lower than 25 and a majority of urban trips may cause age and urban/rural driving to be weighted more heavily.

[0032] The risk rating is further used determine if feedback should be presented to the user. A database of possible feedback 412 can be stored, preferably at the mobile device. Depending on the risk rating, feedback such as “It’s too loud in the vehicle” can be sent to the user at a noise level that correlates to their risk rating. Alternatively, or additionally, the feedback feature could also be used to flag instances where noise in the vehicle is loud enough to prevent a driver from hearing emergency vehicles or horns.

[0033] It should be noted that since a user’s driving behavior is collected along with the noise level in the vehicle, a tolerable noise level is individualized to each particular user. Some users may have a high tolerance to noise and show no or few negative driving behaviors when the noise in the car is high, while others may show frequent negative observable driving behaviors with a relatively low noise level. Thus, one driver may receive feedback only when the noise level is very high, while the other may receive feedback at a fairly low noise level. One advantage of this system is that as the noise level begins to increase to a user’s tolerable level, a feedback message can be provided to alert the user that the noise is quite high. This allows the system to take into account each user’s individual tolerance to noise and provides predictive feedback tailored to the specific user. While this is one way to determine how and what feedback should be provided, other methods would be known to a person skilled in the art.

[0034] Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto. The entire disclosures of all references recited above are incorporated herein by reference.

Claims

What is claimed is:

1. A method of detection of sound in usage based insurance comprising the steps of: measuring noise level in a vehicle; communicating the noise level measurement to a database.

2. The method of claim 1 further comprising; using the noise level measurement and other metrics collected in the same timeframe, to determine user specific correlations between noise level and driving behavior.

3. The method of claim 2 further comprising: using the noise level measurement and other metrics collected in the same timeframe to determine user specific correlations between noise levels and negative driving trip outcomes.

4. The method of claim 3 further comprising providing feedback regarding noise level and driving behaviors to the user.

5. The method of claim 4 further comprising adjusting a users premiums based on their overall driving behaviors including noise level in the vehicle.

6. The method of claim 3 further comprising comparing the user specific correlations between noise level and driving behavior to a database having all of the correlations between noise level and driving behavior for all users enrolled in a usage based insurance program.

7. The method of claim 6 further comprising using the comparison of the user specific correlations between noise level and driving behavior to a database having all of the correlations between noise level and driving behavior for all users enrolled in a usage based insurance program to determine a user specific risk rating.

8. A system for detection of sound in usage based insurance comprising; a mobile device coupled to a communication network; at least one database for storing driver metrics; and a processing unit; the mobile device configured to measure and record noise level and observable driving behaviors and send the measurement to the at least one database; said processing unit configured to retrieve the measured noise levels and compare the noise levels to measured observable driving behaviors.

9. The system of claim 8 wherein the at least one database is multiple databases comprising: a first database for storing user specific correlations between observable driving behaviors and noise level; a second database for storing user specific correlations between negative trip outcomes and noise level; and a third database for storing all correlations between observable driving behaviors and noise level, and correlations between negative trip outcomes and noise level for all users; wherein said processing unit is configured to compare the user specific correlations between negative trip outcomes and noise level and the user specific correlations between negative trip outcomes and noise level to the all correlations between observable driving behaviors and noise level, and correlations between negative trip outcomes and noise level for all users to determine a user specific risk rating.

10. The system of claim 9 wherein the first database is located in a memory unit in the mobile device.

11. The system of claim 9 wherein the second database is located in a memory unit in the mobile device.

12. The system of claim 10 wherein the second database is located in a memory unit in the mobile device.

13. The system of claim 9 wherein the third database is located in a memory unit in a server.