EP2320386B1 - Device and method for creating toll data from anonymous locations - Google Patents

Abstract

The method involves transmitting location records from a thin-client onboard unit (1) to a toll calculation server (5) under a source identifier (RID) i.e. random value. Location anonymous toll data (T) is calculated from the records, and the records in the server are subsequently deleted. Waiting process for a preset time span (11) is carried out in the onboard unit. An identifier (OID) i.e. vehicle device identifier, associated to the source identifier is released from the onboard unit for associating the toll data to the associated identifier. Independent claims are also included for the following: (1) a toll calculation server for executing a method for creating location-anonymous toll data from location records (2) a location-recording vehicle device comprising an identifier for executing a method for creating location-anonymous toll data from location records.

Description

The present invention relates to a method for generating location-anonymized toll data from the location records of a location-recording vehicle device with a unique identifier in a road toll system. The invention further relates to a toll calculation server and a vehicle device for carrying out this method.

Vehicle devices for road toll systems are also referred to as "onboard units" or OBUs. OBUs that can themselves determine and record their location, e.g. by means of a satellite navigation receiver, there are currently two different versions: so-called "thick client" OBUs calculate based on stored toll cards from their location records location-anonymized toll data and send them e.g. via a mobile network to a center of the road toll system, which requires a complex distribution of toll cards to the OBUs and high processing power in the OBUs. In contrast, so-called "thin client" OBUs do not evaluate their location records themselves, but send them "raw" to the central office, which undertakes the toll map matching ("map matching") in order to generate toll data. "Thin client" OBUs are therefore much simpler and less expensive, but worthy of discussion from a data protection point of view, because the center of the road toll system receives all the OBU's "movement profile", including stays in non-tolled locations.

In the WO 2008/000227 Therefore, it has already been proposed to send the location records of a "thin client" OBU under an anonymous sender identification to a special toll calculation server, which performs the "map matching" and returns location-anonymized toll data to the OBU, the then the OBU drops to the central office. Due to the architecture of the Toll Calculation Server, compliance with data protection requirements is difficult to control in this system. Moreover, this solution generates additional traffic in the road toll system.

From the WO 2009/001303 A1 it is known that the center waits for a clearing confirmation of the toll calculation server before it assigns the local anonymized toll data received from the toll calculation server to a user identity received from the OBU, which deprives the authority over the disclosure of the OBU OBU ID and the risk of compromising data security harbors in itself.

The object of the invention is to overcome the disadvantages of the prior art and, in particular, to provide a method for generating toll data for "thin client" OBUs, which offers improved data protection or higher confidentiality for the user. This object is achieved by a method having the features of claim 1.

The invention is based on a completely new, surprisingly simple concept for the realization of data protection at hardware level ("privacy by design"):

The OBU waits for an explicit deletion confirmation from the toll calculation server and then releases its identifier. This achieves hardware-related privacy ("privacy by design"). A toll calculation server which is particularly suitable for the invention is preferably characterized in that it deletes location records after their processing into toll data and sends an acknowledgment to a vehicle unit via them.

A particularly suitable for the invention vehicle device has release means, which send after receiving a deletion confirmation with respect to sent location records their sender ID under the identifier of the vehicle unit.

Thus, in a manner that is simple and transparent to users and system operators, the invention provides hardware-based confidentiality for the sensitive location record data. Location records are stored centrally only for as long as necessary for their processing; afterwards they will be deleted automatically. Any concerns regarding a central traceability or creation of a movement profile of the vehicle equipment can be eliminated. In addition, the invention does not cause increased traffic in the road toll system.

If desired, in each embodiment, the location records in the toll calculation server may be encrypted and sent to the public key of an external archive location prior to being deleted. Such an archival holding, in the nature of a trustee or notary, should enjoy a high degree of trust for all concerned, i. for both the users and the system operator, and can therefore be consulted by any party in disputed cases.

The transmission and release preferably takes place from the vehicle device via a radio network, particularly preferably a mobile radio network. As a result, eg conventional "thin client" OBUs can be used which are equipped with a DSRC or mobile transceiver.

According to a further preferred embodiment of the invention, the location records of a vehicle unit are sent in data packets, which are each provided with the same sender IDs, which simplifies the evaluation, since the vehicle unit here - after waiting for the period or receipt of the deletion confirmation - its identifier only with respect to a single Must disclose sender identification.

Alternatively, the Ortsaufzeichnunaen a vehicle device can be sent in data packets that are provided with changing sender IDs. As a result, the confidentiality can be increased on the transmission interface.

Preferably, data packets provided with alternating sender identifiers are additionally provided with linked packet identifiers which allow their assignment to one another, whereby the vehicle device needs to release its identifier only for the sender identification of the last data packet.

The identifier by which a vehicle device identifies can be both an identifier of the vehicle device itself and an identifier associated with the user of the vehicle device, e.g. an identifier of a user account for billing tolls in the road toll system.

