Telematics device

Field of the invention

The present invention relates to a telematics device, in particular: a telematics device that is arranged to enable and disable a communication interface in order to transmit vehicle properties; a telematics device that is arranged to predict a location of interest; a telematics device that is arranged to detect a collision; a telematics device comprising a solar panel; and/or a telematics device that is arranged to combine the time and location into a combined value. A server arranged to receive and process vehicle properties from the telematics device is also disclosed, as is: a method of operating the telematics device; a method of installing the telematics device; and a system comprising the telematics device.

Background to the Invention

In many situations it is desirable to record the properties of vehicles during a trip, so that this trip can later be analysed. In particular, recorded vehicle properties, such as speeds and locations, can be used to evaluate the performance of a driver or to apportion blame in the event of a collision.

In order to record the properties of a vehicle, it is known to install a 'black box' telematics device in that vehicle. There are a number of problems with these device; for example, these black box devices are wired into the electronics systems of the vehicle in question and as a result the installation of the black box requires a skilled technician. Furthermore, the analysis of the recorded vehicle properties typically takes a significant amount of time, which prevents the vehicle properties from being used for immediate analysis or to give immediate feedback.

Summary of the Invention

According to at least one aspect of the present invention, there is disclosed a telematics device arranged to: record the properties of a vehicle during a trip; enable a communication interface of the telematics device after the vehicle has started the trip; transmit the recorded properties to a server; and (e.g. thereafter) disable the communication interface. Enabling the communication interface only after the start of the trip can offer power savings compared to a telematics device with a constantly enabled communication interface. One benefit of this is that it enables the use of a telematics device that is not connected to the vehicle electronics.

Preferably, the telematics device is arranged to transmit the recorded properties in a single transmission, preferably wherein the single transmission comprises multiple messages and/or data packets, wherein each message and/or data packet comprises one or more datapoints relating to vehicle properties. The single transmission typically relates to a single continuous transmission that occurs at the end of the trip - at this point all of the vehicle properties recorded during the trip may be transmitted.

Preferably, the single transmission includes the recorded properties for an/the entire trip.

Preferably, the device is arranged to disable the communication device following the completion of the single transmission, preferably immediately following the completion of the single transmission.

Preferably, the device is arranged to determine the vehicle has finished the trip.

Preferably, the device is arranged to enable the communication interface following the finishing of the trip.

Preferably, the device is arranged to disable the communication interface less than five minutes after the enabling of the communication interface, preferably less than one minute after the enabling of the communication interface, more preferably less than thirty seconds after the enabling of the communication interface.

Preferably, the device is arranged to enable the communication interface at least 30 seconds after the start of the trip, preferably at least one minute after the start of the trip, more preferably more than five minutes after the start of the trip. Preferably, the device is arranged to enable the communication interface at the earlier time of: at least 30 seconds after the start of the trip, preferably at least one minute after the start of the trip, more preferably more than five minutes after the start of the trip; and once the vehicle has finished the trip.

Preferably, recording the properties comprises recording at least one of: a location, a speed, a velocity, and an acceleration. Preferably, the device is arranged to record and/or transmit the time at which the properties are recorded.

Preferably, determining the vehicle has finished the trip comprises detecting a period during which the vehicle is substantially stationary. Preferably, the period is at least one minute, at least five minutes, and/or at least ten minutes.

Preferably, determining the vehicle has finished the trip comprises assessing a or the location of the vehicle. Preferably, determining the vehicle has finished the trip comprises determining the vehicle is at a finishing point of a previous trip.

Preferably, determining the vehicle has finished the trip comprises determining that an engine of the vehicle has been turned off. Preferably, the turning off of the engine is determined by detecting a reduction in a vibration of the device.

Preferably, the device comprises at least one of a location sensor, a GPS sensor, an acceleration sensor, a velocity sensor, an accelerometer, an orientation sensor, a camera, and a gyroscope.

Preferably, recording the properties comprises recording the properties periodically.

Preferably, recording the properties comprises recording the properties substantially continuously, preferably at least 20 times per second, more preferably 50 times per second.

Preferably, the device is arranged to determine a proximity to a further vehicle. Preferably, the device is arranged to determine the proximity based on the presence of a similar telematics device in the further vehicle.

Preferably, determining a proximity comprises receiving a message from the server indicating the proximity.

Preferably, the device is arranged to enter a low power mode following the disabling of the communications interface and/or before the trip has started.

Preferably, the device is arranged to exit the low power mode when a movement of the vehicle is detected.

Preferably, in the lower power mode a or the location sensor and/or a or the GPS sensor is disabled.

Preferably, the device is arranged to determine when the vehicle has started the trip. Preferably, the device is arranged to determine when the vehicle has started the trip by determining a movement of the vehicle.

Preferably, the server is arranged to store properties relating to a number of trips and/or vehicles.

Preferably, the communication interface comprises at least one of: a 2G interface; a 3G interface; a 4G interface; a 5G interface; a mobile network interface; an area network interface; and a Bluetooth ^® interface.

Preferably, the device is arranged to transmit the recorded vehicle properties to a mobile device of an occupant of the vehicle for further transmission from the mobile device to a or the server.

Preferably, the device is arranged to transmit the recorded properties following an event. Preferably, the event is at least one of: a detected deviation of the vehicle from a or the predicted route; and the vehicle entering a location of interest.

Preferably, the device is arranged to transmit the recorded properties periodically. Preferably, the period depends on at least one of: a variable relating to the driver; an ability of the driver; an experience of the driver; a charge of the battery; a feature of the weather; a detected solar intensity; and an expected duration of the trip.

Preferably, the device and/or the server is arranged to predict a route of the trip. Preferably, a location of interest is determined based on the predicted route.

Preferably, the device and/or the server is arranged to predict a plurality of possible routes of the trip.

Preferably, the prediction of the route is dependent on vehicle properties recorded in relation to previous trips. Preferably, the prediction of the route is based on a previous route. Preferably, the prediction of the route is based on a previous route that has been travelled a plurality of times.

Preferably, the prediction of the route is based on a predicted destination. Preferably, the prediction of the route is based on a destination to which the vehicle has travelled previously.

Preferably, the prediction of the route is dependent on a machine learning model or algorithm and/or artificial intelligence.

Preferably, the machine learning model is retrained following the trip using the recorded vehicle properties relating to the trip.

Preferably, the machine learning model is retrained following (the determination of) an event.

Preferably, the device is arranged to determine an occupant of the vehicle. Preferably, the device is arranged to determine an occupant of the vehicle by using facial recognition technology and/or voice recognition technology.

Preferably, the device is arranged to determine a driver of the vehicle.

Preferably, the device is arranged to transmit the properties to a or the server following the start of the trip.

Preferably, the device is arranged to transmit the recorded properties to a or the server in a single transmission following the start of the trip.

Preferably, the device is arranged to: determine a or the location of interest based on the recorded properties; and output a message in dependence on the location.

According to another aspect of the present invention, there is disclosed a telematics device arranged to record the properties of a vehicle during a trip; determine a location of interest based on the recorded properties; and output a message in dependence on the location.

Preferably, the location of interest comprises at least one of: a location that is related to a or the predicted route of the vehicle; a location the vehicle is predicted to pass; a location to which the vehicle is predicted to be proximate; and a predicted destination of the vehicle.

Preferably, the device is arranged to transmit the recorded properties to a or the server less than a minute after the start of the trip. Preferably, the device is arranged to transmit the recorded properties to a or the server when the vehicle is less than 500m from the start of the trip, preferably less than 100m from the start of the trip.

Preferably, the device is arranged to enable a communication interface; transmit the properties to a or the server; receive the location of interest from the server and disable the communication interface following the transmission and/or receipt.

Preferably, the device determining a or the location of interest comprises the device receiving the location of interest from a or the server.

Preferably, the device is arranged to output the message as the vehicle approaches and/or passes the location of interest.

Preferably, the device is arranged to determine a speed and/or orientation of the vehicle.

Preferably, the device is arranged to output the message in dependence on the determined speed and/or orientation.

Preferably, the device is arranged to output the message only when the vehicle is below a threshold speed, preferably only when the speed is substantially zero.

Preferably, the device is arranged to predict a plurality of locations of interest.

Preferably, the vehicle is arranged to identify a particular location of interest within the plurality of locations of interest in dependence on a detected route; wherein the output message is based on the particular location of interest. Preferably, the location of interest is dependent on an occupant and/or a or the driver of the vehicle. Preferably, the location of interest is dependent on a parameter, such as an experience level or an ability level of the drive of the vehicle.

Preferably, the location of interest comprises an area.

Preferably, the determination of the location of interest comprises the use of machine learning and/or artificial intelligence at the telematics device and/or the server.

Preferably, the output message is presented aurally and/or visually.

Preferably, the output comprises at least one of: an advertisement, preferably an advertisement tailored to an occupant of the vehicle; a notification of an accident; a notification of an accident hotspot; a notification of traffic; a notification of a traffic hotspot; and information about the location of interest, preferably historical information.

Preferably, the device is arranged to: determine an acceleration of a vehicle; determine a change in a velocity of the vehicle over a period of time; and indicate a collision only when: the acceleration exceeds an acceleration threshold; and the integral a function of the change in velocity over the period of time exceeds a collision threshold.

