Communication Device And Method For Protecting A Communication System Against Applying Unauthorized Code

Abstract

A communication device has a first data interface and a second data interface. A safe protection of the communication device against malicious code even under an easily breakable communication line between the communication device and a remote server is achieved by an intermediate protection unit located in a data communication line between the two data interfaces, wherein the intermediate protection unit blocks data in the direction from the second to the first data interface.

Claims

1. Communication device with a first data interface and a second data interface and an intermediate protection unit located in a data communication line between the two data interfaces, wherein the intermediate protection unit blocks data in the direction from the second to the first data interface.

2. Communication device according to claim 1, wherein the intermediate protection unit forms a physical strict one-way physical connection in the communication line in the direction to the second data interface.

3. Communication device according to claim 1, wherein the intermediate protection unit has on its side directed to the second data interface a sender, and is free of hardware capable of further processing signals received from the direction of the second data interface.

4. Communication device according to claim 1, wherein the intermediate protection unit is free of a writeable memory accessible by data coming from the second data interface.

5. Communication device according to claim 1, wherein the intermediate protection unit contains software which only when executed lets data pass in the direction to the first data interface and lets only such data pass which have a predefined format and data size.

6. Communication device according to claim 1, wherein the first data interface is a plug-in connector with a configuration of a data plug and the second interface is a wireless interface.

7. Communication device according to claim 1, being a dongle for an operating device, wherein the operating device is an on-board diagnose system of a vehicle.

8. Communication device according to claim 1, comprising a safety code generator located inside the intermediate protection unit or between the intermediate protection unit and the first data interface.

9. Communication device according to claim 1, comprising a bridging communication line bridging the strict one-way physical connection in the communication line, and a mechanical bridging switch interruptingly located in the bridging communication line, wherein the bridging communication line is activatable and deactivatable by the mechanical switch.

10. Communication device according to claim 1, comprising an mechanical disengage switch interruptingly located within in the blocked section in the communication line.

11. Communication device according to claim 1, comprising a mechanical exception switch which when activated causes a signal upon which information is added to data outgoing from the second data interface that the exception switch is activated.

12. Communication system comprising a communication device according to claim 1, and further comprising a long distance mobile communication device with a short distance data interface which is adapted to the second data interface.

13. Information retrieval system comprising a communication device according to 1, and further comprising a client unit plugged into the first data interface and a server at least indirectly wirelessly connected to the second data interface.

14. Method for protecting a communication device against applying unauthorized code, wherein data is sent through the communication device to a remote server in a communication line, wherein the data passes a part of the communication line which is a one-directional communication line allowing data transfer only in the direction to the server.

15. Method according to claim 14, wherein data is forwarded from the first data interface to the second interface and further to the server, wherein hardware inside an intermediate protection unit located in a data communication line between the two data interfaces restricts communication to the one directional and blocks all communication in the other direction.

16. Information retrieval system comprising a communication system according to claim 12, and further comprising a client unit plugged into the first data interface and a server at least indirectly wirelessly connected to the second data interface.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

[0261] A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0262] FIG. 1 shows an overview diagram of components of a server and a communication system,

[0263] FIG. 2 shows a safe zone inside a communication device of the communication system,

[0264] FIG. 3 shows a flow diagram of a method for identifying a protected data communication between the communication device and the remote server,

[0265] FIG. 4 shows a scheme of a software updating process where two random codes do not match,

[0266] FIG. 5 shows the scheme of the software updating process where the two random codes do match,

[0267] FIG. 6 shows a scheme of a confirmation of a receipt of a software update code,

[0268] FIG. 7 shows a flow diagram similar to FIG. 3 of a method for identifying a protected data communication with a two-step randomization,

[0269] FIG. 8 shows a scheme of a code loop routine,

[0270] FIG. 9 shows a scheme of a three-layered protection of the software of the communication device,

[0271] FIG. 10 shows a software application of the communication device generating a data capsule with driving data and sending it to the server,

[0272] FIG. 11 shows the generation of identification data and placing it into the data capsule to identify data manipulation,

[0273] FIG. 12 shows a detail of an inspection of the identification data by the server,

[0274] FIG. 13 shows a second detail of an inspection of the identification data by the server,

[0275] FIG. 14 shows a further detail of an inspection of the identification data by the server,

[0276] FIG. 15 shows a flow diagram of the identification data generation and inspection,

[0277] FIG. 16 shows a flow diagram of the identification data generation and inspection with a two-step randomization,

[0278] FIG. 17 shows a flow diagram of a method for protection the communication system against applying unauthorized code,

[0279] FIG. 18-22 show a scheme of the process depicted in the flow diagram of FIG. 17 protecting the data transfer from the server to the communication system, and

[0280] FIG. 23-24 show a scheme of a process protecting the data transfer from the communication system to a server,

[0281] FIG. 25 shows a block diagram of data generation and evaluation to identify manipulated data sent from the communication system located within a travelling vehicle to the remote server,

[0282] FIG. 26 shows location and speed data taken from a vehicle journey,

[0283] FIG. 27 shows an example of manipulated location data to reduce the respective speed values,

[0284] FIG. 28 shows a block diagram of data safeguard in case of an accident,

[0285] FIG. 29 shows a block diagram of a simplified data generation and evaluation process,

[0286] FIG. 30 shows a block diagram of a more secure data generation and evaluation process,

[0287] FIG. 31 shows a vehicle with a driving motion detector comprising an activation device,

[0288] FIG. 32 shows the driving motion detector in detail,

[0289] FIG. 33 shows a swing of the driving motion detector hitting a housing,

[0290] FIG. 34-37 show different versions of an activator of an activation device,

[0291] FIG. 38 shows a process of activating a processor after a period of sleep, and a communication with a mobile communication device,

[0292] FIG. 39 shows the process where no mobile communication device is found,

[0293] FIG. 40 shows a process where no mobile communication device is found and motion data is monitored by an additional sensor of the motion detector,

[0294] FIG. 41 shows a process where no movement is detected by the mobile communication device and the motion detector is put asleep,

[0295] FIG. 42 shows an alternative motion detector in detail,

[0296] FIG. 43 shows a further motion detector with an inner housing floating in fluid within an outer housing,

[0297] FIG. 44 shows an alternative spherical motion detector with a wider fluid chamber, and

[0298] FIG. 45 shows a driving motion detector on a string as mounting aid.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0299] FIG. 1 shows a schematic block diagram of a server 2 and a communication device 3. In this embodiment of the invention the server 2 is a server 2 of an insurance company for monitoring the driving of a plurality of insurance customers who have chosen to be billed according to properties of their driving. For monitoring the driving of a vehicle 4, which in FIG. 1 is depicted only schematically, the communication device 3 is connected to an on-board diagnostics system 6 of the vehicle 4 which during driving transfers driving data to the communication device 3. In general, the communication device 3 can be fixed to any device 4 to be monitored, and the server 2 can be any server 2 for evaluation of the monitoring data.

[0300] The communication device 3 is a device fixed to the vehicle 4, preferably without tools removable fixed to the vehicle 4, like plugged into a mechanical plug interface, and has a first data interface 7, which can be a mechanical data interface, like a plug, adjusted to a mechanical data interface 8 of the vehicle 4. In the special embodiment shown in the figure the communication device 3 is a so-called dongle with a plug interface 7 for connecting with a physical interface 8 of the on-board diagnostics system 6, for instance. The on-board diagnostics system 6 is a client of the server 2 which serves many on-board diagnostics systems of different vehicles as data receiving server and software update server.

[0301] As shown in the upper section of FIG. 1, the plug interface 7 is wired with an intermediate protection unit 10, and is together with the protection unit 10 part of a data safe zone 11 within the communication device 3. The protection unit 10 is located in a data communication line between the first data interface 7 and a second data interface 12 which is a wireless data interface 12 transmitting the received data wirelessly, as is depicted by the broken arrows in FIG. 1.

[0302] The safety of the safe zone 11 results from the communication structure of the protection unit 10 which is a one-way data connection 13 in the communication line between the plug interface 7 and a main processing unit 14 of the communication device 3 in the direction to the main processing unit 14 only. The main processing unit 14 may be the electronic circuitry within the communication device 3 that carries out the instructions of a program code by performing the basic arithmetic, logical, control and input/output operations specified by the instructions. It is the processor of the communication device 3 as central part distinguished from external components such as main memory and I/O circuitry.

[0303] In a first embodiment the one-way data connection 13 is a strict one-way physical connection 13 which can be defined as transmission or communication line having on one side only a sender or transmitting unit, like in the safe zone 11, and no electronics capable of further processing received signals. The intermediate protection unit 10 is free of a writable memory, and a remote modification of its software is impeded significantly due to the one-way communication 13 and the lack of a writable memory, accordingly.

[0304] In a second embodiment the one-way data connection 13 is achieved by blocking the data traffic in the reverse direction, like by a data blocker 15. This data blocker 15 can at least partly be part of the protection unit 10, and contains software 16 which only when executed lets data pass in the direction to the first data interface 7 and lets only such data pass which has a format of a time and a data size of one byte. Further, the software 16 is configured in such way that it accepts data only once per 24 hours or less.

[0305] In the shown embodiment the data blocker 15 is a part of the main processing unit 14 as well where it contains software 16 allowing the receipt of data by the protection unit 10 only if it has a format of a time and a data size of one byte. All other data is refused or blocked from sending.

[0306] If in certain situations a data transfer from the main processing unit 14 to or through the protection unit 10 is useful, a data channel 17 is activatable by a mechanical switch 18 which allows a data transfer from the main processing unit 14 to the safe zone 11. The switch 18 is a mechanical switch which is operated mechanically from outside an outer housing 19 of the communication device 3, like pressing a button or switching a knob from a first position to a second position. Such special situations could be present, if a special data output of the protection unit 10 needs to be triggered by a special request, or if it is useful to transfer data through the safe zone 11 to the diagnostic system 6 or any other vehicle system. Preferably, a timer is present inside the safe zone prepared to break the connection with no further manual intervention after a predetermined period of time after the special two way channel has been enabled.

[0307] In case the data transfer from the safe zone 11 to the main processing unit 14—or in general from the diagnostic system 6 or any other vehicle system or client to the server 2—should be interrupted or tagged as special situation data, the communication device 3 comprises a disengage switch 20 which—when mechanically activated—interrupts the one-way communication 13 to the main processing unit 14. Alternatively to or additionally to the disengage switch 20 an exception switch may be present which tags the passing data packages with a tag designating them as special data. This could be useful if the vehicle 4 is driven in a special mode during maintenance or repair or is tested after maintenance or repair.

[0308] The protection unit 10 receives from the on-board diagnostics system 6 all kind of diagnostic data, and filters from those data predetermined kind of information which is then forwarded to the server 2. If the protection unit 10 contains a list of relevant parameters, it may poll parameter data to those parameters from the OBD 6 and thus selects only the relevant data. To keep the protection unit 10 simple, in another variant the protection unit 10 just cycles and continuously outputs across the one direction line 13 all the diagnostic vehicle data to the main processing unit 14. The main processing unit 14 then removes whatever OBD data it needs for the UBI or whatever data gathering in progress and discards the rest.

[0309] During operation the data retrieval and evaluation system, comprising the server 2 and the communication device 3, monitors the status data and operation data of the device to be monitored, like the vehicle 4 in this illustrative example. While in the following, all illustrations refer to the on-board diagnostics 6 of the vehicle 4 and the insurance server 2, every described detail may be used in a broader sense and combined with a general monitoring unit in a monitored device and a remote evaluating server connected to the monitored device via the communication device 3.

[0310] The data of the monitored vehicle parameters are generated in the vehicle 4 and monitored with the on-board diagnostics unit 6 which is connected by wire to the communication device 3. The protection unit 10 filters these data according to a predetermined filtering plan deposited in a memory of the protection unit 10. The resulting data are sent to the main processing unit 14 which forwards the data via WiFi or Bluetooth to the mobile device 24. The mobile device 24 runs a software application for processing those data and forwarding them to the server 2 by GSM or WiFi telecommunication, as appropriate. Further, the mobile device 24 generates data itself which it combines with the monitoring data received from the communication device 3. The combined data are sent to the server 2. Such additional data may be geographical data retrieved by a GPS receiver, speed data, and/or acceleration and deceleration data retrieved by an acceleration sensor included in the mobile device 24.

[0311] For further communication protection the protection unit 10 comprises a random code generator 27 which periodically generates a random code according to a mathematical algorithm contained in the protection unit 10. In an alternative to the random code generator 27 in the protection unit 10, a random code generator in the main processing unit 14 of the communication device 3 may be used.

[0312] The communication device 3 comprises the second data interface 12 with two wireless communication units 22, 23, one communication unit 22 being a Bluetooth unit and the other one a WiFi unit 23. To save space and a separate antenna, both units 22, 23 may use one single antenna, and thus can only by operated successively and not simultaneously. Both communication units 22, 23 are prepared for communication with a mobile communication device 24. While the communication device 3 is a short distance communication device using Bluetooth and/or WiFi, the mobile communication device 24 is a smart phone or any other vehicle implemented or hand held device for long distance wireless remote communication, using GSM, for instance. In the shown embodiment of FIG. 1 the mobile device 24 is connected to the server 2 directly via GSM connection.

[0313] Both connections from the mobile device 24 to the main processing unit 14 and from the mobile device 24 to the server 2 are bi-directional.

