EP2325806A1 - Verfahren zum Erzeugen von Mauttransaktionen - Google Patents

Verfahren zum Erzeugen von Mauttransaktionen Download PDF

Info

Publication number
EP2325806A1
EP2325806A1 EP09450208A EP09450208A EP2325806A1 EP 2325806 A1 EP2325806 A1 EP 2325806A1 EP 09450208 A EP09450208 A EP 09450208A EP 09450208 A EP09450208 A EP 09450208A EP 2325806 A1 EP2325806 A1 EP 2325806A1
Authority
EP
European Patent Office
Prior art keywords
toll
identifier
data
location
location records
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP09450208A
Other languages
English (en)
French (fr)
Other versions
EP2325806B1 (de
Inventor
Jasja Tijink
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kapsch TrafficCom AG
Original Assignee
Kapsch TrafficCom AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kapsch TrafficCom AG filed Critical Kapsch TrafficCom AG
Priority to PL09450208T priority Critical patent/PL2325806T3/pl
Priority to DK09450208.5T priority patent/DK2325806T3/da
Priority to ES09450208T priority patent/ES2401409T3/es
Priority to SI200930524T priority patent/SI2325806T1/sl
Priority to PT94502085T priority patent/PT2325806E/pt
Priority to EP09450208A priority patent/EP2325806B1/de
Publication of EP2325806A1 publication Critical patent/EP2325806A1/de
Application granted granted Critical
Publication of EP2325806B1 publication Critical patent/EP2325806B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present invention relates to a method for generating toll transactions from the location records of a location recording vehicle device with a unique identifier in a road toll system.
  • OBUs Vehicle devices for road toll systems are also referred to as "on-board 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.
  • so-called “thin client” OBUs do not evaluate their location records themselves, but send them “raw” to the central office, which makes the map matching to generate toll data.
  • “Thin client” OBUs are therefore much simpler and less expensive, but problematic from a data protection point of view, because the road toll system headquarters is aware of all the OBU's "movement profile” records, including stays in non-tolled locations.
  • the invention aims to overcome the shortcomings of the prior art, and more particularly to provide a method for creating toll transactions for thin client OBUs which provides enhanced privacy to the user.
  • This object is achieved by a method of the type mentioned above, which comprises the following steps:
  • the invention is based on a novel map matching concept for "thin client" OBUs, which provides complete transparency and privacy to the user.
  • the user By using a user terminal under his own control, the user has full disposition to anonymise his location records. By reading the location records into the user terminal and replacing its identifier with a different sender ID in the terminal, these steps are transparent and traceable to the user. Any concerns regarding central traceability or creation of a movement profile of the OBU can thus be completely eliminated.
  • the inventive method requires no increased data expenditure in the road toll system.
  • said reading is performed by physically connecting the vehicle device or at least its location record memory to the user terminal, further increasing transparency to the user.
  • said reading may be done by encrypting the location records from the vehicle unit to the center and downloading the encrypted location records from the center to the user terminal, the key used being user selectable.
  • the location records are divided into individual data packets, each of which has a header which indicates the number and / or a hash value of the location records contained in the data packet, which enables consistency checks of the center.
  • the header from the vehicle device can also be sent directly together with the identifier to the center, which allows a cross check with the toll data received from the user terminal there.
  • said sending the header with the identifiers from the vehicle device to the control center via a mobile network e.g. conventional "thin client" OBUs are used which are equipped with a mobile radio transceiver.
  • the toll data are added to the headers of the data packets on which they are based and compared in the central office with the headers received by a vehicle device under the same identifier.
  • a closed-loop control system can be created for checking the toll data generated by the user via his user terminal, without the data protection and affect the transparency of the procedure for the user.
  • the headers preferably also respectively indicate the recording period of the location records contained in the data packet, as a result of which further plausibility checks in the center are possible.
  • each data packet is provided with a preferably continuous packet identifier which is unique among all data packets of one and the same vehicle device, whereby e.g. the order and completeness of the data packets can be checked.
  • the location records - and preferably the optionally available headers - are encrypted by the vehicle unit with a key that is identical for several vehicle units for generating a device signature, and the device signature is checked for authenticity in the toll calculation server.
  • the toll data - and preferably the optionally present headers - can be signed by the toll calculation server with a unique server signature, whereby preferably the server signature can also be checked for authenticity in the center.
  • the identifier read from the vehicle device may be both an identifier of the vehicle device itself and an identifier assigned to the user, e.g. an identifier of a user account for billing tolls in the road toll system.
  • the sender identifier used for sending the Ortsaufzeichnugnen from the user terminal to the toll calculation server can be a temporary Internet address of the user computer in the simplest case. Preferably, however, it is a random or user-selectable code, which further increases transparency for the user.
  • the method of the invention is suitable for all types of self-locating vehicular devices, however they may determine their location, e.g. by detection of landmarks or identification of beacons, which is based on the vehicle device. It is particularly advantageous if the vehicle device determines its locations in a manner known per se by means of satellite navigation, for which purpose e.g. GPS-based "thin client" OBUs can be used.
  • 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 (toll transactions) 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 1 , p 2 , p 3. in an internal location record memory.
  • Each data packet 3 is composed of a packet identifier P i (eg, a consecutive numbering), a header H i , the packetized location records p i and a unique identifier OID of the OBU 1 and / or its user.
  • the header H i can additionally contain metadata such as the number of location records p i contained in the data packet 3 or a checksum or a hash value thereof, ie an image of the same.
  • the header H i may also contain metadata for plausibility checking of the location records p i , such as the recording period and / or a summed path from the location records p i .
  • the location records p i - optionally also the header H i , the packet identifier P i and / or the identifier OID - can be encrypted with a device signature S o of the OBU 1, as indicated by the shading in Fig. 1 indicated.
  • the key used to generate the respective device signature S o is not specific to a single OBU 1, but to all or all OBUs 1 of a group in common, so that the identity of the OBU 1 or its user could not be deduced from the device signature S o alone; the device signature S o merely confirms that a data packet 3 originates from a "real" OBU 1, ie an OBU 1 authenticated with a device signature S o in the road toll system.
  • the location records p i or the data packets 3 with the location records p i are read in a first step of the method in a user terminal 4 (arrow 5). This can be done, for example, weekly, monthly, on request or when the location recording memory of the OBU 1 is full.
  • the reading 5 is preferably carried out by physically connecting the OBU 1 to the user terminal 4, for example via a wired interface such as a USB interface or a wireless data connection such as Bluetooth, WLAN or a mobile network.
  • the internal location record memory of the OBU 1 eg a memory chip, could be taken from the OBU 1 and inserted into or connected to the user terminal 4.
  • Another way of reading 5 is to send the location records p i - eg via the later described data path 11 - in a user-encrypted form from the vehicle unit 1 to the center 2 and then from this at a later time to the user terminal where the user decrypts them with the key of his choice.
  • the user can view and check the location records p i with appropriate software.
  • the location records p i are sent from the user terminal 4 via the Internet to a toll calculation server 7.
  • the identifier OID is replaced in the user terminal 4 by a different, "anonymous", sender identifier RID.
  • the sender ID RID is, for example, a user-selected code or a randomly generated value by the user terminal 4. Alternatively - albeit with a correspondingly reduced anonymity - a temporary Internet address of the user terminal 4 could be used as sender identifier RID.
  • Data packets 3 'sent to the toll calculation server 7 are accordingly made up in each case of the packet identifier P i , the header H i , the location records p i and the anonymous sender identifier RID.
  • the toll calculation server 7 is a "map matching" proxy type known per se, of the location records contained in data packets 3 'p i assigns toll locations, lines or areas of a toll map database and determines associated toll of the toll map database.
  • P i calculated from the tolls of all received to a source identifier RID local records of the toll calculation server 7 in this way "ortsanonyminstrumente" toll data RES, which allow no longer be traceable to their individual location records p i.
  • the toll data RES is, for example, a single charge sum for all location records p i of all data packets 3 'of a sender identifier RID.
  • the toll calculation server 7 is preferably arranged so that it only accepts data packets 3 'of the "real", that is, by their device signature S o authenticated OBUs 1 and processed into toll data RES.
  • the toll calculation server 7 may e.g. also exclude duplicates of data packets 3 '.
  • the sender ID RID in the toll calculation server 7 can be checked for duplicates and, if a duplicate occurs, a new sender ID RID can be requested from the user terminal 4.
  • the toll data RES are then returned to the user terminal 4 identified by the sender address RID (arrow 8).
  • the returned toll data RES can additionally be supplemented with the headers H i of those data packets 3 'which underlie them and, for example, are still signed with the device signature S o .
  • a separate toll data header H M can be added, which indicates the number and / or a hash value of all transmitted header H i .
  • the toll data RES - and preferably also the optionally added headers H i and H M - can also be signed with a server signature S M of the toll calculation server 7 to its origin from a "real", ie authenticated with a server signature S M in the road toll system toll calculation server. 7 to prove.
  • the user can also recalculate the received toll data in his user terminal 4 in order to check the result of the toll calculation server 7.
  • the toll data RES received by the toll calculation server 7 is again provided with the identifier OID in the user computer 4 and is thus provided-preferably together with the headers H i , H M - as a toll transaction 9 to the center 2 transmitted (arrow 10).
  • the toll transaction 9 can be checked in the center 2, both with regard to its charging by a "real" billing server 7.
  • the transmission of the toll transaction 9 from the user terminal 4 to the control center 2 can take place in any desired manner, for example via the Internet, a mobile radio network or else simply by physical transmission of a data carrier.
  • a countercheck of the toll data RES in the center 2 by means of a direct data path 11 from the OBU 1 to the center 2 can be made.
  • the OBU 1 sends the headers H i of the data packets 3 together with their identifier OID and optionally the packet identifiers P i in test packets 12 to the central station 2, for example periodically, on request or if their location recording memory is full the central station 2 to a identifier OID received from the user terminal 4 header H i a toll transaction 9 are compared with the directly received from the OBU 1 headers H i from the test packets 12 to detect inconsistencies or missing data packets that a malfunction of the system or a Can indicate tolls.
  • the data path 11 is preferably established via a mobile radio network via which the center 2 can also dial an OBU 1 itself and request the transmission of test packets 12.
  • the data path 11 can also be realized in other ways, for example by means of decentralized transceiver stations of the center 2, e.g. according to the DSRC (dedicated short range communication), WLAN (wireless local area network) or WAVE (wireless access in a vehicle environment) standard.
  • DSRC dedicated short range communication
  • WLAN wireless local area network
  • WAVE wireless access in a vehicle environment

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Abstract

Verfahren zum Erzeugen von Mauttransaktionen (9) aus den Ortsaufzeichnungen (p i ) eines ortsaufzeichnenden Fahrzeuggeräts (1) mit einer eindeutigen Kennung (OID) in einem Straßenmautsystem, mit den Schritten: Auslesen (5) der Ortsaufzeichnungen (p i ) und der Kennung (OID) aus dem Fahrzeuggerät (1) in ein Benutzerterminal (4), Senden (6) der Ortsaufzeichnungen (p i ) unter einer von der Kennung (OID) verschiedenen Absenderkennung (RID) vom Benutzerterminal (4) an einen Mautberechnungsserver (7), welcher daraus ortsanonymisierte Mautdaten (RES) berechnet, Empfangen (8) der berechneten ortsanonymisierten Mautdaten (RES) unter der Absenderkennung (RID) im Benutzerterminal (4), und Übermitteln (10) der ortsanonymisierten Mautdaten (RES) und der Kennung (OID) als Mauttransaktion (9) an eine Zentrale (2) des Straßenmautsystems.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Erzeugen von Mauttransaktionen aus den Ortsaufzeichnungen eines ortsaufzeichnenden Fahrzeuggeräts mit einer eindeutigen Kennung in einem Straßenmautsystem.
  • Fahrzeuggeräte für Straßenmautsysteme werden auch als "on-board units" bzw. OBUs bezeichnet. OBUs, welche selbst ihren Ort bestimmen und aufzeichnen können, z.B. mittels eines Satellitennavigationsempfängers, gibt es derzeit in zwei verschiedenen Ausführungen: Sogenannte "thick client"-OBUs berechnen auf Grundlage von gespeicherten Mautkarten aus ihren Ortsaufzeichnungen ortsanonymisierte Mautdaten und senden diese z.B. über ein Mobilfunknetz an eine Zentrale des Straßenmautsystems, was eine aufwendige Distribution der Mautkarten an die OBUs und hohe Rechenleistung in den OBUs erfordert. Im Gegensatz dazu werten sogenannte "thin client"-OBUs ihre Ortsaufzeichnungen nicht selbst aus, sondern senden diese "roh" an die Zentrale, welche den Mautkartenabgleich ("map matching") vornimmt, um daraus Mautdaten zu erzeugen. "Thin client"-OBUs sind daher wesentlich einfacher und kostengünstiger aufgebaut, jedoch aus Sicht des Datenschutzes problematisch, weil die Zentrale des Straßenmautsystems die gesamten Ortsaufzeichnungen ("Bewegungsprofil") einer OBU erfährt, einschließlich von Aufenthalten an nicht-mautpflichtigen Orten.
  • In der WO 2008/000227 wurde daher bereits vorgeschlagen, die Ortsaufzeichnungen einer "thin client"-OBU unter einer anonymisierten Absenderkennung an einen speziellen Mautberechnungsserver zu senden, welcher das "map matching" durchführt und ortsanonymisierte Mautdaten an die OBU zurücksendet, die die OBU anschließend an die Zentrale absetzt. Aufgrund der für den Benutzer intransparenten Übermittlung der Ortsaufzeichnungen an einen Mautberechnungsserver des Systembetreibers ist dieses System weiterhin nicht geeignet, Datenschutzbedenken vollständig zu entkräften. Überdies erzeugt diese Lösung zusätzlichen Datenverkehr im Straßenmautsystem.
  • Die Erfindung setzt sich zum Ziel, die Nachteile des Standes der Technik zu überwinden und insbesondere ein Verfahren zum Erzeugen von Mauttransaktionen für "thin client"-OBUs zu schaffen, welches verbesserten Datenschutz bzw. Vertraulichkeit für den Benutzer bietet. Dieses Ziel wird mit einem Verfahren der eingangs genannten Art erreicht, das die folgenden Schritte umfaßt:
  • Auslesen der Ortsaufzeichnungen und der Kennung aus dem Fahrzeuggerät in ein Benutzerterminal,
  • Senden der Ortsaufzeichnungen unter einer von der Kennung verschiedenen Absenderkennung vom Benutzerterminal an einen Mautberechnungsserver, welcher daraus ortsanonymisierte Mautdaten berechnet,
  • Empfangen der berechneten ortsanonymisierten Mautdaten unter der Absenderkennung im Benutzerterminal, und
  • Übermitteln der ortsanonymisierten Mautdaten und der Kennung als Mauttransaktion an eine Zentrale des Straßenmautsystems.
  • Die Erfindung beruht auf einem neuartigen Map-Matching-Konzept für "thin client"-OBUs, welches vollständige Transparenz und Datenschutz für den Benutzer bietet. Durch Verwendung eines unter seiner eigenen Kontrolle stehenden Benutzerterminals hat der Benutzer die volle Verfügungsgewalt über das Anonymisieren seiner Ortsaufzeichnungen. Durch das Auslesen der Ortsaufzeichnungen in das Benutzerterminal und die Ersetzung seiner Kennung durch eine davon verschiedene Absenderkennung im Terminal sind diese Schritte für den Benutzer transparent und nachvollziehbar. Jegliche Bedenken hinsichtlich einer zentralen Nachverfolgbarkeit bzw. Erstellung eines Bewegungsprofils der OBU können dadurch zur Gänze ausgeräumt werden. Darüber hinaus benötigt das erfindungsgemäße Verfahren keinen erhöhten Datenaufwand im Straßenmautsystem.
  • Bevorzugt erfolgt das genannte Auslesen durch physisches Anschließen des Fahrzeuggeräts oder zumindest seines Ortsaufzeichnungsspeichers an das Benutzerterminal, was die Transparenz für den Benutzer weiter erhöht.
  • Alternativ kann das genannte Auslesen durch verschlüsseltes Senden der Ortsaufzeichnungen vom Fahrzeuggerät an die Zentrale und Herunterladen der verschlüsselten Ortsaufzeichnungen von der Zentrale auf das Benutzerterminal erfolgen, wobei der verwendete Schlüssel benutzerwählbar ist.
  • Besonders vorteilhaft ist es, wenn die Ortsaufzeichnungen auf einzelne Datenpakete aufgeteilt sind, die jeweils einen Header haben, welcher die Anzahl und/oder einen Hashwert der im Datenpaket enthaltenen Ortsaufzeichnungen angibt, was Konsistenzprüfungen der Zentrale ermöglicht.
  • Dazu können bevorzugt die Header vom Fahrzeuggerät auch direkt zusammen mit der Kennung an die Zentrale gesendet werden, was dort eine Gegenprüfung mit den vom Benutzerterminal empfangenen Mautdaten ermöglicht.
  • Bevorzugt erfolgt das genannte Senden der Header mit den Kennungen vom Fahrzeuggerät an die Zentrale über ein Mobilfunknetz. Dadurch können z.B. herkömmliche "thin client"-OBUs eingesetzt werden, welche mit einem Mobilfunk-Sendeempfänger ausgerüstet sind.
  • In einer weiteren bevorzugten Ausführungsform der Erfindung werden den Mautdaten die Header der ihnen zugrundeliegenden Datenpakete hinzugefügt und in der Zentrale mit den von einem Fahrzeuggerät unter derselben Kennung empfangenen Headern verglichen. Dadurch kann ein geschlossenes Kontrollsystem zur Gegenprüfung der vom Benutzer über sein Benutzerterminal erzeugten Mautdaten geschaffen werden, ohne den Datenschutz und die Transparenz des Verfahrens für den Benutzer zu beeinträchtigen.
  • Bevorzugt geben die Header jeweils auch den Aufzeichnungszeitraum der im Datenpaket enthaltenen Ortsaufzeichnungen an, wodurch weitere Plausibilitätsprüfungen in der Zentrale möglich sind.
  • Gemäß einer weiteren vorteilhaften Ausführungsform der Erfindung wird jedes Datenpaket mit einer unter allen Datenpaketen ein und desselben Fahrzeuggeräts eindeutigen, bevorzugt fortlaufenden Paketkennung versehen, wodurch z.B. die Reihenfolge und Vollständigkeit der Datenpakete überprüft werden kann.
  • In jedem Fall ist es besonders günstig, wenn die Ortsaufzeichnungen - und bevorzugt die optional vorhandenen Header - vom Fahrzeuggerät mit einem für mehrere Fahrzeuggeräte gleichen Schlüssel zur Generierung einer Gerätesignatur verschlüsselt werden und im Mautberechnungsserver die Gerätesignatur auf Echtheit überprüft wird. In gleicher Weise können die Mautdaten - und bevorzugt die optional vorhandenen Header - vom Mautberechnungsserver mit einer eindeutigen Serversignatur signiert sein, wodurch bevorzugt in der Zentrale auch die Serversignatur auf Echtheit überprüft werden kann.
  • Die aus dem Fahrzeuggerät ausgelesene Kennung kann sowohl eine Kennung des Fahrzeuggeräts selbst als auch eine dem Benutzer zugeordnete Kennung sein, z.B. eine Kennung eines Benutzerkontos zur Abrechnung von Mautgebühren im Straßenmautsystem.
  • Die zum Senden der Ortsaufzeichnugnen vom Benutzerterminal an den Mautberechnungsserver verwendete Absenderkennung kann im einfachsten Fall eine temporäre Internetadresse des Benutzerrechners sein. Bevorzugt ist sie jedoch ein Zufallswert oder ein benutzerwählbarer Code, was die Transparenz für den Benutzer noch weiter erhöht.
  • Das Verfahren der Erfindung eignet sich für alle Arten von selbstlokalisierenden Fahrzeuggeräten, auf welche Weise auch immer diese ihren Ort bestimmen, z.B. durch Erkennung von Landmarken oder Identifikation von Baken, an denen sich das Fahrzeuggerät orientiert. Besonders vorteilhaft ist es, wenn das Fahrzeuggerät in an sich bekannter Weise seine Orte mittels Satellitennavigation bestimmt, wofür z.B. GPS-gestützte "thin client"-OBUs herangezogen werden können.
  • Die Erfindung wird nachstehend anhand eines in der beigeschlossenen Zeichnung dargestellten Ausführungsbeispieles näher erläutert, deren einzige Fig. 1 ein Blockdiagramm eines nach dem Verfahren der Erfindung arbeitenden Straßenmautsystems zeigt.
  • Gemäß Fig. 1 bewegt sich eine OBU 1 an Bord eines Fahrzeugs im Rahmen eines Straßenmautsystem mit einer Zentrale 2. Die Zentrale 2 rechnet mautpflichtige Ortsnutzungen der OBU 1, z.B. das Befahren einer Mautstraße, das Eintreten in einen eintrittspflichtigen Bereich, das Verweilen auf einem gebührenpflichtigen Parkplatz usw. über entsprechende Benutzerkonten ab, u. zw. auf Grundlage von Mautdaten (Mauttransaktionen), die durch die Ortsnutzungen der OBU 1 ausgelöst werden, wie in der Technik bekannt.
  • Die OBU 1 ist von selbstlokalisierendem "thin client"-Typ und ermittelt fortlaufend, z.B. periodisch, ihren Ort, beispielsweise mit Hilfe eines Satellitennavigationsempfängers, und zeichnet die so ermittelten Orte ("position fixes") p1, p2, p3... in einem internen Ortsaufzeichnungsspeicher auf.
  • Die Ortsaufzeichnungen pi (i = 1, 2, 3...) der OBU 1 werden zur leichteren Handhabbarkeit auf einzelne Datenpakete 3 aufgeteilt. Jedes Datenpaket 3 setzt sich aus einer Paketkennung Pi (z.B. einer fortlaufenden Numerierung), einem Header Hi, den im Paket zusammengefaßten Ortsaufzeichnungen pi und einer eindeutigen Kennung OID der OBU 1 und/oder ihres Benutzers zusammen. Der Header Hi kann zusätzlich Metadaten enthalten wie die Anzahl der im Datenpaket 3 enthaltenden Ortsaufzeichnungen pi oder eine Checksum oder einen Hashwert derselben, d.h. eine Abbildung derselben. Zusätzlich kann der Header Hi auch Metadaten zur Plausibilisierung der Ortsaufzeichnungen pi enthalten wie den Aufzeichnungszeitraum und/oder eine aufsummierte Wegstrecke aus den Ortsaufzeichnungen pi.
  • Die Ortsaufzeichnungen pi - optional auch der Header Hi, die Paketkennung Pi und/oder die Kennung OID - können mit einer Gerätesignatur So der OBU 1 verschlüsselt werden, wie durch die Schattierung in Fig. 1 angedeutet. Der zur Generierung der jeweiligen Gerätesignatur So verwendete Schlüssel ist nicht spezifisch für eine einzelne OBU 1, sondern allen oder allen OBUs 1 einer Gruppe gemeinsam, sodaß aus der Gerätesignatur So alleine nicht auf die Identität der OBU 1 oder ihres Benutzers geschlossen werden könnte; die Gerätesignatur So bestätigt lediglich, daß ein Datenpaket 3 von einer "echten", d.h. mit einer Gerätesignatur So im Straßenmautsystem authentifizierten OBU 1 stammt.
  • Die Ortsaufzeichnungen pi bzw. die Datenpakete 3 mit den Ortsaufzeichnungen pi werden in einem ersten Schritt des Verfahrens in ein Benutzerterminal 4 ausgelesen (Pfeil 5). Dies kann z.B. wöchentlich, monatlich, auf Aufforderung oder wenn der Ortsaufzeichnungsspeicher der OBU 1 voll ist erfolgen. Das Auslesen 5 erfolgt bevorzugt durch physisches Anschließen der OBU 1 an das Benutzerterminal 4, z.B. über eine drahtgebundene Schnittstelle wie eine USB-Schnittstelle oder eine drahtlose Datenverbindung wie Bluetooth, WLAN oder ein Mobilfunknetz. Alternativ könnte der interne Ortsaufzeichnungsspeicher der OBU 1, z.B. ein Speicherchip, der OBU 1 entnommen und in das Benutzerterminal 4 eingesetzt oder an dieses angeschlossen werden.
  • Eine weitere Möglichkeit des Auslesens 5 besteht darin, die Ortsaufzeichnungen pi - z.B. über den später noch erläuterten Datenpfad 11 - in einer vom Benutzer verschlüsselten Form vom Fahrzeuggerät 1 an die Zentrale 2 zu senden und von dieser dann zu einem späteren Zeitpunkt auf das Benutzerterminal 4 herunterzuladen, wo sie der Benutzer mit dem von ihm selbst gewählten Schlüssel wieder entschlüsselt.
  • Im Benutzerterminal 4 kann der Benutzer, falls gewünscht, mit einer entsprechenden Software die Ortsaufzeichnungen pi ansehen und überprüfen.
  • In einem nächsten Schritt 6 werden die Ortsaufzeichnungen pi vom Benutzerterminal 4 über das Internet an einen Mautberechnungsserver 7 gesandt. Vor dieser Versendung wird jedoch im Benutzerterminal 4 die Kennung OID durch eine davon verschiedene, "anonyme" Absenderkennung RID ersetzt. Die Absenderkennung RID ist beispielsweise ein vom Benutzer frei gewählter Code oder ein vom Benutzerterminal 4 zufällig generierter Wert. Alternativ könnte - wenn auch mit entsprechend verringerter Anonymität - eine temporäre Internetadresse des Benutzerterminals 4 als Absenderkennung RID verwendet werden.
  • An den Mautberechnungsserver 7 abgesandte Datenpakete 3' setzen sich demgemäß jeweils aus der Paketkennung Pi, dem Header Hi, den Ortsaufzeichnungen pi und der anonymen Absenderkennung RID zusammen.
  • Der Mautberechnungsserver 7 ist ein "map matching"-Proxy an sich bekannter Art, der die in Datenpaketen 3' enthaltenen Ortsaufzeichnungen pi mautpflichtigen Orten, Strecken oder Gebieten aus einer Mautkartendatenbank zuordnet und zugehörige Mautgebühren aus der Mautkartendatenbank ermittelt. Aus den Mautgebühren aller zu einer Absenderkennung RID empfangenen Ortsaufzeichnungen pi berechnet der Mautberechnungsserver 7 auf diese Weise "ortsanonymisierte" Mautdaten RES, welche keinen Rückschluß mehr auf die einzelnen Ortsaufzeichnungen pi erlauben. Die Mautdaten RES sind beispielsweise eine einzige Gebührensumme für alle Ortsaufzeichnungen pi aller Datenpakete 3' einer Absenderkennung RID.
  • Der Mautberechnungsserver 7 ist bevorzugt so eingerichtet, daß er nur Datenpakete 3' von "echten", d.h. durch ihre Gerätesignatur So authentifizierten OBUs 1 akzeptiert und zu Mautdaten RES verarbeitet.
  • Anhand der Absenderkennung RID kann der Mautberechnungsserver 7 z.B. auch Duplikate von Datenpaketen 3' ausschließen. Beispielsweise kann die Absenderkennung RID im Mautberechnungsserver 7 auf Duplikate geprüft und bei Auftreten eines Duplikats eine neue Absenderkennung RID vom Benutzerterminal 4 angefordert werden.
  • Die Mautdaten RES werden anschließend an das durch die Absenderadresse RID identifizierte Benutzerterminal 4 zurückgesandt (Pfeil 8). Die zurückgesandten Mautdaten RES können zusätzlich mit den Headern Hi jener Datenpakete 3' ergänzt werden, welche ihnen zugrundelagen und z.B. immer noch mit der Gerätesignatur So signiert sind. Zusätzlich kann ein eigener Mautdaten-Header HM hinzugefügt werden, der die Anzahl und/oder einen Hashwert aller mitübermittelten Header Hi angibt.
  • Die Mautdaten RES - und bevorzugt auch die optional hinzugefügten Header Hi und HM - können ferner mit einer Serversignatur SM des Mautberechnungsservers 7 signiert werden, um ihren Ursprung von einem "echten", d.h. mit einer Serversignatur SM im Straßenmautsystem authentifizierten Mautberechnungsserver 7 zu belegen.
  • Falls gewünscht, kann der Benutzer die empfangenen Mautdaten auch in seinem Benutzerterminal 4 nachrechnen, um das Resultat des Mautberechnungsservers 7 zu prüfen.
  • Im nächsten Schritt werden die vom Mautberechnungsserver 7 empfangenen Mautdaten RES im Benutzerrechner 4 wieder mit der Kennung OID versehen und solcherart - bevorzugt zusammen mit den Headern Hi, HM - als Mauttransaktion 9 an die Zentrale 2 übermittelt (Pfeil 10). Anhand der Serversignatur SM der Mautdaten RES kann in der Zentrale 2 die Mauttransaktion 9 sowohl hinsichtlich ihrer Gebührenberechnung durch einen "echten" Gebührenberechnungsserver 7 überprüft werden.
  • Das Übermitteln der Mauttransaktion 9 vom Benutzerterminal 4 zur Zentrale 2 kann auf beliebige Art und Weise erfolgen, beispielsweise über das Internet, ein Mobilfunknetz oder auch einfach durch physisches Übersenden eines Datenträgers.
  • Optional kann eine Gegenprüfung der Mautdaten RES in der Zentrale 2 mit Hilfe eines direkten Datenpfades 11 von der OBU 1 zur Zentrale 2 vorgenommen werden. Auf dem Datenpfad 11 sendet die OBU 1 - z.B. periodisch, auf Anforderung oder wenn ihr Ortsaufzeichnungsspeicher voll ist - die Header Hi der Datenpakete 3 zusammen mit ihrer Kennung OID und optional den Paketkennungen Pi in Prüfpaketen 12 an die Zentrale 2. Dadurch können in der Zentrale 2 die zu einer Kennung OID vom Benutzerterminal 4 empfangenen Header Hi einer Mauttransaktion 9 mit den von der OBU 1 direkt empfangenen Headern Hi aus den Prüfpaketen 12 verglichen werden, um Inkonsistenzen oder fehlende Datenpakete aufzudecken, welche eine Fehlfunktion des Systems oder ein Mautvergehen anzeigen könnten.
  • Der Datenpfad 11 wird bevorzugt über ein Mobilfunknetz errichtet, über welches die Zentrale 2 eine OBU 1 überdies auch selbst anwählen und zur Übersendung von Prüfpaketen 12 auffordern kann. Alternativ kann der Datenpfad 11 auch auf andere Weise realisiert werden, beispielsweise mit Hilfe dezentralisierter Sendeempfangsstationen der Zentrale 2 z.B. nach dem DSRC- (dedicated short range communication), WLAN- (wireless local area network) oder WAVE- (wireless access in a vehicle environment) -Standard.
  • Die Erfindung ist nicht auf die dargestellten Ausführungsformen beschränkt, sondern umfaßt alle Varianten und Modifikationen, die in den Rahmen der angeschlossenen Ansprüche fallen.

Claims (17)

  1. Verfahren zum Erzeugen von Mauttransaktionen aus den Ortsaufzeichnungen eines ortsaufzeichnenden Fahrzeuggeräts mit einer eindeutigen Kennung in einem Straßenmautsystem, mit den Schritten:
    Auslesen (5) der Ortsaufzeichnungen (pi) und der Kennung (OID) aus dem Fahrzeuggerät (1) in ein Benutzerterminal (4),
    Senden (6) der Ortsaufzeichnungen (pi) unter einer von der Kennung (OID) verschiedenen Absenderkennung (RID) vom Benutzerterminal (4) an einen Mautberechnungsserver (7), welcher daraus ortsanonymisierte Mautdaten (RES) berechnet,
    Empfangen (8) der berechneten ortsanonymisierten Mautdaten (RES) unter der Absenderkennung (RID) im Benutzerterminal (4), und
    Übermitteln (10) der ortsanonymisierten Mautdaten (RES) und der Kennung (OID) als Mauttransaktion (9) an eine Zentrale (2) des Straßenmautsystems.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das genannte Auslesen (5) durch physisches Anschließen des Fahrzeuggeräts (1) oder zumindest seines Ortsaufzeichnungsspeichers an das Benutzerterminal (4) erfolgt.
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das genannte Auslesen (5) durch verschlüsseltes Senden der Ortsaufzeichnungen (pi) vom Fahrzeuggerät (1) an die Zentrale (2) und Herunterladen der verschlüsselten Ortsaufzeichnungen (pi) von der Zentrale (2) auf das Benutzerterminal (4) erfolgt, wobei der verwendete Schlüssel benutzerwählbar ist.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Ortsaufzeichnungen (pi) auf einzelne Datenpakete (3) aufgeteilt sind, die jeweils einen Header (Hi) haben, welcher Metadaten, bevorzugt die Anzahl und/oder eine Checksum und/oder einen Hashwert der im Datenpaket (3) enthaltenen Ortsaufzeichnungen (pi), enthält.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die Header (Hi) vom Fahrzeuggerät (1) zusammen mit seiner Kennung (OID) an die Zentrale (2) gesendet werden.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das genannte Senden (11) vom Fahrzeuggerät (1) an die Zentrale (2) über ein Mobilfunknetz erfolgt.
  7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß den Mautdaten (RES) die Header (Hi) der ihnen zugrundeliegenden Datenpakete (3) hinzugefügt sind und in der Zentrale (2) mit den von einem Fahrzeuggerät (1) unter derselben Kennung (OID) empfangenen Headern (Hi) verglichen werden.
  8. Verfahren nach einem der Ansprüche 4 bis 7, dadurch gekennzeichnet, daß die Header (Hi) jeweils auch den Aufzeichnungszeitraum der im Datenpaket (3) enthaltenen Ortsaufzeichnungen (pi) angeben.
  9. Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, daß jedes Datenpaket (3) mit einer unter allen Datenpaketen ein und desselben Fahrzeuggeräts (1) eindeutigen, bevorzugt fortlaufenden Paketkennung (Pi) versehen wird.
  10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Ortsaufzeichnungen (pi) - und bevorzugt die optional vorhandenen Header (Hi) - vom Fahrzeuggerät (1) mit einem für mehrere Fahrzeuggeräte gleichen Schlüssel zur Generierung einer Gerätesignatur (So) verschlüsselt werden.
  11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß im Mautberechnungsserver (7) die Gerätesignatur (So) auf Echtheit überprüft wird.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, daß die Mautdaten (RES) - und bevorzugt die optional vorhandenen Header (Hi) - vom Mautberechnungsserver (7) mit einer eindeutigen Serversignatur (SM) signiert sind.
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß in der Zentrale (2) die Serversignatur (SM) auf Echtheit überprüft wird.
  14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, daß die genannte Kennung (OID) eine Fahrzeuggerät- oder Benutzerkontokennung ist.
  15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, daß die Absenderkennung (RID) ein Zufallswert oder ein benutzerwählbarer Code ist.
  16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, daß das Fahrzeuggerät (1) seine Orte (pi) mittels Satellitennavigation bestimmt.
  17. Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, daß sowohl im Mautberechnungsserver (7) als auch in der Zentrale (2) des Straßenmautsystems auf Vollständigkeit und Duplikate der Ortsaufzeichnungen (pi) bzw. der ortsanonymisierten Mautdaten (RES) unter der Zuhilfenahme der Header (Hi) geprüft wird und korrigierende Maßnahmen veranlaßt werden, insbesondere ein neuerliches Anfordern von Daten und/oder Fehlermeldungen.
EP09450208A 2009-10-30 2009-10-30 Verfahren zum Erzeugen von Mauttransaktionen Not-in-force EP2325806B1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PL09450208T PL2325806T3 (pl) 2009-10-30 2009-10-30 Sposób generowania transakcji poboru opłat drogowych
DK09450208.5T DK2325806T3 (da) 2009-10-30 2009-10-30 Fremgangsmåde til frembringelsen af afgiftstransaktioner
ES09450208T ES2401409T3 (es) 2009-10-30 2009-10-30 Procedimiento para generar transacciones de peaje
SI200930524T SI2325806T1 (sl) 2009-10-30 2009-10-30 Postopek generiranja cestninskih transakcij
PT94502085T PT2325806E (pt) 2009-10-30 2009-10-30 Processo para gerar transacções de portagens
EP09450208A EP2325806B1 (de) 2009-10-30 2009-10-30 Verfahren zum Erzeugen von Mauttransaktionen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP09450208A EP2325806B1 (de) 2009-10-30 2009-10-30 Verfahren zum Erzeugen von Mauttransaktionen

Publications (2)

Publication Number Publication Date
EP2325806A1 true EP2325806A1 (de) 2011-05-25
EP2325806B1 EP2325806B1 (de) 2012-12-12

Family

ID=41562769

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09450208A Not-in-force EP2325806B1 (de) 2009-10-30 2009-10-30 Verfahren zum Erzeugen von Mauttransaktionen

Country Status (6)

Country Link
EP (1) EP2325806B1 (de)
DK (1) DK2325806T3 (de)
ES (1) ES2401409T3 (de)
PL (1) PL2325806T3 (de)
PT (1) PT2325806E (de)
SI (1) SI2325806T1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110282717A1 (en) * 2010-05-12 2011-11-17 Kapsch Trafficcom Ag Method for collecting tolls for location usages
DE102013208470A1 (de) * 2013-05-08 2014-11-13 Continental Automotive Gmbh Verfahren und Vorrichtung zur Bereitstellung von Daten zur Mauterhebung und Mautsystem

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4425271A1 (de) * 1994-07-18 1996-01-25 Sel Alcatel Ag Verfahren und Geräteanordnung für einen gesicherten, anonymen Zahlungsverkehr
WO2001011571A1 (de) * 1999-08-04 2001-02-15 Vodafone Ag Mautsystem zur zentralen erhebung von nutzungsgebühren von fahrzeugen in einem gebührenpflichtigen wegstreckennetz
EP1403826A1 (de) * 2002-09-25 2004-03-31 Hitachi, Ltd. System und Verfahren zur Sammlung von Fahrzeuginformation
EP1457928A1 (de) * 2003-03-11 2004-09-15 Atos Origin IT Services UK Ltd. Strassenabrechnungssytem
EP1475752A2 (de) * 2003-05-05 2004-11-10 Vodafone Holding GmbH Verfahren und System zur elektronischen Erhebung von Nutzungsgebühren
WO2008000227A1 (de) 2006-06-27 2008-01-03 Deutsche Telekom Ag Verfahren und vorrichtung zur gewährleistung des datenschutzes bei der offboard mauterfassung
WO2009001303A1 (en) * 2007-06-26 2008-12-31 Nxp B.V. Road toll system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4425271A1 (de) * 1994-07-18 1996-01-25 Sel Alcatel Ag Verfahren und Geräteanordnung für einen gesicherten, anonymen Zahlungsverkehr
WO2001011571A1 (de) * 1999-08-04 2001-02-15 Vodafone Ag Mautsystem zur zentralen erhebung von nutzungsgebühren von fahrzeugen in einem gebührenpflichtigen wegstreckennetz
EP1403826A1 (de) * 2002-09-25 2004-03-31 Hitachi, Ltd. System und Verfahren zur Sammlung von Fahrzeuginformation
EP1457928A1 (de) * 2003-03-11 2004-09-15 Atos Origin IT Services UK Ltd. Strassenabrechnungssytem
EP1475752A2 (de) * 2003-05-05 2004-11-10 Vodafone Holding GmbH Verfahren und System zur elektronischen Erhebung von Nutzungsgebühren
WO2008000227A1 (de) 2006-06-27 2008-01-03 Deutsche Telekom Ag Verfahren und vorrichtung zur gewährleistung des datenschutzes bei der offboard mauterfassung
WO2009001303A1 (en) * 2007-06-26 2008-12-31 Nxp B.V. Road toll system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110282717A1 (en) * 2010-05-12 2011-11-17 Kapsch Trafficcom Ag Method for collecting tolls for location usages
US8321265B2 (en) * 2010-05-12 2012-11-27 Kapsch Trafficcom Ag Method for collecting tolls for location usages
DE102013208470A1 (de) * 2013-05-08 2014-11-13 Continental Automotive Gmbh Verfahren und Vorrichtung zur Bereitstellung von Daten zur Mauterhebung und Mautsystem

Also Published As

Publication number Publication date
PT2325806E (pt) 2013-03-06
ES2401409T3 (es) 2013-04-19
PL2325806T3 (pl) 2013-05-31
DK2325806T3 (da) 2013-03-18
SI2325806T1 (sl) 2013-03-29
EP2325806B1 (de) 2012-12-12

Similar Documents

Publication Publication Date Title
EP2860703B1 (de) Verfahren zum Überprüfen von Mauttransaktionen und Komponenten hierfür
EP2038849B1 (de) Verfahren und vorrichtung zur gewährleistung des datenschutzes bei der offboard mauterfassung
EP2423885B1 (de) Vorrichtung und Verfahren zur Funktionsüberwachung eines Strassenmautsystems
DE60006553T2 (de) Verfahren zum verwalten des parkens von fahrzeugen
EP2994890B1 (de) Verfahren und vorrichtung zur bereitstellung von daten zur mauterhebung und mautsystem
DE102013003044A1 (de) Übertragen von Informationen über ein Anzeigesystem eines Fahrzeugs
EP2541502B1 (de) Verfahren zum Ermitteln von Mautgebühren in einem Straßenmautsystem
EP2378489B1 (de) Verfahren zur DSRC-Kommunikation
DE4425271A1 (de) Verfahren und Geräteanordnung für einen gesicherten, anonymen Zahlungsverkehr
EP2320386B1 (de) Verfahren und Vorrichtungen zum Erzeugen von ortsanonymisierten Mautdaten
AT504581A1 (de) Verfahren und system zum auslesen von daten aus einem speicher eines fernen geräts durch einen server
EP2325806B1 (de) Verfahren zum Erzeugen von Mauttransaktionen
EP2490183B1 (de) Fahrzeuggerät, ad-hoc-Netzwerk und Verfahren für ein Strassenmautsystem
DE202015102311U1 (de) Vorrichtung zum Abrechnen von Mautgebühren
EP2503518B1 (de) Verfahren zum Validieren einer Mauttransaktion
DE102021006525A1 (de) Verfahren zur Anonymisierung von Bewegungsdaten
EP2757513B1 (de) Verfahren zum Abrechnen von Ortsnutzungen
WO2020058008A1 (de) Verfahren zum ausführen einer applikation in einem fahrzeug, fahrzeugsystem, computerprogramm und datenträgersignal
EP3038062B1 (de) Verfahren und Fahrzeugeinrichtungen zur DSRC-Kommunikation
EP3188133B1 (de) Positionsdatenverarbeitungseinrichtung und mautsystem sowie verfahren zum betreiben einer positionsdatenverarbeitungseinrichtung und eines mautsystems
EP2242024B1 (de) Verfahren, Komponenten und Systeme zum Erzeugen von Mauttransaktionen
DE102023000470B4 (de) Verfahren zur Datenkommunikation zwischen einem Egofahrzeug und einer zentralen Recheneinrichtung
EP1335324A2 (de) Einrichtung zur Ermittlung von Nutzungsgebühren
DE60205354T2 (de) System und verfahren für die registrierung einer route eines fahrzeugs mit einem mobiltelefon
EP3358533B1 (de) Verfahren zur automatischen ermittlung der nutzung von fahrzeugen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

17P Request for examination filed

Effective date: 20111116

17Q First examination report despatched

Effective date: 20120127

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 588640

Country of ref document: AT

Kind code of ref document: T

Effective date: 20121215

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502009005653

Country of ref document: DE

Effective date: 20130207

REG Reference to a national code

Ref country code: SE

Ref legal event code: TRGR

REG Reference to a national code

Ref country code: PT

Ref legal event code: SC4A

Free format text: AVAILABILITY OF NATIONAL TRANSLATION

Effective date: 20130225

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: BUECHEL, VON REVY AND PARTNER, CH

REG Reference to a national code

Ref country code: DK

Ref legal event code: T3

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2401409

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20130419

REG Reference to a national code

Ref country code: NO

Ref legal event code: T2

Effective date: 20121212

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: PATWIL AG, CH

REG Reference to a national code

Ref country code: SK

Ref legal event code: T3

Ref document number: E 13492

Country of ref document: SK

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130313

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: PL

Ref legal event code: T3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130312

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130412

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: HU

Ref legal event code: AG4A

Ref document number: E016525

Country of ref document: HU

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20130913

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502009005653

Country of ref document: DE

Effective date: 20130913

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131030

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131030

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121212

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CZ

Payment date: 20161027

Year of fee payment: 8

Ref country code: GB

Payment date: 20161020

Year of fee payment: 8

Ref country code: HU

Payment date: 20161019

Year of fee payment: 8

Ref country code: NL

Payment date: 20161019

Year of fee payment: 8

Ref country code: NO

Payment date: 20161024

Year of fee payment: 8

Ref country code: DK

Payment date: 20161019

Year of fee payment: 8

Ref country code: SK

Payment date: 20161027

Year of fee payment: 8

Ref country code: CH

Payment date: 20161020

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: SI

Payment date: 20160923

Year of fee payment: 8

Ref country code: IT

Payment date: 20161024

Year of fee payment: 8

Ref country code: BE

Payment date: 20161019

Year of fee payment: 8

Ref country code: PT

Payment date: 20161028

Year of fee payment: 8

Ref country code: PL

Payment date: 20161027

Year of fee payment: 8

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

REG Reference to a national code

Ref country code: DK

Ref legal event code: EBP

Effective date: 20171031

REG Reference to a national code

Ref country code: NO

Ref legal event code: MMEP

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20171101

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20171030

REG Reference to a national code

Ref country code: SK

Ref legal event code: MM4A

Ref document number: E 13492

Country of ref document: SK

Effective date: 20171030

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171030

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

Ref country code: PT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180430

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171101

Ref country code: SK

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171030

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

Ref country code: CZ

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171030

Ref country code: NO

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

REG Reference to a national code

Ref country code: SI

Ref legal event code: KO00

Effective date: 20180605

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20171031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

Ref country code: HU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

Ref country code: SI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 10

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171030

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20171030

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20201022

Year of fee payment: 12

Ref country code: FR

Payment date: 20201022

Year of fee payment: 12

Ref country code: SE

Payment date: 20201028

Year of fee payment: 12

Ref country code: ES

Payment date: 20201228

Year of fee payment: 12

Ref country code: DE

Payment date: 20201022

Year of fee payment: 12

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502009005653

Country of ref document: DE

REG Reference to a national code

Ref country code: SE

Ref legal event code: EUG

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 588640

Country of ref document: AT

Kind code of ref document: T

Effective date: 20211030

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211031

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220503

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211030

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211031

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20230222

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211031