According to a further aspect of the present invention, there is disclosed a telematics device arranged to: determine an acceleration of a vehicle; determine a change in a velocity of the vehicle over a period of time; and indicate a collision only when: the acceleration exceeds an acceleration threshold; and a function of the change in velocity over the period of time exceeds a collision threshold.

Preferably, the function of the change in velocity comprises a moving average of the acceleration.

Preferably, the function of the change in velocity is comprises an integral of the velocity.

Preferably, the period of time is dependent on the time at which the acceleration has been determined to exceed the acceleration threshold, preferably wherein the period of time comprises a period of time immediately following the exceeding of the acceleration threshold.

Preferably, the period of time comprises the period of time during which the acceleration threshold has been exceeded.

Preferably, the telematics device is arranged to compute the function of the change in velocity only when the acceleration threshold has been exceeded and/or wherein the telematics device is arranged to compute the function of the change in velocity only during the period when the acceleration threshold is exceeded.

Preferably, the acceleration threshold and/or the collision threshold comprises a threshold for a component value of the determined acceleration and/or determined velocity.

Preferably, there are a plurality of acceleration thresholds and/or the collision thresholds, with each threshold comprising a threshold for a different component value of the determined acceleration and/or determined velocity.

Preferably, indicating a collision comprises transmitting the indication and/or vehicle properties to a server.

Preferably, the server is arranged to initiate a call to the device upon receipt of vehicle properties relating to a collision.

Preferably, the device is arranged to present information to the driver regarding the collision. Preferably, presenting information to the driver comprises asking the driver whether there has been a collision.

Preferably, the device is arranged to determine a severity of the collision. Preferably, the severity is dependent on the integral of the change in velocity.

Preferably, the indication of the collision is dependent on the determined severity. Preferably, the device is arranged to contact different parties dependent on the determined severity. Preferably, the device and/or a or the server is arranged to determine a combined value which is a function of a or the recorded location and a or the recording time, the recording time relating to the time at which the recorded location was recorded.

Preferably, the device and/or a or the server is arranged to determine a time period relating to the recording time at which the vehicle properties are recorded.

Preferably, the device and/or a or the server is arranged to determine a geographic area relating to a or the recorded location.

Preferably, the geographic area is selected from a list of predetermined geographic areas.

Preferably, device and/or a or the server is arranged to determine a or the combined value dependent on the time period and the geographic area.

Preferably, a power source of the telematics device comprises a solar panel and/or an internal battery.

Preferably, the power source of the telematics device consists of a solar panel and/or an internal battery.

According to another aspect of the present invention, there is disclosed a telematics device comprising: a sensor arranged to record vehicle properties relating to a trip; a communication interface arranged to transmit the vehicle properties to a server; and a solar panel arranged to provide power to the device.

Preferably, the apparatus comprises an internal battery, wherein the internal battery is arranged to be charged by the solar panel.

Preferably, the internal battery has a capacity of less than lOOOOmAh, preferably less than 5000mAh, more preferably approximately 4400mAh.

Preferably, the solar panel has an area of less than 2m ² , preferably less than lm ² , more preferably less than 0.5m2, yet more preferably less than 0.2m ² .

Preferably, the sensor and/or the communication interface is capable of being powered solely by the solar panel and/or an or the internal battery.

Preferably, the device is arranged to enter a low power mode and/or disable the communication interface so as to conserve battery.

Preferably, the device comprises a speaker arranged to output a message to an occupant of the vehicle.

Preferably, the device comprises a microphone arranged to receive a message from an occupant of the vehicle.

Preferably, the device is arranged to receive a call from a third party. Preferably, the device is arranged to receive a call in dependence on the device detecting a collision.

Preferably, the device comprises an inward-facing camera. Preferably the inward-facing camera is arranged to identify an occupant of the vehicle and/or evaluate the behaviour of an occupant of the vehicle.

Preferably, the sensor is arranged to detect a movement of the vehicle, preferably wherein the sensor is arranged to detect a movement of the vehicle in order to determine the start of the trip.

Preferably, the sensor is arranged to detect a lack of movement of the vehicle in order to determine the end of the trip.

Preferably, the solar panel is arranged to move relative to the remainder of the telematics device. Preferably, the solar panel is arranged to rotate relative to the remainder of the telematics device.

According to another aspect of the present invention, there is disclosed a telematics device comprising a solar panel, wherein the solar panel is arranged to move relative to the remainder of the device

Preferably, one end of the solar panel is rotatably fixed to the remainder of the telematics device. Preferably, a portion of the solar panel is biased away from the remainder of the telematics device, preferably away from a or the microphone of the device.

Preferably, the device is arranged to be activated in dependence on a movement and/or force that acts against a biasing force.

Preferably, the movement is arranged to join complete an electrical connection.

Preferably, the device is arranged to be activated in dependence on a movement and/or force that acts against a biasing force.

Preferably, the device comprises an adhesive portion.

Preferably, a securing force of the adhesive portion is greater than a or the biasing force.

Preferably, the device comprises a tamper-evidence mechanism, preferably a circuit that is broken when the device is removed from a window and/or windscreen.

Preferably, the device is arranged to be fixed to the interior of the windscreen of the vehicle, preferably towards the bottom of the interior of the windshield.

According to a further aspect of the present invention, there is disclosed a telematics apparatus arranged to: record a recorded location and a recording time of a vehicle, the recording time being the time at which the recorded location was recorded; determine a combined value which is a function of the recorded location and the recording time.

Preferably, the apparatus is arranged to determine a time period relating to the recording time, wherein the combined value is based on the time period. Preferably, the recording time period is a period of an hour.

Preferably, the apparatus is arranged to determine a geographic area relating to the recorded location, wherein the combined value is dependent on the geographic area. Preferably, the geographic area relates to a pluscode.

Preferably, the geographic area is selected from a list of predetermined geographic areas.

According to a further aspect of the present invention, there is disclosed a server arranged to: receive a combined value, the combined value being dependent on a recorded location relating to a vehicle and a recording time relating to the recorded location.

Preferably, the server is arranged to compare the combined value to a further combined value.

Preferably, the server is arranged to identify a proximity to an area and/or another vehicle based on the comparison.

Preferably, the server is arranged to determine a list of further combined values to consider in dependence on the combined value and at least one of: a comparison distance; and a comparison time period.

Preferably, the function is arranged so that the combined values of similar times and/or locations are similar.

Preferably, the combined value is dependent on a z order curve.

Preferably, the function is based on a look-up table and/or an algorithm.

According to a further aspect of the present invention, there is disclosed a method of determining relevant datapoints comprising: providing a recorded location; determining a geographic area that includes the recorded location; providing a recording time relating to the recorded location; determining a time period that includes the recording time; combining the geographic area and the time period so as to form a combined value.

Preferably, the method further comprises determining a list of relevant geographic areas based on the recording location and a relevance distance.

Preferably, the method further comprises determining a list of relevant geographic areas based on the recorded time and a relevance time range. Preferably, the method further comprises determining a list of relevant combined values based on a or the relevance distance and/or a or the relevance time range.

According to a further aspect of the present invention, there is disclosed a system comprising: a telematics device arranged to record the properties of a vehicle during a trip; transmit the recorded properties to a server; receive from the server a point of interest that the vehicle is predicted to pass based on the recorded properties; and output a message in dependence on the point of interest; and a server arranged to: receive the recorded properties; predict a route of the vehicle; determine a point of interest based on the route; and transmit the point of interest to the telematics device.

According to a further aspect of the present invention, there is disclosed a server arranged to: receive the properties of a vehicle during a trip; determine a location of interest based on the recorded properties; and transmit a message to a telematics device in dependence on the location.

According to a further aspect of the present invention, there is disclosed a server arranged to: receive from a telematics device an acceleration of a vehicle; determine and/or receive a change in a velocity of the vehicle over a period of time; and indicating a collision only when: the acceleration exceeds an acceleration threshold; a function of the change in velocity over the period of time exceeds a collision threshold.

According to a further aspect of the present invention, there is disclosed a server arranged to: receive a recorded location and a recording time of a vehicle, the recording time being the time at which the recorded location was recorded; determine a combined value which is a function of the recorded location and the recording time.

According to a further aspect of the present invention, there is disclosed a server arranged to: receive a recorded location; determine a geographic area in that includes the recorded location; receive a recording time relating to the recorded location; determine a time period that includes the recording time; combine the geographic area and the time period so as to form a combined value.

Preferably, the server is arranged to determine a list of relevant geographic areas based on the recording location and a relevance distance.

Preferably, the server is arranged to determine a list of relevant geographic areas based on the recorded time and a relevance time range.

Preferably, the server is arranged to determine a proximity between two vehicles. Preferably, the server is arranged to determine the proximity in less than ten minutes following receipt of vehicle properties from a first vehicle, preferably less than one minute, preferably in less than ten seconds, preferably in less than one second.

Preferably, the server is arranged to determine the proximity based on at least one of: a comparison of GPS co ordinates; the presence of a telematics device in at least one of the vehicles; the presence of the aforesaid telematics device in at least one of the vehicles; and the presence of the aforesaid telematics device in both of the vehicles.

According to a further aspect of the present invention, there is disclosed a method of: recording the properties of a vehicle during a trip; enabling a communication interface of the telematics device after the vehicle has started the trip; transmitting the recorded properties to a server; and (thereafter) disabling the communication interface.

