A system and method for obtaining vehicle telematics data

ES 2 812 699 T3

DESCRIPTION

System to obtain vehicle telematic data

Background of the invention

The present application refers to a system for obtaining vehicle telematic data. To assess driver risk and change driving behavior, insurance companies have started using telematics data. Current implementations use one of the following methods based on embedded hardware:

1. A professionally installed “deep install” black box on a vehicle that tracks the vehicle's position and acceleration, or

two. On-board diagnostic device (OBD-II) that connects to the vehicle and acquires information from it.

Due to the high capital and / or operational costs of these hardware-based options, some companies have recently brought a pure smartphone solution to the market. This solution does not require any black box or OBD hardware device. The advantage of a smartphone-based solution is substantially less expensive compared to hardware alternatives, as long as problems around data accuracy can be solved. Previous work has shown how to achieve accurate map-based telematics using personal mobile devices for mileage and trajectory estimation (US patent US 8457880) and estimation of longitudinal / lateral acceleration and associated events (US patent application US 13 / 832,456 and PCT application number: PCT / US14 / 30174).

However, a pure smartphone solution does not robustly achieve the following desired properties:

1. Reliable vehicle identification and monitoring only when the user is in a pre-specified set of vehicles.

two. Shock / impact detection.

3. Exact vehicle movement times.

Four. Accurate estimation of acceleration when the user is moving the phone.

5. Operation when the user has uninstalled the application, or has not inserted the phone in the vehicle.

6. Best estimates to determine when the phone is being used while driving to call or text or access chat applications.

7. An accurate determination of whether the smartphone registration data belongs to the driver or a passenger.

The present invention provides a method and system architecture for combining the best features of a smartphone-based approach together with embedded lightweight label hardware. The smartphone and tag communicate with each other via low-power wireless connection while in the vehicle and work together to: (1) achieve the high degree of precision of a pure expensive hardware solution, (2) provide the features listed above that are difficult or impossible to achieve with a pure smartphone solution, (3) achieve a substantially lower cost alone modestly superior to that of the pure smartphone solution, (4) avoid the high cost of logistics, hardware and deployment inherent in a complete GSM / GPS or OBD II black box solution, while maintaining a high level of data accuracy (5) achieve energy efficient operation, with the tag capable of operating for several years on a small coin-sized battery, (6) improve phone battery life intelligent by downloading some detection functions to the tag, and (7) avoid interference with vehicle wiring or OBD port.

Summary of the invention

The invention for which protection is sought is defined in independent claim 1. According to the invention a system for obtaining vehicle telematic data includes: a sensor tag that can be attached to a vehicle to obtain vehicle telematic data, and a mobile communication device; including the tag: a battery to power the tag; a first processor configured to execute executable code to process accelerometer data; an accelerometer configured to measure the acceleration of the tag and thereby the vehicle; a clock; a memory for storing a unique tag identifier of the tag and for storing trip data, including trip information and acceleration data with corresponding timestamps; and a first communication module for short-range wireless communications with a communication device

ES 2 812 699 T3 mobile communications located in the vehicle through a short-range wireless communications protocol, the first communication module being configured to transmit the unique identifier of the tag and a sequence of acceleration data with time stamp, wherein the first communication module is a low power communication module; and the mobile communication device, including: a display element for displaying information to a user; a user interface for receiving input from a user; a location module for determining and recording location data relative to the location of the mobile communication device, which in use is the position of the vehicle in which the mobile communication device is located and to which the tag is affixed; a second communications module for communicating with the tag via the short-range wireless communication protocol to receive the tag's time-stamped acceleration data; a second processor with an executable application configured to run on it to combine the received timestamped acceleration data with the location data from the location module, so that the acceleration and position of the vehicle at a particular time is known ; and the second additional communication module for transmitting the combined acceleration data and location data to a server via a mobile communication network.

Communication between the tag and the mobile communication device preferably occurs automatically without manual intervention or configuration.

The tag is not connected to the vehicle's computer or power systems.

The short-range wireless communication protocol can be Bluetooth.

The mobile communication device can be a mobile phone.

The communication module is configured to transmit time data associated with the acceleration data to the mobile communication device.

The tag may include a tamper detection mechanism.

