Patent Description:
Aspects of the disclosure generally relate to the analysis of sensor data obtained from a mobile device within an interior of a vehicle. In particular, various aspects of the disclosure relate to receiving and transmitting sensor data, and analyzing the data using classification machine learning algorithms to detect braking events.

Insurance companies value the safety of drivers and the general public. Detecting likely braking events in a particular vehicle and issuing notifications to nearby vehicles promotes safety. Although techniques exist to generally capture data from sensors on smartphones and in vehicles, they might not provide power-efficient methods of doing so. Further, these techniques may not notify nearby drivers of likely braking events. <CIT> discloses monitoring a vehicle operator, the environment ahead of the vehicle, and/or forces acting on the vehicle during the course of vehicle operation to determine whether the vehicle operator is impaired log data relating to vehicle operator impairment for further analysis and send the data to a server for analysis.

The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of the disclosure. It is neither intended to identify key or critical elements of the disclosure nor to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below. According to a first aspect of the invention there is provided a method in accordance with claim <NUM>. According to a second aspect of the invention, there is provided one or more tangible non-transitory computer-readable storage media storing computer-executable instructions for performing a computer process on a computing system according to claim <NUM>.

Advantageous solutions to the problems presented above, and other issues which will be apparent upon the reading of the present disclosure, may be to collect sensor data from sensors associated with a mobile device within a vehicle during a window of time using a polling frequency. In some examples, the sensor data may be raw sensor data. The sensors may comprise a GPS receiver, an accelerometer, a gyroscope, and the like. Accordingly, the raw sensor data may be processed to determine information relating to a location, a speed, and an acceleration of the vehicle. The polling frequency is determined based on the speed of the vehicle and may be determined based on a battery status of the mobile device, traffic information within a first threshold radius of the vehicle, and weather information within a second threshold radius of the vehicle.

In accordance with further aspects of the present disclosure, a method disclosed herein may include collecting raw sensor data from sensors associated with a mobile device within a vehicle during a window of time using a polling frequency. The sensors may comprise a GPS receiver, an accelerometer, and a gyroscope. Accordingly, the raw sensor data may be processed to determine information relating to a location, a speed, and an acceleration of the vehicle. The polling frequency is determined based on the speed of the vehicle and may be determined based on a battery status of the mobile device, traffic information within a first threshold radius of the vehicle, and weather information within the second threshold radius of the vehicle.

In accordance with further aspects of the present disclosure, a computer-assisted method of detecting braking events disclosed herein may include collecting raw sensor data from sensors associated with a mobile device within a vehicle during a window of time using a polling frequency. The sensors may comprise a GPS receiver, an accelerometer, and a gyroscope. Accordingly, the raw sensor data may be processed to determine information relating to a location, a speed, and an acceleration of the vehicle. The polling frequency is determined based, at least in part, on the speed of the vehicle, and may be determined based on a battery status of the mobile device, traffic information within a first threshold of the vehicle, and weather information within a second threshold radius of the vehicle, where the first threshold radius is smaller than the second threshold radius.

Other features and advantages of the disclosure will be apparent from the additional description provided herein.

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:.

In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration, various embodiments of the disclosure that may be practiced. It is to be understood that other embodiments may be utilized.

As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a method, a specially-programmed computer system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).

<FIG> illustrates a block diagram of a braking event detection system <NUM> in a fused sensor data analysis system <NUM> that may be used according to one or more illustrative embodiments of the disclosure. The braking event detection system <NUM> may have a processor <NUM> for controlling overall operation of the braking event detection system <NUM> and its associated components, including RAM <NUM>, ROM <NUM>, input/output module <NUM>, and memory <NUM>. The braking event detection system <NUM>, along with one or more additional devices (e.g., terminals <NUM>, <NUM>) may correspond to one or more special-purpose computing devices, such as fused sensor data analysis computing devices or systems, including mobile computing devices (e.g., smartphones, smart terminals, tablets, and the like) and vehicular-based computing devices, configured as described herein for collecting and analyzing fused sensor data from mobile devices associated with vehicles, detecting braking events, and issuing notifications regarding the braking events.

Input/Output (I/O) <NUM> may include a microphone, keypad, touch screen, and/or stylus through which a user of the braking event detection system <NUM> may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory <NUM> and/or storage to provide instructions to processor <NUM> for enabling the braking event detection system <NUM> to perform various functions. For example, memory <NUM> may store software used by the braking event detection system <NUM>, such as an operating system <NUM>, application programs <NUM>, and an associated internal database <NUM>. Processor <NUM> and its associated components may allow the braking event detection system <NUM> to execute a series of computer-readable instructions to transmit or receive fused sensor data, analyze fused sensor data, detect braking events, and issue notifications.

The braking event detection system <NUM> may operate in a networked environment supporting connections to one or more remote computers, such as terminals/devices <NUM> and <NUM>. The braking event detection system <NUM>, and related terminals/devices <NUM> and <NUM>, may be in signal communication with special-purpose devices installed in vehicles, mobile devices that may travel within vehicles, or devices outside of vehicles that are configured to receive and process fused sensor data. Thus, the braking event detection system <NUM> and terminals/devices <NUM> and <NUM> may each include personal computers (e.g., laptop, desktop, or tablet computers), servers (e.g., web servers, database servers), vehicle-based devices (e.g., on-board vehicle computers, short-range vehicle communication systems, telematics devices), or mobile communication devices (e.g., mobile phones, portable computing devices, and the like), and may include some or all of the elements described above with respect to the braking event detection system <NUM>.

The network connections depicted in <FIG> include a local area network (LAN) <NUM> and a wide area network (WAN) <NUM>, and a wireless telecommunications network <NUM>, but may also include other networks. When used in a LAN networking environment, the braking event detection system <NUM> may be connected to the LAN <NUM> through a network interface or adapter <NUM>. When used in a WAN networking environment, the braking event detection system <NUM> may include a modem <NUM> or other means for establishing communications over the WAN <NUM>, such as network <NUM> (e.g., the Internet). When used in a wireless telecommunications network <NUM>, the braking event detection system <NUM> may include one or more transceivers, digital signal processors, and additional circuitry and software for communicating with wireless computing devices <NUM> (e.g., mobile phones, short-range vehicle communication systems, vehicle telematics devices) via one or more network devices <NUM> (e.g., base transceiver stations) in the wireless network <NUM>.