According to a further aspect of the present invention, there is disclosed a method of: recording the properties of a vehicle during a trip; determining a location of interest based on the recorded properties; and outputting a message in dependence on the location.

According to a further aspect of the present invention, there is disclosed a method of determining an acceleration of a vehicle; determining a change in a velocity of the vehicle over a period of time; and indicating a collision only when: the acceleration exceeds an acceleration threshold; and a function of the change in velocity over the period of time exceeds a collision threshold. According to a further aspect of the present invention, there is disclosed a method of: recording a recorded location and a recording time of a vehicle, the recording time being the time at which the recorded location was recorded; determining a combined value which is a function of the recorded location and the recording time.

According to a further aspect of the present invention, there is disclosed a system comprising the aforementioned device and the aforementioned server.

According to a further aspect of the present invention, there is disclosed a vehicle comprising the aforementioned device.

According to a further aspect of the present invention, there is disclosed a method of installing the aforementioned device.

According to a further aspect of the present invention, there is disclosed a method of installing a telematics deice comprising: a sensor; a communications interface; and a solar panel, the method comprising: affixing the device to the interior of a window and/or windscreen of the vehicle.

Preferably, the method comprises placing an adhesive portion of the device against the window and/or windscreen.

Preferably, the method comprises affixing the device so that the window and/or windscreen applies a force to the solar panel, preferably wherein the force act against a or the biasing force acting on the solar panel.

Preferably, the method comprises affixing the device so that the biasing force acts to force the solar panel against the window and/or windscreen, preferably wherein the biasing force is continuous.

Preferably, the method comprises moving the solar panel relative to the remainder of the telematics device, preferably rotating the solar panel relative to the remainder of the telematics device.

Preferably, the method comprises affixing the device to an area no more than 75% of the distance between the base and the top of the window and/or windscreen, preferably no more than 50%, more preferably no more than 25%.

Preferably, the method comprises affixing the device to an area in dependence on the location of a cleaning device. Preferably, the method comprises affixing the device in dependence on the location of window wipers and/or windscreen wipers.

Preferably, the method comprises affixing the device to an area directly adjacent an area cleaned by window wipers and/or windscreen wipers.

Preferably, the method comprises affixing the device so that the solar panel is in adjacent the window and/or windscreen.

Preferably, the method comprises affixing the device so that a or the microphone of the device is directed to the interior of the vehicle.

Preferably, the method comprises cleaning an area of the window and/or windscreen before affixing the device.

Preferably, the method comprises comprising affixing the device to an area at least 10mm from an edge of the window and/or windscreen, preferably at least 20mm, more preferably at least 50mm.

Preferably, the method comprises comprising affixing the device to an area of the window and/or windscreen in dependence on a transparency of the window and/or windscreen. Preferably, the method comprises affixing the device at an area of high transparency.

Any feature described as being carried out by an apparatus, an application, and a device may be carried out by any of an apparatus, an application, or a device. Where multiple apparatuses are described, each apparatus may be located on a single device. Any of the methods and/or processes described as being performed by the server may be performed instead, or also, by the telematics device. Any of the methods and/or processes described as being performed by the telematics device may be performed instead, or also, by the server.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

The invention also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.

The invention also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.

The invention also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a computer readable medium having stored thereon the computer program as aforesaid.

The invention also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

The present invention will now be described, by way of example, with reference to the accompanying drawings. Description of the Drawings Figures la and lb show a device on which the described methods may be implemented;

Figure 2 shows a system comprising a telematics device and a server;

Figure 3 shows a system comprising a number of vehicles;

Figure 4 shows a method for controlling a device;

Figure 5 shows a method for controlling a device in dependence on a detected collision;

Figure 6a and 6b illustrate a method of detecting a collision;

Figure 7 shows a method for presenting an output in dependence on a predicted route;

Figure 8 shows a datapoint comprising vehicle properties;

Figures 9 and 10 illustrate methods of dividing a geographic area into grid cubes in space and time;

Figure 11 shows a database of datapoints including a combined value based on the grid cubes of Figure 10;

Figure 12 shows a method of determining the combined value;

Figures 13 and 14 show a method of creating a database query list based on the combined value; Figure 15 shows a method of comparing two datapoints; and

Figure 16 shows a method of querying a database based on a combined value.

Description of the preferred embodiments

Referring to Figure la, there is shown an exemplary device 1000, which typically embodies a computer device, on which aspects of the present disclosure can be implemented.

The device 1000 comprises a processor in the form of a CPU 1002, a communication interface 1004, a memory 1006, storage 1008, a power supply 1010, a sensor 1012, and a user interface 1014; the components are connected by a bus 1018.

The CPU 1002 executes instructions, including instructions stored in the memory 1006 and the storage 1008.

The communication interface 1004 enables the device 1000 to transmit and receive communications; typically the communication interface 1004 comprises a modem. In various embodiments, the communication interface 1004 comprises on or more of: an interface for making calls (e.g. using a SIM card); a 3G, 4G, or 5G interface that enables the device 1000 to communicate with other computer via the internet; an area network interface, an Ethernet interface, or a Bluetooth ^® interface. The communication interface 1004 may further comprise a wireless interface or a wired interface, such as a universal serial bus (USB) interface. The communication interface may require a power input of 300mAh, or 3mAh, in order to transmit forty seconds' worth of data.

The memory 1006 stores instructions and other information for use by the CPU 1002. Typically, the memory 1006 usually comprises both Random Access Memory (RAM) and Read Only Memory (ROM).

The storage 1008 provides mass storage for the device 1000. Depending on the device 1000, the storage 1008 is typically an integral storage device in the form of a hard disk device, a flash memory or some other similar solid state memory device, or an array of such devices.

The power supply 1010 provides power to the components of the device 1000. The power supply 1010 may comprise a connection to a mains power supply or another external power supply, such as the electrical system of a vehicle, or a battery.

In some embodiments, the power supply comprises a connection to an external battery, such as a battery of a vehicle in which the device 1000 is installed.

In some embodiments, the power supply 1010 comprises a solar panel, where this solar panel may operate in conjunction with an internal battery. The use of a solar panel and/or an internal battery supply enables the provision of a standalone telematics device, which does not need to be connected to a vehicle battery supply. This enables the device 1000 to be easily installed in a vehicle and/or removed from a vehicle.

Typically, the power supply 1010 comprises an internal battery that is arranged to be charged by a solar panel; the internal battery may have a capacity of less than lOOOOmAh, less than 5000mAh, and/or less than 3000mAh, but more than 2000mAh. In this embodiment, the battery has a capacity of approximately 4400mAh. The solar panel is typically arranged to have a surface area of less than lm ² , less than 0.5m ² , less than 0.2m ² , and/or less than 0.1m ² , but more than 0.05m ² . The solar panel is typically capable of providing at least 100mA per day, at least 200mA per day, and/or at least 300mAh per day of power on average throughout the year.

In order to provide optimal positioning of the solar panel, the solar panel may be biased towards a certain position, e.g. by using a resilient element. Typically the solar panel is rotatably fixed to the device 1000 at one end of the solar panel, so that the solar panel is capable of rotating about the attachment to the device 1000. The other end of the solar panel - that end which is not rotatably fixed - is biased away from the remainder of the device 1000. Such an arrangement is shown in Figure lb. On installation, the device 1000 is typically affixed to a window and/or a windscreen of a vehicle. Installation may comprise affixing the device so that the solar panel is moved against a biasing force. The biasing force ensures that the solar panel is pressed against the window and/or windscreen so that the solar panel is exposed to a high level of sunlight. The biasing force may be arranged to be less than the securing force of an adhesive, e.g. less than ION, less than 5N, less than IN, or less than 0.5N.

In some embodiments, the device 1000 is arranged to be activated in dependence on a movement of the power source 1010 and/or solar panel. In this embodiment, a movement of the solar panel results in the joining of two electric contacts 1020, this results in the device being activated. In this manner, the device is activated as soon as it has been affixed to a window/windscreen (and not before). This also prevents the device from being installed incorrectly (since it will then not activate).

Typically, the device 1100 is arranged to be installed on a section of a window and/or windscreen that has a high transparency (e.g. distanced from any tinting) as well as a level that is regularly cleaned (e.g. by windscreen wipers).

In some embodiments, the power supply 1010 comprises a wind turbine, which may be located external to a vehicle and/or a piezoelectric device, which may convert the movement of a vehicle into electrical power.

In some embodiments, the power supply 1010 comprises a connection interface, which connection interface is arranged to draw power from an external source. The power supply 1010 may be arranged to draw power via a cigarette lighter in a vehicle and/or a USB connection. Where the power supply 1010 comprises a connection interface, the connection interface typically enables a removable connection to be made, so that the device 1000 can still be easily installed and/or removed.

The sensor 1012 enables the recording of vehicle properties, e.g. a speed or a location. The sensor 1012 typically comprises one or more of: an accelerometer, a GPS sensor, a radar device, a lidar device, a camera, and a microphone. In some embodiments, the device 1000 also, or alternatively, receives sensor information via the communication interface 1004. This enables sensor data to be provided from a separate device, such as the mobile phone of an occupant of a vehicle.

The vehicle properties are typically related to a driver of the vehicle, so the vehicle properties may be thought of more particularly as vehicle driver properties in that the properties detected (including typically location, time and speed) may be attributed to the driver that is making the relevant journey.