[0314] The communication device 3 and the mobile device 24 form a communication system 26 which during journeys of the vehicle 4 travels with the vehicle 4, and is thus part of a moving vehicle system comprising the vehicle 4, the mobile device 24 and the communication device 3. This moving vehicle system comprises the on-board diagnostics system 6 of the vehicle 4 and the communication system 26, wherein due to the protection of the communication system 26 against applying unauthorized code by means of the invention the on-board diagnostics system 6 is protected against applying unauthorized code as well. Thus, the invention comprises a method for protecting an on-board diagnostics system 6 of a vehicle against applying unauthorized code as well.

[0315] The communication system 26 communicates with the stationary server 2 and comprises the features of the communication device 3 and the mobile device 24, wherein the features of the communication device 3 may be implemented in the mobile device 24 and vice versa, both devices 3, 24 can form a single mechanical device, accordingly. For the sake of simplicity and easier handling in the following description the features of the communication system 26 are separated into the communication device 3 and the mobile device 24—as shown in the figure—wherein this embodiment does not limit the invention to this special feature distribution.

[0316] FIG. 2 shows the fixed communication unit 3 with its safe zone 11, the interface 7 to the on board diagnose system 6, the Bluetooth and WiFi unit 22/23, and the processing unit 14. The safe zone 11 is connected to the processing unit 14 by means of the signal connection 13, wherein on the safe zone side the connection 13 ends in a transmitter Tx and in the processing unit side in a receiver Rx. By this configuration no signal can be sent to from the processing unit 14 to the safe zone 11, but only in the reverse direction. Optionally, a direction filter unit 21 can be put in the signal line 13 which transfers electrical signals only in the direction away from the safe zone 11.

[0317] The second signal connection 18 comprises the mechanical bidirectional switch 17 with which the second line 18 can be added to and withdrawn form the first line 13. The switch 17 is controlled by a mechanical switch 17a which is operable only by means of manual action, like pushing the switch 17a. The switch 17a is mechanically operable from the outside of the housing 19 of the fixed communication device 3.

[0318] The switch 17a is connected to a bi-directional command unit which controls bi-directional enable unit, like a mechanical actuator. The command unit receives a signal from the switch 17a, like by connection of two electric contacts, and controls the enable unit as a function of the signals received from the switch 17a. Further, the command unit controls the enable unit so that a closed switch 17, resulting in a closed signal contact between the processing unit 14 and the safe zone 11, opens after a predetermined time span, like 10 minutes, and the line 18 is interrupted again. The time span depends on the signals of the switch 17a. If the switch 17a is pushed once, the time span is 10 minutes, if the switch 17a is pushed twice, the time span is 20 minutes, and so on, every push prolongs the time span.

[0319] The switch 17 is a mechanical switch which cannot be operated by software, but needs to be operated mechanically and manually, like pressing a button or activating a switch from a first position to a second position. The reverse signal direction is thus only manually connectable, and adds a second physical signal line 18 to the one way physical connection 13.

[0320] Such special situations could be present, if a special data output of the safe zone 11 needs to be triggered by a special request, or if it is useful to transfer data through the safe zone 11 to the diagnostic system 6 or any other vehicle system.

[0321] In case the data transfer from the safe zone 11 to the main processing unit 14—or in general from the diagnostic system 6 or any other vehicle system to the server 2—should be interrupted or tagged as special situation data, the communication device 4 comprises a disengage switch 20 which—when mechanically activated—interrupts the one way communication 13 to the main processing unit 14. Alternatively the disengage switch 20 tags the passing data packages with a tag designating them as special data. This could be useful if the vehicle 6 is driven in a special mode during maintenance or repair or is tested after maintenance or repair.

[0322] The safe zone 11 receives from the on-board diagnostics system 6 all kind of data, like diagnostics data, vehicle component status data and/or vehicle driving data, and filters from those data predetermined kind of information which is then forwarded to the server 2. Alternatively, the communication unit 3 requests from the on-board diagnostics system 6 specific kind of data, especially driving data characterizing one or more driving parameters, like acceleration, location data, speed data, throttle actuation data, and the like.

[0323] To keep the safe zone 11 simple in another variant the safe zone 11 just cycles and continuously outputs across the one direction line 13 all the diagnostic vehicle data to the main processing unit 14. The main processing unit 14 then removes whatever OBD data it needs for the UBI or whatever data gathering in progress and discards the rest.

[0324] As can be seen from FIG. 2, the on board diagnostic system 6 can be connected in two different ways to the main processing unit 14. Both paths, which are shown with a broken line, can be installed alternatively or additionally. If the signal line through the safe zone 11 is used a data manipulation of the on board diagnostic system 6 can be blocked, since a hacking attempt or malware has to pass the safe zone 11 which is not possible. If the line around the safe zone 11 is used the safe zone 11 cannot be manipulated from the side of the on board diagnostic system 6, which renders the safe zone 11 even safer.

[0325] The server 2 comprises a list 28 of addresses of those communication devices from which the server 2 collects data. In this embodiment of the invention it is a list of MAC addresses (Media Access Control address) or Ethernet Hardware Addresses. Further, the server 2 is furnished with a random code generator 30 which is identical or at least similar to the random code generator 27 of the communication device 3 and comprises the same mathematical algorithm to generate random codes. Accordingly, both random codes are identical upon the input of the same seed key. Both random code generators 27, 30 may be furnished with or connected to a clock 31, 32 and comprise a clock algorithm which sets a pace or rhythm for generating the random codes, either in predetermined time intervals or in predetermined time points of the day. Time points, as time points of code generation may serve as seed key, so that both random code generators 27, 30 supply identical random codes at identical points in time, for instance, or with a predetermined and preferable constant time delay, like a number of seconds or minutes.

[0326] A memory in both the server 2 and communication device 3 may also contain a repertoire of alternative encoding key generation algorithms for the seeds involved. Changes of the encoding key algorithm are affected in a synchronous manner by the server and any connected devices using said Dual Direction Data Security.

[0327] The main processing unit 14 of the communication device 3 contains an operating software program code for controlling the main operations of the main processing unit 14 and/or the communication device 3. This operation program is present in a plurality of different variations, each variant performing identical operations, but differ in details from one another that do not have influence on the result of the operations as such to be performed by the operation program. Nevertheless, the different variations differ in code length, code arrangement, performance speed, execution time and/or further details that distinguish each version clearly from each other version of the program. A plurality of such different program codes are stored in a program code memory 33.

[0328] A GIS database 34 with geographical information, like roads, geographical areas, speed limits combined with locations and the like, is used by the server to allocate driving data to geographical locations or areas for better interpretation of the driving data. A metric computation unit 36 serves for calculating a driving metric, e.g. for every driver, which gives detailed information about the driving behavior of the driver, which influence the insurance premium of the driver or respective vehicle of the driver.

[0329] During operation the data retrieval and evaluation system comprising the server 2 and the communication device 3 monitors the status data and operation data of the device to be monitored, like the vehicle 4 in this illustrative example. While in the following, all illustrations refer to the on-board diagnostics 6 of the vehicle 4 and the insurance server 2, every described detail may be used in a broader sense and combined with a general monitoring unit in a monitored device and a remote evaluating server connected to the monitored device via the communication device 3.

[0330] The data of the monitored vehicle parameters are generated in the vehicle 4 and monitored with the on-board diagnostics unit 6 which is connected by wire to the communication device 3. The protection unit 10 filters these data according to a predetermined filtering plan deposited in a memory of the protection unit 10. The resulting data are sent to the main processing unit 14 which forwards the data via WiFi or Bluetooth to the mobile device 24. The mobile device 24 runs a software application for processing those data and forwarding them to the server 2 by GSM or internet telecommunication, as appropriate. Further, the mobile device 24 generates data itself which it combines with the monitoring data received from the communication device 3. The combined data are sent to the server 2. Such additional data may be geographical data retrieved by a GPS receiver, speed data, and/or acceleration and deceleration data retrieved by an acceleration sensor included in the mobile device 24.

[0331] FIG. 3 shows processes in the server 2, in the communication device 3, and in the mobile telecommunication device 24. To initiate a software upload from the server 2 to the communication device 3, the server 2 and the communication device 3 each identify the protected data communication to the communication device 3 or server 2 respectively. This identification is initiated by the server 2 and not by the client 6 or communication device 3. For this, the server 2 in step 44 generates or reads out from the code basis 33 software code containing operation functions to be performed by the communication device 3. This software code is the code to be uploaded from the server 2 to the communication device 3.

[0332] In step 46 the server 2 generates with its random code generator 30 a random code. The code generator 30 uses the clock time originating from the clock 31 as seed key for deterministic code generation, wherein a predetermined time span is added to the current clock time, like 3 minutes. Accordingly, if the server clock 31 shows 9:07:03 am, the clock time used as seed key is 9:10:03 am. The seed key can be a first kind seed key which determines the output random code alone.

[0333] The random code can then be coupled to the software code to be uploaded from the server 2 to the communication device 3, or more general, sent to the communication device 3 together with the software code. If the code arrives unimpaired at the communication device 3, this is evidence that the software code is not modified maliciously. However, this a rather weak protection. A stronger protection is a hidden coupling of the random code to the software code, so that the separation of them code from the software code is difficult and so is then the manipulation of the software code alone. A hidden coupling can be achieved in the following way, for example.

[0334] The generated random code comprises a random character string as key for identifying the communication to be protected, and a random character position code, wherein both, the random character string and the character position code lie within a predetermined code span, like 0 to 999,999,999 for the random character string and 0 to 9,999 for the character position code.

[0335] In the next step 48 the random character string is inserted into the software code containing operation functions to be performed by the communication device 3, the software code serving as character bed for the random character string. The character string is added into the character bed at the position indicated by the character position code.

[0336] FIG. 4 depicts this procedure in more detail. FIG. 4 shows the server 2, the communication device 3, and the mobile device 24 in the communication line 50. When a communication line 50 between the communication devices 3, 24 is established, the mobile device 24 sends information to the server 2 informing about the active channel 50. Now, the server random code generator 30 generates the random code 52 which comprises the random string sequence 54 and the random character position code 56. This code was generated at a time point, wherein in the generation process a time lag was added to the time point, like 3 minutes added to the day time 9:07:03 am. The code was added in step 48 into the software code serving as character bed 58, which is then the altered data set 60, i.e. the software code 58 with the character string 54 added at the position indicated by the character position code 56.

[0337] A higher security level can be achieved, if the random code 52 comprises a plurality of random string sequences 54 each with a random character position code 56. Each random string sequence 54 is inserted into the character bed 58 at the position indicated by its respective character position code 56.

[0338] In the next step 62 the altered data set 60 is transmitted to the mobile device 24. The mobile device 24 transmits the altered data set 60 to the communication device 3 in step 64. The communication device 3 receives the altered data set 60, the receipt triggering the start 66 of a verification process which runs in the main processing unit 14. In this verification process in step 68 the random code generator 27 of the communication unit 3 periodically generates random codes 70 which—identical with the random codes 52 of the server—involve the day time when the code was generated. The generation period is 1 s, for instance, every second a new random code 70 is generated.

[0339] Each random code 70 is generated from the same mathematical algorithm as used in the server 2, resulting in the identical random codes 52, 70 when using the same time point in the generation process. As the server random code 52 the device random code 70 comprises as random character string 72 and a random character position code 74.

[0340] In step 76 of the process the communication device 3 searches the received altered data set 60 for the random character string 72, which is contained in its own random code 70, at the position indicated by the position code 74. FIG. 4 depicts that the device random code was generated at 9:10:00 am, which is a different time point as the server time point for generation of the server random code 52. The device random code 70 differs from the server random code 52, accordingly. In step 78 the communication device 3 compares the character string found in the altered data set 60 at the position indicated by the character position code 74 with its own random character string 72. As depicted in FIG. 4 the comparison of step 80 fails, the character strings 72 are not identical.

[0341] The time span for repetitive comparisons of character strings is predefined, and preferably is the same time span which was added as time lag to the server clock time for server random code generation. In the given example the time span is 3 minutes and starts with the receipt of the altered data set 60. The communication device 3 checks in step 82 whether the time limit at the end of the time span is over. If this is not the case, after a waiting time 84 a following random code 70 is generated in step 68. Preferably the waiting time 84 is consistent with the interval with which the random codes 70 are generated, so each generated device random code 70 is matched with the server random code 52 or the altered data set 60, respectively.

[0342] This procedure is repeated until either if a match occurs or the time limit is passed. In the latter case step 82 branches to step 86 in which the altered data set 60 is discarded and hence deleted from the memory of the communication device 3. The update of the software failed in this case. This failure is reported from the communication device 3 to the server 2.

[0343] There are several possibilities for a software update failure. If the server 2 sends an altered data set 60 to the communication device 3 and does not receive a response, the communication line 50 is blocked in one or the other direction. If a response is received but negative, the reason could be a too long delay in the communication line 50 for sending the altered data set 60 to the communication device, so the time limit for comparison is over, i.e. the data set 60 arrives at a time which is later than the time point used for generation of the server random code 52. By retrying the update this error can be corrected.

[0344] Another reason could be a wrong clock time in the communication device 3, based on a power cut at some time, for example. Then the communication device 3 needs a reset in clock time which could be done by a person handling with the device 3, like the vehicle holder. Eventually, the communication device 3 needs a new battery to bridge any future power cut. If that does not lead to a later match of random codes 52, 70, the software might be corrupted and needs a reset. In any case, the server 2 knows that the data communication with the communication device 3 is not protected, data from the communication device 3 are being handled with the respective precaution by the server 2.