The tag includes a shock / impact detection mechanism.

The tag can include sensors other than the accelerometer, such as gyroscope, barometer, compass, and position sensors.

The tag signs and can optionally encrypt the data sent to the mobile communication device so that the mobile communication device cannot be tampered with with the undetected data; With encryption, data is kept confidential from the mobile communications device. The mobile communications device forwards the data to the server.

The server signs and can optionally encrypt any data sent to the mobile device so that the mobile device cannot be tampered with with the undetected data; With encryption, data is kept confidential from the mobile device. The mobile device forwards the data to the tag. This data includes parameters, configuration information, and code (for wireless firmware update).

Brief description of the drawings

Figure 1 is an exemplary system for implementing a vehicle telematics methodology;

Figure 2 is a block diagram illustrating in more detail an exemplary tag to be installed on a vehicle;

Figure 3 is a block diagram illustrating an exemplary mobile communication device in more detail;

Figures 4-8 are block diagrams illustrating an exemplary vehicle telematic monitoring method; and Figure 9 shows an exemplary server of Figure 1 in more detail.

Description of achievements

The system and methodology described in this document refer to obtaining vehicle telematic data.

Referring to the accompanying figures, a battery powered, detached sensor tag 10 is affixed to a motor vehicle 12. It is envisaged that the tag 10 will be affixed to the windshield or some other rigid part of the vehicle.

ES 2 812 699 T3 vehicle 12.

Referring to Figure 2, the tag 10 contains a processor in the form of a microcontroller 22 capable of executing programmed instructions ("firmware"), which controls the operation of the various other components of the tag. The components include a low power wireless communication module 32 for communicating with a mobile communication device 14 in the vehicle.

It will be appreciated that mobile communication device 14 can be any suitable mobile communication device, such as a mobile phone, tablet, iPod, or any other suitable communication device.

In either case, the components include one or more sensors, specifically a three-axis accelerometer 24, and optionally one or more of a three-axis gyroscope 26, a light sensor, a pressure sensor, and a magnetometer.

The accelerometer 24 measures the acceleration of the tag 10 and thus the vehicle 12 when the vehicle is moving and reports the data to the microcontroller 22. The accelerometer and other sensors provide digital output generally through a standard interface of serial number.

In the preferred embodiment all of the components on the tag are low power devices, so that one or two small coin cell batteries are sufficient to run the tag for several thousand hours of driving time (several years of operation). ). The firmware of the microcontroller 22 in the tag 10 records telematics data mostly only when the vehicle is moving. When the vehicle is not moving, the components of the tag 10 are in an ultra-low power off or idle state. An "acceleration state machine" controls the different states of the tag 10.

In the illustrated example, the short-range wireless communication protocol is Bluetooth, but any low-power communication can be used. Bluetooth Low Energy (BLE) meets desired power requirements and is widely available on entry-level smartphone devices. In an exemplary embodiment, the microcontroller 22 and the Bluetooth communication module 32 including antenna and crystal are combined on a single chip.

Label 10 records acceleration and other sensor data. It transmits that data to the mobile device 14 through the short-range wireless communication link, which in turn will process that data and transmit at least a portion of the data received and processed through a wireless communications network 16 such as 802.11 (WiFi ) or cellular network to a server 18 with an associated database 20.

Label 10 includes memory 28 in the form of flash storage, for example using serial flash memory. Memory 28 stores data on trip start / end times, acceleration and other sensor data, including telematics cases detected by firmware, such as hard braking, accelerations and turns, unexpected tag movements, collisions or impacts, and debug logs along with timestamps. Label 10 also includes random access memory (RAM) used by firmware and read-only memory (ROM) used to store configuration data and executable instructions.

The tag 10 includes a battery 30 to provide power to the device. The battery can be in a coin type, standard AAA or AA cell form factor, or solar. It is important to note that in the preferred embodiment the tag is not tied to any hardwired source of power, such as the vehicle's electrical power supply or the vehicle's standard on-board diagnostic (OBD) port. Because it does not have an unlimited source of energy, its operation includes methods for using energy sparingly and carefully, as described below.