The user interface 1014 enables a user to control the device 1000 and/or receive information relating to the device 1000. In this embodiment, the user interface comprises a speaker 1016, which enables information to be presented aurally to a user of the device. In some implementations, the user interface 1014 comprises a touchpad, a mouse, and/or a keyboard. In some embodiments, the user interface comprises a touchscreen. The user interface 1014 may comprise an interface to another device; for example, an output of the device 1000 may be presented on an application of a smartphone, where this output can be provided to the smartphone using the communication interface 1004.

In some embodiments, the user interface 1014 comprises an inward-facing camera and/or a microphone, which enables an occupant of the vehicle to be identified. Typically, the user interface 1014 is arranged to detect a driver and/or occupant of the vehicle, e.g. by using facial recognition software or voice recognition software. The device 1000 may also comprise software to prevent impersonation, e.g. liveness detection software or software to detect whether a recording is being played. The inward facing camera and the microphone may also be used to evaluate the behaviour of the driver, e.g. by tracking the driver's gaze, assessing the driver's alertness, and determining whether the driver is losing concentration.

In some embodiments, the user interface 1014 comprises an outward-facing camera, where the outward-facing camera enables the collection of information relating to the surroundings of the vehicle. In particular, the outward-facing camera enables the recording of video data relating to a collision. The device typically comprises an adhesive enabling the device to be affixed to a surface of a vehicle, e.g. a window and/or windscreen.

In some embodiments, the device 1000 comprises a tamper-evident mechanism, which detects the removal of the device 1000 from a window and/or windscreen. Typically, this tamper-evident mechanism comprises a circuit that is broken upon removal of the device. The circuit may be connected when the device 1000 is affixed to the windscreen (e.g. by the joining of the two electrical contacts 1020 of Figure 2); subsequent removal of the device 1000 then breaks this connection, which can be detected. Typically, there are a plurality of electrical connections that are joined when the device 1000 is affixed to a windscreen. These connections may be broken under different conditions, so that a first tamper-evident connection may be broken upon removal of the device 1000 and a second connection that provides power to the communication interface 1000 may be broken subsequently, or not at all. This enables the device 1000 to transmit a signal that indicates the device 1000 has been tampered with and/or removed.

Different aspects of the methods disclosed herein may be implemented on different devices, where these devices may have different components. For example, some aspects of the methods disclosed herein may be implemented on a 'lightweight' device that has a relatively small computing power, and a correspondingly low power consumption; other aspects of the methods disclosed herein may be implemented on a device with a more powerful CPU and/or a greater storage capacity, where this more powerful device may not comprise a sensor. This enables data to be gathered by a first device with low power consumption and then transmitted to a second device with greater processing power for processing.

As shown in Figure 2, there is typically provided a system that comprises a first device that is a telematics device 1100 and a second device that is a server 1200. The telematics device is installed in a first vehicle 10 and is arranged to record properties of the first vehicle 10, such as the location of the first vehicle 10. The telematics device is further arranged to communicate with the server 1200, in particular to transmit the vehicle properties to the server 1200. The server 1200 is arranged receive information from the telematics device 1100, to store the data, and to perform analysis on the data. The server 1200 is further arranged to transmit the results of analysis to the telematics device 1100, where these results can then be communicated to an occupant of the first vehicle 10.

Typically, the server 1200 receives vehicle properties from a plurality of vehicles, so that the server 1200 is capable of determining relationships between vehicles; for example, the server 1200 is capable of determining whether two vehicles have travelled to the same location. The server may also contain other data, such as the location of certain objects; this enables analysis of the journeys of a vehicle and the performance of a driver.

The telematics device 1100 and the server 1200 comprise at least a subset of the components of the device 1000; in particular, the telematics device comprises a communications interface 1104 and a sensor 1108.

Typically, the telematics device 1100 is arranged to be affixed to the inside of a windscreen of the first vehicle. In some embodiments, the telematics device 1100 is arranged to be affixed towards the bottom of the windscreen and/or to a portion of the windscreen that is in the range of travel of the windscreen wipers. This ensures that the telematics device 1100 is located on an area of the windscreen that is clear due to being cleaned by the windscreen wipers. Being located towards the bottom of the windscreen can also reduce the vibrations caused by movements such as closing a car door, which can be desirable to distinguish the closing of a car door from the vehicle being driven.

Referring to Figure 3, there is shown a system comprising a number of vehicles. In particular, the system comprises the first vehicle 10 and a second vehicle 20, which have been involved in a collision. It is desirable to detect a proximity of the first vehicle 10, the second vehicle 20, and/or a third vehicle 30 at the time of the collision between the first vehicle 10 and the second vehicle 20.

It will be appreciated that more generally it may be desirable to determine a proximity of any of the vehicles to other vehicles/objects during a given time period. In particular, this determination of proximity enables a connection to be formed between two drivers and/or two vehicles, where this may be used to determine whether two related vehicles were involved in a collision or near to a collision. This may be used to detect, for example, two vehicles driven by friends that are racing against each other and thereby cause a collision.

In order to detect the proximity of the first vehicle 10, the second vehicle 20, and the third vehicle 30, data relating to each of the vehicles 10, 20, 30 is assessed. As described with reference to Figure 2, typically at least the first vehicle comprises a telematics device 1100, where a sensor of the telematics device 1100 is used to record a number of the properties of the first vehicle 10. These recorded properties are uploaded to the server 1200. These properties typically comprise the location, the speed, and the acceleration of the vehicle at a recording time, where the recording time is also recorded by the telematics device 1100. More generally, the recorded properties typically comprise one or more of: a timestamp relating to a time of recording; a battery voltage relating the telematics device 1100; a battery percentage relating to the telematics device 1100; an acceleration; an acceleration in the x, y, and/or z direction; a maximum acceleration in the x, y, and/or z direction; a location (e.g. a GPS location); a longitude; a latitude; a heading; a velocity; a speed; a dilution of precision, such as a horizontal dilution of precision (HDOP); a quality measure relating to the quality of data being recorded; and a satellite number relating to the number of satellites being used to determine the location

The telematics device 1100 is typically powered by a solar panel and an internal battery. In consequence of the telematics device 1100 being powered by a solar panel, it may only intermittently receive a power input and so it is desirable to minimise the power consumed by the telematics device 1100. In order to minimise power consumption, it is particularly desirable to minimise the amount of time during which the communication interface 1004 is used.

Referring to Figure 4, there is shown a method 100 of controlling the telematics device 1100 to reduce power consumption.

The telematics device 1100 begins 102 in a low power mode; in this low power mode certain features of the telematics device 1100 are disabled. In particular, the communication interface 1104 of the telematics device 1100 is switched off and/or disabled. This reduces the power consumption of the telematics device 1100.

In a first step 104, the telematics device 1100 detects a movement of the first vehicle 10 that is associated with the telematics device 1100.

Once a movement of the first vehicle 10 has been detected, in a second step 406, the telematics device 1100 begins recording trip data. The recording of 'trip data' is preferably synonymous with the recording of 'vehicle properties', where each of these involve the recording of the location of the vehicle in relation to a time, as well as (optionally) the acceleration and/or speed of the vehicle. Typically, this comprises recording at least one of: a location, an acceleration, and a speed using the sensor 1108 of the telematics device 1100 and storing these variables alongside time values in the storage 1008 of the telematics device 1100. The trip data may be recorded periodically or effectively continuously. Typically, the trip data is recorded at 50Flz. During the recording, the trip data is stored locally on the telematics device 1100.

In a third step 106, the telematics device 1100 detects whether the first vehicle 10 has stopped. Typically, this comprises detecting a lack of movement for a certain time period, e.g. ten minutes. By using a threshold duration to detect the first vehicle 10 stopping, it can be ensured that a temporary stop (e.g. at traffic lights) does not result in the method 100 moving onto the fourth step 410.

The third step 108 of the method 100 may also comprise determining if a journey of the vehicle has ended. Determining whether a journey has ended may comprise detecting a lack of movement for a certain time period. This may also comprise determining whether a destination has been reached; the telematics device 1100 may store a list of known destinations based on past journey data - if a number of journeys have previously ended at a certain location this can be stored as a destination - and may detect when the device has stopped at one of these locations in order to detect the end of a journey.

In a fourth step 110, once the telematics device 1100 has detected that the vehicle has stopped, or that the journey has ended, the telematics device 1100 turns on and/or enables the communication interface 1104. In a fifth step 112, the telematics device 1100 transmits the trip data to the server 1200 using the communication interface 1104 of the telematics device 1100.

In a sixth step 114, the telematics device 1100 returns to the low power mode. This comprises (at least) disabling and/or turning off the communication interface 1104 of the telematics device 1100. As part of the switch to the low power mode, other capabilities of the telematics device 1100 may be disabled, for example GPS sensors and the user interface may be disabled. In some embodiments, only an accelerometer is left on, where this accelerometer enables detection of a movement of the vehicle so that the telematics device 1100 can be taken out of the low power mode.

The movement of the vehicle may also be detected by a user input, for example a user may be required to switch on the telematics device 1100 or the telematics device 1100 may detect the opening of a car door by a user. Typically, the movement of the vehicle - and/or the start of a trip - is detected by evaluating the output of a gyroscope and/or accelerometer.