[0345] As is shown in FIG. 5 at the device clock time, which is 9:10:03 am in the example shown, the match is successful. The random codes 52, 70 are identical, and the character string 72 is searched at position 74, strings 54, 72 and positions 56, 74 in the character bed 58 being identical. In case of the random codes 52, 70 each having a plurality of strings 54, 72, the communication device 3 compares at each character position code 74 its respective random character string 72 with the character string 54 found in the altered data set 60 at the respective position indicated by the character position code 74. The match is confirmed in step 80, and the character string 72 is erased in step 88 from the character bed 58 or altered data set 60 respectively which then is the correct software code for the device update. Accordingly, the software modification with the correct software code can take place.

[0346] The communication device 3, however, is programmed for a supplemental protection routine which needs to be positive before performing the software modification. This supplemental protection routine includes the steps of confirmation of the clock time which was used for the generation of the successful random code 70, and eventually the linked character string 72 and character position code 74. These data are sent to the mobile device 24 in step 90 which forwards the data to the server 2 in step 92.

[0347] The server 2 receives at least the clock time in step 94 and compares it with its own clock time for random generation in step 96 and checks the match in step 98. If the check is successful, the clock times are identical, the server 2 sends a confirmation 100 via smart phone transfer 102 to the communication device 3. If the check fails, the clock times are not identical, the server 2 sends a warning 104 via smart phone transfer 102 to the communication device 3. Meanwhile the communication device 3 waits for the reply in the loop waiting 106, checking inbox 108 and checking time limit for receiving the reply 110. If the reply arrives in step 112, the reply is checked for contents 114, and if the reply is positive, hence a confirmation, the data set or modified software is applied 116 to the work storage of the communication device 3. If the reply contains the warning, the data set 58 is discarded and erased 118 from the memory in use for caching the new software before applying to the work storage. The vehicle driver is optionally be informed, like with a message on his smart phone display, that the system is compromised somewhere, and the driver is prompted to disconnect the dongle 3 from the vehicle 4.

[0348] The supplemental protection routine is depicted in a short outline in FIG. 6. The clock time 120 is sent via smart phone 24 to the server 2, compared with the clock time including the added time lag for code generation, and a confirmation or warning is sent to the communication device 3, again via smart phone 24.

[0349] A similar process for protecting the communication device 3 against infection of malware or other unwanted modification of its software is shown in FIG. 7. The flow diagram of FIG. 7 is similar to the one in FIG. 3, and identical steps are marked with the same reference numeral, wherein the flow diagram of FIG. 7 contains a few additional steps inserted in the method.

[0350] The server 2 in step 44 generates or reads out software code. This software code is the code to be sent to the communication device 3. In new step 45 the server 2 determines a code parameter, like the code length, for example. Now, as in FIG. 3, in step 46 the server 2 generates with its random code generator 30 a random code. The code generator 30 uses the clock time as seed key for code generation, wherein a predetermined time span is added to the current clock time, like 3 minutes. The generated random code comprises a random character string as key for identifying the communication to be protected, and a random character position code, wherein both, the random character string and the character position code lie within a predetermined code span, like 0 to 999,999,999 for the random character string and 0 to 9,999 for the character position code.

[0351] In the second further step 47 a second random process is used which modifies the random code. For this a second random code generator is used. Here the determined length of the software code or file serves as second seed key for the modifying process. The seed key can be used as first kind seed key for generation of a second random code which is then used to modify the first random code of the first random process. Or the first random code is used as input and first kind seed key and the file length is used as second kind seed key for controlling the second randomization process. Both methods are equivalent in this specific case.

[0352] The result of this second randomization process is a modified random code which again contains a random character string and a character position code, or a plurality of random character strings each with a related character position code. Alternatively, no new character position codes are produced, but the character position codes from the first randomization process are used and linked to each respective random character string of the second randomization process. This alternative is depicted in step 47a of FIG. 7.

[0353] Now, in step 48 the random character string(s) is/are inserted into the software code, which might be software containing operation functions to be performed by the communication device 3, the software code serving as character bed for the random character string(s) which are added into the character bed at the positions indicated by the character position codes.

[0354] When the modified random code arrives at the communication device 3 in step 66, it triggers the start of a verification process which runs in the main processing unit 14. As in FIG. 3, in step 68 the random code generator 27 of the communication unit 3 periodically generates random codes 70 which—identical with the random codes 52 of the server—involve the day time when the code was generated as seed key. These random codes 70 indicate the positions of the inserted second random codes, but do not reflect their contents, since the inserted second random codes have been gone through the second random process whereas the random codes 70 have not and are different, therefore.

[0355] To copy the second random process performed by the server 2, in step 67 the communication device removes the inserted second random codes from the software code, or—if the code length of the inserted second random codes is known—subtracts this code length from the code length of the received software code.

[0356] Now, the obtained reduced length of the software code is used as seed key for the same second randomization process as was performed in the server 2, the communication device 3 containing the same random generator than the server 2 for performing this second random process. This second random process supplies the modified random codes in step 67a, which are then compared in step 78 with the inserted second random codes removed from the software or still in place at the positions indicated by the character position codes. The rest of the method steps is identical as described with regard to FIG. 3.

[0357] By this method of two interleaved randomization processes the code length of the software code is used as seed key as well, enabling a verification of the original code length of the software to be used by the communication device 3. This method prevents that a malware code is simply added at the end of the software and not detected by the verification process. Such added code will modify the code length of the software and will lead to a modified second seed key, which then will result in a different second random code. In consequence, the comparison of step 78 will fail and the software will be deleted in step 86.

[0358] It may happen, that the communication device 3 is separated from an external power supply, for example if it is separated from the vehicle 4. This could impair random code generation, since a clock 32 would be without power and time measurement would be terminated. This would interfere with the random code comparison procedure since the time points for generation of random codes would change and the random code generators 27, 30 would not be synchronized anymore. To prevent this disadvantage, the communication device 3 is equipped with a battery or capacitor which serves as internal power supply 130 in case the external power supply is not connected. Preferably the internal power supply 130 is located in the protection unit 10.

[0359] As described above, the communication device 3 is protected by several layers 38, 40, 42 of protection. These protection layers can be applied to the mobile device 24 as well, either in combination of two or three layers or alone. For example, the random code comparison procedure as described above for the communication device can be applied to the mobile device 24 as well or alternatively. The device random code will then be generated in the communication device 3, preferably in the safe zone 11, and sent to the mobile device 24, or the mobile device 24 asks the communication device 3 for passing over the device random codes.

[0360] The main processing unit 18 of the communication device 4 contains an operating software program code for controlling the main operations of the main processing unit 18 and/or the communication device 4. In the server 2 this operation program is present in a plurality of different variations, each variant performing identical operations, but differ in details from one another that do not have influence on the result of the operations as such to be performed by the operation program. Nevertheless, the different variations differ in code length, code arrangement, performance speed, execution time and/or further details that distinguish each version clearly from each other version of the program. A plurality of such different program codes are stored in a program code memory of the server 2.

[0361] The main processing unit 14 is connected to an application memory 37 in which the operation program of the communication unit 3 is stored. This program is loaded into the main processing unit 14 and executed by which the sending of data to a remote server is conducted. This program is structured as code loop routine running in a continuous loop. A scheme of such program is depicted in FIG. 8.

[0362] FIG. 8 shows an operation program 122 of the communication device 3 structured as a code loop routine running in a continuous loop 123. The program has several outputs 124 depicted only schematically and branching dependent from several input parameters. The loop 123 lets the program restart as soon as it comes to a finishing point. Each branch at its end reenters the loop 123 into a central process 125 line from which the different functions branch.

[0363] This operation program governs all functions performed by the main processing unit 14 and thus the communication device 3, at least all main functions used for forwarding data generated in the on-board diagnostics unit 6 or elsewhere in the vehicle 4 to the server 2. This is different with code executed inside the safe zone 11 or the protection unit 10. This code may or may not be structured in a loop and may be used for secure generation of verification code to prevent the application of malicious code within the communication unit 3. However, this code generation is not seen as main function of the communication device, especially with regard to filtering and forwarding data to the server 2.

[0364] To prevent a continuous application of malicious code by the communication unit 3 two measures are taken. First, the program code 122 of the main processing unit 14 is modified in a predetermined time scheme. This code modification involves a modification of the operation code 122 of the communication device 3 without modifying the outputs 124 of it. The software modification comprises changes in the software code that do not have an influence on the outputs 124 as such, but can differ the output time. Nevertheless, the modification is visible from the code as such, be it the code length as a matter of characters and/or code lines, or the duration time of execution by inserting a predetermined execution delay in some place, or additional loop diversions, that do not affect computations or functionality. In brief, the code loop is developed with multiple versions that are functionally identical but each code base/loop is structured differently.

[0365] Several versions of the operation software code 122 for the communication device 3 are stored in a code base memory of the server 2. The code 122 is modified by sending an update, or modification respectively, from the server 2 to the communication device 3. The code modification can be performed periodically. However, a modification at random time points aggravates the comprehensibility of the modification initiation and hence the disturbance of the process by an unauthorized person. An unauthorized person does not know beforehand what code or code structure will be present and what code base is needed to have his script packed into it. The server 2, however does keep a record of which current code version is installed and running in each individual processing unit 14.

[0366] As second measure a property of the operation software code 122 is checked and feedback is given about the property to the server 2. For that, the communication device 3, preferably with the code loop routine 122, determines a property of the operation software code 122. There is a plurality of properties which characterizes the operation software code 122 and can thus be used for identifying the software version either alone or in arbitrary combination with one or more other properties. If the software version is the expected one, or more general: If the inspected property is within an predefined bandwidth, the communication with the server 2, which is governed by the operation software code 122, is identified as protected.

[0367] This evaluation of a code loops inspected properties is facilitated by using test cases for which the inspected properties are prior known from development. Server 2 periodically initiates such inspections using such loop evaluation values test cases. The evaluation of LEV test cases can be absolute or statistical if the execution device can impart run-time anomalies.

[0368] One property is the run time of the operation software code 122 between two predefined program points, wherein the two points may be identical if the program is structured in a code loop. Since a software code usually has branches and/or operations depending on the input parameter, and hence the run time may be dependent on the input parameter, an advantageous parameter is the average run time, wherein the parameter is generated over a predefined number of run times. Further, the development of the run time or run time average over the time can be used as further parameter, preferably as running parameter. A distinct change is an indicator for a modification of the software.

[0369] Another property is the variance of run times over a number of run times measured, which is not only an indicator for the variance of input parameters but as well an indicator for a modification of the software. Further, the number of code lines and/or the number of code characters can be used as property.

[0370] After measurement the property is checked, preferably by the server 2. The server 2 compares the values versus values computed for the current software which should be in the communication device 3 according to data in the server 2. An expected property is an indicator for the correct or expected software in the communication device 4 and hence for correct data transfer to the server 2. Statistically significant deviation is a flag of possible hacking and hence incorrect data transfer. The received data can then be treated as less reliable or insecure or may be discarded in general. Further, repair software can be sent to the communication device 3, like a special update, to modify a property of the communication device, namely the corrupted data output to the server 2. If that does not end the code loop property deficiency the order for reset can be sent to the communication device 3 which is reset by this measure. If the reset cannot be performed for whatever reason by the device 3 itself, the reset order can be sent to a user of the device 3 to initiate the reset to default mode, like by activating a respective unit, a reset switch for instance. In the last consequence a new communication device 3 can be sent to the user by the operator of the server 2 or a commissioned party.

[0371] This described protection of the communication device 3 can be applied to the mobile device 24 as well. For example, the application running on the mobile device 24 for handling the communication between communication device 3 and server 2 can then be programmed as code loop, as described above. The code loop properties can be sent to the server 2 for evaluation. And the code loop can be updated or modified respectively as described above. Further protection can be achieved, if the protection unit 10 uses a code loop structured operation program for performing at least its main features. Properties of the code loop can be sent to the server 2 for evaluation. Of course, an update procedure or change of program initiated from the server 2 is not possible due to the strict one-way communication 13. But if a plurality of identical acting program codes are available inside the safe zone, like by installation at the manufacturer, the program codes may be altered as described above. The protection unit 10 then sends to the server 2 not only the code loop property but the version of the currently used code.

[0372] To protect the communication between server 2 and communication device 3, the communication device 3 is protected by several protection layers. FIG. 9 gives a schematic overview over a layered protection of the communication device 3. Each layer 38, 40, 42 can be used individually and without the other layers 38, 40, 42, or two or three layers 38, 40, 42 can be combined in an arbitrary manner.

[0373] In a first protection layer 38, the modification of the operation program code of the main processing unit 14 is protected by blocking the use of new program code by the result of comparison of two random codes. In the second layer 40, the protection of the program code is performed by frequent code modification, preventing an unauthorized person from having complete knowledge of the program code. Additionally or alternatively the second lay protection can be the check for one or more program parameters, like the average and variance of execution time, and detect malicious code by this. The third layer 42 protects the operation of the communication device 3 by uncovering unauthorized program code modification, providing evidence of an attack of the communication device 3, so that the device 3 can be reset, shut down or repaired to prevent the dilution of valuable information by faulty information. The three protection layers 38, 40, 42 are described in detail in the following.

[0374] The protection of layer 38 works with random sequence/code processing and can be illustrated with the flow diagram of FIG. 3. Any update or other modification of the software of the communication device 3 has to be performed with great care to prevent the upload of unwanted modified code to the communication device 3. Therefore, before uploading software code, the protected data communication is checked, and only if the protected data communication is identified, the modified data code will be uploaded to the communication device 3.

[0375] A further measure to protect the communication between the communication system 26 and the server 2 is the identification of manipulated data sent from the communication system 26 to the server 2. Possible options of such identifications are illustrated in FIGS. 10 to 16.