The advantages of not requiring a linked power source are that there is no complicated or cumbersome installation procedure as with a black box installed. Plugging the tag into the vehicle's OBD port is also undesirable since these types of devices can potentially interfere with the vehicle's on-board systems. The capital and functional costs of a telematics system with the unlinked tag are considerably lower than those of black boxes and OBD devices and are more scalable for telematics insurance companies.

The tag 10 includes hardware and firmware instructions in the microcontroller 22 that measure and report the battery power level to the mobile device through the low-power wireless communication link. The hardware can be implemented with an intermediate circuit (not shown) connected between the battery and the microcontroller 22 to measure the battery voltage. When battery power reserves are found to be below a threshold, the user is given a warning on the mobile device to warn users when the battery is running low.

In the illustrated example, the short-range wireless communications protocol is Bluetooth, but it can be used

ES 2 812 699 T3 any low power communication. Bluetooth Low Energy (BLE) meets desired power requirements and is widely available on entry-level smartphone devices. In an exemplary embodiment, the microcontroller 22 and the Bluetooth communication module 32 including antenna and crystal are combined on a single chip.

Referring to Figure 3, the mobile communication device (smartphone) 14 includes a display element 36 by which information is displayed to a user of the device 14. A user interface 38 receives input from the user. User interface 38 can be a keyboard or touch screen, for example.

Device 14 includes a processor 40 connected to the other illustrated modules to control the operation of device 14. The device also includes a location module 42.

The location module 42 is used to determine the location of the mobile communication device 14 and thereby the position of the vehicle in which the mobile communication device 14 is located.

The location module 42 includes one or more position sensors, such as the global positioning system (GPS), as well as cellular or WiFi-based location sensors that are used for an application on the mobile device to obtain information from position and speed. Other sensors, such as a gyroscope and acceleration sensors on the mobile device, can also be used to collect information during a trip.

The device includes an on-board memory 46 as well as a communication module 44, which allows the device to communicate both with the tag 10 and using one or more of the mobile communication networks 16.

To implement the described methodologies, device 14 will include an executable application that is capable of running on the device.

Some key aspects of how the system works are described below, including:

• Tag initialization and installation • Tag-smartphone communication and synchronization protocols • Collision and shock detection • End-to-end security between tag and server, communicating via rogue smartphone • Detection of label handling and label movement relative to vehicle • Orientation algorithm • Server functions

Describing first the initialization and installation of tag 10, tag 10 is installed on a motor vehicle 12. As mentioned above, this can be accomplished in any of a number of ways, including attaching the tag to the windshield. or to any other rigid part of the motor vehicle, as illustrated in Figure 1, for example.

To assign tag 10 to the correct vehicle, an initialization phase must occur. An example of this is illustrated in figure 4.

After the adjustment, the user (who may or may not be the owner or driver of the vehicle) will be able to open the executable application on the mobile communication device 14 and start the initialization phase, which will search for a tag 10 in the vicinity.

A list of tags 10 will be displayed in the vicinity of the user through the display element 36 and the user will be able to select the correct tag 10 through the user interface 38.

The user will then be able to select a vehicle 12 to link to the selected tag 10.

Where it is known which vehicles the user owns, a list of the vehicles can be provided through the display element 36.

In either case, the selected vehicle 12 and the identity of the tag 10 secured to the vehicle 12 are sent to the server 18 along with a user identifier, typically via the communications module 44 and the network of

ES 2 812 699 T3 mobile communications 16.

Changes or movement of the tag to other vehicles will require the user to have to move the tag to a new vehicle and link to the new vehicle, or re-link to the existing vehicle. This can be done through the system server

One notable aspect of the system is that there is no Bluetooth pairing stage between the phone and the required tag. Furthermore, the administrator can specify through a server-side configuration which set of tags will be able to connect to any given smartphone application instance and transfer data bi-directionally between the server and the tag. This set may be "all tags", which means that the application instance can connect to any active tag. However, the set of tags whose data is made visible in the application can be restricted only to those tags that are bound to the user on the server.

For example, suppose that the vehicle V1 belongs to a first user, who also owns the smartphone application A1, it is linked to the tag T1. So if the smartphone application A2 belonging to a different user travels in the vehicle V1, depending on the server-side configuration, the tag T1 and the application A2 can connect with each other and exchange data. But even if that happens, the data belonging to this trip will become visible in the application A1 belonging to the first user and the data used to evaluate the driving use of the vehicle V1, and not a different vehicle belonging to the second user.