It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various network protocols such as TCP/IP, Ethernet, FTP, HTTP and the like, and of various wireless communication technologies such as GSM, CDMA, WiFi, and WiMAX, is presumed, and the various computing devices and mobile device location and configuration system components described herein may be configured to communicate using any of these network protocols or technologies.

Also illustrated in <FIG> is a security and integration layer <NUM>, through which communications may be sent and managed between the braking event detection system <NUM> (e.g., a user's personal mobile device, a vehicle-based system, external server, etc.) and the remote devices (<NUM> and <NUM>) and remote networks (<NUM>, <NUM>, and <NUM>). The security and integration layer <NUM> may comprise one or more separate computing devices, such as web servers, authentication servers, and/or various networking components (e.g., firewalls, routers, gateways, load balancers, etc.), having some or all of the elements described above with respect to the braking event detection system <NUM>. As an example, a security and integration layer <NUM> of a mobile computing device, vehicle-based device, or a server operated by an insurance provider, financial institution, governmental entity, or other organization, may comprise a set of web application servers configured to use secure protocols and to insulate the braking event detection system <NUM> from external devices <NUM> and <NUM>. In some cases, the security and integration layer <NUM> may correspond to a set of dedicated hardware and/or software operating at the same physical location and under the control of same entities as the braking event detection system <NUM>. For example, layer <NUM> may correspond to one or more dedicated web servers and network hardware in an organizational datacenter or in a cloud infrastructure supporting a cloud-based mobile device location and configuration system. In other examples, the security and integration layer <NUM> may correspond to separate hardware and software components which may be operated at a separate physical location and/or by a separate entity.

As discussed below, the data transferred to and from various devices in fused sensor data analysis system <NUM> may include secure and sensitive data, such as driving data, driving locations, vehicle data, and confidential individual data such as insurance data associated with vehicle occupants. In at least some examples, transmission of the data may be performed based on one or more user permissions provided. Therefore, it may be desirable to protect transmissions of such data by using secure network protocols and encryption, and also to protect the integrity of the data when stored on in a database or other storage in a mobile device, analysis server, or other computing devices in the fused sensor data analysis system <NUM>, by using the security and integration layer <NUM> to authenticate users and restrict access to unknown or unauthorized users. In various implementations, security and integration layer <NUM> may provide, for example, a file-based integration scheme or a service-based integration scheme for transmitting data between the various devices in the fused sensor data analysis system <NUM>. Data may be transmitted through the security and integration layer <NUM>, using various network communication protocols. Secure data transmission protocols and/or encryption may be used in file transfers to protect to integrity of the driving data, for example, File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and/or Pretty Good Privacy (PGP) encryption.

In other examples, one or more web services may be implemented within the braking event detection system <NUM> in the fused sensor data analysis system <NUM> and/or the security and integration layer <NUM>. The web services may be accessed by authorized external devices and users to support input, extraction, and manipulation of the data (e.g., driving data, location data, confidential personal data, etc.) between the braking event detection system <NUM> in the fused sensor data analysis system <NUM>. Web services built to support the fused sensor data analysis system <NUM> may be cross-domain and/or cross-platform, and may be built for enterprise use. Such web services may be developed in accordance with various web service standards, such as the Web Service Interoperability (WS-I) guidelines. In some examples, a movement data and/or driving data web service may be implemented in the security and integration layer <NUM> using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to provide secure connections between servers (e.g., braking event detection devices <NUM>) and various clients <NUM> and <NUM> (e.g., mobile devices, data analysis servers, etc.). SSL or TLS may use HTTP or HTTPS to provide authentication and confidentiality.

In other examples, such web services may be implemented using the WS-Security standard, which provides for secure SOAP messages using XML encryption. In still other examples, the security and integration layer <NUM> may include specialized hardware for providing secure web services. For example, secure network appliances in the security and integration layer <NUM> may include built-in features such as hardware-accelerated SSL and HTTPS, WS-Security, and firewalls. Such specialized hardware may be installed and configured in the security and integration layer <NUM> in front of the web servers, so that any external devices may communicate directly with the specialized hardware.

Although not shown in <FIG>, various elements within memory <NUM> or other components in the fused sensor data analysis system <NUM>, may include one or more caches, for example, CPU caches used by the processing unit <NUM>, page caches used by the operating system <NUM>, disk caches of a hard drive, and/or database caches used to cache content from database <NUM>. For embodiments including a CPU cache, the CPU cache may be used by one or more processors in the processing unit <NUM> to reduce memory latency and access time. In such examples, a processor <NUM> may retrieve data from or write data to the CPU cache rather than reading/writing to memory <NUM>, which may improve the speed of these operations. In some examples, a database cache may be created in which certain data from a database <NUM> (e.g., a driving database, a vehicle database, insurance customer database, etc.) is cached in a separate smaller database on an application server separate from the database server. For instance, in a multi-tiered application, a database cache on an application server can reduce data retrieval and data manipulation time by not needing to communicate over a network with a back-end database server. These types of caches and others may be included in various embodiments, and may provide potential advantages in certain implementations of retrieving and analyzing fused sensor data, such as faster response times and less dependence on network conditions when transmitting/receiving fused sensor data, vehicle data, occupant data, etc..

It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various network protocols such as TCP/IP, Ethernet, FTP, HTTP and the like, and of various wireless communication technologies such as GSM, CDMA, WiFi, and WiMAX, is presumed, and the various computer devices and system components described herein may be configured to communicate using any of these network protocols or technologies.

Additionally, one or more application programs <NUM> may be used by the braking event detection system <NUM> within the fused sensor data analysis system <NUM> (e.g., braking event detection software applications, and the like), including computer executable instructions for receiving and storing data from fused sensors of mobile devices, and/or vehicle-based systems, analyzing the fused sensor data to determine whether there is a braking event, issuing notifications regarding the braking event, and/or performing other related functions as described herein.

<FIG> is an illustration of an example implementation of a fused sensor data analysis system <NUM>. The fused sensor data analysis system <NUM> may be similar to and/or may include some or all of the components of the fused sensor data analysis system <NUM> in <FIG>. The system <NUM>, in this example, includes a braking event detection system <NUM>. The system <NUM>, in this example, includes a braking event detection system <NUM>. The braking event detection system <NUM>, described in further detail below, detects braking events for a vehicle. The braking event detection system <NUM> may be similar to and/or may include some or all of the components of the braking event detection system <NUM> in <FIG>. In some examples, the braking event detection system <NUM> may detect a braking event based on fused sensor data received from one or more mobile devices associated with the vehicle. Fused sensor data may include raw sensor data received from one or more sensors of a mobile device <NUM> and/or a vehicle <NUM>, derived sensor data (e.g., outputs from statistical computations on raw sensor data), and/or processed data (e.g., outputs from smoothing algorithms applied on the raw sensor data and/or the derived data). In some examples, fused sensor data may include an aggregation of raw sensor data received from one or more sensors of a mobile device <NUM> and/or a vehicle <NUM>, derived sensor data (e.g., outputs from statistical computations on the raw data), and processed data (e.g., outputs from smoothing algorithms applied on the raw data and/or the derived data) associated with operation of a vehicle with respect to, e.g., accelerating, decelerating, braking, turning, signaling, lane usage, adequate vehicle spacing, speed, distraction management, and other driving-related operations performed by a driver of the vehicle as captured by sensors of, for example, a mobile device (e.g., a mobile device on board or associated with the vehicle). Collectively, this data may be referred to as fused sensor data. In some arrangements, the mobile device may be in signal communication with the vehicle or various systems or components of the vehicle, the braking event detection system <NUM>, and one or more external systems (e.g., an insurance system <NUM>).

The example fused sensor data analysis system <NUM> may contain some or all of the hardware/software components as the fused sensor data analysis system <NUM> depicted in <FIG>. The braking event detection system <NUM> is a special-purpose computing device that is configured to receive fused sensor data (e.g., raw sensor data, signals and the like) from a mobile device <NUM> located within a vehicle <NUM>. The braking event detection system <NUM> may initiate communication with, retrieve data from, or receive raw fused sensor data (e.g., signals) from one or more sensors within a mobile device <NUM> wirelessly over one or more computer networks (e.g., the Internet), where the mobile device <NUM> is located within a vehicle <NUM>. The braking event detection system <NUM> may also be configured to receive driving data from a vehicle <NUM> wirelessly via telematics devices <NUM>, or by way of separate computing systems (e.g., computer <NUM>) over one or more computer networks (e.g., the Internet). Further, the braking event detection system <NUM> may be configured to receive driving vehicle-related data from one or more third-party telematics systems or non-vehicle data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, construction zones, school zones, and natural disasters, etc.).