[0376] FIG. 10 shows the communication system 26 with the communication device 3 and the mobile device 24, and the server 2. The mobile device 24 comprises an application 132, which is software running on the device 24, and a GPS unit 134. The GPS unit 134 determines the current position of the mobile device 24 and stores the position data related to those positions and the time data related to each position in a file. Further, the GPS unit 134 generates speed data from the position data and the related time data, so that for each position a speed value is present representing the driving speed of the vehicle 4 at the respective position.

[0377] The mobile device 24 further comprises a trend line unit 136 which calculates travel trend lines from the position data. For calculating the travel trend lines, the location data, as the position of the vehicle 4, are preferably camouflaged by a position error, especially a random position error. For this, to each location point a random error in the area up to 50 m around the location is added to the respective two dimensional coordinates. Each trend line is calculated from position coordinates, especially from camouflaged position coordinates. The travel trend line represent a travel trend. The trend lines can be straight direction trend lines separated by a predefined travel parameter of the vehicle, like direction change of the travelling route. Travel segments instead of exact location data do not mirror the actual route taken by a vehicle but represent directional tendencies, preferably not highly resolved enough to reconstruct a route but sufficient to relate them to areas of special interest, like geographic area, specifically actuarial areas. Trend lines may be 1.sup.st order polynomial fits to positional coordinates, preferably to positional coordinates camouflaged by coordinate errors. The travel trend lines which can be calculated via a series of least squares error first order polynomial fit of the general form, (Y=a+bX), or higher order polynomial, for example, although other line and trend fitting methods can be used. When a plurality of camouflaged location points is present, the current trend line is calculated in the mobile device 24. When the route driven changes in direction the current trend line is terminated and a new trend line is calculated. The transition from one trend line to the next following trend line can be determined by a nominally monotonic decrease in b below a predefined threshold. For instance, if the least squares are increasing over two, three or more successive points this is considered as indicator to end the present trend line and start a new one. The actual movement of the vehicle is thus transformed via coordinate camouflaging and least squares fitting into a series of trend lines, each trend line being defined by a start coordinate point and a termination coordinate point. The start/termination coordinate point can be the cross point of two trend lines or one of the positional coordinates or coordinate points in other words. The respective coordinate point can be the point where the second, third or following successive decrease of b happened, this point belonging to both trend lines.

[0378] The trend lines, the exact location data, the speed data and eventually further data, like acceleration data, are packed into a data capsule 138 or data package by the application 132 and sent to the server 2 as shown in FIG. 10. To preserve privacy the location data 140, the speed data 142 and the trend lines 144 are stored in separate files. The order of the location data 140 and/or the speed data 142 in each file are randomized, so that an allocation of the speed data 142 to the location data 140 and in general the allocation of the speed data 142 to an exact location is made impossible. Each file is precisely defined in data arrangement and length or maximum length of the file.

[0379] To protect the communication line 50 between the mobile device 24 and the server 2 the data capsule 138 or data package is supplied with security code which allows the identification of a modification of the data capsule 138 after its generation. The generation of this security code and its distribution in the data capsule 138 is depicted in FIG. 11. FIG. 15 shows a flow diagram of the security code process.

[0380] FIG. 11 shows the communication device 3, the mobile device 24 with the software application 132, and the server 2. During the journey of the vehicle 4 driving data, like location data, speed data, and travel trend lines are collected. These data are assembled into the data capsule 138 as depicted in step 202 of FIG. 15 One data capsule 138 may contain all data of one trend line, of a predefined travel time span, of the whole journey or any other travel unit. When this travel unit is finished the entirety of the travel unit data is generated and stored in the data capsule 138, and the data capsule 138 is supplied with a security code.

[0381] For this, in step 204 the application 132 calculates a hash value or any other parameter check value of the data capsule 138. This value refers to the data capsule 138 without the security code added into it.

[0382] To finish the generation of a data capsule 138, the application 132 in step 206 requests the communication device 3 to issue a random code 208 which then is generated by a random code generator 210 of the communication device. This random code generation may or may not be independent of the time of the day, so the random code generator 210 may be the random code generator 27 of the device 3 or be identical to the random code generator 27 or be a supplemental and different unit. The random code 208 may be a true random code made by using a physical parameter, for instance, or be generated identical as with random code generator 27. The random code generator 210 generates the random code 208 in step 212 and transmits it in step 214 to the mobile device 24.

[0383] The mobile device 24 as well as the server 2 both are furnished with a random code generator 216, 218 which are identical or at least similar to one another and comprises the same mathematical algorithm to generate random codes. Both random code generators 216, 218 supply identical random codes from identical inputs. The random code generator 218 may be identical to the random code generator 30 of the server 2 or be a supplemental and different unit.

[0384] In step 220 the application 132 feeds the random code 208 to the random code generator 216 as first kind seed key, in response, the random code generator 216 outputs in step 222 synthetic data 224 as identification data comprising: [0385] one or a plurality of random numbers or random synthetic travel data, [0386] the same number (quantity) of random position codes and [0387] a supplemental position code for the parameter check value 226.

[0388] In the next step 228 the application 132 inserts the synthetic travel data 224 into the respective files of the data package 138 each at the position in the file indicated by the respective position code. Each unit of synthetic travel data together with its position code forms a set of synthetic travel data. In this embodiment the random set number is 10, so 10 sets of synthetic travel data are generated and placed in 10 places throughout the files of the data capsule 138. When this procedure is repeated with a successive data capsule 138 later the random number will most probably be different, and 25 sets are generated, for instance, and distributed in the files of this later data capsule.

[0389] In step 230 the application 132 adds the parameter check value 226 to one of the files according a value random position code generated by the random code generator 216. In step 232 the application 132 adds the random code 208 to the data package 138, like into one of the files or at the end of the package. The generation of the data package 138 is now finished, and it is sent in step 234 to the server 2 for evaluation.

[0390] The server 2 receives the data capsule 138 in step 236 and performs a number of checks with the data capsule 138. The first check in step 238 is the check of the predefined data structure of the files in the data capsule 138. Then, in step 240, the server 2 extracts the device random code 208 from the data capsule 138 and feeds it to its own random code generator 218 in step 242. The random code generator 218 in step 244 generates the same synthetic data 224 as was generated by the random code generator 216 of the application 132 as is depicted in FIG. 13 as well. The server 2 then and performs the following further checks.

[0391] First, in step 246 the server 2 applies the position information of the synthetic travel data 224 to the data capsule 138 and locates synthetic travel data 224 at the random number of position codes in the file and extracts the synthetic travel data 224 from the file in step 248, as is depicted in FIG. 13 as well. Then the server 2 compares in step 250 the extracted synthetic travel data 224 (App) with the self-generated synthetic travel data 224 (Server).

[0392] If the match 252 is negative for only one set of synthetic travel data 224 the data capsule 138 is deleted in step 254. If the match 252 is positive and for each set of synthetic travel data 224 the two fronting synthetic travel data 224 are identical, in step 256 the position values are extracted from the data capsule 138 and the all synthetic travel data 224 is deleted from the data capsule 138 in step 258. Further, the parameter check value 226 is extracted from its respective position which is generated by the random code generator 218, and the parameter check value 226 as well as the random code 208 is deleted from the data capsule 138.

[0393] Now, since the data capsule 138 is free of security data the server 2 calculates in step 260 the hash value or other parameter check value 226 (Server) of the data capsule 138 and compares in step 262 the so calculated value with the extracted check value 226 (App) coming from the communication device 3. This is shown in FIG. 14 and FIG. 15. If this match 264 fails the data capsule 138 is deleted in step 254. If the values are identical the data of the data capsule 138 are released in step 266 for evaluation of the driving data.

[0394] Depending on the driving data stored in the files of the data capsule 138 it could happen that the synthetic travel data 224 somehow shine out of the real travel data and are easy to find, therefore. Found security data may be manipulated as well, so that the identification process is ruined. To prevent the discovery of synthetic travel data the step 222 of generation of those synthetic travel data can be modified by using real travel data in the vicinity of each synthetic travel data. For example, the real driving data directly before and directly behind the position of one set of synthetic travel data can be used to create or modify the synthetic travel data. If the generated synthetic travel data comprise the directive that the sum of real driving data directly before and directly behind the indicated position is to be halved, the synthetic travel data is the average of the two surrounding values, and is well hidden in between the two values. In another example the generated synthetic travel data comprise the directive that a supplemental positive or negative value is added to the average of the neighboring data, the value can be random value generated by the random code generator 216.

[0395] In a further embodiment of the invention conspicuous and/or unfavorable driving data are generated as synthetic travel data and placed as identification data within the real driving data. Such unfavorable data may be high speed values, for instance, preferably a successive set of high speed values are inserted within the real driving data, so that a racing section of the journey is simulated. In case of a data manipulation such data is preferred for elimination, resulting in the elimination or manipulation of identification data. This manipulation will very reliably be detected by the server 2.

[0396] In an alternative process depicted in FIG. 16 the security against data manipulation can be increased. The flow diagram of FIG. 16 is similar to the one in FIG. 15, and identical steps are marked with the same reference numeral, wherein the flow diagram of FIG. 16 contains a few additional steps inserted in the method.

[0397] During the journey of the vehicle 4 location data and speed data are collected, and travel trend lines are generated. These data are assembled into the data capsule 138 as depicted in step 202 of FIG. 16. When this travel unit is finished the entirety of the travel unit data is generated and put into the data capsule 138. In an added step 203 the size of the data capsule 138, like the code length or the numbers of lines or entries of the data capsule 138 is determined. Next, in step 204 the application 132 calculates a hash value or any other parameter check value of the data capsule 138. This value refers to the data capsule 138 without a security code added into it.

[0398] Then, in step 206 a random code 208 is requested, generated by the random code generator 210 of the communication device 3 and sent to the application 132 in step 214. In step 220 the application 132 feeds the random code 208 to the random code generator 216 as first kind seed key, in response in step 222, the random code generator 216 outputs synthetic data 224 as identification data comprising:

one or a plurality of random numbers or random synthetic travel data,
the same number (quantity) of random position codes and
a supplemental position code for the parameter check value 226.

[0399] A second randomization step performed in the mobile device 24 is introduced in new step 225. The size of the data capsule 138 serves as seed key to modify the random numbers or random synthetic travel data obtained in the first mobile device random process. As described along with step 47 in FIG. 9 the seed key can be a first or second kind seed key. The modified the random numbers or random synthetic travel data are inserted into the respective files of the data package 138 each at the position in the file indicated by the respective position code.

[0400] The resolution of this second random process is performed by step 245 in the server 2: The modified the random numbers or random synthetic travel data are removed from the data bed, or—in case their data length is known—their data length is subtracted from the data size of the received data capsule 138. The resulting data size or length is used as seed key for the second randomization process in the server 2 in step 145a, which generates the modified the random numbers or modified random synthetic travel data. These data are compared with the removed data or data at the indicated positions in step 250.

[0401] As described with FIG. 9, the use of the data capsule size allows to detect a size modification and thus the detection of unauthorized code added at the end of the data capsule 138.

[0402] FIG. 17 shows a simplified flow chart of a process to amend software of the communication device 4. For this a data set with new software or data to be inserted into the safe zone processor unit 10 or its memory is generated by the server 2 and sent to the communication device 3, sometimes for better understanding referred to as a dongle, for example and without restriction. Since the data set could be manipulated on its way from the server 2 to the communication device 3, a data set check is performed by the communication device 3 to examine the data set for unwanted manipulations. For this an encryption process is performed which is described in the following.

[0403] In the safe zone 11 the random code generator 27 generates a random code in step 340. The random code may be a true random code made by using a physical parameter as seed key, for instance, or be generated in a deterministic manner. If the generation is deterministic the random code generation is non-reversible and hence non-breakable.

[0404] FIG. 18 depicts this procedure in more detail. FIG. 18 shows the server 2 and the communication device 3. In the communication device 3 the random code in step 342 is fed as seed key to the encryption code generator 27 which generates the encryption code. The ID of the safe zone 11 or in general of the fixed communication device 3 is used as second seed key in the generation of the encryption code. The ID is stored in a memory of the safe zone processor unit 13 and recalled by the safe zone processor for feeding into the encryption code generator 27.

[0405] Next, in step 344, the random code is forwarded to the main processing unit 18 of the communication device 3, and is stored in a memory of the communication device 3. The encryption code, however, is kept in the safe zone 11 and is not identifiable from the outside.

[0406] This process of random code generation and encryption code generation is repeated periodically, as depicted in step 346 of FIG. 17. Each random code is transferred to the main processing unit 14 of the communication device 3 which overwrites the previous random code with the current one in step 348 of FIG. 17 and FIG. 19. Each encryption code is stored in a memory of the safe zone 11 and is transferred to the outside of the safe zone 11 in step 350 only after the expiration of a predetermined waiting time period, preferably over 1 minute, like 5 minutes, for example. Each encryption code arriving at the outside overwrites the previous one in step 352, analogous to the random code storing process, with the difference that no current encryption code is present at the outside of the safe zone 11. This is the case if the waiting time for transferring the encryption code outside the safe zone 11 is at least as long as the repeating interval of the generation of the random code.

[0407] From time to time there is the need for software update of the dongle software or smart phone software, or data in the communicate system 26 need to be brought up to date. In this case data coming from the server 2 need to be incorporated into one of the communication devices 3, 24 of the communication system 26. To prevent a channeling in of malicious software or other data, the respective data set from the server 2 is provided with a safety code which makes apparent any manipulation of the data set. The safety code is present at both sides of the communication line between server 2 and communication device 3, which involves the problem that the safety code as such should be either protected against manipulation or constructed in such way that a manipulation becomes apparent, so that the data set protected by the manipulated data set can be discarded.