Different combinations of which tags are allowed to connect to which smartphone instances are possible, and they can be fully configured on the server side without requiring any changes to the software running the mobile communication device or the tag.

When the user begins to drive the vehicle 12, the tag 10 will announce itself on the short-range wireless communication network, such as Bluetooth. Any mobile device running the corresponding mobile application can see the ad, and potentially any mobile device with the application that depends on the implemented policy (application) will be able to connect to the tag.

For this to occur, it is necessary for the executable application mentioned above to be executed by the user on the mobile communication device 14.

In terms of tag-phone communication and synchronization, the tag firmware 10 implements the following states to achieve efficient battery communication and synchronization between the tag and the mobile device (smartphone). The main states in this state machine are: VERIFY, ANNOUNCE, and CONNECTED. In the VERIFY state, the components on the tag are off, except for a low-power throttle chip that is part of the accelerometer 24, which collects acceleration data at a specified frequency (typically between 5 and 50 Hz depending on hardware capabilities and software), and periodically wakes the processor (for example, once every second or two) using an interrupt. Equivalently, the processor can periodically poll the acceleration data. The processor then runs the state machine implemented in the firmware to determine if the state should remain in the VERIFY state, or if it should go to ANNOUNCEMENT.

This determination is made based on whether the vehicle has been in motion for a configurable period of time. If it has not been moving for a specified period of time, the status is still CHECK; otherwise, it goes to ANNOUNCEMENT. A variety of statistical methods operating on the collected acceleration samples can be used to make this determination. For example, if the acceleration data is collected at 10 Hz and the processor is interrupted every 2 seconds, 20 samples of three-axis accelerometer data are processed to make the determination. One approach to determining rest is to calculate the maximum absolute value of the difference from the mean of the values ​​in each acceleration component. If the maximum in any of the three components is above a configurable threshold A for a configurable amount of time T1, then it goes to the ANNOUNCE state; otherwise it remains in VERIFY. Parameters A and T1 are adjustable values ​​in the method.

An important point is that the ads on the label, which consume energy, occur only when the vehicle is considered to be moving, and stop when a mobile device is connected. Such motion-activated ads conserve battery resources. In certain situations, the tag may be able to connect to multiple mobile devices, in which case the advertisements may continue after connection to one or more other mobile devices. Ads can end after several minutes, even if the vehicle is still moving and no mobile device is connected, and then the tag can return to the VERIFY state for a configurable time.

Referring to Figure 6, the tag 10 is activated by the accelerometer that exceeds a certain measurement threshold for a certain period of time. This is an important functionality as it prolongs the life of the 30 battery by keeping the tag in an ultra-low power sleep mode when the vehicle is not

ES 2 812 699 T3 moving.

Upon entering the ANNOUNCE state, the tag considers a trip to have started and begins recording acceleration data in its RAM. You can also write this data to persistent storage (for example, flash memory). In an embodiment with Bluetooth low energy communication, the tag announces its presence as a Bluetooth peripheral. Alternatively, the tag can be configured as a Bluetooth hub, and the phone a peripheral, in which case the transition to the ANNOUNCE state causes the tag to start searching for announcements from the phone. (In this configuration, the phone would periodically announce its presence.)

Referring to FIG. 5, the "turn on BLE advertisement" block refers to Bluetooth low energy which may have an advertisement on and off state, as is well known in the art.

In ad mode, the chip will normally use more battery power and therefore this will be used conservatively. Thus, tag 10 in an exemplary embodiment will only start announcing once motion is detected to preserve the duration of battery life on tag 10.

Likewise, if the Bluetooth module in the mobile communication device 14 is ON, then the device 14 will automatically connect whenever the smartphone is in the vicinity of the tag 10 and the vehicle begins driving. If the Bluetooth module is off, then a "pop-up window" will be displayed to the user on display element 30 asking the user to enable Bluetooth.

Once the executable application on the mobile communication device 14 has identified the tag 10, then a communication session is set up between the tag 10 and the mobile communication device 14 through the communication modules 32 and 44 respectively.