A mobile device <NUM> in the fused sensor data analysis system <NUM> may be, for example, any mobile device, such as a smartphone, tablet computing device, personal digital assistant (PDA), smart watch, netbook, laptop computer, and other like devices found within a vehicle <NUM>. As used herein, a mobile device <NUM> "within" the vehicle <NUM> includes mobile devices that are inside of or otherwise secured to a vehicle, for instance, in the cabins of a vehicle. The mobile device <NUM> includes a set of mobile device sensors <NUM>, which may include, for example, a GPS receiver <NUM>, an accelerometer <NUM>, a gyroscope <NUM>, a microphone <NUM>, a camera <NUM>, and a magnetometer <NUM>. The mobile device sensors <NUM> may be capable of detecting and recording various conditions at the mobile device <NUM> and operational parameters of the mobile device <NUM>. For example, sensors <NUM> may detect and store data corresponding to the mobile device's location (e.g., GPS coordinates), speed and direction in one or multiple axes (forward and back, left and right, and up and down for example), rates of acceleration or deceleration, specific instances of sudden acceleration, deceleration, and lateral movement, and other data which may be indicative of a vehicle braking event. Additional sensors <NUM> may include audio sensors, video sensors, signal strength sensors, communication network-presence sensors, ambient light sensors, temperature/humidity sensors, and/or barometer sensors, which may be used to, for example, listen to audio signals indicating a door locking/unlocking, door chime, or vehicle ignition, sensing light from an overhead or dashboard light, detecting a temperature or humidity change indicative of entering a vehicle, and/or detecting a presence of a network or communication device associated with a vehicle (e.g., a BLUETOOTH transceiver associated with a vehicle).

Software applications executing on mobile device <NUM> may be configured to detect certain driving data independently using mobile device sensors <NUM>. For example, mobile device <NUM> may be equipped with sensors <NUM>, such as a GPS receiver <NUM>, an accelerometer <NUM>, a gyroscope <NUM>, a microphone <NUM>, a camera <NUM>, and/or a magnetometer <NUM>, and may determine vehicle location, speed, acceleration/deceleration, direction and other basic driving data without needing to communicate with the vehicle sensors <NUM>, or any vehicle system. In other examples, software on the mobile device <NUM> may be configured to receive some or all of the driving data collected by vehicle sensors <NUM>.

Additional sensors <NUM> may detect and store external conditions. For example, audio sensors and proximity sensors <NUM> may detect other nearby mobile devices, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a braking event data analysis.

Data (e.g., raw data or signal) collected by the mobile device sensors <NUM> may be stored, processed, and/or analyzed within the mobile device <NUM>, and/or may be transmitted to one or more external devices for processing, analysis, and the like. For example, as shown in <FIG>, raw sensor data, signals, etc. collected by the mobile device sensors <NUM> may be transmitted to a braking event detection system <NUM>. In some examples, the data collected by the mobile device sensors <NUM> may be stored, processed, and/or analyzed at the vehicle <NUM> by an on-board computing device in the vehicle or by the mobile device <NUM>, and/or may be transmitted to one or more external devices (e.g., an insurance system <NUM>). For example, sensor data may be exchanged (uni-directionally or bi-directionally) between vehicle <NUM> and mobile device <NUM>.

Data may be transmitted between the mobile device <NUM> and the vehicle <NUM> via wireless networks, including those discussed above, or short-range communication systems. Short-range communication systems are data transmission systems configured to transmit and receive data between nearby devices. In this example, short-range communication systems may be used to transmit sensor data to other nearby mobile devices and/or vehicles, and to receive sensor data from other nearby mobile devices and/or vehicles. Short-range communication systems may be implemented using short-range wireless protocols such as WLAN communication protocols (e.g., IEEE <NUM>), Bluetooth (e.g., IEEE <NUM>. <NUM>), or one or more of the Communication Access for Land Mobiles (CALM) wireless communication protocols and air interfaces. The transmissions between the short-range communication systems may be sent via Bluetooth, satellite, GSM infrared, IEEE <NUM>, WiMAX, RFID, and/or any suitable wireless communication media, standards, and protocols. In certain systems, short-range communication systems may include specialized hardware installed in vehicle <NUM> and/or mobile device <NUM> (e.g., transceivers, antennas, etc.), while in other examples the communication systems may be implemented using existing hardware components (e.g., radio and satellite equipment, navigation computers) or may be implemented by software running on the mobile device <NUM> and/or on an on-board computing device within the vehicle <NUM>.

