EP2646994B1 - Fahrzeugkommunikation - Google Patents

Fahrzeugkommunikation Download PDF

Info

Publication number
EP2646994B1
EP2646994B1 EP20110799261 EP11799261A EP2646994B1 EP 2646994 B1 EP2646994 B1 EP 2646994B1 EP 20110799261 EP20110799261 EP 20110799261 EP 11799261 A EP11799261 A EP 11799261A EP 2646994 B1 EP2646994 B1 EP 2646994B1
Authority
EP
European Patent Office
Prior art keywords
vehicle
message
target vehicle
svid
identifier
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.)
Active
Application number
EP20110799261
Other languages
English (en)
French (fr)
Other versions
EP2646994A1 (de
Inventor
Roderick Whitlock
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.)
Tracker Network UK Ltd
Original Assignee
Tracker Network UK Ltd
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 Tracker Network UK Ltd filed Critical Tracker Network UK Ltd
Publication of EP2646994A1 publication Critical patent/EP2646994A1/de
Application granted granted Critical
Publication of EP2646994B1 publication Critical patent/EP2646994B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/205—Indicating the location of the monitored vehicles as destination, e.g. accidents, stolen, rental
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams

Definitions

  • the present invention is in the field of vehicle communications and particularly, but not exclusively, it relates to communications between vehicles for the purposes of information propagation.
  • a "vehicle” can be any kind of motor vehicle, such as a car, lorry, motor cycle, train, coach or ship.
  • a vehicle can be any kind of container, which may be carried, for example, by any kind of motor vehicle.
  • a vehicle can be any movable object, including inanimate objects and also humans and animals, in or on which a communications unit of the kind described herein may be mounted or carried.
  • Some embodiments of the present invention find application in the field of stolen vehicle recovery (SVR). Some other embodiments of the invention find application in vehicle recall, for example, when a vehicle manufacturer needs to recall a make of motor vehicle to fix a fault. Other embodiments of the invention relate to vehicle status determination.
  • SVR stolen vehicle recovery
  • FIG. 1 A generally known SVR system is illustrated in FIG. 1 .
  • One kind of commercially available SVR product is TRACKER LocateTM, produced and sold by TRACKER Network (UK) Limited.
  • a vehicle-mounted transceiver unit VMTU
  • VMTU vehicle-mounted transceiver unit
  • a central SVR control system 100 can communicate with and activate the VMTU (not shown) of the stolen vehicle 115 via a cellular network of radio transmitters 105, 110.
  • the communications for activating a VMTU may employ a suitable kind of wireless communications, for example, GSM, GPRS or UMTS, to name only a few options, and may employ cellular technology of the kind typically associated with mobile telephone handsets.
  • US6792351 discloses a method and apparatus for multi-vehicle communication in which a message that is received at a vehicle may be relayed to other vehicles.
  • the present invention provides a communications apparatus for a vehicle, the apparatus comprising:
  • 'propagate' means that a message source can over time communicate a message to multiple destinations, whereby each destination can over time communicate the message on to multiple other destinations, and so on.
  • Each message source may communicate the same message a plurality of times, for example, repeatedly, periodically, aperiodically, randomly or in response to a trigger of some kind, so that, over time, plural different destinations have the opportunity of receiving the message.
  • Such communications can also be referred to as 'viral communications'.
  • an SVR embodiment of the invention dispenses with a cellular network of radio towers. Radio communications are replaced in this embodiment with optical communications. SVR messages are communicated virally to optical VMTUs (OVMTUs) either by initiation points or by OVMTUs mounted on or in other vehicles. According to the embodiment, each OVMTU handles SVR messages according to basic logic, which takes the form:
  • the nature of the message is determined by the result of the comparison between the target vehicle identified in the received message and the identity of the vehicle in which the OVMTU is mounted.
  • the target vehicle identified in the received message is determined by the result of the comparison between the target vehicle identified in the received message and the identity of the vehicle in which the OVMTU is mounted.
  • at least a target vehicle identifier would be expected to appear in both kinds of message.
  • a central computer system 200 is in communication with at least one initiation point 210 via a network 205.
  • the central computer system 200 is, for example, a PC-based system operating under a WindowsTM operating system and performing SVR operations according to SVR application software.
  • an operator of the central computer system 200 may receive a message from an owner of a stolen vehicle, via a telephone call, and control the central computer system 200 to match the owner and vehicle registration details against a database (not shown) containing a pre-registered and associated unique vehicle identifier (for example, a vehicle identification number, or VIN).
  • the central computer system 200 may then communicate the unique vehicle identifier to the initiation point 210, via the network 205.
  • embodiments of the invention In principle, for embodiments of the invention to operate, as will become apparent from the following description, it is only necessary to have a single initiation point acting as a source of message propagation. However, embodiments of the invention typically have a plurality of initiation points, distributed according to considerations such as geography, vehicle traffic characteristics and speed of detection requirements.
  • the network 205 may be a proprietary network or a public network such as the Internet.
  • some or all of the initiation points may be in communication with the central computer system 200 using wireless transmissions, for example employing a GSM cellular radio network (not shown), whereby the initiation points are equipped with radio receivers arranged, for example, to receive standard SMS messages or the like.
  • GSM Global System for Mobile communications
  • any alternative kind of communications standard and system could be employed to facilitate communications between a central computer system and associated initiation points.
  • an initiation point 210 generally comprises means for receiving messages from the central computer system 200 and means for generating respective optical signals to be transmitted by an optical transmitter 215 to vehicles that pass by the initiation point 210.
  • Fig. 2 also illustrates an exemplary road system, including a two-way, West/East carriageway 230, on which vehicles 240 can travel from West to East on the North side of the road and from East to West on the South side of the road.
  • the road is shown having roadside verges 225 and a central reservation 215.
  • the road system includes a junction at which a North/South carriageway 235 joins the West/East carriageway 230 from the South.
  • the initiation point 210 is located at the roadside 225 on the North side of the West/East carriageway 230, and the associated optical transmitter 215 is mounted on top of a mast 220 and is arranged to direct optical signals in a generally Westwardly direction into the path of vehicles 240 travelling East on the West/East carriageway 230. More generally, it will be appreciated that an optical transmitter of the kind described herein could be arranged to emit optical signals in any direction, or in substantially all directions, in order to enable receipt of optical signals by vehicles travelling in any direction in relation to the location of the initiation point.
  • Initiation points may be at convenient fixed locations, for example at the roadside, at motorway intersections, mounted on gantries over roads, or railways, at petrol stations, at regional or national borders, or in motorway service stations.
  • initiation points may be mobile, for example employing equipment mounted in police vehicles, other emergency vehicles, haulage vehicles or the like. Of course, mobile initiation points would tend to be in communication with a central computer system via wireless communications.
  • each of the five vehicles has on-board an OVMTU, the details of which will be described in detail hereinafter.
  • the initiation point 210 is transmitting an optical SVR signal 250 to vehicle C.
  • the optical signal 250 includes a stolen vehicle identify (SVID) request including an identifier I, which identifies a stolen vehicle.
  • SVID stolen vehicle identify
  • the initiation point 210 moments before communicating with vehicle C, the initiation point 210 had transmitted the same optical SVR signal 250 to vehicle A, as vehicle A had passed the initiation point 210.
  • Vehicles A and C are labelled as A(I) and C(I), to indicate that they have both stored the stolen vehicle identifier I, which was received from the initiation point 210.
  • vehicles A and C are message destinations.
  • Fig. 2 also shows vehicle A transmitting, via an optical SVR signal 255, an SVID request including the identifier I to vehicle D. Again, moments earlier, vehicle A had transmitted the same SVID request to vehicle B. Vehicles B and D are labelled as B(AI) and D(AI), to indicate that they have received, via vehicle A, and stored the stolen vehicle identifier I. In this scenario, vehicles B and D are message destinations with respect to vehicle A, and vehicle A is acting as a message source with respect to vehicles B and D.
  • Fig. 2 shows vehicle B transmitting, via an optical SVR signal 260, the identifier I to vehicle E.
  • Vehicle E is labelled as E(BAI) to indicate that it has received, via vehicles A and then B, and stored the stolen vehicle identifier I.
  • vehicle E is a message destination with respect to vehicle B
  • vehicle B is a message source with respect to vehicle E.
  • Fig. 2 shows vehicle E transmitting, via an optical SVR signal 265, an SVR response signal indicating that its identity matches the identity I of the stolen vehicle.
  • vehicle E is a message source with respect to vehicle B
  • vehicle B is a message destination with respect to vehicle E.
  • a stolen vehicle has been identified by a sequence comprising only four optical signals: initiation point 210 ⁇ vehicle A; vehicle A ⁇ vehicle B; vehicle B ⁇ vehicle E; and vehicle E ⁇ vehicle B.
  • each vehicle or, indeed, its respective OVMTU
  • more than four optical signals and messages may have been transmitted (but not necessarily received) in order to achieve four successfully-received transmissions.
  • the diagram in Fig. 3 illustrates in more detail the functional components of an exemplary initiation point 210 according to an embodiment of the present invention.
  • an initiation point can receive messages as well as propagate them.
  • the initiation point 210 comprises a microprocessor (or processor) 305, an optical receiver circuit 310 driven by a photo diode 312, an optical transmitter circuit 315 driving a light emitting diode (LED) 317, main memory 320 containing at least a store 322 for SVID requests, a program memory 325 for storing program code for controlling the operation of the initiation point 210, a network interface 330 for connecting the initiation point 210 to the network 205, a management interface 335, by which an operator or service engineer can connect to the initiation point 210 for updating or maintenance purposes.
  • a microprocessor or processor
  • an operator or service engineer can communicate with the initiation point 210 via the network interface, by logging in and using a remote control console or the like in a known way.
  • the components in the exemplary initiation point 210 are connected by an appropriate interconnect or BUS arrangement 307.
  • the processor 305 of the initiation point 210 may be an embedded processor, which performs functions according to firmware instructions that are stored in and loaded from the program memory 325.
  • the main memory 320 may be volatile RAM or non-volatile EEPROM, while the program memory may be non-volatile EEPROM or ROM.
  • the main memory 320 and the program memory 325 may both comprise EEPROM, which would beneficially mean that data is not lost during a power outage.
  • the entire functionality of the initiation point (apart from, perhaps, electronic components for driving the photo detector and LED) is embodied in a single bespoke application specific integrated circuit (ASIC).
  • ASIC application specific integrated circuit
  • the functionality may instead be deployed in any appropriate manner.
  • received data can be stored in processor registers in addition to, or instead of, in main memory, or in any other kind of storage element(s).
  • the processor 305 is programmed to receive, from the central computer system 200, SVID, requests, each including a unique SVID, and store each received SVID request in the SVID store 322. Then, periodically, the processor reads the SVID request(s) from the SVID store 322 and causes the transmitter 315 to transmit associated SVID requests to passing vehicles, in order to propagate the SVID
  • An exemplary messaging protocol for communicating SVID requests will be described in more detail hereinafter.
  • one or more SVID requests associated with stolen and not-yet-detected vehicles, may be 'active' at any time and stored by the initiation point 210, and the plural SVID requests may then be transmitted one after another to passing vehicles.
  • this may of course mean that one passing vehicle only receives one, or a subset, of all active SVID requests that are being sequentially transmitted. If this is the case, then, over time, it is expected that plural passing vehicles would, between them, and in the aggregate, receive all SVID requests, in order that all SVID requests may be propagated according to embodiments of the invention.
  • each SVID request may be transmitted ten times per second, for example, every 0.1 seconds.
  • the time between transmitting different SVID requests may be far shorter, for example with a 0.02 second gap, to ensure that each passing vehicle receives a maximum number of different SVID requests.
  • the frequency of the transmissions may be adjusted, however, depending on the anticipated speed of passing vehicles.
  • an initiation point may include a movement detector (not shown), which is capable of detecting when a vehicle is approaching the initiation point and only then triggering a transmission of the SVID requests.
  • the LED 317 is a relatively high power infra-red LED operating at 940nm, and including an appropriate focusing lens and reflector arrangement to ensure that the maximum optical power is focused and transmitted in the direction of the approaching vehicle.
  • the optical wavelength is similar to that employed by infra-red remote control devices. However, other operating wavelengths could be used, for example 880nm. Indeed, any operating wavelength of light could be employed, although it is anticipated that only wavelengths that are imperceptible to humans and animals would be employed.
  • the optical signals may be generated by modulating visible light that is emitted by standard headlamps when they are switched on. The modulation is made sufficiently fast as to be imperceptible to humans, and thereby not distracting or indicative of active signalling.
  • optical communications are performed by modulating data onto an optical carrier signal.
  • the details of such optical communications are extremely well known and will not be described herein.
  • the diagram in Fig. 4 illustrates in more detail the functional components of an exemplary OVMTU 400.
  • the OVMTU 400 comprises a microprocessor (or processor) 405, a comparator 406, an optical receiver unit 410 driven by a photo diode 412, an optical transmitter unit 415 driving a light emitting diode 417, main memory 420, a program memory 425 for storing program code for controlling the operation of OVMTU, a code generator 430, a management interface 435, via which the OVMTU can be configured for installation into a particular vehicle, and an indicator 445.
  • the indicator 445 may be any kind of audible alarm, flashing light, graphical display or similar that is suitable for notifying a driver of the vehicle that a stolen vehicle has just been detected.
  • the main memory 420 contains at least a store 421 for SVID requests, a store 422 for a home vehicle identifier (HVID), a store 423 for an optional coding key (CodKey) and a store 424 for a stolen vehicle register (SVREG).
  • HVID is the identifier of the vehicle in (or on) which the OVMTU is mounted. While according to the present embodiment a store is typically a location in a memory element, it could equally be a register in a processor element or any other suitable data retention element.
  • the components in the exemplary OVMTU 400 are connected by an appropriate interconnect or BUS arrangement 407.
  • the processor 405 and memory 420, 425 may be similarly specified to the equivalent components in the initiation point 210.
  • HVID and CodKey data at least should be stored in non-volatile memory.
  • the main memory 420 comprises volatile RAM
  • the HVID and CodKey data may instead be stored in the program memory 425 or in an alternative (not shown) non-volatile memory store.
  • all or a majority of the functionality of the OVMTU is embedded in an ASIC.
  • a main part of an OVMTU 400 typically comprises a sealed casing containing a majority of the processing elements, a power input and inputs for receiving wired connections from the optical transmitter 415 and receiver 410 units.
  • the main part of the OVMTU 400 may be concealed in any appropriate location, for example in the engine compartment, in the boot (or trunk), under the vehicle or in the passenger compartment.
  • the OVMTU may form one of the standard subsystems of a vehicle, and, as such, be installed during manufacture rather than being, for example, a retro-fitted item.
  • optical transmitter 415 and receiver 410 units are arranged so that the optical diode 412 and LED 417 are mounted within a light cluster unit, for example, of the headlights or tail lights (or both) of a vehicle.
  • the headlight and/or tail light clusters of a vehicle are manufactured to include optical transmitter and receiver units that are suitable for connection to the main part of a respective OVMTU.
  • the transmitter and receiver units could be mounted in various different ways and in various different places.
  • a transmitter could be mounted within the passenger compartment of a vehicle, and effectively radiate invisible light in all directions.
  • the optical transmitter and/or receiver may be mounted on or in the rear-side of a rear view mirror, facing outwardly forwards through the windshield. Other alternative arrangements can be envisaged.
  • an exemplary OVMTU 400 is programmed to perform at least four operations:
  • an OVMTU may receive from a stolen vehicle a response message indicating that an SVID matches the stolen vehicle's HVID (for example, the response may have been caused by an earlier SVID message from a different OVMTU).
  • the recipient OVMTU still causes the indicator 445 to indicate that a stolen vehicle has been detected. In this way, any OVMTU can perform SVID notification, irrespective of whether or not it has previously received or transmitted a respective SVID request.
  • the OVMTU 400 does not as such detect the presence of other vehicles, and the repetition rate of the SVID request messages is relatively high in order to ensure that other vehicles passing by are likely to receive the messages.
  • the OVMTU may be adapted to adjust repetition rate according to vehicle speed and/or detect other vehicles in the proximity of the vehicle in order to trigger the transmission of the SVID requests.
  • One exemplary way of detecting home vehicle speed is to connect into a control area network (CAN) bus of the home vehicle, in order to detect a speedometer value of the home vehicle.
  • CAN control area network
  • an OVMTU is responsible for identifying whether it has a HVID that matches a received SVID and notifying the source of the SVID (or potentially any other passing OVMTU or initiation point) that there is a match.
  • an OVMTU can be arranged to generate a response only if there is a match, and not otherwise. This has the advantage of conserving vehicle battery power, particularly if the vehicle is not operating (for example, the engine is not running) in a manner that recharges the battery.
  • the OVMTU may instead return its HVID to the source of the SVID and leave it to the source to determine whether there is a match.
  • the OVMTU may perform its own comparison to determine that there is a match and, in addition, confirm the match and return its HVID to the source.
  • embodiments of the present invention encompass any protocol that enables a source to perform SVR Notification.
  • SVR Notification in effect informs the driver of the vehicle that originated an SVID request (or which has received a response to an SVID request prompted by another OVMTU) that a stolen vehicle has been detected in the proximity of the stolen vehicle.
  • the driver of the source vehicle is then able to, for example, contact the police or a designated call centre to provide information including the driver's location; thereby indicating the approximate location of the stolen vehicle.
  • the indicator 445 provides an indication including the SVID (or any other representation of the SVID or other identifier that can be correlated by the police or call centre operator with the stolen vehicle), which can be imparted to the police or call centre operator.
  • the driver in reporting detection of the stolen vehicle, the driver does not necessarily know which car in his proximity has been stolen, and thus is not motivated to intervene or approach the stolen vehicle.
  • the stolen vehicle may communicate with a plurality of other OVMTUs, and the drivers of the respective vehicles may all contact the police or call centre. In this way, the police can map the progress of the stolen vehicle and calculate an optimal detection and interception location.
  • the SVR Notification may be adapted to include details of the make and model of the detected stolen vehicle, so that a police officer can intervene, approach and recover the stolen vehicle.
  • the OVMTU may be adapted to respond to an SVID request, when there is a match, only if the respective vehicle has been non-operational (and stationary) for a period of time; for example for more than five minutes, or more than ten minutes.
  • an SVR notification typically relates to a parked vehicle, and the reported location is expected to remain relatively accurate.
  • OVMTU optical stolen vehicle notification
  • SVREG SVREG register
  • OSVN optical stolen vehicle notification
  • OVMTUs that operate in this way are typically also programmed to detect OSVN messages from other OVMTUs, and trigger an appropriate SVR Notification to the driver as described above.
  • the SVREG register may remain set until the respective stolen vehicle is recovered, or it may remain set for a fixed period of time, for example an hour, which provides ample opportunity for the vehicle to be detected without draining the vehicle battery if it is parked and not operational.
  • an OVMTU has been described in terms of a unit that is installed and mounted within a vehicle.
  • the functional operation of an OVMTU is performed by a standalone, portable unit, which can be attached to containers or carried by a person or animal.
  • a police officer or other official who is concerned with detection, and perhaps being detected, may carry such equipment.
  • a portable unit may operate in exactly the same way as an OVMTU, thereby extending the capability of an overall system to be used to detect stolen vehicles.
  • a portable unit can be carried into areas that do not have a high throughput of vehicles, such as in a garage area or side-street, and can even be used to communicate SVID requests to vehicles that are parked away from the road.
  • a portable unit (or, indeed, a vehicle-mounted unit) that is carried by a police officer or other party associated with detection (rather than being detected), may dispense with SVR Comparison functionality.
  • the diagram in Fig. 5a illustrates the contents of an exemplary SVID, request 500.
  • the request 500 is generated at the central computer system 200 and comprises: an SVR designation 505, which in this embodiment indicates that the message is an SVID request 510; a target vehicle identifier 510, which, in this example, is an SVID, for example a VIN; a code 515 associated with the SVID, whereby the authenticity of the SVID can be checked; a value 520 indicating whether or not a recipient of the request should propagate the request; and an absolute end time 525.
  • the propagate value 520 may be YES or NO, wherein a NO means that the SVID request should not be propagated if the engine of the associated vehicle is not operating, for example, in order to conserve battery power. On the other hand, a YES means that the SVR request should be propagated even if the engine of the associated vehicle is not operating. It will be appreciated that the propagate value is an optional item of information, which may be advantageous in some embodiments for preventing a vehicle battery from being depleted.
  • the end time 525 determines for how long initiation points and OVMTUs should propagate the request.
  • OVMTUs and initiation points are arranged to delete the respective request. In this way, the overall system is prevented from propagating requests after a vehicle has been recovered, or in perpetuity. Requests that have not led to vehicle recovery can be re-issued by the central computer system, if desired.
  • the diagram in Fig. 5b illustrates the contents of an exemplary SVID response message 550, which is transmitted by an OVMTU, according to the present embodiment, if the SVID received in an SVID request matches the HVID.
  • the response 550 includes a confirmation portion 555 indicating that the message relates to an SVR response; the HVID (for example the VIN code) 560; and a code 565 associated with the HVID, so that the authenticity of the response can be checked.
  • the SVID and/or HVID may be accompanied by a vehicle descriptor, for example a make, model, year, registration plate and/or colour.
  • authentication of an SVID request is advantageously performed in order to identify erroneous or fake SVID requests, which could otherwise be introduced into the system for malicious intent.
  • authentication of this kind is most desirable, for example in order to prevent subversion of a system, it is not essential, and, in some embodiments, for example those which are not concerned with SVR matters, authentication may not be required. Nevertheless, for good measure, all embodiments described in detail herein employ SVID authentication of some kind in order to limit opportunities for subversion.
  • the central computer system 200 is responsible for generating and distributing the SVID or HVID code as part of an SVID request.
  • the code may take one of many different forms, requiring various different kinds of encoding or decoding operation in order to perform authentication.
  • a code may simply be a hash code of known kind calculated over an SVID or HVID.
  • hash codes are typically generated as relative short, fixed length codes, which result from a numeric operation applied to an inputted SVID. Although such codes are typically not unique for all possible SVID codes, it will be appreciated that the chances of a so-called hash collision can be made sufficiently low, in order to satisfy a recipient that an SVID is genuine.
  • a code generator 430 of an OVMTU that receives an SVID request may apply the same hash encoding algorithm to an SVID as the central computer system, and compare the result with the received hash code in order to perform authentication (where a match indicates authentication and a non-match indicates the potential for a maliciously-introduced SVID request).
  • a CodKey 423 may not be required, although the hash code generating algorithm, or at least an element of it, may be stored in non-volatile memory, in a way which allows it to be updated from time to time, for example, via the management interface 435.
  • the code generator 430 may be arranged to perform a cryptographic hash operation, for example, employing a pre-shared encryption key (stored as CodKey 423) to generate a cryptographic hash code.
  • CodKey 423 a pre-shared encryption key
  • the same key and algorithm would be employed by the central computer system and the recipient to generate the hash code from the SVID, in order to facilitate comparison and authentication. Again, a match would provide authentication and a non-match would indicate potentially malicious intent.
  • the code may be an encoded version of the SVID, which can be decoded to reveal the original SVID.
  • the code generator 430 may perform the decoding operation, in order that the encoded SVID can be decoded and compared with the received and un-encoded SVID
  • the SVID code may be a signature of the SVID, which is cryptographically generated by the central computer system using a secret key of a cryptographic key pair.
  • Each OVMTU may then have the public key (stored as the CodKey 423) of the pair and be able to authenticate the certificate in a known way.
  • FIGs. 6a and 6b exemplifies the operation of a system according to an embodiment of the present invention, in which vehicles are motor cars and SVIDs are VINs.
  • a new SVID is entered into the central computer system 200, which generates [block 602] an SVID request 500 and communicates [block 604] the request to the initiation point(s) 210.
  • the SVID request includes a cryptographic hash code, which is generated by the central computer system 200.
  • the processor 305 receives and stores the SVID request [block 606].
  • the processor 305 reads the SVID memory 322 and propagates the SVID request 608 by way of an optical signal 250.
  • the processor 305 checks [block 610] the end time 525 of the request and, if the associated end time 525 has timed-out or expired, the processor deletes [block 612] the SVID request from the memory 322. The process then iterates to block 608 to process and propagate any new and remaining SVID requests.
  • Each new SVID request 500 communicated by a source is received and stored [block 614] in SVID request memory 421.
  • a new SVID request 500 may be received from an initiation point or from another OVMTU.
  • the new SVID request 500 is authenticated [block 616], by using the code generator 430 and an associated key, which is stored in the CodKey memory 423, to perform a cryptographic hash operation over the received SVID 510 and compare the result with the received hash code 515. If the received SVID is not authentic, the associated SVID request is deleted from memory [block 618] and the process iterates to block 614 to wait for the next new SVID request.
  • the SVID 510 is compared [block 620] by the comparator 406 with the HVID, which is stored in the HVID memory 422 of the recipient OVMTU. If there is no match [block 622], then the process iterates to block 614 to wait for the next new SVID request. If, on the other hand, the SVID and HVID match, the OVMTU generates a response 550, which is communicated [block 626] in an optical signal 265, which is sent to and hopefully received by the source (either the initiation point or the other OVMTU). Finally, the process iterates to block 614 to wait for the next new SVID request.
  • the source does not receive the response (for example, it may be out of range by the time the response is generated and transmitted, then detection of the stolen vehicle may not happen until another OVMTU communicates the SVID to the stolen vehicle.
  • further optional actions may be adopted to increase the likelihood of stolen vehicle detection, as will be described below.
  • the OVMTU periodically (for example, every 0.1 seconds) reads the SVID requests 500 from the SVID request memory 421 and propagates them [block 628] in an optical signal 260 to be received by any nearby OVMTU (or initiation point that is capable of receiving signals as well as transmitting them) that is capable of receiving the requests.
  • the processor determines for each SVID request whether the respective propagate value 520 is set to YES or NO, and only propagates SVR requests that have a YES value. In any event, next, the OVMTU then determines whether a response 265 is received 630.
  • the process iterates to block 628 in order to read and propagate the (or at least any remaining) SVID request(s).
  • the systems that are described above, or variants thereof, can be employed for performing other operations, such as vehicle recall (VR).
  • the respective systems are arranged to perform only vehicle recall and not SVR.
  • the same system and components that are described above are employed to perform vehicle recall operations in addition to SVR operations.
  • FIG. 5c An exemplary VRID request 570 is illustrated in the diagram in Fig. 5c .
  • the VR request 570 resembles the request 500 illustrated in Fig. 5a , except that a request designation 575 indicates 'VR' rather than 'SVR'.
  • the request 570 includes: a target vehicle identity (in this instance a VRID) 580; a VRID code 585, for authentication; a propagate value 590; and an end time value 595.
  • the target vehicle identity may be issued in terms of a class of vehicle, for example defined by car make, model and year. In this way, all vehicles in a certain batch can be recalled.
  • the target vehicle identifier may be issued to a specific vehicle, for example defined by a VIN
  • an HVID stored by OVMTUs can include any or all associated vehicle identification data (for example, VIN, make, model, year, colour, engine size, etc.) to facilitate identification of groups of one or more vehicles by any appropriate identification means.
  • each OVMTU handles VR messages according to basic logic, which takes the form:
  • an OVMTU receives and stores [block 700] a new VR request 570 from another OVMTU or from an initiation point.
  • the new VR request 570 is authenticated [block 701], by using the code generator 430 and an associated key, which is stored in the CodKey memory 423, to perform a cryptographic hash operation over the received VRID 580 and compare the result with the received hash code 585. If the received VRID is not authentic, the associated VR request 570 is deleted from memory [block 702] and the process iterates to block 700 to wait for the next new VR request.
  • the VRID 580 is compared [block 703] by the comparator 406 with the HVID, which is stored in the HVID memory 422 of the recipient OVMTU. If there is no match [block 704], then the process iterates to block 700 to wait for the next new VRID request. If, on the other hand, the VRID and HVID match, the OVMTU causes the indicator 445 to indicate [block 705] to the home vehicle's driver that the home vehicle should be taken to a service centre. This is in contrast with an SVID request match, which does not indicate anything to the driver of the home vehicle (who is typically a car thief), so as not to alert the driver that the system is performing SVR operations.
  • the OVMTU periodically (for example, every 0.1 seconds) reads the VRID requests from the VRID request memory 421 and propagates them [block 708] in an optical signal 709 to be received by any nearby OVMTU capable of receiving the requests.
  • the processor 405 checks, using the real time clock 440, whether the VRID request has timed out by comparison with the end time 590. If it has timed-out then the VRID request is deleted from the VRID memory [block 712]. Then, whether or not the SVID request has timed-out, after a delay [block 714] of, for example, 0.1 seconds, the process iterates to block 708 in order to propagate the (or at least the remaining) VRID request(s).
  • a third exemplary kind of request message is illustrated in Fig. 8a and an associated response message is illustrated in Fig. 8b .
  • the request and response messages relate to a status enquiry, for example, to determine if an identified OVMTU (for example, as illustrated in Fig. 4 ) is operating properly.
  • the request message 800 has a 'STATUS REQUEST' message designation 805, so that a recipient OVMTU knows what the message is a status request; a target vehicle identifier 810; a target vehicle identifier code 815; a propagate value 820; and an end time 825.
  • the response message 850 includes a 'STATUS RESPONSE' designation 855, so that a recipient OVMTU knows what the message is a response to a status enquiry; a RESPONSE PAYLOAD 860, which contains the status of the responding OVMTU; a vehicle identifier 865; and a vehicle identifier code 870.
  • the codes, 815 and 870, propagate value 820 and end time 825 are for use as has already been described above.
  • a request message 800 is originated by a central computer system and propagated, via at least one initiation point, to a plurality of vehicles and then from vehicle to vehicle (generally as described above).
  • the request message may include a target vehicle identifier identifying a single vehicle, for example by using a VIN.
  • the request message as in a VR embodiment, may include a target vehicle identifier identifying a class of vehicle, for example by designating make, model and year.
  • the target vehicle identifier may identify an OVMTU (either singularly or as a category, defined in an appropriate way, for example by OVMTU serial number, model or age).
  • the response message 850 identifies the actual vehicle or OVMTU that is responding, in order that the status can be identified against a particular vehicle or VMTU.
  • a diagnostic routine 426 of the OVMTU When a recipient OVMTU, which has a HVID that matches the target vehicle identifier 810, receives the status request message, a diagnostic routine 426 of the OVMTU operates and provides status data to be included in the payload 860 of a response 850.
  • the status data may simply signify that the OVMTU is operable.
  • the diagnostics routine 426 may cause the OVMTU to perform a self-test.
  • the OVMTU may cause the LED 417 to transmit a burst of optical radiation, at least a small portion of which reflects off of the inside of the glass that covers a headlamp cluster in which the LED 417 is mounted (or off of the inside of a windshield) and is detected by the photo detector 412.
  • the amount of optical radiation that is detected can be measured, for example using a simple A-D converter arrangement, and the measurement can form at least a part of the payload 860. If the same measurement is conducted periodically (for example in response to weekly or monthly status requests), a change in the amount of detected radiation (for example, the change may be a reduced amount of detected radiation) may indicate that either the LED 417 or the photo detector 412 is deteriorating and requires attention. This may lead to a vehicle recall request being issued for the vehicle. Of course, if there is no detected reflected radiation, then this may indicate that the transmitter arrangement has failed and a driver notification may be generated immediately. Many other ways of testing status will be evident to the skilled person.
  • the OVMTU After generating the status response message 850, the OVMTU stores the response in the SVID/VRID memory 421, and then periodically propagates the message, along with any other SVID and/or VRID messages that are to be propagated, to any destination OVMTU or initiation point that is capable of receiving such messages. In this way, a response message 850 will eventually be propagated back to an initiation point 210, which can receive the message via the photo diode 312 and optical receiver 310 arrangement. Then, the initiation point 210 can return the status message 850 to the central computer system, for example, via the network 205.
  • message propagation can be one-way or two-way and may be initiated at an initiation point or by a vehicle and/or VMTU.
  • an SVID request or VR request is typically initiated at an initiation point with an aim of being propagated to as many vehicles as possible, without any need to return a response to an initiation point.
  • a status enquiry may be one-way or two-way.
  • an initiation point may issue a status enquiry to one or more vehicles, the enquiry being propagated, potentially via many other vehicles, to the targeted vehicle(s).
  • the or each targeted vehicle may generate a response, which is propagated, potentially via many other vehicles, to an initiation point (though not necessarily the same initiation point).
  • a one-way status message would arise, for example, if a status message is generated by a vehicle in response to a detected vehicle condition. In such a case, the message would be returned to an initiation point, potentially, via many other vehicles.
  • an OVMTU and associated systems may be enabled to perform any one or more operations including (but not limited to) SVD, VR and status monitoring.
  • a priority may be applied to different received requests (or messages), wherein the priority may for example dictate which requests are propagated first or which requests are propagated most frequently.
  • an SVR request may take priority over a VR request, and the SVR request may be propagated more often than the VR request.
  • the priority may be set by the central computer system, for example by assigning and embedding a priority value of 1-5 in a request message (where a 1 means highest priority and a 5 means the lowest priority).
  • OVMTUs may be adapted to act according to the priority.
  • an OVMTU may be arranged to identify and treat different requests in a different manner, according to a predetermined order of priority.
  • Status monitoring embodiments may, in addition, be employed to report on the status of a vehicle.
  • the OVMTU potentially has access to a large amount of performance and diagnostics information of the vehicle.
  • the OVMTU can then be controlled to report elements of this information back to a central computer, according to embodiments of the present invention.
  • the information can be reported in response to associated status requests.
  • the OVMTU may be arranged to read and report the information back to the central computer system pro-actively and without needing a request.
  • the information may then be reported back periodically (for example each week or month) or as a result of trigger events (for example, overheating or degraded petrol consumption, or simply periodically).
  • Other information that may be reported back relates to driver performance, such as speeding or heavy braking.
  • Such information may be useful is adjusting insurance premiums or the like.
  • Another example of when a proactive message initiated by an OVMTU can be useful is in a situation of danger, for example kidnapping, when a driver or passenger who is a victim can (secretly) activate a panic button, to begin propagation by the OVMTU of an alarm message, which can be detected by other OVMTUs.
  • optical communications for example, to initiate, propagate and respond to messages.
  • An advantage of using optical communications is that the respective components and systems are relatively cheap, for example, by comparison to radio communications components and systems. This means that optical-based systems can become more pervasive, because additional vehicles and more people (such as traffic wardens) can be provided with an OVMTU for a relatively low cost.
  • an SVR response indicating that a stolen vehicle has been detected (that is an SVID matches an HVID), which was transmitted, for example, using 'direct' (that is, point-to-point, without intervening repeating or other assistance) line-of-sight optical communications, provides a high degree of confidence that the respective stolen vehicle is in the proximity of the recipient OVMTU.
  • "in the proximity of' a vehicle typically means that another vehicle (or initiation point) is in the optical line-of-sight of the first vehicle.
  • a line-of-sight might extend to 50 meters or more, but is likely to be, for practical and reliable communications purposes, about 5-20 metres.
  • embodiments of the present invention employ other kinds of wireless communications, such as direct, point-to-point radio communications.
  • a greater range and not being limited to relatively short-range optical line-of-sight can be advantageous, since the location of a recipient is not as important as the ability for a recipient to propagate the message.
  • Some embodiments of the invention employ relatively short range, direct radio communications such as, for example, communications based on Bluetooth or Wi-Fi standards, or some other kind of simple short-range point-to-point wireless standard.
  • the power level employed for radio embodiments can be controlled so that the distance coverage is limited to coverage in the proximity of a vehicle.
  • power level can be limited so that distance coverage in free space is about 100 metres, 50 meters, 20 meters, or even less.
  • coverage would naturally be limited, for example, and be bounded by buildings on either side of a road.
  • Other embodiments of the invention employ other communications, such as (and without limitation) ultrasonic or microwave communications.
  • different signal powers can be employed by the same equipment for different kinds of request.
  • an SVR request which needs relatively accurate location information, may employ relatively low power (shorter distance) signalling.
  • a VR request for which location is less important than the ability to receive and propagate messages, may employ relatively higher power (longer distance) signalling.
  • the distances covered are expected to be far shorter than those achievable using known radio communications of the kind, for example, employed in cellular mobile telephony.
  • a target vehicle identifier will change depending on the nature of the vehicle in or on which the OVMTU (or other alternative form of transceiver unit) is mounted. For example, if the vehicle is a train or ship, the identifier may be a unique registration number. If the vehicle is a human, the identifier may be a name and/or social security number. If the vehicle is an animal, the identifier may be an animal licence number or the like.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Traffic Control Systems (AREA)
  • Alarm Systems (AREA)

Claims (15)

  1. Kommunikationsvorrichtung (400) für ein Fahrzeug, wobei die Kommunikationsvorrichtung (400) umfasst:
    einen ersten Speicher (422) zum Speichern einer Heimfahrzeugkennung, zum Identifizieren eines Heimfahrzeugs an oder in dem die Vorrichtung (400) betrieben wird;
    einen Empfänger (410) zum Empfangen von Nachrichten unmittelbar von einer Nachrichtenquelle in der Nähe des Heimfahrzeugs;
    einen zweiten Speicher (421) zum Speichern mindestens einer Zielfahrzeugkennung;
    einen Sender (415) zum Senden von Nachrichten unmittelbar zu einem Nachrichtenziel in der Nähe des Heimfahrzeugs; wobei
    die Vorrichtung (400) eingerichtet ist:
    eine Nachricht, die eine Zielfahrzeugkennung beinhaltet, von einer Nachrichtenquelle zu empfangen und die Zielfahrzeugkennung im zweiten Speicher (421) zu speichern;
    die empfangene Zielfahrzeugkennung mit der Heimfahrzeugkennung zu vergleichen, um festzustellen, ob das Heimfahrzeug das zugehörige Zielfahrzeug ist; und
    als Antwort auf die Feststellung, dass das Heimfahrzeug nicht das zugehörige Zielfahrzeug ist, die empfangene Nachricht an ein oder mehrere Nachrichtenziele zu übertragen;
    dadurch gekennzeichnet, dass die Vorrichtung (400) eingerichtet ist:
    eine Antwort auf eine übertragene Nachricht eines Nachrichtenziels zu empfangen und auf Grundlage der Antwort zu bestimmen, dass das entsprechende Nachrichtenziel das Zielfahrzeug ist.
  2. Vorrichtung (400) nach Anspruch 1, die eingerichtet ist, nur dann eine Nachricht zu übertragen, die eine empfangene Zielfahrzeugkennung beinhaltet, wenn die empfangene Zielfahrzeugkennung der Heimfahrzeugkennung entspricht.
  3. Vorrichtung (400) nach Anspruch 1, die eingerichtet ist, nur dann eine Nachricht zu übertragen, die eine empfangene Zielfahrzeugkennung beinhaltet, wenn die Kennungen nicht übereinstimmen.
  4. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, die eingerichtet ist, eine Nachricht auszusenden, die angibt, dass die empfangene Zielfahrzeugkennung mit der Heimfahrzeugkennung übereinstimmt, wenn die Kennungen übereinstimmen.
  5. Vorrichtung (400) nach Anspruch 4, die eingerichtet ist, zu bestätigen, dass die empfangene Zielfahrzeugkennung mit der Heimfahrzeugkennung übereinstimmt und im Falle einer festgestellten Übereinstimmung eine Nachricht zur Nachrichtenquelle zu senden, um die Übereinstimmung zu bestätigen.
  6. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, wobei eine Fahrzeugkennung einen Kennungsteil und einen Authentisierungsteil, um den Kennungsteil zu authentisieren, umfasst, wobei die Vorrichtung (400) eingerichtet ist, eine Fahrzeugkennung beim Empfangen zu authentisieren, indem der Authentisierungsteil verwendet wird.
  7. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, die eingerichtet ist, eine Nachricht zu empfangen, die angibt, dass die entsprechende Nachrichtenquelle ein Fahrzeug ist, das eine Heimfahrzeugkennung aufweist, wobei die Heimfahrzeugkennung einer Zielfahrzeugkennung entspricht und zuvor von der gleichen Nachrichtenquelle empfangen wurde.
  8. Vorrichtung (400) nach Anspruch 7, umfassend Anzeigemittel (445), wobei die Vorrichtung eingerichtet ist, die Anzeigemittel (445) zu veranlassen, einem Bediener des Heimfahrzeugs anzuzeigen, dass eine Nachrichtenquelle ein Zielfahrzeug ist.
  9. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, wobei der zweite Datenspeicher (422) zum Speichern von mehr als nur einer Zielfahrzeugkennung geeignet ist.
  10. Vorrichtung (400) nach Anspruch 9, die eingerichtet ist, vom zweiten Datenspeicher (422) zu lesen und mehrere Zielfahrzeugkennungen auszusenden.
  11. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, wobei eine empfangene Nachricht eine Ablaufzeit beinhaltet und wobei die verbundene Nachricht nicht übertragen wird, wenn die Ablaufzeit verstrichen ist.
  12. Vorrichtung (400) nach einem der vorhergehenden Ansprüche, wobei eine Zielfahrzeugkennung ein gestohlenes Fahrzeug identifiziert.
  13. Ein Kommunikationssystem, umfassend:
    ein Steuerzentrum (200) zur Ausgabe von Nachrichten, die jeweils mindestens eine Zielfahrzeugkennung beinhalten;
    mehrere Vorrichtungen (400) nach einem der Ansprüche 1 bis 12; und
    mindestens eine Initiierungsstelle (210), wobei die oder jede der Initiierungsstellen Mittel zum Empfangen von Nachrichten vom Steuerzentrum (200) und Mittel zum periodischen Übertragen von Nachrichten an die genannten Vorrichtungen (400) aufweisen, wobei die Nachrichten mindestens eine Zielfahrzeugkennung beinhalten.
  14. Kommunikationssystem nach Anspruch 13, wobei die mindestens eine Initiierungsstelle (210) umfasst:
    eine Schnittstelle (330) zum Empfangen von Nachrichten vom Steuerzentrum; und
    einen drahtlosen Sender (315) zum Übertragen von Nachrichten; und
    einen drahtlosen Empfänger (310) zum Empfangen von Nachrichten, die von einer oder mehrerer der Vorrichtungen (400) übertragen wurden.
  15. Verfahren zum Übertragen einer Nachricht an mehrere Fahrzeuge, umfassend:
    Empfangen einer Nachricht von einer Nachrichtenquelle, wobei die Nachricht eine Zielfahrzeugkennung beinhaltet;
    Vergleichen der empfangenen Zielfahrzeugkennung mit einer Heimfahrzeugkennung eines Empfängerfahrzeugs, um festzustellen, ob das Empfängerfahrzeug das zugehörige Zielfahrzeug ist; und
    in Antwort auf die Feststellung, dass das Heimfahrzeug nicht das Zielfahrzeug ist, Übertragen der empfangenen Nachricht an ein oder mehrere Nachrichtenziele;
    gekennzeichnet durch
    Empfangen einer Antwort auf eine übertragene Nachricht von einem Nachrichtenziel und Bestimmen auf Grundlage der Antwort, dass das entsprechende Nachrichtenziel das Zielfahrzeug ist.
EP20110799261 2010-11-29 2011-11-29 Fahrzeugkommunikation Active EP2646994B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1020151.5A GB2486163A (en) 2010-11-29 2010-11-29 Vehicle to vehicle communication system for locating a target vehicle
PCT/EP2011/071327 WO2012072653A1 (en) 2010-11-29 2011-11-29 Vehicle communications

Publications (2)

Publication Number Publication Date
EP2646994A1 EP2646994A1 (de) 2013-10-09
EP2646994B1 true EP2646994B1 (de) 2015-05-20

Family

ID=43500754

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20110799261 Active EP2646994B1 (de) 2010-11-29 2011-11-29 Fahrzeugkommunikation

Country Status (4)

Country Link
EP (1) EP2646994B1 (de)
ES (1) ES2544443T3 (de)
GB (1) GB2486163A (de)
WO (1) WO2012072653A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI716135B (zh) * 2019-10-04 2021-01-11 財團法人資訊工業策進會 用於車用網路之安全監控裝置及方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016216541B4 (de) 2016-09-01 2023-03-23 Volkswagen Aktiengesellschaft Verfahren zum Auffinden eines mit einem Funksender gekoppelten Objekts

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6792351B2 (en) * 2001-06-26 2004-09-14 Medius, Inc. Method and apparatus for multi-vehicle communication
US20040183657A1 (en) * 2003-03-18 2004-09-23 Eung-Soon Chang Robbed vehicle information communication system for vehicle drivers
US7647165B2 (en) * 2003-07-23 2010-01-12 Timothy Gordon Godfrey Method and apparatus for vehicle tracking and control
DE102006053619B4 (de) * 2006-11-14 2009-04-02 Continental Automotive Gmbh Identifikationsanordnung für ein Fahrzeug
NL2000561C2 (nl) * 2007-03-27 2008-10-02 Stichting Noble House Verkeerscommunicatiesysteem en werkwijze voor het communiceren in het verkeer.

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI716135B (zh) * 2019-10-04 2021-01-11 財團法人資訊工業策進會 用於車用網路之安全監控裝置及方法
US11392690B2 (en) 2019-10-04 2022-07-19 Institute For Information Industry Security monitoring apparatus and method for vehicle network

Also Published As

Publication number Publication date
GB201020151D0 (en) 2011-01-12
ES2544443T3 (es) 2015-08-31
EP2646994A1 (de) 2013-10-09
GB2486163A (en) 2012-06-13
WO2012072653A1 (en) 2012-06-07

Similar Documents

Publication Publication Date Title
US8280583B2 (en) Transmission of vehicle-relevant data of a vehicle via mobile communication
USRE48562E1 (en) Systems and/or methods of data acquisition from a transceiver
US10580295B2 (en) Vehicular safety system
US9193367B2 (en) Crossing proximity and train-on-approach notification system
US10262291B2 (en) System for delivering shipping items
US11375351B2 (en) Method and system for communicating vehicle position information to an intelligent transportation system
WO2017043133A1 (ja) 情報処理装置、通信装置、情報処理方法及びプログラム
WO2011094024A2 (en) Method and system for improved traffic signage
US9232406B2 (en) Systems and/or methods of data acquisition from a transceiver
KR100831935B1 (ko) 적응형 통신 기술을 이용한 지능형 차량 안전 운행 방법 및시스템
US20170316685A1 (en) Vehicle accident management system and method for operating same
JPH11175896A (ja) 交差点衝突防止方法及びシステム及び交差点衝突防止プログラムを格納した記憶媒体及び交差点装置
US20190248325A1 (en) System and method for securing a vehicle
WO2001092909A2 (en) Vehicle anti-theft system and method
JP4478330B2 (ja) 交通安全性を高める装置
EP2646994B1 (de) Fahrzeugkommunikation
CN104276109A (zh) 中央锁和防碰撞组合设备、便携式保护设备及方法
WO2001032480A1 (en) A mobile object monitoring system
US7800484B2 (en) Car safety device
USRE49644E1 (en) Systems and/or methods of data acquisition from a transceiver
RU2179121C1 (ru) Система оперативного слежения за транспортным средством

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

17P Request for examination filed

Effective date: 20130701

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

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20140402

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20141201

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

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

Country of ref document: AT

Kind code of ref document: T

Effective date: 20150615

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602011016658

Country of ref document: DE

Effective date: 20150702

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

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20150831

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 728087

Country of ref document: AT

Kind code of ref document: T

Effective date: 20150520

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

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

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

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

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

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 5

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

Ref country code: AT

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

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

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

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

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

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

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

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

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602011016658

Country of ref document: DE

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 NON-PAYMENT OF DUE FEES

Effective date: 20150520

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

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

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

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

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

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

Effective date: 20151129

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

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

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

Ref country code: CH

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

Effective date: 20151130

Ref country code: LI

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

Effective date: 20151130

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 6

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

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

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

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

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

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

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

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

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

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

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

Ref country code: NL

Payment date: 20231126

Year of fee payment: 13

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

Ref country code: GB

Payment date: 20231127

Year of fee payment: 13

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

Ref country code: ES

Payment date: 20231201

Year of fee payment: 13

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

Ref country code: IT

Payment date: 20231122

Year of fee payment: 13

Ref country code: IE

Payment date: 20231127

Year of fee payment: 13

Ref country code: FR

Payment date: 20231127

Year of fee payment: 13

Ref country code: DE

Payment date: 20231129

Year of fee payment: 13

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

Ref country code: BE

Payment date: 20231127

Year of fee payment: 13