The sender identifier used to send the location records to the toll calculation server may be both random and user-selectable code, further increasing transparency for the user.

The method of the invention is suitable for all types of self-locating vehicle devices, in whatever way they determine their location, eg by recognizing landmarks or identifying beacons on which the vehicle device is oriented. It is particularly advantageous if the vehicle device uses its locations in a manner known per se Satellite navigation determines, for example, GPS-based "thin client" OBUs can be used.

The invention will be explained in more detail below with reference to in the accompanying drawings dargstellen embodiments whose Fig. 1 and 2 show two different embodiments of a method according to the invention and components of the invention containing road toll system in block diagram form.

According to Fig. 1 an OBU 1 moves aboard a vehicle in the context of a road toll system with a control center 2. The center 2 calculates toll road use of the OBU 1, eg driving on a toll road, entering an area subject to charges, staying on a paid parking, etc. appropriate user accounts, u. on the basis of toll data. T, which are triggered by the location uses of the OBU 1, as known in the art.

The OBU 1 is of a self-locating "thin client" type and determines its location continuously, eg periodically, for example with the aid of a satellite navigation receiver, and records the so-determined positions (position fixes) p ₁ , p ₂ , p _3. (generally p _i ) in an internal location record memory.

Each OBU 1 is provided with a unique identifier OID in the road toll system, for example a unique identifier of the OBU 1 itself and / or its user or an account of the latter. Knowing the identifier OID of an OBU 1 and its location records p _{i, it would} be possible to deduce the movement profile of an OBU 1, which is prevented as follows.

The location records p _{i of} the OBU 1 are - even if this is not mandatory - for ease of handling on individual data packets 3 divided. The data packets 3 can with a packet identifier P _i (see Fig. 2 ), eg a continuous one Numbering, and a header (not shown), for example, containing metadata such as the number of contained in the data packet 3 location records p _i , a hash value of the same and so on.

The location records p _i or data packets 3 are sent in a first step 4 of the OBU 1 to a toll calculation server 5, for example via a mobile network, u.zw. under a different from the identifier OID, quasi "anonymous" sender ID RID. The sender identifier RID is, for example, a user-selected code or a randomly generated value by the OBU 1. Alternatively - albeit with a correspondingly reduced anonymity - a temporary mobile network identification or temporary Internet address of the OBU 1 could be used as the sender identifier RID.

The toll calculation server 5 contains a "map matching" device 6, which assigns the received location records p _i tolled places, routes or areas from a toll card database 6 'and determines associated tolls from the toll card database 6'. The "map matching" device 6 calculates in this manner "location-anonymised" toll data T which does not permit any conclusion on the individual location records p _i from the toll charges of the location records p _i received for a sender identifier RID. The toll data T are eg a single charge sum for all location records p _{i of} all data packets 3 of a sender identifier RID.

The "map matching" device 6 of the toll calculation server 5 is preceded by a buffer memory 7 in the form of a ring memory, in which all the local records p _i or data packets 3 sent by OBUs 1 arrive in succession in order to be processed by the device 6. Due to the average workload of the device 6, therefore, a time period can be set, within which at a certain time in the buffer memory 7 received location records p _{i have been converted} to location-anonymized toll data T and have been automatically deleted by the arrival of new location records, the latter, for example, when the buffer memory 7 as in Fig. 1 shown executed as a ring memory, which is automatically cyclically overwritten by incoming new data continuously. Should this period be exceptionally exceeded at an exceptionally low utilization of the buffer memory 7, can be ensured by an additional periodic, eg daily, deletion of entries in the buffer memory 7, which are older than the said period, that after that predetermined period of time anyway Location records p _i more in the toll calculation server 5 are available.

If at an exceptionally high load on the ring memory 7 or the "map-matching" device 6 local records p _i should be deleted unprocessed, the OBU 1 such site records p _i either automatically or on request of the toll calculation server 5 or on request of the center 2 retransmit.

If desired, the toll calculation server 5 may be archived for evidence purposes in a trustworthy encrypted form, the location records p _i prior to the deletion, for example by encrypting them with the public key of an archive location 9 at this transmits (step 10). The private key of the archive point 8, which is necessary for decrypting the location records p _i , may not be known to the user or the operator of the road toll system and only the operator of the archive point 9, which thus works as a notary or trustee for both sides.

The toll calculation server 5 then sends the calculated toll data T to the center 2 in step 8 under the sender ID RID.

On the other hand, the OBU 1 waits for the said period of time (step 11) and then releases its "identity", ie its identifier OID or price (step 12). The release takes place in Fig. 1 in that the OBU 1 sends the sender identifier RID used by it under its identifier OID to the center 2. The center 2 can thus allocate the toll data T received by the billing server 5 under the sender identifier RID to the identifier OID received from the OBU 1 for this sender identifier RID (step 13) in order to generate location-anonymized toll data T assigned to the OBU 1.