The vehicle <NUM> may be, for example, an automobile, motorcycle, scooter, bus, recreational vehicle, boat, bicycle, or other vehicle for which braking events may be detected. The vehicle <NUM> may include one or more sensors <NUM>, which are capable of detecting and recording various conditions at the vehicle and operating parameters of the vehicle. For example, the sensors <NUM> may detect, transmit, or store data corresponding to the vehicle's location (e.g., GPS coordinates), speed and direction, rates of acceleration, deceleration, and/or may detect transmit specific instances of sudden acceleration, sudden deceleration, and swerving. The sensors <NUM> may also detect, transmit, or store data received from the vehicle's internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems. Thus, in some examples, the braking event detection system <NUM> may acquire information about the vehicle <NUM> directly from the vehicle <NUM>.

Additional sensors <NUM> may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility. Additional sensors <NUM> may also detect and store data relating to compliance with traffic laws and the observance of traffic signals and signs. Additional sensors <NUM> may further detect and store data relating to the maintenance of the vehicle <NUM>, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), tire pressure, or combinations thereof.

The vehicle <NUM> may also include cameras or proximity sensors <NUM> capable of recording additional conditions inside or outside of the vehicle <NUM>. For example, internal cameras <NUM> may detect conditions such as the number of passengers and the types of passengers (e.g., adults, children, teenagers, handicapped, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, unsecured objects in the vehicle). Sensors <NUM> also may be configured to collect data a driver's movements or the condition of a driver. For example, the vehicle <NUM> may include sensors <NUM> that monitor a driver's movements, such as the driver's eye position and/or head position, etc. Additional sensors <NUM> may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication. The condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer. Further, the vehicle <NUM> may include sensors <NUM> that capable of detecting other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into an analysis of vehicle telematics data. Certain vehicle sensors <NUM> also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g., commute, errand, new route, etc.). A Global Positioning System (GPS), locational sensors positioned inside the vehicle <NUM>, and/or locational sensors or devices external to the vehicle <NUM> may be used determine the route, trip type (e.g., commute, errand, new route, etc.), lane position, and other vehicle position or location data.

The data collected by the vehicle sensors <NUM> may be stored or analyzed within the respective vehicle <NUM> by an on-board computing device or mobile device <NUM>, or may be transmitted to one or more external devices. For example, as shown in <FIG>, raw sensor data may be transmitted to a braking event detection system <NUM>, which may be a collection of special-purpose computing devices that are interconnected and in signal communication with each other. The special-purpose computing devices may be programmed with a particular set of instructions that, when executed, perform functions associated processing the raw sensor data to detect braking events and generate and/or issue notifications to other vehicles regarding the braking events. As such, a braking event detection system <NUM> may be a separate special-purpose computing device or may be integrated into one or more components within the vehicle <NUM>, such as the telematics device <NUM>, or in the internal computing systems (e.g., on-board vehicle computing device) of the vehicle <NUM>. Additionally, the sensor data may be transmitted as vehicle telematics data via a telematics device <NUM> to one or more remote computing devices, such as a braking event detection system <NUM>. A telematics device <NUM> may be a computing device containing many or all of the hardware/software components as the braking event detection system <NUM> depicted in <FIG>. As discussed above, the telematics device <NUM> may receive vehicle telematics data from vehicle sensors <NUM>, and may transmit the data to one or more external computer systems (e.g., an insurance system <NUM>) over a wireless network. Telematics devices <NUM> also may be configured to detect or determine additional types of data relating to real-time driving and the condition of the vehicle <NUM>. In certain embodiments, the telematics device <NUM> may contain or may be integral with one or more of the vehicle sensors <NUM>. The telematics device <NUM> may also store the type of the vehicle <NUM>, for example, the make, model, trim (or sub-model), year, and/or engine specifications, as well as other information such as vehicle owner or driver information, insurance information, and financing information for the vehicle <NUM>.

In the example shown in <FIG>, the telematics device <NUM> may receive vehicle telematics data from vehicle sensors <NUM>, and may transmit the data to a braking event detection system <NUM>. However, in other examples, one or more of the vehicle sensors <NUM> may be configured to transmit data directly to a braking event detection system <NUM> without using a telematics device <NUM>. For instance, a telematics device <NUM> may be configured to receive and transmit data from certain vehicle sensors <NUM>, while other sensors may be configured to directly transmit data to a braking event detection system <NUM> without using the telematics device <NUM>. Thus, telematics devices <NUM> may be optional in certain embodiments.

In certain embodiments, the mobile device <NUM> within the vehicle <NUM> may be programmed with instructions to collect vehicle telematics data from the telematics device <NUM> or from the vehicle sensors <NUM>, and then to transmit the vehicle telematics data to the braking event detection system <NUM> and other external computing devices. For example, the mobile device <NUM> may transmit the vehicle telematics data directly to a braking event detection system <NUM>, and thus may be used in conjunction with or instead of the telematics device <NUM>. Moreover, the processing components of the mobile device <NUM> may be used to collect and analyze vehicle telematics data to detect braking events, issue notifications to other vehicles regarding braking events, and perform other related functions. Therefore, in certain embodiments, the mobile device <NUM> may be used in conjunction with or instead of the braking event detection unit <NUM>.

The vehicle <NUM> may include a braking event detection unit <NUM>, which may be a separate computing device or may be integrated into one or more other components within the vehicle <NUM>, such as the telematics device <NUM>, the internal computing systems of the vehicle <NUM>, and/or the mobile device <NUM>. In some examples, the mobile device <NUM> may include a braking event detection unit <NUM> which may be a device separate and independent from the braking event detection unit <NUM> of the vehicle <NUM>. The braking event detection units <NUM> and <NUM> may alternatively be implemented by computing devices separate and independent from the vehicle <NUM> and the mobile device <NUM>, such as one or more computer systems <NUM>. In any of these examples, the braking event detection units <NUM> and <NUM> may contain some or all of the hardware/software components as the braking event detection system <NUM> depicted in <FIG>.