In general, the method 100 of controlling the telematics device 1100 described with reference to Figure 7 relates to the telematics device transmitting trip data only at the completion of a journey, or upon occurrence of a certain event (such as a stoppage of a certain duration). Furthermore, the telematics device 1100 is typically arranged to transmit trip data if a potential problem is detected, such as a collision of the first vehicle 1100.

The data transmitted may depend on the event that triggers the transmission. As an example, the finishing of a trip may result in data relating to the entire trip being sent, where the datapoints may be separated by a second. The detection of a collision may instead result in more frequent data being sent relating to only a portion of the trip preceding/following the collision, e.g. collision datapoints may be separated by 0.02 seconds. It will be appreciated that the separation of data points may vary depending on the embodiment and the situation, so that there may be a variety of situations that result in different granularities of data being transmitted.

While Figure 4 illustrates the telematics device 1100 moving into and out of a low power mode in dependence on a movement of the vehicle, it will be appreciated that other events may be used to control the telematics device 1100. For example, the communication interface 1104 may be enabled in dependence on: the first vehicle 10 being involved in a collision; the first vehicle 10 entering a certain geographic area; and the first vehicle 10 exceeding a certain speed or acceleration. Furthermore, the enabling and disabling of the communication interface 1104 may depend on one or more of the following: the charge of a battery of the telematics device; a time since the last transmission of vehicle properties; the exceeding of a velocity or acceleration; the entry of the first vehicle 10 into a certain area (e.g. an accident hotspot); the time of day; and the season of the year.

Referring to Figure 5, there is shown a method 200 of the telematics device 1100 transmitting trip data in dependence on the first vehicle 10 being involved in a collision.

In a first step 202, the telematics device 1100 records trip data.

In a second step 204, the telematics device 1100 determines whether the first vehicle 10 has been involved in a collision. Typically, this comprises the sensor of the telematics device 1100 detecting an acceleration that exceeds a threshold value. The detection of a collision may also depend on the exceeding of a threshold jerk value, or a lack of movement for a period following the exceeding of an acceleration threshold or a jerk threshold. A more detailed method of determining a collision is described in more detail with reference to Figures 6a and 6b.

In a third step 206, the telematics device 1100 turns on the communication interface 1104 of the telematics device 1100. In a fifth step 208, the telematics device 1100 transmits the trip data to the server 1200 using the communication interface 1104.

In a fourth step 210, the telematics device 1100 determines whether the telematics device 1100 has received a call. In some embodiments, following a collision, the telematics device 1100 is arranged to receive a call so that the occupants of the first vehicle 10 can inform the caller of their status. Typically, this call is received over a telephone network; it may also be received via an internet connection. The telematics device 1100 is arranged to transmit trip data to the server 1200 when a collision has been detected. The transmitted trip data may relate to the entirety of a trip, or to a subset of the trip. Typically, data relating to the one to ten seconds of the trip immediately preceding the detected collision are transmitted to the server 1200.

In some embodiments, the data sent in relation to a collision comprises more frequent data than the data sent for a typical trip. For example, collision data recorded at 50Hz may be transmitted, while data for a typical trip (e.g. that submitted at the end of a trip) may be transmitted recorded at lHz.

The collision data is typically transmitted first, with the remainder of the trip data being transmitted afterwards to increase the likelihood of the collision data being received by the server 1200.

The server 1200 is then arranged to initiate or organise a call to the telematics device 1100. Typically, this call is an automated call, so that the call can be made immediately (without needing the input of a person).

In some embodiments, the server 1200 initiates or organises a call to another device of an occupant of the first vehicle 10.

In a fifth step 212, if an incoming call is detected by the telematics device 1100, the telematics device 1100 accepts the call.

The use of a call, in particular an automated call, that is initiated by the server 1200 enables the number of false positive collisions to be minimised. The call typically involves an automated system querying whether there has been a collision via the user interface of the telematics device 1100; the occupants of the first vehicle 10 are then able to confirm or deny that a collision has occurred.

If a collision is confirmed, or if there is no response, the telematics device 1100 and/or the server 1200 may contact another party. As an example, the server 1200 may contact the emergency services or an agent of an insurance company of the driver of the first vehicle 10.

Preferably the call uses a mobile call network, mobile call networks tend to have a smaller power consumption and a better connection than data connections. More generally, any contact means may be used, so that a call or message may be sent over any communications network.

Referring to Figure 6a, there is described a method 300 of detecting a collision. This method may be implemented using the telematics device 1100.

In a first step 302, the telematics device 1100 determines the exceeding of a threshold acceleration; this threshold acceleration relates to an acceleration that is expected only during a collision (as opposed to being a value expected during normal acceleration/braking/turning). The exceeding of this acceleration threshold indicates a possible collision.

In a second step 304, a function of the acceleration (a 'delta-v') immediately preceding and/or following the exceeding of the acceleration threshold - and therefore the possible collision - is determined. The telematics device 1100 records trip data for the duration of the trip, so upon the exceeding of the acceleration threshold an amount of the recorded data can be assessed. Typically, this function is a change in the velocity, and/or an integral of the change in the velocity.

The time preceding and/or following the collision for which the change in velocity is detected may be predetermined or may be dependent on a feature of the trip or the collision, such as the location of the vehicle, the speed of the vehicle at the time of the possible collision, or the driver of the vehicle. Typically, the delta-v is calculated for and/or evaluated for the period during which the acceleration exceeds the acceleration threshold.

The delta-v is a function of the acceleration, where this delta-v may simply be equivalent to the acceleration. Typically, the delta-v is determined based on a moving average of the acceleration, where the duration of time over which the moving average is taken may be predetermined or may depend on a feature of the trip or the collision. The time window used for the moving average may be at least the last 5 seconds, at least the last 1 second, at least the last 0.5 seconds, at least the last 0.1 seconds, at least the last 0.05 seconds, and/or at least the last 0.02 seconds. Equally, the time window used for the moving average may be at most the last 5 seconds, at most the last 1 second, at most the last 0.5 seconds, at most the last 0.1 seconds, at most the last 0.05 seconds, and/or at most the last 0.02 seconds. The use of a moving average smooths the acceleration graph. The time period used for the moving average may also depend on a feature of the collision, such as an estimated severity.

Typically, the telematics device 1100 is arranged to determine the moving average and/or the delta-v only when the acceleration threshold is exceeded, and to halt determination of the moving average and/or delta-v once the acceleration threshold stops being exceeded. This reduces the strain on the processor of the telematics device 1100 that is related to a continuous calculation of the delta-v, thereby prolonging the battery life of the telematics device 1100.

The delta-v is typically determine using the points of the moving average of the acceleration, where the delta-v at any time may be a function of the points of the moving average (e.g. an average of two points) or may be equal to the moving average.

In a third step 306, the change in velocity (the delta-v), or the change in the square of velocity, is integrated over the relevant time period. This gives an indication of the momentum or energy change over the period in question. In a fourth step 308, this integral is compared to a threshold value.

Figure 6b illustrates this method with an exemplary graph showing acceleration values and delta-v values.

The threshold acceleration may relate to a component of the acceleration, for example the threshold acceleration may be considered in the 'x-direction'. Typically, the axes in which the acceleration/velocity are recorded relate to the axes of the first vehicle 10; for example, the x-direction is in the major axis of the first vehicle 10, and relates to a backwards/forwards acceleration of the first vehicle 10, the y-direction is in a first minor axis of the car and relates to a left/right acceleration of the first vehicle 10, the z-direction is in a second minor axis of the car and relates to an up/down acceleration of the first vehicle 10. There may be a plurality of threshold accelerations relating to a plurality of axes so that there may be a first threshold acceleration for acceleration in the x axis and a second threshold acceleration for acceleration in the y axis. The second step 304 of the method 300 of detecting a collision is only triggered if each of the threshold accelerations is exceeded. As an example, there may be a threshold of 1.2g in the x direction and a threshold of 1.75g in the y and z directions; the collision detection may depend on a single one of these thresholds being exceeded, or two or more of these thresholds being exceeded.