[0408] This problem can be solved with a safety code in form of the encryption code including one or more of the following four characteristics. First, the encryption code is generated on both sides, in the server 2 and the communication device 3, in a safe zone 11. For this the server 2 is protected in an appropriate way so that its safe zone 11 is safe against manipulations. Second, the encryption code is on both sides generated from an identical seed key which is a random key to ensure that the encryption key is not known before its generation or leaving the safe zone respectively. Third, the seed key is generated in a safe zone 11 and thus protected against manipulation, and is then transmitted to the other side. Fourth, the identical encryption code is used for modifying the data set on both sides, like encryption and decryption, adding and comparing protection information, like a pseudo code, or the like.

[0409] In case of a required data set transfer from the server 2 to the communication system 26, the server 2 opens a communication channel to the communication system 26 in step 354. If the channel is established, the server 2 sends a request to the dongle 3 in step 356 to send the current random code stored in the memory of the main processor 18. The dongle 3 transmits the random code to the server 2 in step 358 of FIG. 17 and FIG. 20 and stores this random code permanently in step 360 of FIG. 17 and FIG. 21 so that it is safe against overwriting.

[0410] Now the process branches in activities in the dongle 3 and activities in the server 2. The dongle 3 waits in step 362 for the arrival of the encryption code which is assigned to the permanently stored random code. Since this could take several minutes, it may happen that before the arrival of the encryption code the encrypted data set from the server 2 arrives at the dongle 3. The dongle 3 waits in any case until it receives the respective encryption code and stores it safe against overwriting.

[0411] The server 2 on the other side receives the random code in step 364 and feeds its encryption code generation unit. Since the encryption code generation uses the dongle ID as second seed key the server 2 accesses a data base which contains all Dongle IDs of all dongles which are supplied with data sets by the server 2. Since the server 2 knows which dongle needs to be supplied with the respective data set, it retrieves its ID in step 366 and feeds it together with the random code to the encryption code generator in step 368 and generates the encryption code. This encryption code should be identical to the encryption code which is present in the dongle 3, either still in the safe zone 11 or in the memory of the main processor 14.

[0412] As a further protection measure the server 2 ads in step 370 protection information into the data set. With respect to the data of the original data set these data are pseudo data since they do not contribute to the purpose of the data set to update software or other data in the communication system 26. The pseudo data are inserted in the data set at positions selected by the server 2 or derived from the encryption code. Instead of fixed positions the pseudo data can be inserted at given data, like at every occurrence of the number 57 in the data set. The inserted pseudo data and the position information are stored separately in step 372.

[0413] Now, in steps 374 and 376 the server 2 encrypts the pseudo data and position information on one hand and the extended data set on the other hand. To one of the so obtained files the server 2 ads the random code as such in step 378. The encryption of the data set is done with the encryption code. The encryption of the pseudo data and location data are done with the information about the length of the extended data set. Further, the random code, the encryption code, and/or the dongle ID can be used as additional information for the encryption.

[0414] Then the server 2 sends in step 380 both files to the communication system 26, either as one file or as two separate files in one transmission or linked together in two transmissions in step 382.

[0415] In the communication system 26, either of its devices 3, 24, like the dongle 3 or the smart phone 24, may perform the following steps, dependent which device 3, 24 is supplied with the data update. In the following this process is described with respect to the device 3, however, the process can be applied to the mobile device 24 as well.

[0416] When in step 384 the fixed device 3 receives the data set it searches in step 386 the correct encryption code with the aid of the attached random code. If no encryption code is linked to the random code stored in the dongle 3, the dongle 3 waits for its arrival from the safe zone 11. Then the dongle 3 decrypts in step 388 the data set using the encryption code as decryption key.

[0417] Alternatively, the random code is not attached to the data set, so the connection between the random code and the encryption code—or encrypted data—is camouflaged for better protection. Upon receipt of the encrypted data set the dongle 3 tries out every random code stored since the inquiry of the server for the random code. It will then eventually use the correct random code to generate the correct encryption code, so that the decryption is successful. Only if any decryption with all random codes stored from the inquiry on fail, the data set is discarded as possibly manipulated.

[0418] To resume the process of FIG. 17, next, the length of the decrypted and extended data set is used in step 390 to decrypt the supplemental information containing the pseudo data and its position information. Depending on the respective encryption process the random code, the encryption code and the dongle ID are used as well for decryption. Now the pseudo data in the data set and in the separate file are uncovered and are compared in step 392 by the dongle 3 using the position information to find the pseudo data in the data set. If the pseudo data of the supplemental file is identical with the information at the indicated locations in the data set, the data set is accepted in step 394. If only one detail does not match, the data set is categorized as manipulated data and discarded.

[0419] In case of the successful match the pseudo data is removed from the data set, and the remaining information in the data set is used for data update in the dongle, like executing the data set or storing the information in a data base for later retrieval. Further, in step 96, the extracted pseudo data is returned to the server 2 for confirmation and for indication of the complete and successful data transfer of the data set.

[0420] It may happen, that the communication device 3 is separated from an external power supply, for example if it is separated from the vehicle 6. This could impair random code generation, since the device 3 could run out of power. If the power supply is reinstated again the device 3 will start its activity again, however, not knowing the current time. This is uncritical, since the random code generation will start again after the power reinstatement, and any random code may serve for the encryption code generation process in the device 3 and in the server 2. A power blackout, thus does not influence the security of the system 26 as such, but only brings to a hold the activity of the device 3, the information transmission to the server 2 and, of course, any data update process. To prevent this disadvantage the communication device 3 is equipped with the power supply 130, like a battery or capacitor, which serves as limited internal power supply in case the external power supply is not connected. Preferably the internal power supply 130 is located inside the safe zone 11, so not even any supply of power needs to be going into the safe zone 11, rendering its protection even safer.

[0421] Short description of the method steps according to FIG. 17: [0422] 340 Dongle Citadel Safe Zone CPU generates a Random Key [0423] 342 Safe Zone CPU generates an Encryption Key from the Random Key and the Safe Zone ID [0424] 344 Random Key is transferred from the Safe Zone to the Dongle Main CPU [0425] 346 Random Key generation is repeated periodically [0426] 348 Each Random Key is sent to Dongle Main CPU and previous Random Key is overwritten [0427] 350 Safe zone CPU waits time span before sending the Encryption Key to Dongle Main CPU [0428] 352 Dongle Main CPU deletes received Encryption Key immediately unless Server request is present [0429] 354 In case of an impending data set transfer, the Server checks Smart Phone for Communication Link to Dongle [0430] 356 Server sends to Dongle CPU (directly or via the Smart Phone) a request for the current Random Key [0431] 358 The Dongle Main CPU transmits (directly or via the Smart Phone) the current Random Key to the Server [0432] 360 Same current Random Key is stored by the Dongle Main CPU [0433] 362 Dongle Main CPU waits for arrival of corresponding Encryption Key, stores it and links it to Random Key [0434] 364 The Server CPU receives the Random Key [0435] 366 Server accesses a data base of IDs of all involved Dongles and retrieves the ID of the transmitting Dongle [0436] 368 The Server uses the retrieved ID and Random Key to generate its own Encryption Key [0437] 370 The Server inserts into data set additional Pseudo Data at a given location or at given data [0438] 372 The Server stores the same Pseudo data and the location information in a separate file [0439] 374 Server encrypts the Pseudo Data and location data using Random Key, ID, and code length of data set [0440] 376 The Server employs own and identical Encryption Key to encrypt the data set destined for transmission [0441] 378 The Server also attaches to the encrypted code the Random Key [0442] 380 The Server sends the encrypted code plus Random Key via Smart Phone to the Dongle Main CPU [0443] 382 The extra data package is sent as a separate transmission [0444] 384 The Dongle Main CPU receives the data [0445] 386 The Dongle Main CPU uses the received Random Key to find the corresponding Encryption Key [0446] 388 The Dongle Main CPU uses the Encryption Key to decrypt the data transmission [0447] 390 The length of data set is determined and used with Dongle ID and Random Key to decode the Transmission [0448] 392 The inserted Data as indicated by Transmission is compared with data of data set at indicated positions [0449] 394 If they match the data set is accepted [0450] 396 The extracted Pseudo Data is transmitted back to the server to indicate completion of the download

[0451] It may be useful that data from the on board diagnostics system 6 are sent to the remote server 2 for evaluation. In general, driving data may be sent from the on board diagnostics system 6 to the fixed device 3. The data may be modified or not and forwarded to the mobile device 24 or directly to the server. Again, the data may be modified or not in the mobile device 24 and forwarded to the server 2. The communication lines between fixed device 3 and mobile device 24, and between mobile device 24 and server 2 are vulnerable against unwanted data attacks. To protect the data along the line from the fixed device 3 to the mobile device 24, and further to the server 2, the encryption code may be used to encrypt a data set, containing driving data, for example, in one of the communication devices 3, 24. The encrypted data set can then be sent to the server 2 which decrypts the data set. The process may be the same as described above in the reverse direction. The random code may serve in both processes, the encryption and the decryption, as seed key, either alone or together with other data, like the IP of the device 3.

[0452] An embodiment of this data transfer from the communication device 3 to the server 2 is shown in FIGS. 23 and 24. If data coming from the on-board device 6 are sent to the server 2 via the communication device 3, these data should reach the server 2 uncompromised. They are protected, therefore. For this the method starts as described above to FIG. 18:

[0453] Step 340: The Dongle Citadel Safe Zone CPU generates a Random Key. Step 342: Safe Zone CPU generates an Encryption Key from the Random Key and the Safe Zone ID. Step 344: The Random Key is transferred from the Safe Zone to the Dongle Main CPU. Step 346: The Random Key generation is repeated periodically. Step 348: Each Random Key is sent to Dongle Main CPU and previous Random Key is overwritten. Step 350: The Safe zone CPU waits time span before sending the Encryption Key to Dongle Main CPU. Step 352: The Dongle Main CPU deletes received Encryption Key immediately unless Server request is present.

[0454] Now the method branches, since it is not the server 2 which prompts for a data transfer and thus for the transmittal of the seed key or random code, but it is the communication device 3 which sends a data package 398 to the server 2. The communication device proceeds with step 358, therefore: The Dongle Main CPU transmits (directly or via the Smart Phone) the current Random Key to the Server. Step 360: The same current Random Key is stored by the Dongle Main CPU. Step 364: The Server CPU receives the Random Key and 366: accesses a data base of IDs of all involved Dongles and retrieves the ID of the transmitting Dongle. Then in step 368 the Server uses the retrieved ID and Random Key to generate its own Encryption Key.

[0455] Meanwhile the communication device 3 encrypts the data package 398 with the stored encryption key which is linked to the random code which was sent to the server 2 as is shown in FIG. 24. The communication device 3 then sends the encrypted data package 398 to the server 2 (FIG. 24). The server with its encryption key decrypts the data package. This process may be performed analogous to the steps 388 to 394 as described above.

[0456] The communication device 3 comprises the second data interface 12 with two wireless communication units 22, 23, one communication unit 22 being a Bluetooth unit and the other one a WiFi unit 23. To save space and a separate antenna, both units 22, 23 may use one single antenna, and thus can only by operated successively and not simultaneously. Both communication units 22, 23 are prepared for communication with a mobile communication device 24. While the communication device 3 is a short distance communication device using Bluetooth and/or WiFi, the mobile communication device 24 is a smart phone or any other vehicle implemented or hand held device for long distance wireless remote communication, using GSM, for instance. In the shown embodiment of FIG. 1 the mobile device 24 is connected to the server 2 directly via GSM connection. The connection from the mobile device 24 to the server 2 is bi-directional. The same is true for Bluetooth channel between the mobile device 24 and the main processing unit 14. The WiFi channel 23, however, is unidirectional to mobile unit 24, and may only be used to the degree of sending the first device identification signal, like SSID.

[0457] While in principle the data transfer between the fixed communication device 3 and the mobile communication device 24 is possible with either method, Bluetooth or WiFi, the protection of data against interception is easier with Bluetooth, first due to its limited range, and second since a logon and logoff of WiFi connections coming and going is common with smart phones moving through a plurality of WiFi zones during a journey. For this reason a communication between the communication device 3 and the mobile communication device 24 is preferably performed via Bluetooth. Also the internal processing architecture of the main processing unit 14 can remain much simpler and lower cost as well as with a coding structure that does not require a traditional operating system like Android which also inhibits hacking loop holes.

[0458] During normal use a smart phone does not search for open Bluetooth connections in the surroundings. Accordingly, if the fixed communication device 3 attempts to start a communication session with the mobile communication device 24 using Bluetooth, such attempt will fail when the mobile communication device 24 has it Bluetooth 22 switched off. Nevertheless, when the communication device 3 is awoken, like by noting an odometer change, it first seeks to establish Bluetooth connection with an application in the mobile communication device 24.

[0459] The application may itself being started up when it senses a significant GPS event. This sensing may be done by a daemon operating in the background. However, most probably no Bluetooth connection is active, so the seeking signal by the communication device 3 comes to nothing.

[0460] To reliably start a communication session with the mobile communication device 24, the fixed communication device 3 uses a WiFi channel to send a communication request to the mobile communication device 24. This WiFi is only passively sensed by the app of the mobile communication device 24. It is only used as a default mode of synchronization if the fixed communication device 3 fails to find a Bluetooth response from the application in the smart phone. A background demon or similar mechanism sense the ID, identifies it as related to the application running in mobile communication device 24 and the fixed communication device 3 mates to that application.