The braking event detection units <NUM> and <NUM> may be implemented in hardware and/or software configured to receive raw sensor data from the vehicle sensors <NUM> and the mobile device sensors <NUM> respectively, and/or other vehicle telematics data sources. The braking event detection unit <NUM> may further be configured to receive raw sensor data from a telematics device <NUM>. After receiving the raw sensor data and vehicle telematics data, the braking event detection units <NUM> and <NUM> may process the raw data and/or analyze the raw sensor data and vehicle telematics data to determine whether a braking event occurred during a particular window of time. One or more notifications may be generated based on the determination and/or issued to other nearby mobile devices and vehicles. For example, the braking event detection units <NUM> and <NUM> may analyze the sensor data collected from the mobile sensors <NUM> and the vehicle sensors <NUM>. The braking event detection units <NUM> and <NUM> may then apply machine learning algorithms to the collected sensor data to determine whether a particular window of time should be classified as a braking event. In examples where a window of time is classified as a braking event, the braking event detection units <NUM> and <NUM> may notify nearby vehicles and associated mobile devices regarding the braking event.

Further, in certain implementations, the functionality of the braking event detection units <NUM> and <NUM>, such as collecting and analyzing sensor data to detect braking events, and issuing notifications to nearby mobile devices and vehicles regarding the braking events, may be performed in a braking event detection system <NUM> rather than by the individual vehicle <NUM> or mobile device <NUM>. In such implementations, the vehicle <NUM> or mobile device <NUM> may only collect and transmit sensor data to a braking event detection system <NUM>, and thus the braking event detection units <NUM> and <NUM> may be optional. Thus, in various examples, the analyses and actions performed within the braking event detection units <NUM> and <NUM> may be performed entirely within the braking event detection units <NUM> and <NUM>, entirely within the braking event detection system <NUM>, or in some combination of the two. For instance, the braking event detection units <NUM> and <NUM> may continuously receive and analyze sensor data and determine whether the sensor data indicates a change in acceleration/deceleration is above a predefined threshold. While the changes in acceleration/deceleration are below the predefined threshold (i.e., there is minimal likelihood of a braking event), the braking event detection units <NUM> and <NUM> may continue to receive and analyze data, such that large or repetitive amounts of data need not be transmitted to the braking event detection system <NUM>. However, upon detecting a change in acceleration/deceleration above the predefined threshold, the braking event detection units <NUM> and <NUM> may transmit the sensor data to the braking event detection system <NUM>, such that the braking event detection system <NUM> may apply machine learning algorithms to determine whether a braking event has occurred. In these examples, the braking event detection units <NUM> and <NUM> may control the type of data and the amount of data transmitted to the braking event detection system <NUM> for processing.

Detailed descriptions and examples of the analyses that may be performed by the braking event detection units <NUM> and <NUM> and/or by the braking event detection system <NUM> are described below.

<FIG> shows an example implementation of a braking event detection system <NUM>. In some example implementations, the braking event detection system <NUM> is a special-purpose computing device programmed with instructions, that when executed, perform functions associated with collecting or receiving raw sensor data from mobile devices and vehicles during a window of time, processing the raw sensor data, determining whether a braking event likely occurred during the window of time, and generating and/or issuing notifications to nearby mobile devices and vehicles where a braking event likely occurred. In these example implementations, the units <NUM>-<NUM> of the braking event detection system <NUM> correspond to particular sets of instructions embodied as software programs residing at the braking event detection system <NUM>. In other example implementations, the braking event detection system <NUM> is a collection of special-purpose computing devices that are interconnected and in signal communication with each other. In these examples, each unit or device <NUM>-<NUM> of the braking event detection system <NUM> respectively corresponds to a special-purpose computing device programmed with a particular set of instructions, that, when executed, perform respective functions associated with collecting sensor data from mobile devices and vehicles during a window of time, processing the sensor data, determining whether a braking event likely occurred during the window of time, and issuing notifications to nearby mobile devices and vehicles where a braking event likely occurred. Such special-purpose computing devices may be, for example, application servers programmed to perform the particular set of functions.

The braking event detection system <NUM>, in this example, includes various modules, units and databases that facilitate collecting and processing raw sensor data during a window of time, determining whether a braking event likely occurred during the window of time, and issuing notifications to nearby mobile devices and vehicles where a braking event likely occurred. It will be appreciated that the braking event detection system <NUM> illustrated in <FIG> is shown by way of example, and that other implementations of a braking event detection system may include additional or alternative modules, units, devices, and/or databases without departing from the scope of the claimed subject matter. In this example, the braking event detection system <NUM> includes a sensor data collection module <NUM>, a sensor data processing module <NUM>, a sensor data calibration module <NUM>, a braking event classification module <NUM>, a braking event notification module <NUM>, and a data store <NUM>. Each module may include hardware and/or software configured to perform various functions within the braking event detection system <NUM>. Further, each module may be a separate and distinct computing device or one or more modules may be integrated into a single computing device.

The data store <NUM> may store information relating to the determination of whether sensor data represents a braking event, information relating to the drivers of the vehicle <NUM>, information relating to the mobile device <NUM>, information relating to nearby vehicles, and information relating to nearby mobile devices. For example, the data store <NUM> may include a braking event classification model <NUM>, and a driver information database <NUM>. It will be appreciated that in other examples, the data store <NUM> may include additional and/or alternative database.

In this example, the braking event classification model <NUM> may store information relating to one or more classification machine learning algorithms, including random forest, k-means clustering, neural network, support vector machine, etc.. The classification machine learning algorithms may be used by the braking event detection system <NUM> to determine whether or not sensor data collected during or representing a particular window of time likely represents a braking event. As such, the classification machine learning algorithms may classify as a window of time into <NUM> classes: a likely braking event, and an unlikely braking event. A classification machine learning algorithm may be based on various features relating to the sensor data. The features may include sensor data collected from the mobile sensors <NUM>, the vehicle sensors <NUM>, and any other vehicle telematics data. The features may also include data derived by performing statistical calculations (e.g., calculating a maximum value, minimum value, standard deviation, variance, absolute value, mean, median, etc.) or post-processing (e.g., reducing redundancies, reducing noise, etc.) on the sensor data collected from the mobile sensors <NUM>, the vehicle sensors <NUM>, and any other vehicle telematics data. In some examples, the features used by the classification machine learning algorithm may have different levels of importance, such that some features are more indicative of a likely braking event than others. Accordingly, the classification machine learning algorithm may assign various weights to the features.

The driver information database <NUM> may store information associated with drivers of the vehicles <NUM> (e.g., name of driver, vehicle identification, one or more associated mobile devices, etc.) and information associated with drivers of nearby vehicles (e.g., name of driver, vehicle identification, one or more associated mobile devices, etc.). In some examples, the driver information database <NUM> may also store the driver's affiliation with one or more insurance companies.