Fig. 2 shows various variants of components of the method of Fig. 1 , The assignment of the toll data T to the identifier OID is not done here in the center 2, but directly in the toll calculation server 5 by the OBU 1 releases its identifier OID in step 12 to the toll calculation server 5 and the latter sends the result of the assignment 13 to the center 2 ( Step 14).

Furthermore, in Fig. 2 shown that the OBU 1 - waiting for the arrival of an explicit confirmation 15 of the toll calculation server 5 on the successful deletion of the location records p _i - instead of waiting for a time period 11. Upon receipt of the deletion confirmation 15, the OBU 1 reveals its identifier OID in step 12.

Fig. 2 also shows the variant that the individual data packets 3 can be provided with changing sender IDs RID _i in order to make tracking on the interface 4 more difficult. In step 12, the OBU 1 can then immediately identify several of its last used sender IDs RID _i with their identifier OID.

If the individual data packets 3 are linked with each other, for example by corresponding mutual references in their packet identifiers P _i , then it is sufficient if the OBU 1 in step 12 only the last sender ID RID _i a chained data packet sequence identified with its identifier OID, because the toll calculation server 5 can open the previous sender ID RID _i due to the packet chainings.

Alternatively, the toll calculation server 5 could also be linked Originators RID _i continuously accruing toll data T _i, for example, accumulate to a total fee and thereby only the last station ID, RID cancel always _i. Also in this case, it is sufficient if the OBU 1 identifies only its last sender identifier RID _i with its identifier OID in step 12.

Finally shows Fig. 2 The stack memory 7 is eg periodically deleted or removed its oldest entries after a predetermined period of time, they should not have been processed in time, and / or the OBU 1 is always waiting here for a deletion confirmation 16.

The invention is not limited to the illustrated embodiments, but includes all variants and modifications that fall within the scope of the appended claims.

Claims (10)

1. Method for generating location-anonymised toll data (T) from the recorded location data (p_i) of a location-recording onboard unit (1) with a unique identifier (OID) in a road toll system, with the steps:

   transmitting (4) the recorded location data (p_i) under at least one sender identifier (RID) different from the identifier (OID) from the onboard unit (1) to a toll calculation server (5),

   calculating (6) location-anonymised toll data (T) from the recorded location data (pi) and subsequently deleting the recorded location data (p_i) in the toll calculation server (5),

   waiting in the onboard unit (1) for the arrival of an explicit confirmation (15) of the toll calculation server (5) of the completed deletion of the recorded location data (p_i), and subsequently

   releasing (12) the identifier (OID) belonging to the sender identifier (RID) by transmitting it from the onboard unit (1) to the toll calculation server (5), which matches (13) the location-anonymised toll data (T) to the identifier (OID) and

   transmits these to a central control unit (2) of the toll system.
2. Method according to claim 1, characterised in that the recorded location data (p_i) are encrypted in the toll calculation server (5) before deletion with the public key of an external archive unit (9) and are transmitted to this.
3. Method according to claim 1 or 2, characterised in that transmitting (4) and releasing (12) is performed from the onboard unit (1) via a radio network, preferably a mobile radio network.
4. Method according to one of claims 1 to 3, characterised in that the recorded location data (p_i) of an onboard unit (1) are sent in data packages (3), which are respectively provided with the same sender identifiers (RID).
5. Method according to one of claims 1 to 3, characterised in that the recorded location data (p_i) of an onboard unit are sent in data packages (3), which are provided with changing sender identifiers (RID_i).
6. Method according to claim 5, characterised in that the data packages (3) are provided with concatenated package identifiers (P_i), which allow them to be matched to one another, wherein releasing (12) of the identifier (OID) only occurs with respect to the sender identifier (RID_i) of the last data package (3).
7. Method according to one of claims 1 to 6, characterised in that the said identifier (OID) is an onboard unit or user account identifier.
8. Method according to one of claims 1 to 7, characterised in that the sender identifier (RID) is a random value or a user-selectable code.
9. Toll calculation server (5) for conducting the method according to one of claims 1 to 8, configured for receiving recorded location data (p_i) and calculating location-anonymised toll data (T) therefrom, characterised in that it deletes recorded location data (p_i) after they are processed into toll data (T) and sends a confirmation (15) of this to an onboard unit (1).
10. Location-recording onboard unit (1) with an identifier (OID) for conducting the method according to one of claims 1 to 8, configured for transmitting (4) its recorded location data (p_i) under at least one sender identifier (RID) different from the identifier (OID), characterised by releasing elements, which after receiving a deletion confirmation (15) with respect to sent recorded location data (p_i) sends the sender identifier (RID) thereof under its identifier (OID).

Images