[0461] Accordingly, the mobile communication device 24 does not respond to the request. But it senses the WiFi ID of the fixed communication device 3, and thus knows that it is in the insured vehicle. The mobile communication device 24 now starts to log data, like Quality Metric data, via the internal GPS sensor. No communication link is forged, the dongle WiFi ID is just read by the application, and there is no data streaming in either direction. Rather the application in communication device 24, using the prior “permission” granted installation of the application, is able to turn on the mobile communication device Bluetooth. The fixed communication device 3 may continue in parallel with its WiFi SSID transmission to poll for Bluetooth, and accordingly detects the now turned on Bluetooth from mobile communication device 24 and a session and 2-way communication channel is established

[0462] If the mobile communication device 24 has operating system restrictions that will not enable the smart phone application upon identifying the Dongle WiFi SSID to turn on the Bluetooth, then it may send a push notice to the smartphone display and/or an audio to notice the user, like “Please Turn on the Bluetooth”. If the user meets this prompt a Bluetooth communication line between the fixed communication device 3 and the mobile communication device 24 is established, and both devices 3, 24 exchange data only via this channel.

[0463] If the driver does not turn on the Bluetooth, the first device logs the duration of transit and the OBD odometer reading for future upload to the server 2. In coordination the application in mobile communication device 24 logs that it detected the SSID of dongle fixed communication unit 3 and hence the Bluetooth channel 22 is not enabled—this relevant noncompliance of the insured party is communicated to the insurer and any relevant Quality metric data complied while the vehicle is in motion as detected by mobile communication device 24's GPS.

[0464] FIG. 25 shows in a block diagram the server 2, the communication system 26 with the communication device 3 fixed in the vehicle 4 and the mobile device 24 located in the vehicle 4 and the on-board diagnostics system 6. The on-board diagnostics system 6 sends odometer data, like mileage and/or vehicle speed to the interface 7, 8 where these data are received by the safe zone 11 or the protection unit 10, respectively. These data come along with the time points at which these data where acquired or measured, respectively. The safe zone 11 transmits these data to the main processing unit 14 which forwards the data to the mobile device 24.

[0465] Further, the safe zone 11 transmits the random code to the main processing unit 14 which forwards it the mobile device 24 for encoding data to be sent to the server 2. The communication unit 3 contains an acceleration sensor 502 which during driving of the vehicle 4 takes acceleration values measured and transmits them to the main processing unit 14 which again forwards the data to the mobile device 24. To keep the acceleration sensor 502 safe from malicious invasion the acceleration sensor 502 may be located inside the safe zone 11.

[0466] In the mobile device 24 alternatively or additionally an acceleration sensor 504 may be present taking acceleration values of the mobile phone 24. Although these values are much less accurate, unless the mobile device 24 is fixed in a vehicle holder during travel, these values may be used identically to the values taken by sensor 502, or at least in the same manner but considering their inaccuracy. Further, the mobile device 24 features a GPS unit 506 receiving satellite signals and generating location data and speed data from it. The location data are the location points of presence of the vehicle, so that the succession of the location points track the journey of the vehicle. Location and speed data are transferred to an application 508 which can be identical with the application 132 and runs a program executing one or more of the following method steps.

[0467] The speed data originating from the GPS unit 506 are discarded and not used. Instead, the position data are used to calculate speed data from them. Location data, i.e. the geostationary location points where the vehicle 4 traveled, and the respective speed data, i.e. the driving speed of the vehicle 4 at the location points, are stored in a data buffer 510. The location data may be irregularly or erratically picked or accepted from the GPS unit 506, preferably in a random time sequence. Since the time points associated with the picked location points are known, the speed can be calculated from the randomly picked location points.

[0468] Preferably, the GPS data are in a NMEA form and stored in the buffer 510, at least the x,y,z coordinates, the time stamp, at sub-second time intervals the co-occurring accelerometer readings and at pre-specified transit time intervals the vehicle odometer mileage reading. It should be noted that if longer distance communication like GPS are used, all the above buffer data compilation and storage could be done in the server 2. Hence, in said buffer is preferably maintained in a time synchronized manner successive GPS records with co-occurring accelerometer reading reflecting the rate of any measurable speed changes per the sensitivity of said accelerometer device and at specified time intervals during a transit the corresponding odometer reading.

[0469] The buffer 510 stores the received data for a predetermined instance of time, like 30 minutes, or 5 hours. After this time period it erases the data, like overwrites them with new data. This is shown in FIG. 25 by data blocks 512 “filled” into the buffer 510 on the top and leaving the buffer 510 at the bottom a timespan t later. The server 2 may also on occasion specify a longer or shorter period of buffer data retention to facilitate various tests of GPS data integrity. Said buffer storage is managed when capacity is reached in a First-in/First Out (FOIFO) manner.

[0470] Each block 512 contains odometer data, acceleration data, position data, speed data and time associated to location data and speed data. Each block 512 contains the data acquired over a predetermined time period, like 10 seconds.

[0471] The data blocks 512 are taken out from the buffer 510 and fed to further processing in the application 508, not necessary at the end of the timespan t but at any useful time point. Alternatively, the data are directly fed for further processing and a copy of the data is branchingly fed to the buffer 510 for safeguarding.

[0472] The data are processed as follows. Location points and speed values are stored in separate files 514, 516 and may be randomized in order therein to keep data privacy, as is indicated by the double sided arrows in FIG. 25. However, this is not necessary to find a manipulation of the location data and can be omitted here. Then these files are entered into a data capsule 518 which can be identical with data capsule 138. Travel trend lines TL are calculated from the location data which are stored in the data capsule 518 as well. Further, odometer data and acceleration data are stored in the data capsule 518.

[0473] The data capsule 518 is then encoded using the random code from the safe zone 11, the encoding being indicated in FIG. 25 by the section lining of the box, and is then sent by the mobile device 24 to the server 2. There it is decoded by an identical random key which releases the data for further processing.

[0474] The position data are mapped to a road map or road map data 520. It is then checked in a step 522 whether the location data meet road data in such measure that a reasonable travel path is located on roads. If this is not the case, especially if the travel path crosses water without a bridge or a ferry, this is evidence for a manipulation of the location data.

[0475] The regular use of the location data is to associate an area or an area class to the respective travel section in step 524, like a travel trend line, and map a driving characteristic, like driving speed in this travel section with the area class to derive a driving quality metric in step 526. This metric is highly valuable for UBI or many other purposes.

[0476] Another check for finding a manipulation of the location data is performed in step 528, where position data are compared to acceleration data. If, for example, an acceleration of the vehicle was captured by the acceleration sensor and the location data are not reflecting this acceleration, this again is strong evidence for a manipulation of the location data.

[0477] Especially, the comparison for consistency of odometer and acceleration, like GPS NMEA derived acceleration—positive or negative, does not require upload to the server but can be done to a sufficient degree of accuracy in the mobile device. Hence, in one embodiment, if the accelerometer data does not match the GPS derived GPS (i.e. change in speed over time) to a sufficient degree—we send the buffer to the server to do an odometer based test against the GPS data.

[0478] A further check is performed in step 530, where from the road map data the distance traveled according to the location data is derived and compared with the mileage from the odometer data, which is the distance shown by the odometer data between two or more odometer reading events. Here a manipulation of the location data is uncovered easily.

[0479] In other words, in the server the GPS NMEA records are examined versus a GIS data base to assess accrued mileage. The GPS based mileage, preferably derived from successive NMEA reported x,y,z coordinates, is compared with the corresponding odometer readings. If the GPS mileage computation is significantly less than the odometer derived mileage for the corresponding GPS reading, a flag is set indicating the possibility of GPS manipulation as would be done to obscure speeding and unsafe driving. Additionally one can investigate accelerometer readings to see if the GPS readings are reflecting such speed change nuances causing acceleration/deceleration events to be recorded. Significant deviations in being able to recreate acceleration/deceleration events from corresponding GPS data in the buffer would also be reason to further examine the possibility of GPS spoofing and malicious hacking.

[0480] Said analysis of buffer GPS records versus accelerometer readings, unlike GPS records versus odometer reading that are facilitated by a GIS database, can be done in real time in the mobile device giving early warning of GPS data manipulation to obscure high speed and erratic driving. If the mobile device contains or has direct access to a GIS database, the propriety check using mileage derived from GPS coordinates or speed values versus odometer reading can be done in a real time manner in the mobile device

[0481] One scenario for manipulation of driving data is to reduce recorded speed values from the speed data file to always show some low value or to appear more natural, variations with said low mean speed. This can be done by hacking the mobile device 24, which is indicated by the flash arrow 532 in FIG. 25. This is easiest when the position data are manipulated before they are entered into the application 508 and especially before they are entered into the data capsule 518.

[0482] FIG. 26 shows location data 514 in its file and speed data 516 in its file, the speed data 516 being extracted from the location data 514. During the journey of the vehicle 4 on a road 540 location points 542 are detected by the mobile device 24 and stored in the file as location data 514. The location data 514 may be taken at random points or random instants of time, as can be seen in FIG. 26, for data privacy camouflaging, but can be omitted with regard to the consistency check. Further, it is shown, that both data 514, 516 are randomized in their file. However, it is easier for checking purposes to leave the data in their generation order with regular and uniform time spans between each reading.

[0483] The speed data, i.e. the speed with which the vehicle 4 drove on the road 540, are calculated from the location data 514. Accordingly, the GPS speed reading is ignored or not used by the application 508, but instead the calculated speed stand in known relation to the detailed position readings stored in the buffer 510.

[0484] When manipulation software sees coordinates with a speed of over 50 miles per hour, for example, it reduces it to below 50 miles per hour by moving the respective coordinates closer to each other before sending them to the application 508 to place into the data capsule 518. But since it is not known from which coordinate points the speed was calculated the coordinates cannot be adjusted in a logical way. Or one needs to adjust the coordinates of every successive point even more.

[0485] A result of such manipulation is shown in FIG. 27 which shows original measured coordinate points from GPS sensor 506 on the left hand diagram. Only 8 location points are shown for simplicity. The middle diagram shows an example of manipulated coordinate points to reduce the speed and thus the distance between locations. Since the exact location points are sent to the server 2, as outlined above, the route driven can be extracted by overlying the locations over a road map. This is shown in the right hand drawing of FIG. 27. It can be seen that the manipulated locations do no more fit to the road map, by lie in a lake 544, in the woods 546 and in a river 548, giving clear indication that they are not the locations as originally taken. This can be taken as fingerprint of hacking the mobile device 24 and manipulation of the driving data.

[0486] The use of the buffer 510 is shown in FIG. 28. In case one or both of the acceleration sensors 502, 504 measure an acceleration higher than a predetermined threshold, this threshold being set in relation to accident values, like 3 g for example, this is a hint for the occurrence of an accident. Now. the complete data contents of the buffer 510 is permanently stored outside the buffer 510. This can be done by storing it in a data capsule 518 and transmitting this data capsule 518 to the server 2 and stored there. Then the server or another calculation device can upon request evaluate these data so they can be used for clearing up an accident or another driving event.

[0487] Another reason for sending the buffer contents to the server 2 would be a data inconsistency between the driving data and the reference data. If such inconsistency occurs, or upon any other evidence for the manipulation of some of the driving data, the server 2 may prompt the communication device 24 for transmittal of the buffer contents. The communication device 24 then sends all data capsules 512 of the buffer 510 to the server 2.

[0488] FIG. 29 shows a simplified data handling of the communication device 24. Here the data capsules 512 are encoded right away and sent to the server 2 after leaving the buffer 510. The capsules 512 can be identical with data capsules 138. Alternatively to sending the data capsules 512 one after the other to the server 2, the communication device 24 may pick only some of them for transmittal to the server 2 to maintain data privacy to a better degree. Preferably, the data capsules 512—encoded or not—are picked in a random sequence from the buffer, only a minority of the capsules 512 in the buffer 510 being sent to the server 2. Here no complete travel data set is evaluated but only random samples of the driving data.

[0489] FIG. 30 shows an embodiment where the reference data coming from the fixed communication device 3 are forwarded directly to the server 2 without merging the driving data to them within one data capsule. The encoding can take place in the mobile device 24, as shown in FIG. 30, or in the fixed device 3 already, only encoded reference data passing the mobile device 24 then on its way to the server 2. The driving data acquired by the mobile device can go to the buffer and be handled as described above. They can be encoded, or not as shown in FIG. 30.

[0490] FIG. 31 shows a vehicle 602a, which is a motorcycle, and a vehicle 602b, which is a car, at which a driving motion detector 604 is placed, like in the glove box of the vehicle 602b, or with adhesive material at a surface of the vehicle 602a. Inside the vehicle 602b or outside the vehicle 602a is a mobile communication device 6 which is in communication with the driving motion detector 604 via Bluetooth. The mobile communication device 606 can be a smart phone. The mobile communication device 606 further communicates via GSM 608 or WiFi, if connected to a local network, with a server 6010 which is a server 6010 of a vehicle manufacturer or a vehicle insurance company for collecting driving data from a plurality of vehicles 602.

[0491] The driving motion detector 604 is shown in FIG. 32 in detail. The driving motion detector 604 comprises a housing 612, a power supply 614 and two power consumer one of which is a control unit 616 with a processor, and the other is a sender 618. On the circuit board 620 carrying the control unit 616 and the sender 618 a memory 622 is present. The sender 618 is a Bluetooth sender which preferably is able to connect to the mobile device 606 over WiFi as well.