<FIG> is a flowchart <NUM> of example steps for determining whether sensor data for a particular window of time likely represents a braking event. The various components of the braking event detection system <NUM> and/or the braking event detection unit <NUM> of the mobile device <NUM> may be used to perform these method steps. In step <NUM>, the sensor data collection module <NUM> may receive raw sensor data during a window of time (or data from a window of time) from the one or more sensors <NUM> installed at, attached to, and/or remotely located relative to the mobile device <NUM>. In some examples, the mobile device <NUM> may collect sensor data from the one or more sensors <NUM> and transmit the sensor data to the braking event detection system <NUM> in real-time. As such, the mobile device <NUM> may broadcast the sensor data to the braking event detection system <NUM>. In other examples, the mobile device <NUM> may collect the sensor data from the one or more sensors <NUM>, transmit the sensor data to the braking event detection unit <NUM> in real-time, and the braking event detection unit <NUM> may transmit the sensor data to the braking event detection system <NUM>. The braking event detection unit <NUM> may or may not transmit the sensor data to the braking event detection system <NUM> in real-time. For instance, the braking event detection unit <NUM> may begin to collect sensor data from the one or more sensors <NUM> at the start of a window of time, and wait to transmit sensor data from the one or more sensors <NUM> until the end of the window of time. In another example, the braking event detection unit <NUM> may collect sensor data and determine where the change in acceleration is above a predefined threshold, as described above. In this example, the braking event detection unit <NUM> may only transmit the sensor data to the braking event detection system <NUM> where the change in acceleration is above the predefined threshold. For instance, referring now to <FIG>, a flowchart <NUM> of example steps for controlling data transmissions to the braking event detection system <NUM> is shown. In step <NUM>, the braking event detection unit <NUM> may collect raw sensor data, including data relating to an acceleration/deceleration of the vehicle <NUM>. In step <NUM>, the braking event detection unit <NUM> may determine whether the change in acceleration/deceleration is above a predetermined threshold (e.g., greater than <NUM>/s<NUM>, less than greater than -<NUM>/s<NUM>, greater than <NUM>/s<NUM>, less than greater than -<NUM>/s<NUM>, etc.). Where the change in acceleration in above the predefined threshold in step <NUM>, the braking event detection unit <NUM> may transmit the raw sensor data collected during a window of time to the braking event detection system <NUM> for processing in step <NUM>. Alternatively, where the change in acceleration is not above the predefined threshold in step <NUM>, the braking event detection unit <NUM> may continue collecting raw sensor data in step <NUM>, electing not to transmit the previously collected raw sensor data to the braking event detection system <NUM>. As such, in these examples, the braking event detection unit <NUM> advantageously limits and/or controls the number of transmissions between the mobile device <NUM> and the braking event detection system <NUM>. In yet other examples, the braking event detection unit <NUM> may transmit sensor data to the braking event detection <NUM> system in response to a request from the braking event detection system <NUM> to collect and transmit data during a window of time.

Referring back to <FIG>, examples of sensor data collected from the sensors <NUM> of the mobile device <NUM> may include location from the GPS receiver <NUM>, acceleration from the accelerometer <NUM>, rotational motion from the gyroscope <NUM>, sound from the microphone <NUM>, movement from the camera <NUM>, and magnetization from the magnetometer <NUM>. Examples of sensor data derived from the data collected from the sensors <NUM> of the mobile device <NUM> (features) may include minimum acceleration, total acceleration, variance in acceleration, variance in rotational motion, maximum rotational motion, minimum speed, maximum speed, median acceleration, and indicators of whether the minimum acceleration is below a predefined threshold (e.g., <NUM> mph, <NUM> mph, etc.). The derived data (or features) may be used by the classification machine learning algorithms to determine whether or not a braking event occurred within a window of time. In some examples, the features may have different levels of importance, such that some features are more indicative of a likely braking event than others.

In some arrangements, the braking event detection system <NUM> may specify a polling frequency collect raw sensor data from the sensors <NUM>. The polling frequency may control the number of data points requested during a window of time. For instance, a polling frequency of one may request the sensors <NUM> to collect every data point (e.g., consecutive data points). A polling frequency greater than one may request the sensors to <NUM> to collect non-consecutive data points. For example, a polling frequency of two may request the sensors <NUM> to collect every second data point, and a polling frequency of three may request the sensors <NUM> to collect every third data point.

In some examples, the braking event detection system <NUM> may advantageously adjust the polling frequency for collecting sensor data from the sensors <NUM> based on multiple factors. The polling frequency for collecting sensor data adjusts the number of requests to the sensors <NUM> such that, in some arrangements, the sensors <NUM> capture non-consecutive data points, rather than consecutive data points, as performed in other arrangements. For instance, the braking event detection system <NUM> may request the sensors <NUM> to collect only every second data point, every third data point, etc. In some examples, the sensors <NUM> may be configured to have an adjustable polling frequency for collecting sensor data. Additionally or alternatively, the mobile device <NUM>, the braking event detection module <NUM>, and/or the braking event detection unit <NUM> may be configured to collect data from the sensors <NUM> at the polling frequency calculated by the sensor data collection module <NUM>. In some examples, the braking event detection system <NUM> may specify more than one polling frequency. For example, the braking event detection system <NUM> may request the sensors <NUM> may collect every second data point and every third data point.

By reducing the polling frequency for collecting sensor data, the braking event detection module <NUM> advantageously reduces the power consumption of devices associated with the method of detecting braking events, and also advantageously increases the accuracy of the sensor data and/or analysis of the sensor data. For example, by collecting every second (or third, etc.) data point from the GPS receiver <NUM>, the braking event detection system <NUM> may advantageously conserve the mobile device's <NUM> limited resources (e.g., battery life), since collecting data from the GPS receiver <NUM> is a power-intensive process. Further, by collecting every second (or third, etc.) data point from the GPS receiver <NUM>, the braking event detection system <NUM> may also advantageously eliminate noise and/or anomalies in the data stream resulting from constant movement of the mobile device <NUM> within the vehicle <NUM>. The elimination of noise and/or anomalies in this early step <NUM> of the method illustrated in <FIG> also reduces the amount of post-processing (e.g., filtering, smoothing, etc.) required in later steps <NUM> of the method. It will be appreciated that the braking event detection system <NUM> may additionally or alternatively adjust the polling frequency for other sensors <NUM>, including the accelerometer <NUM>, the gyroscope <NUM>, the microphone <NUM>, the camera <NUM>, and the magnetometer <NUM>.

