EP3038062A1 - Procédé et dispositifs de véhicule pour communication DSRC - Google Patents

Procédé et dispositifs de véhicule pour communication DSRC Download PDF

Info

Publication number
EP3038062A1
EP3038062A1 EP14200173.4A EP14200173A EP3038062A1 EP 3038062 A1 EP3038062 A1 EP 3038062A1 EP 14200173 A EP14200173 A EP 14200173A EP 3038062 A1 EP3038062 A1 EP 3038062A1
Authority
EP
European Patent Office
Prior art keywords
identifier
subroutine
program
processor
main program
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
EP14200173.4A
Other languages
German (de)
English (en)
Other versions
EP3038062B1 (fr
Inventor
Frank Lukanek
Ullrich Krämer
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.)
Toll Collect GmbH
Original Assignee
Toll Collect GmbH
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 Toll Collect GmbH filed Critical Toll Collect GmbH
Priority to EP14200173.4A priority Critical patent/EP3038062B1/fr
Publication of EP3038062A1 publication Critical patent/EP3038062A1/fr
Application granted granted Critical
Publication of EP3038062B1 publication Critical patent/EP3038062B1/fr
Active 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

Definitions

  • the present invention relates to methods and vehicle facilities for so-called Dedicated Short Range Communication, hereinafter referred to as DSRC communication. More particularly, the present invention relates to a method of performing DSRC communication by means of a vehicle device and to a vehicle device having a DSRC communication module configured to perform a DSRC communication method.
  • the communication between a vehicle device for example a vehicle device with a so-called on-board unit, which is also known as on-board entity (OBE), and a beacon, for example a roadside entity (RSE), can be for example a DSRC communication.
  • OBE on-board entity
  • RSE roadside entity
  • DSRC communication Some aspects of DSRC communication are standardized. Specifications for such DSRC communication can be found, for example, in the following standards: EN 15509, EN ISO 14906, Cen ISO / TS 12813, Cen ISO / TS 13141 and EN 12834. Auf These standards are expressly incorporated herein by reference.
  • EP 2 360 641 B1 a method for DSRC communication between beacons and vehicle devices of a road toll system, wherein the beacons have a native key and the vehicle devices do not have the native key but individual keys.
  • the EP 2 602 767 B1 describes a method for signaling toll transactions in a road toll system with geographically distributed beacons that handle toll transactions with vehicle vehicle equipment passing through them. The method described there is also based on DSRC communication.
  • the DSRC communication between the beacon on the one hand and the vehicle equipment on the other hand is used in particular for the purposes of toll collection.
  • the DSRC communication can thus be relevant for a payment service, namely the payment of the toll. Therefore, it may be necessary to perform a main program on the vehicle equipment that has been previously certified.
  • the certification of the main program confirms that the main program complies with the standards and complies with the standards of the institutions involved in the payment service. In particular, it is therefore not possible for non-certified main programs to use a payment service based on DSRC communication.
  • a problem in this context is that the specifications of the institutions involved in the payment service may change over time and / or other institutions would like to use the payment service based on DSRC communication.
  • toll collection it may happen, for example, that other countries want to use the payment service based on the DSRC communication, but have different requirements than countries already participating in the payment service.
  • a method for performing DSRC communication by means of a vehicle device comprising a DSRC communication module comprising: executing a receive ready routine of a main program stored in the vehicle device by a processor of the DSRC communication module; Receiving, by a processor-coupled DSRC transceiver of the DSRC communication module, a request message transmitted from a roadside beacon that includes an identifier; Sending a response message comprising a processing result by the DSRC transceiver to the roadside beacon; which is characterized in that it further comprises, between the receiving and the sending: checking, by means of the processor, in the context of instructions of the main program, whether the vehicle identifier-side program part of the main program is associated with the received identifier; if the vehicle identifier-side program part of the main program is assigned to the received identifier: executing the associated vehicle-body-side program part of the main program by the processor (52) at least to generate the processing
  • a method for carrying out DSRC communication by means of a vehicle device comprising a DSRC communication module comprises executing a receive ready routine of a main program stored in the vehicle device by a processor of the DSRC.
  • a vehicle device with a DSRC communication module comprising a DSRC transceiver and a processor, and with a program memory
  • the processor is operatively coupled to the DSRC transceiver and to the program memory and wherein the program memory comprises a main program having a receive ready routine, the execution of which configures the processor to receive, by means of the DSRC transceiver, a request message sent from a roadside beacon, comprising an identifier;
  • the program memory comprises at least a first subroutine which is not part of the main program, wherein both the execution of the subroutine and the execution of a vehicle device side program part of the main program further configure the processor to generate a processing result in dependence on the received identifier and for transmitting a response message comprising the processing result to the roadside beacon by the DSRC transceiver;
  • the main program comprises instructions that configure the processor to check whether the vehicle-identifying-side program part
  • a vehicle device with a DSRC communication module which comprises at least one DSRC transceiver and at least one processor, and with at least one first program memory, the processor transmitting to the DSRC transceiver and operatively coupled to the program memory, and wherein the program memory comprises a main program receive ready routine, the execution of which configures the processor to receive, by means of the DSRC transceiver, a request message sent from a roadside beacon comprising an identifier; and characterized in that the program memory comprises a first subroutine and at least a second subroutine none of which is part of the main program, wherein both the execution of the first subroutine and the execution of the second subroutine further configure the processor to generate a processing result in dependence from the received identifier and for sending a response message comprising the processing result to the roadside beacon by the DSRC transceiver; wherein the main program comprises instructions that configure the processor to (a)
  • the invention provides methods and vehicle facilities for DSRC communication with a roadside beacon, in which an identifier is received by the in-vehicle beacon from the roadside beacon.
  • a processing result transmitted back from the vehicle device to the roadside beacon is generated either from a vehicle-side program part of a main program stored in the vehicle device, which controls the reception of the identifier, or from a first subroutine stored in the vehicle device or from a stored in the vehicle device second subroutine.
  • the method according to the invention and the vehicle device according to the invention thus realize the only general inventive idea, which is to provide the execution of a first subroutine as an alternative to the execution of a vehicle device side program part of the main program or of a second subroutine.
  • the invention sees in this sense in each case the execution a first subroutine, unless on the one hand the alternative embodiment in the form of a vehicle-body-side program part of the main program or on the other hand a second subroutine is displayed.
  • a first value of the first identifier is preferably already stored in a memory of the vehicle device prior to receipt of the value of the received identifier, for example in an index file comprising a plurality of different vehicle device side pre-stored values of identifiers of the same type, including the first value of the first Identifier counts.
  • a roadside beacon is understood as meaning any DSRC transceiver module which is immovably stationary (for example on a control bridge spanning the road) or temporarily mobile (for example in / on a control vehicle) on, on, above or next to a traffic surface which is connected to a traffic control surface Vehicle can be traveled, at a distance to the vehicle, which allows a DSRC communication.
  • a distance depending on the intended range in the range of a few centimeters to a few hundred meters.
  • the program memory according to the invention may be comprised by the DSRC communication module, or by another component of the vehicle device, for example a vehicle device, which is coupled via a communication link to the DSRC communication module.
  • each vehicle device with a DSRC communication module according to the invention whose DSRC communication module is configured to carry out both of the methods according to the invention for DSRC communication as well as each of the embodiments of the inventive method described below.
  • the following embodiments of the invention are written based only on the first aspect of the method according to the invention, these embodiments are also transferable to the second aspect of the products according to the invention.
  • the features of the method-related embodiments are to be interpreted as a change of the claim category to the second aspect of the products according to the invention by comprising components for carrying out the corresponding embodiment of the product according to the invention and / or components of the product according to the invention are formed, the implementation of the corresponding embodiments to ensure.
  • embodiments of at least one of the methods according to the invention provide that this method according to the invention further comprises returning to a first receive ready routine of an initialization phase of the main program after transmission of the processing result message.
  • embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the subroutine to be executed is determined by the processor as part of instructions of the main program from at least one index file stored in the vehicle device, the at least one identifier associated with the first link Subroutine or a second subroutine contains.
  • the received identifier is preferably compared with at least one identifier of the index file, which is linked with a reference to at least the first subroutine.
  • the link comprises a jump address which refers to a program memory part of the vehicle device containing the first subroutine or the second subroutine.
  • an index file is not mandatory for checking whether a vehicle-device-side program part of the main program is associated with the received identifier.
  • the (main program) identifier associated with the vehicle body side program part of the main program may be stored in the main program itself. Only in the case where the received identifier does not correspond to the main program identifier are instructions of the main program executed by the processor which searches the index file for a value matching the value of the received identifier of the identifier associated with the first subroutine.
  • no index file is mandatory for checking whether the first subroutine is assigned to the received identifier.
  • the first identifier associated with the first subroutine may be stored in the main program itself. Only in the case where the received identifier does not correspond to the first identifier, instructions of the main program are executed by the processor which puts the index file in one with the Value of the received identifier searches matching value of the identifier associated with the second subroutine.
  • Embodiments of at least one of the inventive methods or at least one embodiment mentioned above provide that the receive ready routine is comprised of an initialization phase of the main program, the identifier comprises a service identifier, and the first subroutine or a second subroutine is associated with the service identifier, and wherein after step a) and before step b) exiting the initialization phase of the main program to continue the initialization phase by means of the first subroutine or the second subroutine.
  • Embodiments of at least one of the inventive methods or at least one embodiment mentioned above provide that the request message is received by the DSRC communication module in an initialization phase of the main program and includes a Bakendienstendienstabelle comprising the identifier in the form of a service identifier, and wherein the response message in the Initialization phase of the main program or a first or second sub-program is sent and contains a vehicle service table that includes the processing result.
  • the determination of at least one of the received identifier associated, stored in the vehicle device, first or second subroutine runs in the context of instructions of the main program, which are assigned to a receiving ready routine comprehensive initialization phase of the main program.
  • developments of one of the two aforementioned embodiments provide, in a first variant, that at least one of the inventive methods by carrying out a receive ready routine of a stored in the vehicle device first subroutine by a processor of the DSRC communication module, receiving a sent from a roadside beacon request message, the Element identifier by a DSRC transceiver operatively coupled to the processor of the DSRC communication module; transmitting a response message comprising a processing result generated by the processor in response to the processing of the request message in response to the received item identifier by the DSRC transceiver to the roadside beacon, and between receiving and transmitting, further comprising: checking, by means of the processor, in the context of instructions of the first subroutine, whether the element identifier is associated with a vehicle device side program part of the first subroutine; if the vehicle identifier side program part of the first subroutine is assigned to the element identifier: executing the vehicle device side program part of the subroutine by the processor at least to generate the processing
  • an alternative second variant is provided with respect to the execution of a second subroutine, may be provided to the above-mentioned first variants of developments alternatively second variants of developments, the in contrast to the first variants, which provides for the alternative execution of the vehicle device side program part of the subroutine, which provide alternative execution of a second subroutine.
  • the determination of at least one of the received identifier associated, stored in the vehicle device, first or second subroutine does not run in the context of instructions of the main program, which are assigned to a receive ready routine comprehensive initialization phase of the main program may be provided in that the receive ready routine is comprised of a presentation phase of the main program, the identifier comprises an element identifier, and the first subroutine or a second subroutine is associated with the element identifier, and before the receive ready routine is executed, completing the initialization phase of the main program, and after step a) and before step b) the presentation phase of the main program to continue the presentation phase by means of the first subroutine or the second subroutine.
  • Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the first subroutine, the second subroutine and / or the first subroutine comprise / in their presentation phase (s) an attribute data set or by the processor when executing the first subroutine , the second subroutine or the subroutine in its presentation phase, and that the processing result message is created in dependence on the attribute data set and / or comprises the attribute data record.
  • a further development of this embodiment further provides for performing a DSRC transaction based on the attribute record, the DSRC transaction providing at least one prestored attribute so that the provided attribute can be read by means of the beacon; and / or receiving a new attribute from the beacon and dropping the attribute in a memory of the vehicle device.
  • Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the DSRC communication is compliant with at least one of the following standards: EN 15509, EN ISO 14906, Cen ISO / TS 12813, Cen ISO / TS 13141, EN 12834.
  • embodiments of at least one of the methods of the invention or at least one embodiment mentioned above may further include receiving a subroutine and an identifier by means of a cellular communication module of the vehicle device, executing a program loader having (a) placing the subroutine in the program memory, and (b) adding comprising an indication of the subroutine in an index file associated with the identifier, and using the index file to determine the first or second subroutine associated with the received identifier.
  • At least one of the vehicle devices according to the invention may be provided such that this vehicle device comprises a mobile radio communication module which is connected to a processor of the vehicle device and a memory containing a program loader, wherein the processor is configured to be instructed by a message received by the cellular communication module to execute the program loader, the execution of which configures the processor to receive a message received by the cellular communication module an identifier associated subroutine in the program memory of the vehicle device and add a linked to the identifier hint to the subroutine index file to read the processor of the DSRC communication module by the execution of instructions of the main program for determining the received identifier associated with the first or second Subprogram is configured.
  • the main program exists and runs completely independently of the subroutines. If a subroutine for a received identifier can not be determined from the index file, the main program may configure the processor of the DSRC communication module to send a corresponding unavailability response to the beacon and then switch to a final phase and / or back into the receive ready routine.
  • the processor of the memory of the vehicle device may be the already mentioned processor of the DSRC communication module; Instead, it can also be provided by a vehicle device in addition to the already mentioned processor of the DSRC communication module, wherein the vehicle device, like the DSRC communication module, is included in the vehicle device and coupled to the DSRC communication module via a communication link.
  • the memory of the vehicle device may be the already mentioned program memory; but it may instead be another memory provided in addition by the DSRC communication module or a vehicle device which, like the DSRC communication module, is included in the vehicle device and coupled to the DSRC communication module via a communication link.
  • Storing the subprogram in the program memory involves both copying or moving the subroutine into the program memory and, alternatively or optionally, installing the subprogram in the program memory.
  • the subprogram received by the mobile radio communication module may initially be present in the main memory of the processor in the form of an installation routine for the subroutine or may be received as such from the mobile radio communication module.
  • subroutine associated with the identifier any type of information that enables the subroutine to be found. Such an indication can be understood to mean the name of the subroutine, a jump address to a storage location of the subroutine, or any other link pointing to the subroutine.
  • the shows Fig. 1 schematically and exemplarily a block diagram of an electronic toll collection system 10.
  • the DSRC communication is used in particular between a vehicle device (OBE) 11 and a beacon (RSE) 12.
  • OBE vehicle device
  • RSE beacon
  • the vehicle device 11 is carried in a vehicle that enters in a vicinity of the beacon 12.
  • the size of the near zone is essentially limited by the DSRC technology itself.
  • Via the DSRC communication between the vehicle device 11 and the beacon 12 for example, data is exchanged that is relevant to a payment service, as is typical, for example, for toll collection purposes.
  • the vehicle device 11 can be connected to a central system 13, which can be operated by a so-called OBE provider.
  • This connection can be, for example, a connection via a conventional mobile radio network, for example a GSM, a UMTS, a GPRS, an EDGE, an LTE or another mobile radio network.
  • a configuration and / or a personalization of the vehicle device 11 can take place via the connection between the central system 13 of the OBE provider and the vehicle device 11.
  • a configuration is understood to mean the assignment of the vehicle device identity to a vehicle identity, which can be identified, for example, by the assignment of at least one vehicle identifier (eg vehicle license plate number and / or insurance number of the vehicle) to at least one OBE license.
  • Identification eg serial number or mobile number of the vehicle device 11 (OBE) in a decentralized data memory of the vehicle device and / or in a central data memory of the OBE provider include or imply toll-relevant vehicle data (eg, number of axles, pollutant class, permissible total weight, etc.) for the OBE identifier.
  • a personalization is understood to mean the assignment of the vehicle device identity to a user identity, which can be determined, for example, by the assignment of at least one user identifier (eg customer number and / or means of payment of the customer (credit card number, account number. ) to at least one OBE identifier (eg serial number or mobile number of the vehicle device 11 (OBE) in a decentralized data memory of the vehicle device and / or in a central data memory of the OBE provider. since only a registered user is authorized to initiate or execute a configuration on a vehicle device (OBE) personalized by means of his registration.
  • OBE vehicle device
  • the beacon 12 may be connected to another central system 14, which is operated by a toll operator, a so-called toll charger.
  • the connection between the beacon 12 and operated by the toll operator central system 14 may be configured as desired, for example, be configured wired and / or done via a mobile network.
  • the beacon 12 forwards data to the toll system operated central system 14.
  • the central system 13 operated by the OBE provider may be connected to the central system 14 operated by the toll operator, as described in US Pat Fig. 1 is illustrated schematically, this connection can be configured arbitrarily.
  • the central system operated by the OBE provider and the central system operated by the toll operator can also be understood as a common system.
  • the in the Fig. 2 Vehicle device 11 shown comprises a DSRC communication module 50, which is designed for communication with a beacon 12.
  • the DSRC communication module 50 includes a DSRC transceiver 51 configured to transmit and receive data in accordance with the DSRC communication. Furthermore, a program memory 53 is provided in the DSRC communication module 50, on which a certified main program can be stored.
  • the program memory 53 may be a first program memory and the DSRC communication module 50 may also include a second program memory, which is not shown in the figures, however
  • a processor 52 is operatively coupled to both the program memory 53 and the DSRC transceiver 51.
  • the processor 52 is in particular designed to execute the certified main program stored on the program memory 53 and to use the DSRC transceiver 51 for these purposes, and in particular to perform the DSRC communication with the beacon 12.
  • the processor 52 may be a separate processor that performs substantially only for the processes of the DSRC module 50.
  • the vehicle device 11 may include an OBU (on-board unit, also not shown) communicatively coupled to the DSRC communication module 50 with an OBU processor, which may, for example, store position data that it receives from a position determination device (for example, a GNSS device). Receiver of a Global Navigation Satellite System (GNSS)) of the vehicle device 11 receives, processed with the result, to detect the driving on a toll road.
  • the vehicle device may comprise a mobile radio communication module which is communicatively coupled to the DSRC communication module 50 and / or the OBU.
  • the mobile communication module may be comprised of the OBU and / or the DSRC communication module.
  • OBU and position determining device may comprise a common housing and preferably be arranged on a common circuit board. However, they can also each be covered by a separate housing, wherein the communication between them can be wired or wireless (eg by means of W-LAN or Bluetooth).
  • the vehicle device 11 is occasionally also referred to as "OBE" for a short time.
  • a flowchart of exemplary DSRC communication is schematic and exemplary in the Fig. 3 illustrated. This exemplary method will be explained in more detail below.
  • the DSRC communication takes place between the beacon on the one hand (RSE - left side) and the vehicle device (OBE - right side) on the other.
  • RSE - left side the beacon on the one hand
  • OBE - right side the vehicle device
  • the two vertical axes in the Fig. 3 the passage of time.
  • a DSRC communication as used in the Fig. 3 is shown as an example, can be roughly divided into a so-called initialization phase 2.0, in a so-called Presentation Phase 3.0, in a so-called Receipt Phase 4.0 and in a so-called Release & Closing Phase 5.0.
  • the initialization phase 2.0 may include a first receive ready routine of a main program stored in the program memory 53 of the DSRC communication module 50 by a processor 52 of the DSRC communication module 50.
  • the main program can be a certified main program.
  • the vehicle device 11 continuously executes the initialization phase 2.0 of the main program, which is stored on the program memory 53 of the vehicle device 11.
  • the initialization phase of the main program comprises the execution of measures of the processor 52 and / or the provision of functionalities of the vehicle device 11, with which prior to the receipt of a first request message from the beacon 12 (RSE) the readiness of the vehicle device 11, in particular the DSRC communication module 50 be ensured for the receipt of such a request message.
  • the execution of the initialization phase by the vehicle device OBE on a so-called index file 7.0 (see. Fig. 4 ), which may also be stored on the program memory 53 of the vehicle device OBE.
  • the DSRC communication module 50 starts a DSRC transaction via a (in the Fig. 3 not shown, s. Fig. 4 ) Program entry 1 with the above briefly explained initialization phase 2.0 in which initially only one reception standby routine of the main program is executed to the Vehicle device 11 for a request message from the beacon 12 receptive form.
  • the initialization phase 2.0 may include a continuous transmission of a request message (INITIALIZATION.request).
  • This request message may include a Bakendienstendiensttable, also called Beacon Service Table (BST).
  • BST Beacon Service Table
  • the request message may include an identifier that may be included in the bakery service table, such as a service identifier, also referred to as an application identifier (AID), and / or an item identifier, also referred to as an item identifier (EID).
  • AID application identifier
  • EID item identifier
  • the bakery service which may be identified by the AID, may be a tolling service for the purposes of toll collection (eg value of AID equal to 1), a support bakery service for purposes of location determination (eg. Value of the AID equals 21) and / or a monitoring service for the purposes of checking for a country-specific registration (eg value of AID equal to 20). More detailed information on the possible services can be found in the standards mentioned above.
  • the vehicle device 11 can receive this request message by means of the DSRC transceiver 51.
  • the vehicle device returns OBE with a reply message (INITIALIZATION.response) and transmits a so-called vehicle service table, also referred to as a vehicle service table (VST), in the context of this reply message.
  • This VST contains identified service elements, for example all service elements, for example by means of element identifier EID, which are supported by the DSRC module 50.
  • the BST does not yet include an EID.
  • a selection of operable EIDs may be sent to the beacon 12 by the vehicle device 11, such as by transmitting the VST, for example as part of the VST.
  • the beacon then sends the EID to the on-board unit for which it would like to receive further information from the on-board unit.
  • a service element identified by an EID may be a country or region-specific toll service contract and / or toll transaction type in the case of an AID identifying a tolling service.
  • the DSRC communication module 50 can respond to the received beacon BST with the VST.
  • beacon BST a particular service identifier AID from beacon 12 may be requested.
  • the beacon 12 searches, for example, a so-called ContextMark with an associated element identifier EID, with which the beacon 12 wants to continue to communicate.
  • the DSRC communication can be based on the EID determined in the initialization phase 2.0.
  • the beacon 12 queries with the determined EID further attributes of the vehicle device 11 and receives from the DSRC communication module 50 is a so-called presentation response, such as said GET_STAMPED.response.
  • the beacon 12 requests the vehicle device 11 by means of a so-called GET_STAMPED.request message and / or as part of a so-called GET.request message, itself and some static data (for example, values of so-called attributes in the form of Attribute data summarized in an attribute data set) of the vehicle device 11.
  • This static data which the beacon 12 can query during the presentation phase of the vehicle device 11, may relate in particular to a payment service.
  • the static data may identify the vehicle itself, such as the dimensions of the vehicle, the registration number of the vehicle, weight information on the vehicle, axle information, etc.
  • the vehicle device 11 provides this data as part of a GET_STAMPED.response message and / or as part of a GET.response message to the beacon 12.
  • 3.0 authentication of the vehicle device OBE take place.
  • the beacon 12 After this presentation phase 3.0, the beacon 12 has collected enough information from the vehicle device 11 to perform the payment process. Presentation phase 3.0 is followed by a so-called Receipt phase 4.0. During this phase 4.0, the beacon 12 may write data to the vehicle device 11 ("Write.data"), for example into the said program memory 53. Such data may be used, for example, in a DSRC communication with a next beacon are taken into account, which is passed by the vehicle in which the vehicle device 11 is carried.
  • Data may be used, for example, in a DSRC communication with a next beacon are taken into account, which is passed by the vehicle in which the vehicle device 11 is carried.
  • a DSRC communication can end with a so-called Tracking & Closing - Phase 5.0.
  • the essential data exchange between the beacon 12 and the vehicle device 11 has already taken place and the transaction in question can no longer fail.
  • the vehicle device 11 is informed by the beacon 12 essentially only that no further data is sent from the beacon 12 to the vehicle device 11 or that the vehicle device 11 has no further data to send to the beacon 12.
  • Exemplary DSRC communication comprises in particular a so-called CARDME transaction.
  • the data which in particular the vehicle device 11 transmits to the beacon 11 during the presentation phase 3.0 may be data concerning a payment service
  • the main program stored on the program memory 53 of the Vehicle device it is stored 11 is certified.
  • the certification of the main program expresses that the main program complies with the specifications of the institutions involved in the payment process, for example the central system operated by the toll operator and / or the specifications of the central system operated by the OBE provider, as well as with the requirements of the respectively relevant standards, for example EN ISO 14906 and / or EN 15509 compliant.
  • the problems with this is that the specifications of, in particular, the institutions involved in the payment process may change and / or new specifications from new institutions should be added to the transaction functionality of the vehicle equipment. Specifically, for example, the specifications of different toll operators from different countries may differ from each other. If, however, the requirements of the participating institutions change, it may also be necessary to adapt the course of the main program. However, since an adjustment may result in a change in the main program, a re-certification of the main program must be performed after such a change of the main program, which may be cumbersome. On the other hand, there are still no generally valid certification tests.
  • new attributes are required for a DSRC communication, for example because a toll operator has changed his specifications and / or because a new toll operator has been added, the following problems may specifically arise: For example, new attributes in the program structure of the certified main program are unknown and can not be adjusted by further parameters. It is also possible that new, so-called state table functions or security functions for the DSRC communication module 50 may be added by a toll operator or by another institution, for example because they are needed for a particular DSRC communication.
  • the initialization phase 2.0 may, as stated, include a first receive ready routine of a main program stored in the program memory 53 of the DSRC communication module 50 by a processor 52 of the DSRC communication module 50.
  • This initialization 2.0 can be part of the Main program, which is stored on the program memory 53, be.
  • the main program can be a certified main program.
  • the processor 52 performs this initialization phase 2.0, e.g. based on an index file 7.0 likewise stored in the program memory 53, although this does not necessarily have to be the case.
  • the initialization phase can also be executed independently of the index file 7.0.
  • the DSRC communication module 50 receives, by means of the DSRC transceiver 51, the request message that the beacon 12 previously transmitted.
  • the request message comprises an identifier AID, which may, for example, be contained in a Bakendienstendiensttabelle BST of the request message.
  • the in-vehicle device 11 processes the request message and, after processing the request message, sends a processing result message to the beacon 12. In between, for example, within the processing of the request message, the vehicle device 11 performs certain steps, which will be presented in more detail below.
  • the processor 52 uses the index file 7.0 to determine at least one of the jump addresses assigned to the identifier.
  • the access of the processor 52 in the context of instructions of the initialization phase 2.0 of the main program to the index file 7.0 and the receipt of the jump address are indicated by dashed arrows in Fig. 4 shown.
  • the at least one jump address refers to a program memory part of the vehicle device 11, which contains a subroutine, for example a reloaded reduced initialization phase 2.3 of a first subroutine or a reloaded reduced initialization phase 2.4 of a second subroutine, none of these subroutines being part of the main program.
  • the identifier that the beacon 12 has sent out results in a branch from the main program if the identifier is not assigned a program part of the main program.
  • This can be understood as parameter-dependent program branching in real time, the parameter that determines the program branch being an identifier that is sent from the beacon 12 and received by the vehicle device 11.
  • the initialization phase of the subprograms can be said to be reduced because it lacks the receive routine and the branch routine of the main program.
  • the processor 52 returns to the initialization phase 2.0 of the main program after the processing result has been sent to the beacon 12.
  • the data transmitted to the beacon 12 in the subsequent communication steps comprise processing results of the processor 52 which likewise depend on the service identifier AID to which no program part of the main program is assigned, so that the further processing steps of the initialization phase 2.3 or 2.4 and the subsequent phases are preferably also instructed or performed by the subroutine.
  • this is not mandatory, because in the subsequent presentation phase 3.0 a program branching out of the main program into a subprogram can again take place, which is determined by the identifier received by the beacon 12 in the presentation phase 3.0.
  • the identifier received in the initialization phase 2.0 may include a service identifier AID, and the at least one jump address may be associated with the service identifier AID.
  • the subroutine may include not only a recharged initialization phase 2.3, but also a recharged presentation phase 3.3 and / or a recharged receipt phase 4.3 and / or a recharged tracking & closing phase 5.3.
  • the processor 52 in the reloaded after execution of the initialization phase 2.3 Phases 3.3, 4.3. and 5.3 transitions to perform the DSRC communication with the beacon 12. All phases 3.3, 4.3 and 5.3 are outside the main program.
  • the subroutine will be certified according to the reloaded phases 2.3, 3.3, 4.3 and 5.3. However, this does not require that the default 2.0, 3.0, 4.0, and 5.0 phases of the main program be changed. In other words, the certification of the main program remains at phases 2.0, 3.0. 4.0 and 5.0 are also unaffected when reloading phases 2.3, 3.3, 4.3 and 5.3. The same applies mutatis mutandis to the subroutine with phases 2.4, 3.4, 4.4 and 5.4. It is possible to have additional subprograms connected at this point. This will be discussed in more detail below.
  • the initialization phase 2.0 is abandoned, in particular, if, as explained above, the transmitted identifier is a service identifier to which no program part of the main program is assigned.
  • the service identifier may be a so-called Application Identifier (AID).
  • AID Application Identifier
  • the standard EN ISO 14906 stipulates that 31 different AIDs can be addressed.
  • the processor 52 determines based on the another index file subroutine 3.1 and performs the call of the subroutine 3.1, which completes the presentation phase 3.1 vehicle equipment side in which its instructions configure the processor to generate another response message in the presentation phase 3.1 to the beacon and the DSRC transceiver 51 to send to the roadside beacon.
  • the answer includes the attributes of identification and classification of the vehicle.
  • the roadside beacon 12 performs a transaction based on the received data by assigning the vehicle a toll corresponding to its classification.
  • a receipt via this transaction is sent by the roadside 12 in the subsequent receipt phase 4.1 to the DSRC communication module 50, which in turn confirms the receipt in a reply message.
  • Tracking & Closing phase 5.1 the communication between beacon 11 and DSRC communication module 50 is completed.
  • Phase 5.1 ends the subroutine and moves to a final phase 6 of the main program. This objection is provided by the main program for each jump from the main program to a subroutine; that is, with one jump, the main program sets, for example, a pointer to the final phase 6.
  • This pointer passes it to the subroutine or writes it to a pointer file in the program memory 53 known to each subroutine.
  • the main program switches back to the receive ready routine of the initialization phase 2.0 to establish the readiness of the DSRC communication module 50 for the BST of the next beacon 12.
  • the second variant to which a flowchart based on Fig. 5 is shown schematically resembles in their basic idea of the first variant.
  • the processor 52 may proceed as follows: First, the request message is processed as part of instructions of the main program in a first processing process with the consequence of either: (a) initiating the execution of one in the first Program memory 53 or a second program memory of the DSRC communication module 50 stored first subroutine 2.3, which is not part of the main program, when the identifier received with the request message corresponds to a first identifier, or (b): the initiation of the execution of a second subroutine 2.4, which is not part of the main program, if the identifier received with the request message does not correspond to the first identifier.
  • the processor 52 may refrain from checking whether the request message requires use of a particular program part of the main program.
  • This variant is expedient, for example, if the main program essentially represents a program framework which, for example, substantially comprises only code for executing the initialization phase 2.0. Thus, if it is deposited on the vehicle device 11 that the request message can not be operated anyway with code of the main program, a pertinent examination is unnecessary.
  • the main program in this case by the obligatory access to a first index file 7.0, in which any possible value of the received identifier - in this case, the service identifier AID - with the jump address of the identifier associated subroutine is linked.
  • the processor 52 determines the first or second subroutine 2.3 or 2.4 to be executed.
  • the processor 52 can then proceed as follows: further processing of the request message in a second processing process following the first processing process in dependence on the received identifier, either in the context of instructions of the first subroutine 2.3 in case (a) or in the context of instructions of the second subroutine 2.4 in case (b); and generating the processing result message in or subsequent to the second processing process within instructions of the first subroutine or the second subroutine.
  • reception standby routine Since no presentation phase 3.0 is provided in the second variant, at least the reception standby routine always takes place after a response has been sent in the initialization phase 2.3 or 2.4 presentation phase to a presentation phase of the subprogram 3.3. or 3.4. In the following, it is assumed that the reception standby routine of the subroutine 3.3 is executed by the processor 52.
  • the processor takes in the context of instructions of the subroutine 3.3 a second index file 7.1 which first or second subroutine 3.5 or 3.6, depending on the received element identifier EID.
  • Such program modules can be identified by said element identifiers (EID).
  • the identifier transmitted by the beacon 12 may additionally or alternatively to the service identifier also comprise such an element identifier (EID).
  • the processor 52 may check whether a program part of the main program is allocated to the received element identifier (EID) or according to the second variant. If this is not the case, again a jump address assigned to the element identifier can be determined, this jump address referring to a program memory part of the vehicle device 11 which contains a further subroutine which is not part of the main program.
  • a program branch depending on a received element identifier for example, not already in the initialization phase 2.0, but only in the presentation phase 3.0 of the main program or in a reloaded presentation phase 3.3 of one of the reloaded subroutines.
  • the processor 52 determines that the service requested by the beacon 12 and identified by the service identifier AID is associated with a program portion of the main program, the processor 52 transmits said vehicle service table VST to the beacon via the DSRC transceiver 51 12 and goes into presentation phase 3.0.
  • the processor 52 checks to see if the received item identifier EID is still associated with a corresponding program part within the main program, according to the first variant.
  • the processor 52 can execute the presentation phase 3.0 by means of the main program and then proceed to the said receipt phase 4.0 and from there to the tracking & closing phase 5.0.
  • the test can proceed according to the second variant presented above. That is to say, the processor 52 does not necessarily have to execute program parts of the main program, but can always execute subroutines, which are not part of the main program, in order to serve the request of the beacon 12.
  • Which subroutine to execute may be predetermined by said identifier emitted by the beacon 12 (eg an AID and / or an EID).
  • both the service identifier AID and the element identifier EID may be stored, for example in the form of jump addresses, at which storage location the relevant subroutine is located.
  • the processor 52 determines from another, for example Index file 7.1 a jump address associated with the received element identifier EID which, for example, points to a first subroutine (first variant) or a second subroutine (second variant) comprising reloaded program code for a presentation phase 3.1.
  • the jump address may also refer to another subroutine that includes reloaded program code for a different presentation phase, and so on.
  • the item identifier sent by the beacon 12 does not carry any program portion of the main program (corresponding to the first variant) or first subroutine (corresponding to FIG the second variant) is assigned to a program branching on the side of the vehicle device 11.
  • This type of branching can also be understood as a real-time program branching.
  • no Receipt phase 4.0 and no Tracking & Closing phase 5.0 are provided in the main program, because the second variant is based on leaving the main program at least in the cases in which the vehicle device at all to support a DSRC communication in Reference to the received identifier provided.
  • the subroutines for example the subroutine with the phases 3.1, 4.1 and 5.1, the subroutine with the phases 3.2, 4.2 and 5.2, the subroutine with the phases 2.3, 3.3, 4.3 and 5.3 and / or the subroutine with the phases 2.4, 3.4 , 4.4 and 5.4 can each be certified separately from one another and in particular independently of the main program, without the reloading and recertification of the subprograms being accompanied by a certification loss of the main program with phases 2.0, 3.0, 4.0 and 5.0.
  • the processor 52 can access an index file 7.0 stored in the program memory 53.
  • the jump addresses are stored within this index file 7.0.
  • a program loader for adding subroutines in the program memory 53 of the vehicle device 11, a program loader, in short: program loader, 8.0 may be provided.
  • An embodiment provides that the program loader 8.0 with a processor is executed, which need not necessarily be the processor 52 of the DSRC communication module 50, but for example, a processor of a connected to the DSRC communication module vehicle device (OBU) may be.
  • OBU DSRC communication module vehicle device
  • the program loader 8.0 copies or installs, for example, the new subroutine received in the program memory 53 with the instructions and an identifier AID or EID from the center 13 and supplements the index file 7.0 or 7.1 for a new reference, for example a new jump address, to this new subroutine associated with the identifier AID or EID to which this new subroutine is associated.
  • said program loader 8.0 can be provided, which can be operated via a Human Machine Interface (HMI) 57.
  • HMI Human Machine Interface
  • About the program loader 8.0 can be said in particular in the Fig. 4 . 5 and 6 schematically illustrated subroutines and subroutines are loaded into the program memory a working memory, but without affecting the possibly certified main program or subroutine.
  • the certification of the main program does not include certification of the index file 7.0.
  • the index file 7.0 can be supplemented by said jump addresses, without this leading to a certification loss of the main program.
  • the added program code of the subprograms can be stored, for example, in said program memory 53.
  • the program memory may include a main memory for storing the main program.
  • the reloaded program code of the subroutines can be stored.
  • the added program code of the subroutines can also be stored in another memory or in another memory part, for example in a memory of a vehicle device, which is included in the vehicle device 11 as well as the DSRC communication module 50, the vehicle processor with the processor 52 DSRC Communication module 50 is coupled via a communication link.
  • the DSRC communication module 50 may include a random access memory (not shown in the figures) that may also be part of, or implemented separately from, the program memory 53.
  • the initialization phase 2.0 will first pass through completely and the program branching will take place only in the context of the presentation phase 3.0. If the program is in this phase and the processor 52 receives an unknown EID at this point, the processor 52 calls the index file 7.0 and uses the index file 7.0 to determine the jump address associated with the new EID. These Jump address then points, for example, to the subprogram with the reloaded presentation phase 3.1 or to the subprogram with the reloaded presentation phase 3.2 or to another subprogram.
  • the beacon 12 sends the EID in the context of the presentation phase 3.0, for example, with the request message GET_STAMPED.request or with the request message GET.request.
  • the program branching out of the main program if the received EID no program part is assigned in the main program.
  • said subroutines can be added ("reloaded") to the program memory 53 of the vehicle device in non-time critical situations, for example when the vehicle is not being moved and has a stable communication link to the central system 13 of the OBE provider.
  • the addressing for the reloaded subroutines for example, by means of the corresponding programmed index file 7.0 or 7.1. This addition to index file 7.0 or 7.1 does not cause a certification loss of the main program.
  • a number of customary transaction parameters are transmitted, for example a so-called logical link control identifier LID.
  • a number of customary transaction parameters are preferably also transferred, for example said logical link control identifier LID.
  • the Fig. 4 illustrates branches to a total of four subroutines. Of course, more or fewer than four subroutines can be provided. For example, if only one new service identifier AID is added to the main program, one branch will suffice for the subroutine with phases 2.3, 3.3, 4.3 and 5.3. According to the embodiment of the Fig. 4 Each of the four subroutines includes its own recharged receipt phase 4.1, 4.2, 4.3 or 4.4 and its own recharged Tracking & Closing phase 5.1, 5.2, 5.3 and 5.4 respectively. All Tracking & Closing Phases 5.0 through 5.4 result in a proper completion 6 of the DSRC communication.
  • the processor 52 performs the phase 3.1 jumps out of this according to the above presented first or second variant in the phase 3.2, 3.3 or 3.4. Even during the execution of phases of the reloaded subroutines, situations may arise in which a request of the beacon 12 can not be served by the further execution of the currently executed subroutine, but a jump to another subroutine may be necessary, this jump corresponding to one the variants presented above can take place.
  • processor 52 may re-certify the initialization phase 2.0 of the DSRC communication after completing the DSRC communication Main program.
  • processor 52 may re-certify the initialization phase 2.0 of the DSRC communication after completing the DSRC communication Main program.
  • the processor 52 can be designed to use the main memory for buffering data and / or code for the purpose of executing program code of the main program and / or of added program code of the subroutines. For example, all subroutines or subroutines most recently used, subroutines most often used, subroutines identified by comparison of received position data, labeled with corresponding geographic data, etc., may have one or more selected subroutines whose location is known by the persistent index file in loading the main program from the program memory 53 into the main memory of the processor 52 or as a result of executing a start routine of the main program which precedes the reception standby routine, also from the program memory 53 are loaded into the working memory.
  • the main program creates in memory a temporary index file, which is called by the main program first when an identifier is received which requires the execution of a subroutine.
  • the subroutine can be called up and executed much more quickly than if it had to be reloaded from the program memory (53). If the received identifier does not coincide with any identifier of the temporary index file, it will result in succession is called into the persistent index file stored in the program memory 53 and searched for a matching identifier.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Traffic Control Systems (AREA)
EP14200173.4A 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC Active EP3038062B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP14200173.4A EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP14200173.4A EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Publications (2)

Publication Number Publication Date
EP3038062A1 true EP3038062A1 (fr) 2016-06-29
EP3038062B1 EP3038062B1 (fr) 2021-09-01

Family

ID=52134047

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14200173.4A Active EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Country Status (1)

Country Link
EP (1) EP3038062B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111599168A (zh) * 2020-04-01 2020-08-28 广东中科臻恒信息技术有限公司 基于路侧单元的道路交通信息采集方法、设备、存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1385126A1 (fr) * 2002-06-25 2004-01-28 DaimlerChrysler AG Dispositif d'estimation de frais d'usage et système de perception de frais
WO2006015792A1 (fr) * 2004-08-06 2006-02-16 Daimlerchrysler Ag Systeme, terminal embarque et centrale exterieure a un vehicule pour le prelevement de droits de peage routier
EP1630747A2 (fr) * 2004-08-31 2006-03-01 Fela Management AG Système et méthode de perception des droits de péage
DE102005055835A1 (de) * 2005-11-23 2007-05-24 Siemens Ag Verfahren zum Betreiben einer mobilen Detektionseinheit (OBU) in Geltungsbereichen unterschiedlicher Mauterfassungssysteme
EP2360646B1 (fr) 2010-01-29 2012-06-06 Kapsch TrafficCom AG Procédé de communication DSRC
EP2602767B1 (fr) 2011-12-05 2013-12-04 Kapsch TrafficCom AG Procédé et unité à bord destinés à la signalisation de transactions de péage dans un système de péage routier

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1385126A1 (fr) * 2002-06-25 2004-01-28 DaimlerChrysler AG Dispositif d'estimation de frais d'usage et système de perception de frais
WO2006015792A1 (fr) * 2004-08-06 2006-02-16 Daimlerchrysler Ag Systeme, terminal embarque et centrale exterieure a un vehicule pour le prelevement de droits de peage routier
EP1630747A2 (fr) * 2004-08-31 2006-03-01 Fela Management AG Système et méthode de perception des droits de péage
DE102005055835A1 (de) * 2005-11-23 2007-05-24 Siemens Ag Verfahren zum Betreiben einer mobilen Detektionseinheit (OBU) in Geltungsbereichen unterschiedlicher Mauterfassungssysteme
EP2360646B1 (fr) 2010-01-29 2012-06-06 Kapsch TrafficCom AG Procédé de communication DSRC
EP2602767B1 (fr) 2011-12-05 2013-12-04 Kapsch TrafficCom AG Procédé et unité à bord destinés à la signalisation de transactions de péage dans un système de péage routier

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111599168A (zh) * 2020-04-01 2020-08-28 广东中科臻恒信息技术有限公司 基于路侧单元的道路交通信息采集方法、设备、存储介质

Also Published As

Publication number Publication date
EP3038062B1 (fr) 2021-09-01

Similar Documents

Publication Publication Date Title
DE4134922C1 (fr)
EP2833329B1 (fr) Procédé et système destinés à améliorer un processus de stationnement payant de véhicule dans une installation de parking, programme informatique et produit-programme informatique
WO2009049859A2 (fr) Procédé d'exécution d'une opération de stationnement au moyen d'un appareil de téléphonie mobile
EP2913989B1 (fr) Liaison d'un terminal à un dispositif mobile pour l'attribution de frais
WO2015185405A1 (fr) Procédé et dispositifs d'exploitation d'un système de parc de véhicules
EP1866872A1 (fr) Procede et dispositif d'enregistrement automatique de trajet
DE19925254A1 (de) Verfahren zum Betrieb einer Kommunikationsanordnung
WO2019096840A1 (fr) Procédé et système pour mettre à jour un logiciel de véhicule
EP2500869A1 (fr) Procédé de mise à disposition de services de données en fonction du lieu
DE102015203929A1 (de) Aktualisierung von Kartendaten einer Navigationsvorrichtung für Fahrzeuge
EP3038062B1 (fr) Procédé et dispositifs de véhicule pour communication DSRC
WO2013139455A1 (fr) Procédé pour afficher des places de stationnement
EP3242206A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
DE202014106268U1 (de) Fahrzeugeinrichtungen zur DSRC-Kommunikation
EP1702199B1 (fr) Mise en service d'une application chez un client mobile
WO2017220307A1 (fr) Mise à jour d'une carte numérique
DE102016217890A1 (de) Verfahren und Vorrichtung zum Verwenden eines elektronischen Führerscheines
EP3242205A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
EP3188133B1 (fr) Dispositif de traitement de donnees de position et systeme de peage et procede de fonctionnement d'un dispositif de traitement de donnees de position et d'un systeme de peage
EP2059916B1 (fr) Terminal mobile pour un système d'information routière et procédé pour activer un dispositif de contrôle d'accès dans un terminal mobile
DE102017205276A1 (de) System und Verfahren zur automatischen Erkennung einer technischen Aktion eines Fahrzeugs
DE102021121896A1 (de) Anpassen einer einen Ladevorgang betreffenden Eigenschaftsinformation
DE102016209684A1 (de) Verfahren zur Aktualisierung einer Software eines Landfahrzeuges, Aktualisierungsvorrichtung und Übertragungssystem
DE102020200324A1 (de) Verfahren zur Zugangskontrolle sowie Zugangskontrollsystem
EP3346451B1 (fr) Procédé destinés au suivi de véhicules assujettis au péage dans un système de péage et un système de péage correspondant

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): AL 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 RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161213