[0492] Inside the housing 612 an activation device 624a is present for detecting a motion of the vehicle 602 and for connecting the power supply 614 to at least one of the power consumers 616, 618 upon a movement of the vehicle 602. For this, in this embodiment, it comprises a swing system 626a with a swing 628a on a system suspension 630a with a joint in form of a swing axle which enables a platform 632 to swing in a one dimensional direction.

[0493] Within the swing system 626a two activators 634a, 636a are located. These activators 634a, 636a are acceleration sensors, each of them featuring an activation track 638a in a form of a tube housing, an activation element 640a, and an activation contact 642a. In this embodiment the activation track 638a has the form of a tube, the activation element 640a is a mercury pellet, and the activation contact 642a comprises two contact elements which are connected onto the two poles of an electric circuit fed by the power supply 614.

[0494] The driving motion detector 604 is fastened at the vehicle 602, thus inside the vehicle 602b, as displayed in FIG. 31, or on the outside of the vehicle 602a, as is shown in FIG. 31 and FIG. 38 on an outer surface of a motor cycle. The fastening can be done by means of adhesive elements, like adhesive strips, or other fastening elements. The driving motion detector 604 is fastened in such position that the one dimensional swinging direction is parallel to the vehicle driving direction. Further the driving motion detector 604 should be fastened vertically, so that the swing 628a hangs down symmetrically within the housing 612 when the vehicle 602 stands still on a horizontal plane. For this it would be helpful to have a string attached to the top of the driving motion detector 604 and include instructions to suspend by the string while fastening the driving motion detector 604 at the vehicle, like pressing the adhesive patches to a mounting surface.

[0495] When the vehicle 602 accelerates this acceleration is sensed by the acceleration sensor or activation device 624a respectively in the following way. The acceleration causes the swing 628a to swing due to the inertia of the swing mass. To adjust a reliable swinging a weight 644 may be placed on the bottom end of the swing. When the acceleration exceeds a predefined magnitude the swing will hit the housing from the inside, as is displayed in FIG. 33.

[0496] FIG. 33 shows the swing system 626a within the housing 612a with its system suspension 630a and its swing 628a, on which the platform 632 is fastened. The platform 632 carries the activator 636a with its rearward directed activation contact 642a. If the vehicle 602 accelerates forward, as is indicated by the straight arrow in FIG. 33, the swing due to its inertia will keep behind and hit the rearward wall of the housing 612, as is depicted in FIG. 33. This hitting will cause a strong acceleration of the activator housing 638a in driving direction of the vehicle 602 whereas the activation element 640a is still free movable within the activation track 638a. Due to its inertia it moves backwards—relative to the accelerated housing 638a—and hits the activation contact 642a and its two electric contacts or poles which are shown in FIG. 33. The two contacts are electrically connected herewith since the activation element 640a is electrically conductive. The electrical circuit is closed and at least one of the power consumers 616, 618 are fed with electric power from the power supply 614.

[0497] As can be seen in FIG. 33 the activator 636a is aligned in such a way that when the swing 628a is at rest in free down hanging position the activation element is located in the housing opposite to the activation contact 642a. In the shown embodiment this is realized by an incline of the bottom of the activation track 638a in rest position of the swing 628a. The activation element 640a runs to the lowest point within the housing 638a which is opposite to the activation contact 642a. By this measure a misactivation of the activation device 624a due to vibrations of the vehicle 602 or minor accelerations, like due to a door closing or a person sitting in the vehicle 602, is prevented. Such accelerations fall under the predetermined threshold and are not detected by the acceleration sensor. The predetermined threshold may thus not be defined by a sharp acceleration value but can be defined by an integrated acceleration value, like over ¼ swing period of the swing system 626a.

[0498] Upon registration of the acceleration and activation of the power consumer the energy of the power supply is continually used by one or more power consumers. This will exhaust the power supply undesirably fast. To prevent a fast exhaust the control unit 616 or memory 622 comprises a program which puts asleep one or more—preferably all power consumers of the driving motion detector 604. If during a predetermined time span no acceleration is detected the control unit 616 cuts off power from the power consumer(s) and cuts off itself from the power, and so inactivates the power consumer(s) and itself. Preferably, the control unit 616 puts the whole driving motion detector 604 in a deactivated condition that does not use any electric power.

[0499] The restart of the activations of the control unit 616 needs a switching action from another element. This switching action is performed by the activation device 624a upon the vehicle acceleration, as described above. The electric loop is closed and electric voltage is present at the control unit 616 which reactivates it. This reactivation triggers the control unit 616 to open another electric circuit to supply the control unit 616 with electric power. If the activation element 640 removes from the activation contact 642 and thus opens the electric circuit again, the control unit still keeps under voltage and thus keeps active. The second circuit is cut off by the control unit 616 upon the absence of acceleration for a predetermined time span, as described above.

[0500] As can be seen in FIG. 34, the activation device 624a contains two activators 634a, 636a which are arranged in opposite directions one to another. The activator 636a detects acceleration in forward driving direction of the vehicle 602, and the activator 634a detects acceleration in rearward driving direction of the vehicle 602. Both activators 634a, 636a are inclined in opposite directions, so that both activation elements 640a rest opposite to their respective activation contact 642a in the absence of acceleration.

[0501] FIG. 34 shows two activators 634b, 636b on a platform 632 analogous to FIG. 33. The following description is basically limited to the variations with respect to the foregoing embodiment which are referenced with respect to identical or similar features and functions. To not repeatedly describe the same features and functions, features and functions of the foregoing embodiments are overtaken without being described again, unless features or functions are described differently. Further, basically the same components are marked with the same reference numerals. For an easier understanding the same components in different embodiments are marked with the same reference numeral but different reference letter, wherein the components can be identical or may exhibit minor differences in design, dimension, position and/or function. In case a reference numeral without its reference letter is mentioned all components with the same reference numeral are addressed.

[0502] The two activators 634b, 636b correspond to the activators 634a, 636a of FIG. 33, they are opposite in direction and inclined oppositely, so that their activation contact 642b each is on a higher level than the ground under the respective activation element 640a. Again, the activator 634b is for backward acceleration detection, and the activator 636b for forward acceleration detection.

[0503] FIG. 35 shows a different activator 634c which can be used in the activation device 624a or any other activation device 624. The activator 634c is equipped with a different activation track 638c which has the form of a tube housing with a bend lifting both ends over the lowest ground level in the middle of the housing 638c. Of course, all elevations refer to a resting position of the activation device 624 as, for example, shown in FIG. 35. The activation element 640a, i.e. the mercury or metal pellet, rests in the middle position between the two activation contacts 642b. Depending on the direction of the vehicle acceleration the activation element 640b—upon the platform 632 hitting the housing—moves backwards (forward acceleration of the vehicle 602) or forwards (backward acceleration of the vehicle 602) and contacts the respective activation contact 642b.

[0504] A further embodiment of an activator 634d is shown in FIG. 36. The activation track 638d is formed as a basin or bowl with a slight bend, so that the radial outer rim of the housing 638d is surrounds the central section of the housing 638d in a higher position. The activation element 640a rests in the middle section, accordingly, and moves towards the higher rim upon acceleration of the vehicle 602, or upon the platform 632 hitting the detector housing 612, respectively. The activation contact 642c is running as two rings at the rim, one ring for the plus pole and the other ring for the minus pole of the electric circuit.

[0505] This assembly has the advantage that it detects all horizontal acceleration in any horizontal direction. This makes it unnecessary to install the driving motion detector 604 in a specific horizontal direction at the vehicle 602. A marking of the vehicle driving direction at the detector housing 612 can be omitted. However, it is essential that the housing is placed in horizontal position at the vehicle 602, so that the activation element 640 rests opposite to the activation contact 642a-b of the embodiments of FIG. 32 to FIG. 34, or essentially in the middle between the activation contact 642b-c of the embodiments of FIG. 35 and FIG. 36.

[0506] In the embodiment shown in FIG. 37 the activator 634e comprises a metal ball, like a steel ball, as activation element 640b. The activation track 638e can have essentially the same form as in FIG. 35, like a tube with a bend lowering the middle section between both end sections. A form as in FIG. 36 is possible as well, wherein the single activation contact 642d runs around inside the rim. However, the activation contact 642d should be different in so far as one pole is positioned at the bottom of the activation track 638d and only the other pole is positioned at both tube ends or around the rim, respectively. The activation element rolls on the first pole, and closes the circuit upon hitting the other pole at the ends or rim. An easy realization would be the housing 638d forming the first pole on which the ball runs during its movement. The other pole is electrically isolated fastened in the housing 638d.

[0507] FIG. 38 shows a method for detecting motion of a mechanical system, like a vehicle 602, which in the embodiment shown in FIG. 38 is a motorcycle 602a. The motorcycle 602a carries a driving motion detector 604 which sticks to the trim or tank of the motorcycle, as is shown in FIG. 38. The driving motion detector 604 comprises an activator 634, a sender 618, a control unit 616 and a memory 622. A power supply in form of a battery is present as well but not shown in FIG. 38. The motorcycle, or in general: the vehicle 602, stands parked without movement for a longer time. The power consumers within the driving motion detector 604 are inactive, therefore, sparing the power supply 614 from energy drain during this waiting time. This state of the driving motion detector 604 is called inactive state in the following. Further, if the driving motion detector 604 is deactivated, like by the control unit 616, the driving motion detector 604 is in the inactive state as well. In this state power consumers may completely be shut off from electric power or be in a standby mode where they consume only little power, preferably the mode with least power consumption existing in the respective power consumer.

[0508] When the vehicle 602 is moved, like by a driver grabbing the motorcycle or starting a drive with a car, the vehicle 602 in step 702 accelerates in its motion direction as indicated by the straight arrow in FIG. 38. As described before, the activator 634 by movement of the activation element 640 in step 704 and contacting the activation contact 642 in step 706 activates an inactive power feed from the power supply 614 to the power consumer upon the contact which is a signal of the activator 634 working as acceleration sensor. In step 708 the control unit 616 is activated by the power feed of the closed electric circuit. This state of the driving motion detector 604 is called active state in the following.

[0509] The control unit 616 activates the sender 618 in step 710 which then sends in step 712 a communication request to the mobile communication device 606. This request can be sent by WiFi, preferably by Bluetooth. The communication line between the sender 618 and the mobile communication device 606 is established upon this inquiry.

[0510] If the mobile communication device 606 is in contact with the driving motion detector 604, and thus the driving motion detector 604 is active, the device 606 monitors the vehicle movement. This can be done by monitoring its own movement, e.g. by monitoring GPS signals arriving at the mobile communication device 606 and/or by monitoring the acceleration of the mobile communication device 606 itself by means of an acceleration sensor in the mobile communication device 606. If the result of this monitoring is that the mobile communication device 606 is moving, its state is called moving state in the following. If the result of the monitoring is that the mobile communication device 606 is static, i.e. not moving, its state is called static state in the following. The result of this monitoring is returned to the sender 606 in step 714.

[0511] In the active state the driving motion detector 604 monitors acceleration. If it detects periodic acceleration events, i.e. a more or less periodic contact of the activation element 640 with the activation contact 642, it considers itself being in motion, it is in a moving state. In case the driving motion detector 604 does no longer sense acceleration events, it considers itself not moving, it is in a static state.

[0512] From the view of the driving motion detector 604 the mobile communication device 606 has three states: moving, static, and not present, i.e. no communication line can be established from the driving motion detector 604 to the mobile communication device 606. In combination with the moving and static state of the driving motion detector 604 altogether six states are possible within the system comprising driving motion detector 604 and mobile communication device 606.

[0513] Detector 604 is moving—mobile device 606 is moving: The vehicle 602 is driving. The driving motion detector 604 is active and the mobile communication device 606 detects vehicle movement as well. The mobile communication device 606 confirms this motion to the sender in step 714. During operation the control unit 616 monitors the power level of the power supply 614 and sends the respective power level report in step 716 to the mobile communication device 66.

[0514] In the moving—moving state the motion of the vehicle 602 is monitored by the mobile communication device 606 which stores the results. The stored data can be the location point which the vehicle passed, the time points at which the vehicle passed the respective locations and/or the speed with which the vehicle moved at the time points and/or location points. The results as such or in processed form, preferably camouflaged for keeping privacy of driver data, are forwarded from the mobile communication device 606 to the remote stationary server 610 for further processing, such as UBI.

[0515] If communication between the mobile communication device 606 and the driving motion detector 604 is established both devices inform the other unit periodically about the own state, either by sending the state information to the other device, or by polling the state from the device. Accordingly, both devices are informed about the states of both devices. Further, the mobile communication device 606 can infer if the driver is still engaged/seated in the vehicle. If the mobile communication device 606 device is no longer in contact with the motion detection unit, it terminates related driving data acquisition.

[0516] Detector 604 is moving—mobile device 606 is not present: This system state is shown in FIG. 39. It could happen that the vehicle is moving but no mobile communication device 606 is present. Accordingly, the communication 712 between sender 618 and mobile communication device 606 fails. In this case the driving motion detector 604 serves as permanent acceleration sensor monitoring the vehicle motion permanently. This monitoring will be done with the internal acceleration sensor, like the activator 634, 636, a vibration sensor, and/or an additional electronic acceleration sensor 646 as introduced in FIG. 40. If only a mechanical acceleration sensor is present, like the activator 634, 636, the control unit 616 stores the time points of all contact events where the activation element 640 contacts the activation contact 642 and thus indicates acceleration of the vehicle above the detecting threshold. Since during normal operation the vehicle acceleration surpasses this detecting threshold regularly and many times during a trip the driving event can be detected by this monitoring easily, and it can clearly be distinguished from a single or short time acceleration which indicates vehicle action as such, like door movement or the like, but not a driving event where the vehicle 602 drives more than only a few meters. In one of the following times where communication between the sender 618 and the mobile communication device 606 is established the stored motion data are sent to the mobile communication device 606 and from there to the server 610 for further processing.