Referring now to <FIG>, a flowchart <NUM> of example method steps for adjusting the polling frequency for collecting sensor data from a mobile device <NUM> is shown. The sensor data collection module <NUM> of the braking event detection system <NUM> and/or of the braking event detection unit <NUM> may be used to perform these method steps. At step <NUM>, the sensor data collection module <NUM> may determine a current speed of the vehicle <NUM>. For instance, the sensor data collection module <NUM> may request the current speed of the vehicle <NUM> from the mobile device <NUM>, which may in turn request the current speed of the vehicle from the GPS receiver <NUM>. In some examples, the current speed of the vehicle may be an average speed based on multiple requests to the GPS receiver <NUM> (e.g., an average speed of the vehicle <NUM> over the last <NUM> seconds, over the last minute, etc.). At step <NUM>, the sensor data collection module <NUM> may determine the battery status of the mobile device <NUM>. At step <NUM>, the sensor data collection module <NUM> may collect traffic and weather related data within a threshold radius of the vehicle <NUM>. In some examples, traffic related data may be collected for a first threshold radius, and weather related data may be collected for a second threshold radius, such that the first threshold radius is smaller than the second threshold radius. As described above, the mobile device <NUM> may be in signal communication with external traffic databases and external weather databases. Thus, the mobile device <NUM> may retrieve traffic and weather related data from the external traffic databases and external weather databases based on a location (e.g., coordinate) retrieved from the GPS receiver <NUM>.

At step <NUM>, the sensor data collection module <NUM> may analyze the determinations from steps <NUM>, <NUM>, and <NUM> to determine a polling frequency for collecting sensor data from the sensors <NUM> of the mobile device <NUM>. For example, where the vehicle <NUM> is travelling at a low speed (e.g., less than <NUM> mph), the battery status of the mobile device <NUM> is low, the traffic is normal, and/or the weather is normal, the sensor data collection module <NUM> may reduce the polling frequency such that only every <NUM> data points are collected. In another example, where the vehicle <NUM> is travelling at a high speed (e.g., more than <NUM> mph), the battery status of the mobile device <NUM> is high (e.g., above <NUM>% capacity), the traffic is normal, and/or the weather is normal, the sensor data collection module <NUM> may reduce the polling frequency such that every <NUM> data points are collected. In yet another example, where the vehicle <NUM> is travelling at a high speed, the battery status of the mobile device <NUM> is high, the traffic is heavy, and/or there is rain/snow and/or low visibility, the sensor data collection module <NUM> may maintain the polling frequency such that every data point is collected. It will be appreciated that additional or alternative factors may be used by the sensor data collection module <NUM> to determine a polling frequency.

Referring back to <FIG>, in step <NUM>, the sensor data processing module <NUM> may process the raw sensor data collected by the sensor data collection module <NUM>. For instance, the sensor data processing module <NUM> may partition the sensor data into windows of time. The window of time may be a predefined duration of time (e.g., a <NUM>-second window, a <NUM>-second window, etc.) with a start time and an end time. Within a particular window of time, the sensor data processing module <NUM> may perform a data smoothing algorithm to remove noise and duplicate values. The sensor data processing module <NUM> may identify a duplicate data point by comparing a first data point with a second data point that immediately follows the first data point. Where the first data point is has the same value and/or is within a predetermined threshold of the second data point (e.g., within <NUM>% of, within <NUM>% of, etc.), the sensor data processing module <NUM> may flag the second data point as a duplicate data point. Data points flagged as duplicate data points may be removed by the sensor data processing module <NUM> using the data smoothing algorithm. In some arrangements, this may be performed by replacing the duplicate data point with an average value of the data point immediately before it (i.e., a second data point that immediately precedes the duplicate data point) and the data point immediately after it (i.e., a third data point that immediately follows the duplicate data point). The smoothed data may be used by the classification machine learning algorithms in addition to or instead of the raw and derived sensor described above.

In some examples, the sensor data processing module <NUM> may generate a new set of sensor data with a further reduced polling frequency. For example, where the sensor data collection module <NUM> used a polling frequency of every <NUM> data points to generate the raw sensor data, the sensor data processing module <NUM> may generate a new set of sensor data using a polling frequency of every <NUM> data points (of the original data) by using every other data point (of the raw sensor data). The generated set of sensor data with a reduced polling frequency may be used in addition to or instead of the sensor data collected by the sensor data processing module <NUM>. Thus, the braking event detection system <NUM> may ultimately determine whether a braking event has occurred based on one or more sets of sensor data, where the one or more sets of sensor data may be based on different polling frequencies.

Additionally, the sensor data calibration module <NUM> may perform an alignment of the sensor data based on the axes of the mobile device <NUM> and the reference frame of the vehicle <NUM> (i.e., translate the first, second, and third axes of the sensor data into an x-axis, y-axis, and z-axis). In certain embodiments, the sensor data calibration module <NUM> may perform the alignment based on gravity. In other words, the sensor data calibration module <NUM> may use gravity to determine an orientation of the mobile device <NUM> within the vehicle <NUM>. <FIG> shows various aspects of a vehicle <NUM> and a mobile device <NUM> therein used to align sensor data from the mobile device <NUM> to a reference frame of the vehicle <NUM>. As shown in <FIG>, the sensor data calibration module <NUM> may transform the sensor data such that the z-axis of the sensor data associated with the mobile device <NUM> is aligned with the direction of gravity <NUM> (e.g., a vector indicating acceleration due to gravity), and the x-axis of the sensor data associated with the mobile device <NUM> is aligned with the direction of travel <NUM>. To determine the x-axis based on the sensor data, the sensor data calibration module <NUM> may determine along which axis the maximum speed and acceleration take place. In particular, the sensor data calibration module <NUM> may analyze the sensor data to detect large magnitudes of movement (e.g., speed, acceleration, rotational movement, etc.) along an axis, and infer that this axis corresponds to the x-axis of the reference frame of the vehicle <NUM>. In these examples, the y-axis is the remaining axis.