Therefore, it should be noted that the tag 10 is in the idle / suspend state while the vehicle 12 is not driving. Once the vehicle 12 begins to drive, the tag 10 is activated and begins recording accelerometer data. That happens regardless of whether the mobile device is in the vehicle or not. Therefore, the memory must be large enough to store enough data to handle several hours of driving in the absence of the user's mobile device 14. The number of hours of recordable data will vary depending on the size of the memory 28.

Upon detecting a suitable advertisement, the central node connects to the peripheral. In the exemplary embodiment, the telephone (central) initiates a connection to the tag (peripheral). Once the connection is successful, the tag goes into the CONNECTED state.

In the CONNECTED state, the tag and the phone communicate with each other. This communication involves the reliable transmission of any data previously recorded in the tag's storage, including information on previous trips, previously detected cases (such as heavy braking, acceleration, collisions, handling, etc.), debugging or diagnostic information, and the like. . After the reliable transmission of this information using a protocol where the phone acknowledges reception, the tag begins live transmission of acceleration data and other sensor data to the phone.

The mobile communications device 14 will transmit this combined data (data from the tag sensor 10 and GPS and / or additional sensor data such as position, gyroscope, acceleration from the mobile communications device) to the backend server. server) 18.

An example data packet might consist of:

• Timestamp • The X, Y, Z acceleration component of the tag • Additional sensor data from the tag (eg gyroscope) • One or more sensor data streams from the mobile device, such as GPS positions , speed and heading; network location samples; X, Y, Z components of the accelerometer; 3-axis gyro values, magnetometer data

In addition, the transmitted data includes a user ID, a tag ID, and an application ID.

In the exemplary embodiment both the reliability and the transmission of this data are via the Bluetooth low energy link layer protocol. The notification and indication capabilities of Bluetooth can be used for this purpose. It should be apparent that any other wireless communication medium and link layer protocol can also be used, including but not limited to Bluetooth (not low energy), WiFi, WiFi7

ES 2 812 699 T3

Direct and the like.

Once the tag 10 and the mobile device 14 have been connected and the tag is in the CONNECTED state, in order to further preserve power, the advertisements are stopped, or sent less frequently than in the ANNOUNCE state. Also, live streaming of sensor data does not require the short-distance Bluetooth radio to be turned on continuously. The radio turns on just before the scheduled broadcast. For example, the radio can be turned on every second to trigger a small number of packets and then turned off.

The tag remains in the CONNECTED state until either the connection is terminated because the tag and the phone are no longer in communication range, or until the tag firmware determines that the vehicle has not been moved for a period of time. time T2. In either case, the tag goes into the ANNOUNCE state for a period of time T3. The functions here are the same as in the ANNOUNCE state described above. If the vehicle remains idle for T4, the tag goes to the VERIFY state, where most of the components are off.

Note that the mobile device processes and communicates all the information received from the tag to the server.

If there is no tag 10 located within a predetermined time T5 and the vehicle is moving, the mobile communication device 14 will be able to continue recording only the data from the GPS and / or its own sensors.

In an exemplary embodiment, the user can select whether to transmit the data from the mobile communications device 14 to the backup server 18 via cellular data or whether the data should be stored and transmitted only when the mobile communications device 14 It comes within the range of a short-range wireless LAN such as WiFi.

If the setting on the mobile communications device is to not allow the use of mobile cellular data, then such data will only be transmitted when the device is connected to a WiFi network.

In both the case of cellular transmission and WiFi transmission when data is received on servers, the server-side software will process this data and return the processed or “clean” data to the mobile communications device to update its data. trip and driver behavior currently stored for display back to the user. Such clean data involves the ability of backup servers to determine the difference between running data and driving data, and the types of transportation being used, such as a train or a bus.

Now describing the collision and crash detection functionality of the system, any event of significant acceleration whose magnitude exceeds a specified configurable threshold A2 is recorded in persistent storage on the tag. Such cases are considered potential collisions and are immediately communicated to the mobile communication device using the communication protocol described above (in the CONNECTED state).