[0517] FIG. 40 shows the driving motion detector 604 with an additional sensor 646. The sensor 646 can be an acceleration sensor, a GPS sensor, a vibration sensor, or the like. During normal system operation where the mobile communication device 6 is present, the additional acceleration sensor 646 may be put inactive to save electric energy. But if the communication to the mobile communication device 606 fails vehicle motion should be monitored by the driving motion detector 604 alone. This is more accurate with a sensor 646 which not only quantitatively detects acceleration events but is able to qualitatively monitor acceleration.

[0518] Additionally or alternatively a GPS unit 646 may be present which monitors the present location of the driving motion detector 604 preferably together with its current speed. Location, speed, acceleration time and/or route distance can be tracked and stored in the memory 622, so that an idea of driving is achieved even without the presence of a mobile communication device 606.

[0519] In general, but especially if no mobile communication device 606 is present, the detector 604 may have the capability to communicate directly with the server 602 over long distance communication line, like GSM or any other mobile phone or internet communication network.

[0520] Further, a vibration sensor 646 may be present instead or additionally to an acceleration sensor 646. The vibration sensor 646 may help to find the correct system state if the driving motion detector 604 fails to sense acceleration but the mobile communication device senses motion, like on a smooth highway. On the other hand if the vehicle moves but the mobile communication device fails to sense motion, like a motor cycle during conversation of two bikers, the vibration sensor 646 may detect motor vibrations, so that the driving motion detector 604 will clearly sense vehicle action.

[0521] The process is similar to the process shown in FIG. 38, but in step 708 not only the control unit 616 and sender 618 are activated as power consumer, but the accelerometer 646 as well. This monitors the vehicle acceleration more precisely than the mechanical accelerometer 634, and acceleration data and/or motion data are stored in the memory 622. These data or data processed from these data are sent to the mobile communication device 606 if the communication line is established during a later event.

[0522] Since the operation of an electronic acceleration device 646 is power consuming, before activating the acceleration device 646 the control unit 616 determines the power level of the power supply 614. If this is higher than a predefined power level threshold the acceleration device 646 is activated. If the power level is lower the acceleration device 646 may not be used at all or be used only intermittently, like below a predetermined threshold of operating time during which no mobile communication device 606 is found during the moving state of the detector 604.

[0523] Detector 604 is static—mobile device 606 is static: As depicted in FIG. 41 it could happen that the mobile communication device 6 finds that the vehicle 602 is not moving or not moving enough to qualify the motion as a driving trip for which driving data are gathered and processed. It then sends in step 718 the information, like a confirmation, to the driving motion detector 604 that the vehicle 602 is not moving or not moving enough. The control unit 616 then in step 720 writes data of the activation event into the memory and in step 722 deactivates the power consumers, including itself, to wait for the next vehicle motion in the inactive state.

[0524] Detector 604 is static—mobile device 606 is not present: The driving motion detector 604 is active and in its static state not registering acceleration events, and no communication between mobile communication device 606 and driving motion detector 604 is present or can be installed, or it broke recently. In this system state the mobile communication device 606 is not present or turned off. Since no recording of vehicle motion is possible, neither by the mobile device 606 nor by the detector 604, a monitoring of acceleration it not necessary. The control unit 616 writes data of the activation event into the memory and in step 722 deactivates the power consumers, including itself, to wait for the next vehicle motion inactively.

[0525] Detector 604 is moving—mobile device 606 is static: This is a system state where the mobile communication device 606 is present at least near the vehicle but does not register movement. If the communication line keeps alive the vehicle 602 is not moving, and the acceleration events from the detector 604 is coming from a different event, like a shaking of the vehicle 602 during packing with heavy items, or during swaying of the motor cycle while not moving, like at a street light or during a conversation of two bikers. In this situation the detector 604 continues its acceleration monitoring until the state changes into a clear state for deactivation.

[0526] Detector 604 is static—mobile device 606 is moving: In this state the driving motion detector 604 does no longer senses acceleration events, it considers itself not moving, it is in the static state. But this alone will not trigger the driving motion detector 604 to fall into the inactive state. Instead it will exchange state information with the mobile communication device 606. If the mobile communication device 606 is still moving there is a state conflict, and it is not clear if the vehicle 602 is moving. The vehicle 602 could be still moving but on a very smooth highway without significant vehicle acceleration. If, on the other hand, the vehicle is static parking somewhere, and the smart phone is moving while the driver is walking or driving with another vehicle, like a bus, train, or bike, the mobile communication device 606 will move away from the vehicle 602. In a consequence the communication line between mobile communication device 606 and driving motion detector 604 will break up. This will change the system status to static—non present. Accordingly, the static—moving state implies that the vehicle is still moving but the driving motion detector 604, for whatever reason, does not sense acceleration. It will thus keep up monitoring and stay in its active state in which it will exchange status with the mobile communication device 606. The mobile device will register this system status and report to the remote server 610. The server 610 or any service behind will monitor this status conflict, and in case this happens more and more often will attempt to replace the driving motion detector 604.

[0527] Of course, there is a second constellation within the static—moving state: It is the inactive—moving state. In this state there is no communication between mobile communication device 606 and sleeping driving motion detector 604, and the mobile communication device 606 does not monitor driving data.

[0528] In general, the monitoring of the vehicle driving and collecting of driving data by the mobile communication device 606 is always triggered by the active driving motion detector 604. If no such trigger is present, like no communication line is present, there will be no driving data collection within the herewith described co-operation between mobile communication device 606 and driving motion detector 604. Even if the communication line breaks during movement the recording of driving data will be terminated by the mobile device 606 after a set time span without contact to the detector 604.

[0529] Further, the control unit 166 in step 722 may store data to every acceleration event into its memory, like date and time of the event. Further, it preferably stores data on activation and deactivation of the control unit 616 into the memory. I.e. before its deactivation it saves the time point of deactivation, or shortly before, and after activation it saves the respective time point as well.

[0530] The process of deactivation of power consumers in the driving motion detector 604 should be triggered by data from an acceleration sensor. If in a system state where deactivation is allowed over a predetermined time span no acceleration or too little acceleration is sensed, like no signal from the activator 634, the deactivation is started, e.g. by the control unit 616. A simple way is a fixed time span of absence of signals of the activator 634. If an electronic accelerometer 646 is present, signals from this accelerometer 646 can be taken instead. Preferably signals from the accelerometer 646 and from the activator 634 are compared or examined together. If, for example, the activator 634 is silent, but the accelerometer 646 sends data from which one could conclude that the vehicle is still moving, like on a perfectly even paved new highway during a smooth ride with no traffic disturbances, the time span can be adjusted to the signals or the signals of the accelerometer 646 are taken alone to decide whether the ride is finished or not.

[0531] During operation of the driving motion detector 604 the power supply 614 feeds power consumer with electric energy. In case the power supply 614 goes flat it will no longer report vehicle motion to the mobile communication device 606. Since the mobile communication device 606 may not be able to distinguish his motion in the vehicle 602 from other motion, like in a train, in another car or on a bike, it will most probably not register a driving trip and will not record driving data, accordingly. To prevent such data loss, the control unit 616 monitors the power level of the power supply 614 and sends the respective power level report in step 716 to the mobile communication device 606.

[0532] Upon a drop of the power level below a predefined threshold the mobile communication device 606 will notify the driver to replace the power source of the power supply 614, like a battery or the like. In case the power source is not replaced before the mobile communication device 604 goes completely down the server 610 is notified about the near end of the detector operation. The server 610 will then send a message to the driver, like an e-mail or a letter, to prompt him to replace the power source or perhaps if the policy so specifies mail to the insured the appropriate batteries.

[0533] As described with respect to the additional acceleration sensor 646 or the GPS unit, in the event of low power, like a power level below a predefined threshold, the control unit 616 may restrict or terminate the activity of one or more power consumers of the driving motion detector 604. Such power consumers can be the accelerometer 646 or a GPS-chip, or even the sender 618 which is operated less frequently than with full battery.

[0534] FIG. 42 shows a driving motion detector 604b with a swing system suspension 630b allowing a two-dimensional swinging of the activator 634a or the platform 632 respectively. It comprises a ball joint which has two functions. The first function is to allow a bump of the platform 632 not only against forward and rearward wall of the housing 612 but against the side walls as well. This function makes the mounting of the driving motion detector 604b at the vehicle 602 easier, since it is no more necessary to take account of the driving direction of the vehicle 602. The second function is a compensation of a tilted disposition of the vehicle 602 and/or a tilted mounting of the driving motion detector 604b at the vehicle 602. Here the friction of the system suspension 630b is reduced compared to a system suspension 630a in a tiled housing 612. This makes the activation device 624b more sensitive and thus more reliable.

[0535] FIG. 43 shows an alternative driving motion detector 604c. It comprises an outer housing 6048a and an inner housing 6050 and a fluid space 6052a partly filled with fluid 654, like water or light oil. Inside the inner housing 650 an activator 634 is placed on a platform 656 which is fixed to the inner housing 650. Preferably the activator 634 is the activator 634c or the activator 634d, wherein the activation track 638e is shaped as bowl and not as a tube. Below or above the activator 634 a further platform is present, preferably a printed circuit board 620, with a control unit 616, a sender 618, a memory 622 and eventually an accelerometer 646. On the bottom of the inner housing 650 a weight 658 is located which can be a power supply, like a battery.

[0536] The driving motion detector 604d of FIG. 44 is constructed identically except for the larger outer housing 648b which allows for a larger fluid space 652b.

[0537] The outer housing 648 and the inner housing 650 are concentric to one another, like two spheres or two cylinders where the outer housing 648 completely surrounds the inner housing 648 over 360°, preferably in all directions. The housings 648, 650 can be made from every material strong enough to withhold mechanical forces of wear during use of the driving motion detector 604. The weight of the inner housing 648 completely with all elements inside is balanced in such a way with the specific gravity and amount of the fluid 654, that the inner housing 648 is concentric with the outer housing 650, so that the inner housing 648 does not touch the outer housing 650 but freely flows in the fluid space 652a. Of course, upon motion of the driving motion detector 604c,d the inner housing 648 may bump into the outer housing 650, but this will only be a temporary touching which still allows the inner housing 648 to freely turn itself inside and relative to the outer housing 650.

[0538] As described before, the driving motion detector 604c,d is placed at the vehicle 602, like in a glove box of any other space within the vehicle 602, or in a tool box of a motorcycle. In this embodiment it is not essential in which direction the driving motion detector 604c,d is placed at the vehicle 602, since the weight 658 will always turn the inner housing 648 vertical in which position the activator 634 is placed horizontal within the inner housing 648. This construction will make the activator 634 always be horizontal in the absence of acceleration and turning movement of the driving motion detector 604c,d. The function of activation and deactivation can thus be the same as described above for the other activators 634.

[0539] Upon acceleration of the driving motion detector 604c,d the activator will activate a power consumer as described above. With regard to the driving motion detector 604c this activation omits the amplifying of acceleration due to bumping of the platform 632 against the housing 612, since the thickness of the fluid space 652a is too small for a significant speed difference between the two housings 648a, 650. Further, since the weight of the inner housing 648a with insides is adapted to the fluid 654 it flows essentially zero-g within the outer housing preventing it from bumping much into the outer housing.

[0540] This is different with the driving motion detector 604d of FIG. 44. Here the fluid space 652b has a width of about 35% of the radius of the inner housing 650. Upon acceleration of the driving motion detector 604d the fluid has enough room to slosh around the inner housing 650 and thus to sway within the outer housing 648b. This fluid movement will accelerate the inner housing 650 stronger than the original acceleration of the outer housing 648b and thus amplifies the acceleration. This makes the detector 604d more sensitive and thus more reliable.

[0541] As is shown in FIG. 42 the driving motion detector 604a,b is fastened to the vehicle 602, e.g. by one or more adhesive elements 660 which adhere the driving motion detector 604a,b to a surface of the vehicle 602, as shown in FIG. 40, for example. To vertically fasten the driving motion detector 604a,b at the vehicle 02 it may comprise a string 662 on the outside of its housing 612 at which the housing 612 hangs vertically down if pulled up with the string 662. FIG. 45 shows the string 662 and the driving motion detector 604a,b hanging vertically down. In this position the driving motion detector 604a,b can be fastened to the vehicle 602, so that it has the correct position for a reliably working activation device 64. The vertical position at the vehicle 602 will keep the activator 634 in the correct working alignment to ensure reliable operation.

[0542] As is shown in FIG. 42, the driving motion detector 604a,b may comprise a safety element 664 for detection of a detachment of the driving motion detector 604a,b from the vehicle surface to which it was mounted. The safety element 664 may be a wire which passes through one or more adhesive elements 660 in such way that it breaks upon detachment of the adhesive elements 660 from a surface to which it was bonded. If a driver wants to detach the driving motion detector 604a,b from the vehicle 602 for a ride which the driver does not want to be monitored, the safety element 664 breaks which is detected by the control unit 616, e.g. because of an increase of the electric resistance of an electric circuit running through the safety element 664. In FIG. 42 the safety element 664 passes only one of the adhesive elements 660, however, the safety element 664 may pass through both or all existing adhesive elements 660, or more than one safety element 664 is present, each passing one or more adhesive elements 660.