Referring back to <FIG>, in certain embodiments, in addition to the sensor data obtained from the sensors <NUM> of the mobile device <NUM>, the braking event detection system <NUM> may collect and process sensor data from the sensors <NUM> of the vehicle <NUM>. The sensor data from the sensors <NUM> of the vehicle <NUM> may be used to supplement the sensor data from the sensors <NUM> of the mobile device <NUM> as desired. The additional data may be beneficial in providing increased certainty in detecting braking events. For example, where the sensor data from the sensors <NUM> of the mobile device <NUM> contain too much noise (e.g., due to movement of the mobile device <NUM> within the vehicle <NUM>), or signal communication with the mobile device <NUM> is lost, the braking event detection system <NUM> (and/or the braking event detection unit <NUM>) may collect and process sensor data from the sensors <NUM> of the vehicle <NUM>. The braking event detection system <NUM> may implement similar methods to those described above with respect to sensor data obtained from the sensors <NUM> of the mobile device <NUM>. In these examples, the sensor data from the sensors <NUM> may also be used to perform an alignment of the sensor data based on the axes of the mobile device <NUM> instead of relying on the direction of gravity. For instance, the braking event detection system <NUM> may match axes of the mobile device <NUM> with the reference frame of the vehicle by comparing similar sensor data values collected from the sensors <NUM> and the sensors <NUM>. It will be appreciated that other methods known in the art for aligning axes for sensor data collected from a mobile device and a vehicle may be used.

In step <NUM>, the braking event classification module <NUM> may determine whether a particular window of time should be classified as a braking event, based, at least in part, on fused sensor data. Fused sensor data may include raw data collected from the GPS receiver <NUM>, the accelerometer <NUM>, the gyroscope <NUM>, the microphone <NUM>, the camera <NUM>, and the magnetometer <NUM>, as well as derived data (e.g., statistical computations on the raw data) and processed data (e.g., smoothing algorithms on the raw data and/or the derived data). The braking event classification module <NUM> may apply the classification machine learning algorithms stored in the braking event classification model <NUM> to classify a window as either a braking event or not a braking event. As described above, certain features of the fused sensor data may be more indicative of a braking event than others. For example, a smoothed version of minimum acceleration calculated using raw data from the GPS receiver <NUM>, with a polling frequency of every <NUM> data points may be the most accurate feature in determining whether a window should be classified as a braking event. Other important features may include the minimum acceleration calculated using raw data from the GPS receiver <NUM> with a polling frequency of every <NUM> data points, but without the smooth algorithm. It will be appreciated that the order of importance of the various raw data, derived data, and processed data features will be determined based on the classification machine learning algorithms.

A classification of a braking event may indicate that the fused sensor data associated with the window of time is likely a braking event. By contrast, a classification of a non-braking event may indicate that the fused sensor data associated with the window of time is not likely a braking event. In some examples, the braking event classification module <NUM> may specify a probability threshold (e.g., <NUM>%, <NUM>%, etc.). As such, if, according to the classification machine learning algorithms, the probability of the sensor data associated with the window of time being a braking event is above the probability threshold, the braking event classification module <NUM> may classify the window of time as a braking event. In contrast, if, according to the classification machine learning algorithms, the probability of the sensor data associated with the window of time being a braking event is below the probability threshold, the braking event classification module <NUM> may classify the window of time as not a braking event. Thus, the precision and recall of the classification machine learning algorithms may be controlled by configuring the braking event classification module <NUM> to have a probability threshold. A higher probability threshold translates to greater precision and lower recall, whereas a lower probability threshold translates to lower precision and greater recall.

If a window is classified as a non-braking event <NUM>, the braking event detection system <NUM> may continue collecting sensor data in step <NUM> for a different window of time. As such, the method steps <NUM>-<NUM> provided in <FIG> may be repeated for different windows of time. For instance, the method steps may repeated using a sliding window algorithm, such that consecutive windows are overlapping and shifted by one data point, as shown in graph <NUM> <FIG>. Additionally or alternatively, the method steps may be repeated for consecutive windows such that there is no overlap, as shown in graph <NUM> in <FIG>.

Referring back to <FIG>, if a window is classified as a braking event <NUM>, the braking event notification module <NUM> may generate and/or issue a notification (e.g., a visual notification, an audio notification, etc.) to nearby mobile devices and/or nearby vehicles regarding the braking event in step <NUM>. A nearby mobile device may be a second mobile device that is within a predetermined distance (e.g., <NUM> feet, <NUM> feet, <NUM> feet, <NUM> feet, etc.) of the mobile device <NUM>. A nearby ve3hicle may be a second vehicle that is within a predetermined distance (e.g., <NUM> feet, <NUM> feet, <NUM> feet, <NUM> feet, etc.) of the vehicle <NUM>. In some examples, the braking event notification module <NUM> may broadcast a notification of the braking event on a publicly-accessible server, such that nearby mobile devices and/or nearby vehicles may periodically poll the server for likely braking events. Accordingly, the notification on the server may be associated with a GPS coordinate of the vehicle <NUM>. In other examples, the braking event notification module <NUM> may notify nearby mobile devices and/or nearby vehicles using short-range communication protocols, such as WLAN, Bluetooth, CALM, or via short-range vehicle communication systems. The notification may include displaying a message on a display on the nearby mobile devices and/or the nearby vehicles. Additionally or alternatively, the notification may include emitting a sound on the nearby mobile devices and/or the nearby vehicles. In these examples, the notification may also include the probability of the sensor data associated with the window of time being a braking event, as calculated by the braking event classification module <NUM>.

In some examples, the classification machine learning algorithms may also classify whether a window of time indicates a hard braking event (e.g., sudden acceleration/deceleration). In such examples, the notification issued to nearby mobile devices and/or nearby vehicles may be altered to indicate urgency (e.g., larger display, louder sound, using both visual and audio notifications, etc.). Further, in case of hard braking, the braking event notification module <NUM> may also issue a notification to an insurance system <NUM> indicating the vehicle's <NUM> speed, acceleration, distance from other vehicles, and any other indications of hard braking. A vehicle or driver's insurance information may be retrieved from the driver information database <NUM>.

Claim 1:
A method (<NUM>) comprising:
collecting (<NUM>), during operation of a vehicle (<NUM>), first data corresponding to an attention level of a driver of the vehicle (<NUM>);
collecting (<NUM>), at a polling frequency based on one or more speeds of the vehicle (<NUM>), second data associated with motion of the vehicle (<NUM>);
detecting (<NUM>), based on the second data, a braking event;
generating (<NUM>), based on the braking event and based on the attention level of the driver, a notification relating to the braking event; and
causing display of the notification.