Referring to Figure 7, the microcontroller 22 samples and stores the readings from the accelerometer 24 that include the X, Y and Z values ​​of the accelerometer. The microcontroller 22 determines from the accelerometer values ​​if a crash / impact has occurred by checking whether any of the X, Y or Z values ​​or a combination of the values, for example, (Χ^Λtwo + Υ^Λtwo + Ζ^Λ2), exceeds a predetermined threshold for a predetermined period of time.

One method is to derive the acceleration components in the vertical direction (gravity) and in the direction perpendicular to gravity, and then consider an impact to have occurred if one or both components exceed the specified threshold values. Estimating the direction of gravity can be done in a number of ways, including using a low-pass filter on the entire acceleration data stream observed thus far over the life of the unit or even longer. If a crash / impact event has occurred, then accelerometer data 24 is immediately stored in memory 28 and simultaneously transmitted through communication module 32 to mobile communication device 14. The mobile communication device 14 can augment the tag data with its own sensor data, such as position and speed, and transmit it to the server in real time.

Additional sensor information from the near past and near future obtained from the mobile communication device sensors (position, speed) can also be transmitted in a crash / impact detection scenario.

In an exemplary embodiment, mobile device (smartphone) 14 is a rogue device. That is, the telematics data produced by the tag traverses the mobile device en route to the server, but neither the tag nor the server can trust the mobile device, which is owned by a potentially untrusted user. The invention includes a method by which the authenticity of the data and messages sent by the tag can be verified by the server, and vice versa.

The traditional approach to this problem is to use public key cryptography: each server and tag has a

ES 2 812 699 T3 well-known public key, with a corresponding secret private key known only to the owner of the key. By digitally signing each message with its private key, an entity can verify that a recipient can verify the authenticity of the message. Due to computational restrictions on the tag, the invention uses symmetric keys, rather than more expensive public key operations.

Each tag has a secret internal ID (S_ID) number built into the tag hardware (chip). The server knows the mapping between S_ID and the device ID (MAC address).

All data sent from the tag to the mobile device, to be passed to the server, and sent from the server to the mobile communications device to be passed to the tag (including any configuration and recognition information), is digitally signed using a secret key derived from S_ID and the device ID. In an exemplary embodiment, define a secret key K = f (S_ID, deviceID); In one embodiment, the function f is a bitwise XOR operation. Each message includes an authentication token based on a one-way hash (for example, SHA-1) of the K-appended content. The ACKNOWLEDGMENT messages from the server also contain an authentication token based on a single-address shuffle function of K, so they are sure they come from the server (the intermediary mobile device never sees S_ID or K).

When an acknowledgment is received from the server, the acknowledged data is purged from the tag's flash memory; no data purge occurs until a signed ACKNOWLEDGMENT is received for that data. In particular, data recognized by the mobile device in the vehicle is not purged from the tag: end-to-end recognition authenticated from the server is required. As described above, these records include case records, travel duration records, diagnostic records, etc.

It should be noted that when acceleration and other sensor data is transmitted to the mobile device from the tag, it can be discarded by the rogue mobile application, but cannot be manipulated or changed without detection by the server. If an unauthorized application discards the data, the server will not know it, but the symptom will be the same as a trip in the trip duration log without corresponding acceleration data. If an unauthorized application tries to "kill off" the trip log data as well, any subsequent trips that will be displayed on the server will inform the server of missing trips and missing data, relaying information that something is wrong and broken. . That is enough to take corrective action, including informing the user of potential problems or potentially malicious behavior.

Like live streamed acceleration cases, live case or crash alerts are also sent to the phone without a comprehensive final acknowledgment from the server, but they are sent signed so that they can be verified as authentic. It should be noted that the communication protocol between the tag and the mobile device includes link layer retries, so they are likely to be received by the server as long as the mobile device is working properly (data from the mobile device to the server is sent using a reliable protocol like TCP). It should be noted that if confidentiality is desired in addition to authenticity, the secret key K can be used to encrypt the data.

Clock updates from the server to the tag can occur as long as the phone is online. To update the clock, the phone requests a time stamp (a one time message) from the label. The phone sends the time stamp to the server. The server constructs a timestamp containing the current time and an authenticator based on a one-way mix function of the timestamp and the K key. The tag sets its clock only if the authenticator verifies successfully.