Typically, the acceleration thresholds considered are: a threshold of at least lg, at least 1.2g, at least 1.5g, and/or at least 2g in the x direction; a threshold of at least 0.5g, at least lg, at least 1.2g, and/or at least 1.8g in the y direction; a threshold of at least 0.5g, at least lg, at least 1.2g, and/or at least 1.8g in the z direction - typically the data is normalised in the z direction to account for gravity (so that the absolute threshold is at least 1.5g, at least 2g, at least 2.2g, and/or at least 2.8g in the z direction; a (total) acceleration of at least lg, at least 1.2g, at least 1.5g, , at least 1.75g, and/or at least 2g.

The acceleration threshold may relate to an absolute acceleration, a magnitude of the acceleration, and/or a change in the acceleration over a period of time (e.g. a second).

Similarly, the delta-v may relate to the change in a subset of the components of the velocity. Typically, there are a plurality of acceleration thresholds considered (relating to, e.g., an impulse that moves the car backwards and upwards); thereafter the magnitude of the change in total velocity (the 'delta-v') is considered.

By integrating the delta-v or the delta-v squared (essentially to obtain an indication of a momentum or energy change), collisions can be distinguished from other events that cause rapid accelerations, such as the slamming of a car door. In particular, the detection of a rapid change in momentum or energy can be used to identify a collision as well as providing an indication of the severity of the collision. ln some embodiments, the threshold acceleration relates to a ratio between two or more acceleration components (e.g. acceleration in the x axis divided by acceleration in the y axis).

The estimated severity of the collision may be used to inform next steps. For example a high severity collision, where the energy change exceeds a high threshold, may result in the emergency services being contacted immediately. A low severity collision, where the energy change only exceeds a lower threshold may result in a text being sent to a party querying whether a collision has occurred and providing next steps in the event that a collision has occurred. This could happen where the energy change indicates a collision is possible, but unlikely. A medium severity collision may result in the server 1200 initiating a call to the telematics device 1100 as described with reference to Figure 5.

The severity may be estimated by an evaluation of acceleration, jerk, or an evaluation of the delta-v. Typically, the threshold acceleration is used to initiate an evaluation of the delta-v; the delta-v is then evaluated. The integral of the delta-v is used to assess the severity of the collision. Equally, the severity may be determined using the maximum acceleration or jerk or a combination of these properties.

Similarly, a location of the collision and/or a type of collision may be determined based on the vehicle properties; this determination may depend on a measured acceleration, where the point of impact and the direction of impact can be determined from the measured acceleration.

Typically, the detection of a collision, or a possible collision, triggers the transmission from the telematics device 1100 to the server 1200 of an initial package containing trip data that is likely to be particularly relevant to the collision, such as trip data from the seconds immediately preceding the collision. Less relevant information, such as the route taken from the origin of the journey to the collision, can then be transmitted in a second package. This ensures that the most important data reaches the server 1200 even if a consistent connection cannot be maintained or the connection fails.

In various embodiments, the detection of a collision is dependent on a direction of an acceleration, jerk, velocity change, and/or energy change. In particular, the detection of a collision may depend on the component of one or more of these properties perpendicular to the major axis of the first vehicle 10 (in the y-direction or z-direction). In general, user- controlled acceleration and braking will occur in a direction parallel to the major axis of the first vehicle 10 unless the first vehicle 10 is turning; therefore, a large acceleration in a direction perpendicular to this major axis (optionally in the absence of braking that suggests a sharp turn is approaching) can be used to detect a collision.

In some embodiments, the method 300 of detecting a collision comprises a further step of contextualising the acceleration. As an example, this step may comprise a turn, or swerve, detection step, where it is determined whether the vehicle is turning (since this may cause high accelerations). The detection of a turn typically depends on an evaluation of the acceleration profile, where a turn may be determined based on there being an acceleration over an extended period, preferably a period of at least one second. A turn may also be determined by detecting a corresponding braking (which can be determined by identifying a deceleration in the x direction) or by an evaluation of the GPS coordinates. A non-collision event, such as a swerve or a speedbump may be detected using pattern recognition, where a pattern relating to these events can be determined from previous data. Before evaluating the delta-v, the telematics device 1100 may run a pattern recognition check on the acceleration profile.

Referring to Figure 7, there is described a method 400 of the telematics device 1100 predicting a route and presenting an output in dependence on this route.

In a first step 402, the telematics device 1100 turns on the communication interface 1104. Typically, this occurs once the telematics device 1100 detects a movement of the vehicle.

In a second step 404, the telematics device 1100 transmits location data of the vehicle to the server 1200.

As described with reference to Figure 4, in order to reduce power consumption it is desirable to use the communication interface as few times as possible. Therefore, the telematics device 1100 may transmit the location data at only one time. Typically, the telematics device 1100 records data for a certain period after the first vehicle 10 has first started moving (e.g. for the first ten seconds), before turning on the communication interfacell04 and transmitting the location data. The communication interface may then be turned off to reduce power consumption 1104. The communication interface 1104 may be left on until a response has been received from the server 1200, before being turned off.

The communication interface 1104 may be disabled and enabled a plurality of times, e.g. every ten minutes, every five minutes, or every minute.

In some embodiments, the communication interface 1104 is enabled at a first time to transmit vehicle properties and then the communication interface 1104 is disabled. At a later time, e.g. at least five minutes or at least one minute after the initial transmission, the communication interface 1104 is enabled, a transmission from the server 1200 is received, and the communication interface 1104 is disabled. This enables a first enablement period where vehicle properties are transmitted by the telematics device 1100 to the server 1200, a disablement period where the server 1200 evaluates the properties, and then a second enablement period where the results of the evaluation are transmitted to the telematics device 1100.

The telematics device 1100 may also be arranged to transmit location information (and enable the communication interface 1104) periodically, or following an event. For example, location information may be transmitted following each hour, following a stoppage for a certain time period, or following the detection of unusual user behaviour (e.g. a driver driving to a previously unvisited area).

In a third step 406, at the server 1200, a route is predicted for the vehicle. The prediction of the route may be based on the past behaviour of the user, the route currently being travelled, and the context of the trip (e.g. the day of the week). The prediction of the route may also depend on artificial intelligence and/or machine learning algorithms. By performing the prediction on the server, and not on the local telematics device 1100, the prediction can take place on a device with a powerful CPU or a powerful GPU. This allows rapid prediction of the route.

Typically, the route prediction and/or the location determination depends on a machine learning algorithm that is updated periodically, e.g. following each trip. The re-training of the machine learning algorithm based on trip data enables the route prediction and the location prediction to be continuously updated.

In some embodiments, the route prediction, location prediction, and/or the training of a machine learning algorithm may be based on a certain time period, such as a recent year, or a recent month or week (and/or the most recent in each case); this enables the predictions to remain accurate as the behaviour of the user changes. The predictions and/or machine learning models may also be updated based on an event, e.g. the user moving to a new location, or the user graduating university. The updating based on an event typically requires a user input; alternatively, an event may be detected based on vehicle property data (e.g. the vehicle being regularly parked at a new location may be used to determine that the user has moved house and so the machine learning model may be retrained with data recorded since the determined move.

In some embodiments, the third step 406 comprises the determination of a plurality of possible routes. These routes may comprise a plurality of possible routes between the origin of the journey and a predicted destination and/or a plurality of routes to a plurality of predicted possible destinations.

In a fourth step 408, the server determines locations or 'areas of interest' that lie along the predicted route(s). Typically, this comprises querying a database 410 that contains the location information of areas of interest. These areas of interest may, for example, comprise accident hotspots, shopping locations, and traffic hotspots. The areas of interest may also depend on recent or real-time data, such as recent accident data, recent weather data, or recent traffic data.

In a fifth step 412, the server transmits the areas of interest to the telematics device 1100. In a sixth step 414, the telematics device 1100 receives the areas of interest.

In a seventh step 416, the telematics device 1100 determines whether the first vehicle 10 is near one of the areas of interest. In an eighth step 418, the telematics device 1100 outputs a message based on this area of interest.

The prediction of the route(s) is typically based on initial trip data, e.g. the trip data for the first minute, the first thirty seconds, or the first ten seconds of the trip. The transmitted trip data (and the enabling of the communication interface 1104) may be arranged to include a first turn of the vehicle, and/or a second turn of the vehicle. The route prediction may then be based on previous routes taken with the same first or second turn. This prediction of the route based on only the initial trip data enables areas of interest to be determined rapidly while minimising the amount of time that the communication interface 1100 is enabled (to conserve battery).

In various embodiments and situations, the telematics device determines 1100 whether the first vehicle is predicted to pass the area of interest, to pass near the area of interest, to be on route to the area of interest, to have a destination in the area of interest, or to have another relation to the area of interest.

The presentation of the message to the occupants of the first vehicle 10 is typically aural or visual.

Examples of messages that may be output to the occupants of the first vehicle 10:

The telematics device 1100 may output a warning that the first vehicle 10 is approaching an accident hotspot or the site of an accident.

The telematics device 1100 may inform the occupants of the first vehicle 10 that the first vehicle 10 is approaching a shopping location (e.g. a petrol station).

The telematics device 1100 may inform the occupants of a special offer at a nearby shopping location.

The telematics device 1100 may provide personalised or targeted advertising based on a predicted route.

The telematics device 1100 may inform the occupants of road closures and/or traffic cameras.

In some embodiments, the telematics device 1100 turns on the communication interface 1104 and transmits location data if a deviation from the predicted route(s) is detected.

In order to predict routes, the telematics device 1100 and/or the server 1200 may be arranged to evaluate previous trip data in order to determine previous routes and/or common routes. This enables a prediction to be made based on only a small amount of initial trip data.

In some embodiments, the output of the message is dependent on the speed and/or the direction of the first vehicle 10. In particular, the message may be based on the direction so as to ensure the vehicle is able to enter the location (e.g. the location may be a petrol station, and the message being based on the direction may be the telematics device 1100 ensuring that the vehicle is on the right side of the road to enter the petrol station). The output of the message may also be dependent on road conditions and/or features; for example, messages may be arranged to be output when the first vehicle 10 is stopped at traffic lights.

It will be appreciated that the method 400 of predicting a route, and indeed any of the other methods disclosed herein, may be performed entirely using the telematics device 1100, entirely using the server 1200, or using a combination of the telematics device 1100 and the server 1200. Any of the steps disclosed in any of the methods herein may be performed on either or both of the telematics device 1100 or the server 1200.

Referring to Figure 8, each datapoint 500 of vehicle properties/trip data that is recorded by the telematics device 1100 contains a number of pieces of information. Exemplary types of information that may be recorded include:

A point identifier 502; this is a unique identifier useable to identify the datapoint 500.

A time 504, which is the time at which the datapoint 500 was recorded.

A longitude 506 and latitude 508 that identify where the first vehicle 10 was when the datapoint 500 was recorded. An acceleration x co-ordinate 510, an acceleration y co-ordinate 512, and an acceleration z co-ordinate 514.

A speed.

A vehicle identifier 522. More generally, the datapoint 500 typically comprises the vehicle properties; exemplary vehicle properties have been described above.

The acceleration values 510, 512, 514 and the velocity values 516, 518, 520 may be recorded in a predetermined frame of reference (e.g. where the x axis is east-west, the y axis is north-south, and the z axis is towards/away from the earth) or in a frame of reference dependent on the vehicle whose properties are being recorded (e.g. where the x axis is along the major axis of the vehicle - e.g. 'forward'-'backward', and the y and z axes are along the minor axes of the vehicle).

The vehicle identifier 522 identifies the vehicle for which the datapoint was recorded. The vehicle identifier 522 may be an arbitrary identifier, which may be related to the telematics device 1100 (e.g. each telematics device produced may have a different identifier). The vehicle identifier 522 may also enable the determination of properties of the vehicle. In the example of Figure 8, the vehicle identifier is a numberplate number, which enables the determination of the type of vehicle - this numberplate number may therefore be used to determine the weight and/or dimensions of the vehicle for which data is being recorded.

A plurality of datapoints forms a database. A database relating to the first vehicle 10 is stored on the telematics device 1100. A database relating to a plurality of vehicles is stored on the server 1200. Typically, the telematics device 1100 forms a database of datapoints for each journey taken by the first vehicle 10; at the end of each journey, this database is uploaded to the server 1200 and combined with the database held at the server 1200.

In some embodiments, before datapoints 500 are added to the database, the datapoints 500 are checked for errors and/or inconsistencies. In particular, datapoints 500 that are missing information or that are clearly incorrect are not added to the database.

Referring to Figure 9, there is illustrated a method of storing location information.

The telematics device 1100 typically comprises a GPS sensor, which is arranged to obtain the GPS coordinates of the location of the first vehicle 10. These coordinates can be stored in the form of a longitude 506 and a latitude 508. An alternate method of storing location information is described with reference to Figure 9.

With this alternate method, a location (e.g. a city, or the entire world) is divided into one or more areas, which areas can be referenced using reference codes (101 - 112 in the example of Figure 9). Such a system can be referenced using pluscodes and/or what3words, which can be used to define a grid system for the entire world (information on pluscodes and what3words can be found respectively at https://plus. codes/ and https://what3words.com/).

In some embodiments, the location is split into squares of 200m ² and/or rectangles of 200m x 100m.

Similarly, the time may be converted into a different format, such as a UNIX timecode to enable easier analysis. Typically, the time 504 is converted to a UNIX time, divided by 3300, and rounded down to a whole number. This gives a time that is in UNIX format and rounded down to the nearest hour. It will be appreciated that other location formats may be used (e.g. a co-ordinate range), and other time formats may be used (e.g. hours since a reference time).

It will be appreciated that any area and any location period may be used, for example grid cubes may be used that include an area of (or less or more than) 5km ² , 3km ² , 1km ² , 500 m ² , 200 m ² , 100 m ² , 50m ² , or 10m ² . The areas may be of any shape, for example the areas may be of a rectangular shape or a hexagonal shape. Typically, shapes that tessellate are used, and the area is divided into areas of the same shape and/or size; however, more generally, a variety of shapes of areas and sizes of areas may be used. The area used may depend on the location being considered, for example in rural locations, or areas with little traffic, the areas considered may be large. In urban locations, or locations with lots of traffic, smaller areas may be used. The size of the areas used may depend on a predicted amount of traffic.

Similarly the time period may be a period of (or less or more than) a year, six months, three months, one month, two weeks, one week, three days, one day, twelve hours, five hours, two hours, one hour, thirty minutes, ten minutes, five minutes, or one minute. The time period used may depend on the time of day and/or a predicted amount of traffic. A long time period may be used at times of lower traffic, e.g. at night, where a shorter time period is used at times of higher traffic, e.g. rush hours. As an example, the day may be broken into time periods of: 00:00 - 09:00; 09:00 - 10:00, 10:00 - 13:00, 13:00 - 17:00, 17:00 - 18:00, 18:00 - 00:00.

In some embodiments, the time period and/or the area used depends on a user input and/or on a capability of the telematics device 1100 and/or the server 1200. The areas may be selected so as to enable calculation in a certain time period, where the use of larger areas and longer time periods enables quicker calculation.

Referring to Figure 10, a grid can be formed with each grid cube being dependent on the time and the location. Each grid cube relates to a certain geographic area and a certain time period (e.g. 200m ² _, or a 200m x 100m box, and a time period of an hour), with each cube being given an identifier. Beneficially, the use of a time period of an hour enables a timestamp to be determined as the unix time divided by 3600 (rounding this value down to the nearest integer gives an hour while avoiding the signalling of unnecessary bytes).

In the example of Figure 10, the grid is a regular grid. As mentioned above, the areas and the time periods considered may depend on a variety of factors, where different time periods may be used for different times so that the grid cubes are of an irregular size.

Referring to Figure 11, by combining a timestamp 522 and a location 524 of each datapoint, a grid cube identifier - or a 'combined value' 526 can be determined. A proximity between two vehicles can then be determined by comparing the combined values for multiple datapoints; two combined values being equal indicates that the two vehicles relating to those datapoints have been in the same geographic area during the same time period.

Referring to Figure 12, a method 600 of deriving the combined value is shown.

In a first step 602, the telematics device 1100 and/or the server 1200 receives vehicle properties. This typically comprises receiving GPS coordinates at a certain time from the sensor of the telematics device 1100.

In a second step 604, the location is converted to a pluscode. More generally, the precise GPS coordinates are converted to an identifier that references a geographic area.

In a third step 606, the time is converted to a UNIX time, divided by 3300, and rounded down to a whole number. This provides a time value that relates to a period of an hour. More generally, the time is converted to a value that denotes a time period.

In a fourth step 608, the combined value 826 is determined based on the converted location and time values.

In a fifth step 610, the database held at the telematics device 1100 and/or the server 1200 is updated.

The combined value 826 is typically arranged so that adjacent areas and/or adjacent time periods have similar values. Therefore, combined values 826 relating to nearby locations and/or similar times have similar combined values 826 - and a comparison of combined values 826 indicates such similarity.

This can be thought of as nearby cubes of the grid cube of Figure 10 having similar values. To achieve these similar values, a z-order curve and/or a space-filling curve may be used to organise the combined values 826 that relate to the grid cube of Figure 10. As examples, functions such as a Hilbert curve, a Peano curve or a Morton curve may be used.

Referring to Figure 13, a method 700 of determining relevant datapoints based on an input datapoint is disclosed.

The method 700 of determining relevant datapoints may be implemented by the telematics device 1100 and/or the server 1200; in particular, this method may be implemented when the first vehicle 10 is involved in a collision in order to find other vehicles which may have had some relevance to the collision (e.g. by being near the first vehicle 10 around the time of the collision).

In a first step 702, the vehicle properties at the time of interest are received. Typically, this comprises receiving the longitude 506 and latitude 508 of the first vehicle 10 at the time of the collision from the sensor of the telematics device 1100. ln a second step 704, a time period and area of interest are determined. These values may be determined by an insurer, or may be dependent on the journey in question.

As an example, it may be desirable to detect all vehicles that had been within 50m of the crash location in the past hour.

In a third step 706, a list of combined values to query is created. In some situations, it may be desired to find only vehicles in the immediate vicinity of the collision in the time period including the collision; this may lead to only a single combined value being searched. In other situations, it may be desirable to find vehicles within a certain radius of the collision, or within certain areas near the collision. In particular, where the collision is near the border of one of the geographical grid cubes (as shown in Figures 9 and 10), it may be desirable to also search for vehicles that have been present in an adjacent grid cube.

The time periods to consider and the grid cubes to consider may depend on a feature of the input datapoint being considered as well as the type of analysis being undertaken. For example, an initial analysis may consider a fairly narrow time period and geographic area, whereas a more thorough (and longer-taking) analysis might consider a broader time period and geographic area.

In some embodiments, the list of combined values to query depends on the journey of the first vehicle 10 to the point of the collision and/or the predicted route of the first vehicle 10 to a predicted destination.

In a practical example, there is considered a point recorded at a latitude of 55.02° and a longitude of -1.58° on 21 May 2020, 1:10:57PM.

The longitude and latitude is converted into a 'spacekey' of 785180888, where this spacekey relates to a predetermined geographic area. The time is converted to a 'timekey' of 441685, where this timekey is the unix time at 21 May 2020, 1:10:57PM divided by 3600 (159006600/3600).

The spacekey and timekey are then combined using a z-order curve to obtain a combined value of "623925247335314321". For the sake of concision, this combined value can be shortened by taking the log ₁₀ value of the combined value, where logi ₀ (623925247335314321) = 17.80 (to 2d.p). In practice, the log value is typically not truncated, to a avoid a loss of precision. However, in some embodiments, a truncation of the log value is used to identify related areas. Similar areas/time periods will have similar combined values, so a truncation of the combined value or the log of the combined value can be used to find the values for, e.g. adjacent areas at the same time, or the same area at adjacent times (or adjacent areas at adjacent times). As an example, a query may be formed to search for all log values that are equal to 17.80 or 17.8 depending on a situation (such as the location of a collision).

Referring to Figure 14, the grid cubes of Figure 10 are shown with grid cubes of interest indicated. For the example of Figure 14 a period of 2 hours and a radius of 100m are used, this results in four grid cubes - and therefore four combined values - being determined as being of relevance.

In a fourth step 708, the database is queried to find each datapoint 500 that has a combined value that is contained in the list of combined values to query.

In a fifth step 710, the datapoints 500 with combined values that are in the list of combined values to query are returned. Further analysis may then be performed on the returned datapoints 500; for example, the precise times 504, longitudes 506, and latitudes 508 for the returned datapoints 500 can be evaluated to determine vehicles that were within the vicinity of the first vehicle 10 at the time of the collision.

This two step process enables an initial filtering stage to be carried out very quickly, with more detailed analysis then only needing to be performed on a subset of datapoints 500.

The speed with which the analysis can be carried out utilising the combined values 826 enables the provision of real-time analysis, which enables the provision of targeted outputs as has been described with reference to Figure 7.

Referring to Figure 15, there is described a method of further analysis that may be carried out on the returned datapoints 500 from the method 700 of returning relevant datapoints of Figure 14. For each of the returned datapoints, a time difference 528 and a distance 530 are determined based on the timestamp 522 and the location 524 of the input datapoint and the timestamp 522 and the location 524 of each relevant datapoint.

The time difference 528 (in the example of Figure 15 this is the time difference in hours) and the distance 530 are used to form a score 532. This score may, for example, be calculated as to:

The grid length is a length related to the geographic areas; e.g. here the grid length is 200m.

This score 532 is an indication of how far removed (both in distance and time) each datapoint 500 is from the input datapoint. This can be used to sort the returned relevant datapoints 500 for further analysis.

A modified score 534 is also calculated here, which in this embodiment is a log score equal to logio(score) to two decimal places.

As well as storing vehicle data, in some embodiments the telematics device 1100 and/or the server 1200 is arranged to store data relating to geographic areas. Therefore, the telematics device 1100 and/or the server 1200 is able to identify whether the first vehicle 10 has passed through a certain geographic area. As an example, the geographic areas may relate to accident hotspots.

Referring to Figure 16, a detailed method 620 of querying a database (e.g. on the server) to find relevant datapoints is disclosed. The first step 622, second step 624, and third step 626 of the method of Figure 12 are the same as the first step 602, the second step 604, and the third step 606 of the method 600 of Figure 16.

In a fourth step 628, a number of points to query is determined. The number of points to query relates to a number of points in the trip for which a combined value is to be calculated and used to identify other proximate vehicles. This number of points may be dependent on a time available for analysis or based on a feature of a collision/trip (e.g. a collision of a high value vehicle may merit more investigation than a collision of a lower value vehicle, and a long trip may require more points than a shorter trip).

In a fifth step 630, a combined value is determined for each of the number of points (e.g. as occurs in the fourth step 608 of the method 600 of Figure 12).

In a sixth step 632, a database of combined values is queried based on the determined combined values and in a seventh step 634, the values in the database are compared to the combined values determined in the fourth step 628. The sixth step and the seventh step may, for example, comprise identifying any combined values in the database that are within a certain range of the determined combined values. The trips associated with these identified combined values may then be further investigated (e.g. to identify if the drivers of two vehicles with similar combined values have a pre-existing relationship). This method of comparison enables relevant vehicles and objects to be immediately identified and flagged for further review.

As well as, or instead of, determining a combined value, the fifth step 630 may comprise executing an algorithm or a model. For example, a feature of a trip, such as a maximum speed of the vehicle may be determined. Similarly, a model analysis may, for example, comprise an analysis of an expected trip route. In this regard, a user may input the recorded trip data into a model to obtain a prediction of a destination for a trip so that the user can predict where a trip would have ended had there not been a collision.

Example information that may be obtained based on modelling and/or based on the comparison of the combined value includes:

A vehicle's most popular locations over time.

A change in the movement of a vehicle over time.

Whether a vehicle has visited location X {ever} and/or (during a time period a:b}. Whether vehicles {X} and {Y} have ever been in the same location and/or have been in the same location within a certain time period.

Whether any vehicle has entered a geographic area A from direction {B}.

The most popular overnight locations for vehicle X.

For a trip {ID}, where an associated vehicle is going.

Where a selected vehicle is going at a given time.

Whether vehicle X's movement data throws any flags, e.g. is vehicle X a food delivery driver or a parcel delivery driver? Or does vehicle X drive through any accident hotspots regularly?

Each of the above queries may be addressed by referencing information stored in the database (e.g. on the server), where this database typically contains information associated with a plurality of vehicles. Due to the database containing information associated with a plurality of vehicles it can be determined whether a vehicle has visited a certain location during a certain time period and it can also be determined whether this vehicle has been proximate to another vehicle (by comparing combined scores associated with each vehicle). Similarly, a profession or behaviour of a driver can be assessed by an analysis of past movement data and/or combined scores, where a delivery driver is likely to make trips to a range of locations and then stay at each location for only a short time before leaving.

Alternatives and modifications

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention. As an example, the telematics device 1100 may connect to a nearby device, such as the smartphone of an occupant of the first vehicle 10 in order to transmit the vehicle properties. The telematics device 1100 transmits the vehicle properties to the nearby device, e.g. via Bluetooth ^® , which nearby device may then transmit the vehicle properties to the server 1200. This can further reduce power consumption, since the transmission to a nearby device may be less power intensive than direct transmission to the server.

In some embodiments, telematics data is stored in a series of files, where the name of each file contains an indication of the location of the vehicle during a certain time period. Within each file there may be stored more specific data. Specifically, the file name may contain the grid cubes entered during a certain hour of travel, where the file contains specific co-ordinates and times relating to the hour of travel.

In some embodiments, the telematics data is stored in a single database. In some embodiments, the telematics data is stored locally to a computer device that is analysing the telematics data. Telematics data that is accessed a plurality of times by any computer device may be stored in a cache of this computer device to reduce the time taken to access this data.

In some embodiments, the user interface of the telematics device 1100 determines a driver and/or occupant(s) of the first vehicle 10 and records the vehicle properties with reference to the driver and/or occupant(s) of the first vehicle 10. The telematics device 1100 may be arranged to store profiles relating to a plurality of drivers, where the recorded properties may then be used to personalise the methods disclosed herein. For example, the areas of interest determined as part of the method 400 of predicting a route may depend on the current driver and/or occupant(s) of the first vehicle 10.

In some embodiments, contextual data, such as weather data is recorded or considered by the telematics device 1100 and/or the server 1200. The contextual data may be used as part of the route prediction and/or the determination of areas of interest. As an example, certain routes may be accident hotspots in bad weather, but safe in good weather; therefore, the telematics device 1100 and/or the server 1200 may determine or predict the weather in order to determine whether a certain area is an area of interest.

In some embodiments, the transmission of vehicle properties and/or the determination of locations of interest is dependent on a parameter relating to the driver. Typically, this is a calculated 'quality' of the driver. The quality may be based on: the driver's experience, previous vehicle properties, and/or an insurance history. The telematics device 1100 and/or the server 1200 may be arranged to evaluate past vehicle properties so as to determine strengths and weaknesses of the drivers and determine locations of interest accordingly. As an example, a driver that has been involved in a collision on a roundabout may be warned when they are approaching a large roundabout - this may enable the drive to take extra care, to ensure that they are in an appropriate lane in good time, or to avoid the roundabout by taking an alternate route.

More generally, the transmission of vehicle properties and/or the determination of locations of interest is dependent on a feature of the vehicle, the drive, or the trip; as an example, cars with weak engine may be at risk on motorways.

In some embodiments, the telematics device 1100 may require user identification at the beginning of each trip. This may be implemented by sounding an alarm if the start of a trip is identified and the driver has not identified themselves. This is of particular use in fleet operations, e.g. with buses or delivery vans, where a vehicle may be regularly driven by multiple drivers. Driver identification typically comprises the use of voice recognition technology; once the driver is identified, the trip can be recorded with reference to this driver.

Following the completion of a trip, or an event, the telematics device 1100 transmits the vehicle properties to the server 1200. The vehicle properties may be collated and transmitted or stored in the form of 'trip properties' where the trip properties typically comprise at least one of: an origin, a destination, a trip duration, a number of datapoints, driver information, and/or event information (e.g. did the trip include any speeding or any accidents).

Trip data may be collated into a 'block' of driver properties/parameters, where the driver properties typically comprise one or more of: a number of trips undertaken, a home address, insurance information, contact information (e.g. next of kin), a driving score and/or ability score relating to the driver, a record of any accidents and/or undesirable driving events (e.g. speeding), and/or a record of any improvement or worsening of driving. The driver properties may be used to assess the quality of a driver, and may be useable to determine appropriate insurance rates.

The driver information (e.g. the insurance information) may be used to prepare an accident form in the event that a collision is detected, where this form may also be populated using data relating to the collision (e.g. an estimated severity and recorded acceleration data).

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.