RBV Designated contracting states (corrected)

Designated state(s): AL 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 RS SE SI SK SM TR

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20181008

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20210303

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL 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 RS 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

Ref country code: AT

Ref legal event code: REF

Ref document number: 1427025

Country of ref document: AT

Kind code of ref document: T

Effective date: 20210915

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502014015841

Country of ref document: DE

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: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20210901

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: 20210901

Ref country code: RS

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: 20210901

Ref country code: SE

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: 20210901

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: 20211201

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: 20210901

Ref country code: NO

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: 20211201

Ref country code: ES

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: 20210901

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: 20210901

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 FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

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: 20210901

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: 20211202

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

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: 20220101

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: 20210901

Ref country code: SK

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: 20210901

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: 20210901

Ref country code: PT

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: 20220103

Ref country code: NL

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: 20210901

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: 20210901

Ref country code: CZ

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: 20210901

Ref country code: AL

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: 20210901

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502014015841

Country of ref document: DE

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

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: 20210901

Ref country code: IT

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: 20210901

Ref country code: DK

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: 20210901

26N No opposition filed

Effective date: 20220602

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

Ref country code: SI

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: 20210901

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: 20211223

Ref country code: IE

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

Effective date: 20211223

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

Ref country code: HU

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

Effective date: 20141223

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

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: 20210901

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20231207

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

Ref country code: GB

Payment date: 20231220

Year of fee payment: 10

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

Ref country code: FR

Payment date: 20231219

Year of fee payment: 10

Ref country code: DE

Payment date: 20231214

Year of fee payment: 10

Ref country code: AT

Payment date: 20231214

Year of fee payment: 10

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

Ref country code: BE

Payment date: 20231218

Year of fee payment: 10

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

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: 20210901

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

Ref country code: CH

Payment date: 20240110

Year of fee payment: 10