This clock synchronization is important so that the accelerometer data stored in memory 28 can later be linked with GPS data measured by the executable application running on the mobile communication device 14 and the data from the backup server.

In the event that the mobile communication device 14 cannot connect to the tag 10 and the vehicle is moving, the smartphone can be configured to collect and deliver its own sensor data to the server, or not to do so.

The tag 10 includes a tamper detection mechanism 34. The tampering mechanism uses one or both of the following two methods.

The first method uses the accelerometer and using an orientation algorithm where the tag 10, once secured to the vehicle, will have knowledge of its correction angle in relation to the direction of travel of the vehicle. This algorithm calculates the rotation matrix that it converts from the accelerometer axes on the label to give the axes corresponding to the vehicle's frame of reference. If the tag 19 experiences any sudden change in this orientation, the most likely reason is a movement of the attached tag, which would be considered tampering. This tampering event will be recorded in the tag's flash memory and securely transmitted to the backup server. Detecting such tampering reduces potential fraud.

ES 2 812 699 T3

The second method uses a light sensor chip included in the tag 10, which will be covered by the tag housing. Removing the label from its intended position will break the housing part and expose the light sensor. This, in turn, will trigger a tampering event, which will be transmitted to flash memory 28 and then sent via mobile device 14 to server 18.

In either case, the microcontroller 22 executes an orientation algorithm that aligns the axes of the accelerometer of the tag 10 with respect to the coordinate system of the vehicle 12 regardless of how the tag 10 is placed on the vehicle. This targeting algorithm can be run on the tag 10 or the mobile device 14 or the backup server. The calculated orientation is configured on the tag, enabling the tag to detect cases using only its own calculation.

In an exemplary embodiment, the orientation algorithm will be executed when the vehicle is in motion to the point where the microcontroller 22 is confident that it is correctly aligned with the vehicle. Once this occurs, the microcontroller 22 will not rerun the algorithm unless it is physically removed from its location and replaced on the vehicle.

The combination of the sensor tag and the smartphone sensor data can be used as follows to determine if the smartphone is on the driver or passenger side of the vehicle. The method requires knowing where the tag is affixed to the vehicle, which is easy to record in a database. The method uses the property that the centripetal acceleration experienced by any object depends on the radius of the turn that is made, in the car's frame of reference. This information can be derived using the method disclosed in US patent application US 13 / 832,456 and PCT application number: PCT / US14 / 30174.

Specifically, this acceleration is equal to the product of the radius of gyration and the square of the angular velocity. Because the angles are swept at the same speed that is observed anywhere on the turning vehicle, the acceleration experienced depends solely on the radius. By knowing the position of the label and comparing the magnitudes of the lateral (centripetal) derived acceleration between the label and the smartphone for the right bearing and left bearing turns observed during a drive, respectively, an estimate of the placement can be obtained. on the phone in different time segments while driving (to take into account the possible change in phone placement while driving).

Regarding distinguishing whether the phone is in the front or rear seat, the signal strength of the tag's radio transmissions is available on the smartphone. Knowing the position of the label enables such an estimate to be obtained as long as the label is not equidistant from the front and rear seats. For example, a tag affixed to the front or rear windshield would provide the required degree of demarcation.

Referring to Figure 9, server 18 includes a number of modules to implement the present invention and associated memory 20.

In an exemplary embodiment, the modules described below may be implemented by a machine-readable medium that represents instructions that, when executed by a machine, cause the machine to perform any of the methods described above.

In another exemplary embodiment the modules may be implemented using firmware specifically programmed to execute the method described herein.

It will be appreciated that the embodiments of the present invention are not limited to such an architecture, and that they may also find application in a distributed architecture system, or unit by unit. Therefore, the illustrated modules can be located on one or more servers operated by one or more institutions.

It will also be appreciated that in any of these cases the modules form a physical apparatus with physical modules specifically for executing the steps of the method described herein.

In either case, a communication module 52 receives data that has been transmitted by the mobile communication device 14.

Next, an analysis module 54 analyzes the received data to determine the driver's behaviors.

Finally, in an exemplary application of the aforementioned method and system, a calculation module 56 uses the analyzed data to calculate a reward for the user, such as reduced premiums in a motor vehicle insurance plan.