WO2024194621A1

WO2024194621A1 - Motor vehicle immobiliser

Info

Publication number: WO2024194621A1
Application number: PCT/GB2024/050734
Authority: WO
Inventors: Jordan HEATH
Original assignee: Emobiliser Limited
Priority date: 2023-03-17
Filing date: 2024-03-18
Publication date: 2024-09-26

Abstract

A controller for a vehicle immobilisation system, the controller comprising: an input arranged to receive an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle; a processor arranged to generate a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle; an output arranged to output the control signal to the immobilisation system.

Description

MOTOR VEHICLE IMMOBILISER

Technical Field

The present invention relates vehicle immobilisation. Aspects of the invention relate to a controller for a vehicle immobilisation system, a mobile phone device comprising said controller, a vehicle comprising said controller, an authentication server, a method for controlling a vehicle immobilisation system, a method for authenticating drivers, and a computing program.

Background

Vehicle related crimes and offences are prevalent in the UK and other countries around the world. Examples of such crimes and offences may for example include vehicle theft, driving without a valid driving licence or insurance, vehicle manslaughter, driving under the influence of drugs or alcohol and reckless driving, to name a few. Vehicles are also often stolen and sold on or stolen and used to transport criminals to conduct more illegal activities.

Known systems which try to combat car crime include theft prevention systems such as UWB (Ultra- Wideband) based systems which involve timestamping the initiation of an unlock instruction and when it is received by a receiver of the vehicle and using time of flight calculations to determine the distance the instruction has travelled. This calculation can identify whether the request to unlock the vehicle has been sent by a person in the immediate vicinity of the vehicle or not. If the timeframe exceeds a threshold, it will be identified as a “relay-attack”, which is when criminals have a device that is used to clone the owner’s car key code which allows them to open and mobilise the vehicle without needing the original car key or car fob.

Another example theft prevention system is PEPS (Passive Entry Passive Starts), which uses dual authentication between the key and vehicle to try and eliminate relay attacks or passive keyless entry (PKE).

Another theft prevention system is a “ghost” immobiliser, which requires a specific numerical code, pattern of behaviour or proximity fob for the vehicle to be mobilised.

A problem with known systems is that they do not stop drivers driving without a valid driving licence or insurance, or a driver changing places with another passenger in a vehicle after an offence has taken place, such as a passenger who has not consumed drugs or alcohol switching places with the driver who has. If the theft prevention fails (for example, a criminal breaks into a property and obtains the car key or fob or hacks a ghost immobiliser and discovers the numerical code), there is little to stop the thief gaining access to the vehicle and driving away. If a vehicle has been stolen and abandoned, it can also be difficult to identify the thief. The described system seeks to alleviate at least some of the above-mentioned problems.

Summary

Aspects and embodiments of the invention provide a vehicle immobilisation system, a method for immobilising a vehicle and a vehicle immobiliser device.

According to a first aspect of the present invention there is provided a controller for a vehicle immobilisation system, the controller comprising: an input arranged to receive an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle; a processor arranged to generate a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle; an output arranged to output the control signal to the immobilisation system.

The present invention provides a controller for a vehicle immobilisation system. The controller is configured to receive an authentication status message from a server which indicates that the driver is clear to drive the vehicle because, for example, their vehicle driving licence is valid and they are insured on the vehicle. Upon receiving the authentication status message the controller generates a control signal for the immobilisation system to either mobilise the vehicle by disengaging the vehicle immobilisation system or to immobilise the vehicle.

Prior to receiving the authentication status message, the processor may be arranged to generate an authentication request for an authentication server, the authentication request requesting confirmation of the authentication status of the driver and the output is arranged to output the authentication request to the authentication server. The controller may initiate the interaction with the authentication server by sending a request for the driver to be authenticated as eligible to drive.

The input may be arranged to receive driver identification data. The driver identification data may comprise biometric data and/or data associated with a mobile device of the driver. In order to authenticate the driver the controller may collect driver identification data. Such data may comprise biometric data from the driver or may comprise identification data associated with a mobile device of the driver. Biometric data may comprise image data, audio data (e.g. the driver may be requested to speak a pass phrase), a thumbprint or other biometric data. The driver identification data may also or alternatively comprise a username and password.

The controller may verify the identity of the driver, e.g. the controller may be a mobile device and may be able to confirm the identity of the driver via a biometric challenge. Verification of the driver’s identity may occur remotely and the authentication request may comprise the driver identification data. Alternatively, the processor may be arranged to verify the identity of the driver from the received driver identification data and the authentication request may comprise the identity of the driver. In a further option, the processor may be arranged to generate a driver identification request and the output may be arranged to output the driver identification request to an identification server, e.g. a driving licence authority or other trusted identity authority such as a passport issuing authority.

According to a second aspect of the present invention there is provided a mobile phone device comprising a controller according to the first aspect of the invention. The controller may be embodied in the driver’s mobile phone device which may communicate, e.g. via Bluetooth or Wifi, with the vehicle immobilisation system.

According to a third aspect of the present invention there is provided a vehicle comprising a controller according to the first aspect of the invention. The vehicle may comprise a vehicle immobilisation system.

The vehicle may further comprise an NFC reader configured to interact with an NFC authentication card. The vehicle may comprise a processor and a communications output wherein in the event a driver interacts with the NFC reader using the NFC authentication card, the processor is arranged to generate the authentication request and the output is arranged to output the authentication request to the authentication server. In the event that a driver does not have access to the controller according to the first aspect of the present invention, e.g. because they’ve forgotten or lost their mobile device, the vehicle may be provided with an near field communication (NFC) reader which can interact with an NFC card in order to either mobilise the vehicle or to transmit an authentication request from the vehicle to the authentication server. The NFC card may be regarded as a backup controller device.

According to a fourth aspect of the present invention there is provided an authentication server for determining an authentication status of a driver of a vehicle, the authentication status indicating whether the driver is authenticated to drive the vehicle; the authentication server comprising: an input arranged to receive an authentication request from a requesting device, the authentication request requesting the authentication status of the driver and the requesting device being associated with the vehicle; a processor arranged to determine the authentication status and to generate an authentication status message, the authentication status message comprising an indication of whether the driver of the vehicle is authenticated to drive the vehicle; an output arranged to output the authentication status message to the requesting device.

The present invention comprises an authentication server that may receive an authentication request from a requesting device (e.g. a controller according to the first aspect of the present invention) and then determine the authentication status of the driver. Determining the authentication status of the driver may comprise checking the driver’s current eligibility to drive against the current status of their driving licence and their current vehicle insurance status. Determining the authentication status may comprise sending a search request to a vehicle licensing authority, e.g. in the UK the search request may be sent to the driver and vehicle licensing agency (DVLA), to check the status of a driving licence associated with the driver and wherein, the input may be arranged to receive a driving licence search result from the vehicle licensing authority.

The processor may be arranged to generate the authentication status message in dependence on the driving licence search result received from the vehicle licensing agency.

The processor may be arranged to store the driving licence search result in a data store. As well as using the returned driving licence search result to generate the authentication status in response to an authentication request, the processor may additionally store the result for later use. For example, the vehicle licensing authority may only update the status of driver’s licences once per day and so the processor may be arranged to store a driving licence search result for later use in the same day.

Determining the authentication status may comprise retrieving a driving licence search result from a data store, the driving licence search result having been received from a vehicle licensing authority within a pre-determined period and the processor may be arranged to generate the authentication status message in dependence on the stored driving licence search result. Before sending the search request to the vehicle licensing authority the processor may be arranged to check if it has previously stored a driving licence search result that is still valid. For example, driving licence search results may be valid for a pre-determined period of time (e.g. 24 hours) and so the processor may be able to utilise a previously provided search result.

Determining the authentication status may comprise sending a search request to a vehicle insurance authority to check the status of motor insurance associated with the driver and wherein, the input may be arranged to receive a motor insurance search result from the vehicle insurance authority.

The processor may be arranged to generate the authentication status message in dependence on the motor insurance search result.

The processor may be arranged to store the motor insurance search result in a data store. As well as using the returned motor insurance search result to generate the authentication status in response to an authentication request, the processor may additionally store the result for later use. For example, the vehicle insurance authority may only update the status of driver’s motor insurances once per day and so the processor may be arranged to store a motor insurance search result for later use in the same day.

Determining the authentication status may comprise retrieving a motor insurance search result from a data store, the motor insurance search result having been received from a vehicle insurance authority within a pre-determined period and the processor may be arranged to generate the authentication status message in dependence on the stored motor insurance search result. Before sending the search request to the vehicle insurance authority the processor may be arranged to check if it has previously stored a motor insurance search result that is still valid. For example, motor insurance search results may be valid for a pre-determined period of time (e.g. 24 hours) and so the processor may be able to utilise a previously provided search result.

The authentication status message may be configured to indicate the driver is authenticated to drive the vehicle in the event that both the driving licence search result corresponds to a valid driving licence and the motor insurance search result corresponds to a valid motor insurance policy.

The authentication status message may be configured to indicate the driver is not authenticated to drive the vehicle in the event that the driving licence search result corresponds to an invalid driving licence and/or the motor insurance search result corresponds to an invalid motor insurance policy.

The input may be arranged to receive a notification that the vehicle has been stolen, the processor may be arranged to generate a tracking signal to a tracker on the vehicle and the output may be arranged to output the tracking signal in order for the authentication server to track the vehicle. In the event that a vehicle is stolen the server may receive a stolen notification, e.g. from the police or from the vehicle owner.

The processor may be arranged to generate an authentication status message indicating that the driver is not authenticated to drive the vehicle in the event that the input has received a notification that the vehicle has been stolen. In the event that the vehicle has been notified as stolen then any subsequent authentication requests may be denied. In this manner the vehicle may be immobilised.

The processor may be arranged to generate an immobilisation signal for the vehicle immobilisation system and the output may be arranged to output the immobilisation signal to the vehicle.

The requesting device may be the controller according to the first aspect of the present invention.

The requesting device may be the vehicle, the authentication request may comprise an indication that it has been generated in response to a vehicle user interacting with an NFC reader within the vehicle using an NFC authentication card.

The processor may be arranged to perform one or both of the following: generate a tracking signal to a tracker on the vehicle and to output the tracking signal via the output; generate a notification message to the vehicle owner to notify them that the NFC authentication card has been used and to output the notification message via the output. In the event that the backup card, the NFC authentication card, has been used to mobilise the vehicle, the owner/driver may be notified that this has occurred in case an unauthorised user has obtained the backup card.

The input may be arranged to receive driver identification data from the requesting device.

The processor may be arranged to identify the driver from the received driver identification data and to include the identity of the driver in any search requests sent to a vehicle licensing authority or vehicle insurance authority. According to a fifth aspect of the present invention there is provided a method of controlling a vehicle immobilisation system, the method comprising: receiving an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle; generating a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle; outputting the control signal to the immobilisation system.

According to a sixth aspect of the present invention there is provide a method of determining an authentication status of a driver of a vehicle, the authentication status indicating whether the driver is authenticated to drive the vehicle; the authentication server comprising: receiving an authentication request from a requesting device, the authentication request requesting the authentication status of the driver and the requesting device being associated with the vehicle; determining the authentication status and generating an authentication status message, the authentication status message comprising an indication of whether the driver of the vehicle is authenticated to drive the vehicle; outputting the authentication status message to the requesting device.

The invention extends to a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the fifth or sixth aspects of the present invention.

The invention extends to a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of the fifth or sixth aspects of the present invention.

Within the scope of this application, it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner.

Brief Description of the Drawings

One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram showing a controller for a vehicle immobilisation system in accordance with an embodiment of the present invention; Figure 2 is a schematic diagram showing an authentication server in accordance with an embodiment of the present invention;

Figure 3 is a flowchart showing a method for controlling a vehicle immobilisation system in accordance with an embodiment of the present invention;

Figure 4 is a is a flowchart showing a method for determining an authentication status of a driver of a vehicle in accordance with an embodiment of the present invention.

Detailed Description

The present disclosure relates to a controller for a vehicle immobilisation system, a mobile phone device comprising said controller, a vehicle comprising said controller, an authentication server, a method for controlling a vehicle immobilisation system, a method for authenticating drivers, and a computing program.

The vehicle immobilisation system may be configured to prevent a vehicle from starting unless certain criteria are met. In particular, the driver may be required to have a valid driving licence and/or motor insurance. The driver may also need to be registered with the vehicle for the vehicle to be mobilised or need to have permission from a user registered with the vehicle.

To be able to mobilise a vehicle, a user may provide their driving licence and/or motor insurance details, for example via an application or webpage. Driving licence details may for example include one or more of driving licence number, name, address, date of birth and expiry. Motor insurance details may for example include one or more of name, address, policy number and expiry of the policy. Driving licence and/or motor insurance details may be stored in a database, for example on the cloud.

The authentication server may access one or more database(s) (or register(s)) of valid driving licences. The server may search a local database or query a remote database, such as the register of a driving authority of the country in which the user is based (e.g. the Driver and Vehicle Licensing Agency, DVLA, in the UK), and search for the driving licence details that correspond to the driving licence details that have been input by the user. If valid driving licence details are found in the database of valid driving licences, a control signal may be sent to the controller indicating that the vehicle can be mobilised.

Figure 1 shows an example controller 100 for a vehicle immobiliser system 102 according to an embodiment of the present invention. The controller 100 may comprise an input 104, a processor 106, and an output 108, configured to send a control signal 110 to an immobilisation system 102 to prevent the vehicle from starting.

The controller 100 may be in the vehicle (e.g. embedded or installed in the vehicle) or it may be separate to the vehicle (e.g. a personal device such as a wearable device or smartphone).

The driver may be associated with the controller 100. For example, when the controller 100 is a personal device (e.g., smart phone), the user may be associated with the personal device. The personal device may for example comprise a smartphone, a wearable device, a smart card, a proximity card, a Near Field Communication (NFC) chip, and/or an NFC or Radio Frequency Identification (RFID) fob/card.

The controller 100 may comprise the input 104, which may be a receiver or transceiver. The authentication status message 112 may for example be received at the input (receiver) or transceiver of the controller 100.

The input 104 is arranged to receive an authentication status message 112 from the authentication server comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle. The input (104) may for example be a receiver. The authentication status message 112 may be coded (e.g. encrypted). The controller 100 may be arranged to decode (decrypt) the authentication status message 112. A driver may for example be authenticated to drive the vehicle if they have a valid driving licence and motor insurance. A driving licence may for example be valid if it has not expired, it is not fake, it is not a provisional licence, it has not been suspended or revoked, and/or the user does not have more than the maximum number of penalty points on their licence.

A user may for example have valid motor insurance if they have taken out insurance and their insurance has not expired, payments have not been missed, and/or the policy the user has covers the vehicle they wish to drive.

The processor 106 is arranged to generate a control signal for the vehicle immobilisation system 102 comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle.

The output 108 is arranged to output the control signal to the immobilisation system.

The controller 100 may output the control signal 110 at the output 108, which may be a transmitter. The transmitter may be in the vicinity of the driver and may be in communication with a receiver (input) of the vehicle immobilisation system 102, which may be located in the vehicle. The controller/personal device may comprise the transmitter and may be configured to transmit a signal (control signal) comprising instructions to either immobilise the vehicle (e.g., if the driving licence and/or motor insurance is invalid) or mobilise the vehicle (e.g., if the driving licence and/or motor insurance is valid). The vehicle immobilisation system 102 may comprise an input (e.g., receiver) for receiving the control signal.

The control signal 110 may be coded (e.g. encrypted). The control signal 110 may be sent to the immobilisation system, such as the Engine Control Unit (ECU) (8) or the Battery Management System (BMS), depending on whether the vehicle is an electric vehicle or a petrol or diesel-powered vehicle.

The receiver(s) referenced herein may be any type of receiver configured to receive signals described. This may include but is not limited to a radio frequency receiver, a Bluetooth receiver, and a wireless receiver.

The immobilisation system 102 may be configured to immobilise the vehicle. The immobilisation system 102 may for example be an Engine Control Unit (ECU) or a Battery Management System (BMS)) depending on whether the vehicle is an electric vehicle or a petrol or diesel-powered vehicle. Fossil fuel vehicles may comprise an Engine Control Unit (ECU) and electric or renewable energy vehicles may comprise a Battery Management System (BMS).

If the control signal 110 indicates that the vehicle can be mobilised (e.g., that the user has a valid driving licence and motor insurance) the controller 100 or vehicle immobilisation system 102 may send a signal to the fuel supply or battery respectively, which allows the vehicle to be mobilised. In another example, other criteria may also need to be met for the vehicle to be mobilised, such as having valid car key or car fob. If the control signal 110 indicates that the vehicle should be immobilised (e.g., because the user’s driving licence or insurance is invalid), then the controller 100 or vehicle immobilisation system 102 may send a signal to the fuel supply or battery respectively to immobilise the vehicle.

The processor 106 may be arranged to generate an authentication request for the authentication server, requesting confirmation of the authentication status of the driver. This for example may occur when vehicle detects a user has entered the vehicle, the vehicle is unlocked, or the vehicle is turned on, or it may occur periodically (e.g., every 24 hours). The output 108 may be arranged to output the authentication request to the authentication server.

The controller 100 may be configured to generate the authentication request for the authentication server, requesting confirmation of the authentication status of the driver, and output the authentication request to the authentication server periodically, for example every 24 hours. The controller 100 may comprise a timer or clock configured to prompt the processor to generate the authentication request periodically (e.g., after a pre-determined period has passed, such as 24 hours). This allows the driving licence and motor insurance details to be checked regularly (e.g., every 24 hours). A user may need to be authenticated before the vehicle can be mobilised. For example, a user may have to correctly insert a password, use facial recognition, and/or touch identification to access the application associated with the vehicle immobiliser system or the “wallet” of a smartphone. They may also select that they wish to drive a particular vehicle associated with their account. This authentication step may be required each time the user wishes to drive the vehicle/ once the engine has been turned off and the user wishes to drive again.

The input 104 may also be arranged to receive driver identification data. This may for example be carried out to confirm the user’s identity. User verification may be conducted to confirm the user driving is a user whose driving licence and/or motor insurance details have been checked and found to be valid. The authentication request may comprise the driver identification data and as such, the control signal, and whether the driver is authenticated to drive the vehicle or not, may be dependent on the driver identification data. The driver may for example be authenticated to drive the vehicle if their identity is confirmed as being a user who is registered to drive the vehicle, or a user who has met other criteria (e.g. a user with a valid driving licence and/or motor insurance).

User verification may for example involve a user confirming their identity by logging into an application on their personal device (e.g. smartphone) with biometric identification (e.g., touch identification, facial recognition, voice recognition, iris recognition, retina recognition etc.), a password, or a passcode. Once the user has successfully logged into the application, the user may for example select the vehicle they wish to drive. The user may be required to set up the biometric identification capability in their personal device. For example, the user may be required to provide their fingerprint, image of their face and/or eye, and/or voice etc., which may be stored as reference data. When a user later provides their biometric data to verify their identify, the biometric data provided may be compared to the reference data. If the biometric data provided corresponds to the reference data, the user’s identify may be considered to be verified.

Alternatively, or additionally, user verification may involve a user verifying their identity via an identity verifier of the vehicle. For example, the vehicle may comprise one or more sensors for biometric identification (e.g., a touch sensor to identify a user via their fingerprint (touch identification), a camera to identify a user via their facial features (facial recognition), iris (iris recognition), infra-red scanner to scan a user’s retinal pattern to identify a user (retina recognition), a microphone to identify a user through their voice (voice recognition), and/or a user interface for a user to input a password or passcode. The user may be required to set up the biometric identification capability in their vehicle. For example, the user may be required to provide their fingerprint, image of their face and/or eye, and/or voice etc., which may be stored in a datastore of the vehicle or external storage system (e.g. in the cloud) as reference data. When a user later provides their biometric data to verify their identify, the biometric data provided may be compared to the reference data. If the biometric data provided corresponds to the reference data, the user’s identify may be considered to be verified. Once a driver’s identify has been verified, the driver is found to have a valid driving licence and/or the driver is found to have valid motor insurance, a signal may be sent from the personal device, or from a processor of the vehicle, to a controller in the vehicle, indicating that the vehicle can be mobilised. If the driver’s identify cannot be verified, or the identified driver does not have a valid driving licence and/or valid motor insurance, a signal may be sent from the controller to the immobilisation system, instructing the immobilisation system to prevent the vehicle from starting (immobilise the vehicle).

The processor 106 may also be arranged to generate a driver identification request and the output 108 may be arranged to output the driver identification request to an identification server. For example, the identity of the driver may be determined by an external system.

Figure 2 shows an example authentication server 200 for determining an authentication status of a driver of a vehicle, the authentication status indicating whether the driver is authenticated to drive the vehicle. The authentication server 200 may comprise an input 202, a processor 204, and an output 206. The input 202 may be arranged to receive an authentication request from a requesting device requesting the authentication status of the driver. The requesting device may for example comprise but is not limited to the controller 100 (e.g., a mobile phone, or an embedded controller), or the vehicle itself. The processor 204 may be arranged to determine the authentication status and generate an authentication status message (e.g. signal) comprising an indication of whether the driver of the vehicle is authenticated to drive the vehicle. The output 206 may be arranged to output the status message to the requesting device.

Vehicle owners may input their driving licence number on a website or application. Alternatively or additionally drivers may input driving licence data by taking a picture of their driving licence or scanning it and uploading it to the server. Such data may also be held in the central database. The processor 204 of the authentication server may be configured to determine if the driving licence is valid. This may for example be done by searching a register of the driving authority of the relevant country, such as the Driver and Vehicle Licencing Agency (DVLA) in the UK, based on the driving licence details input or driver identified, and determining whether a valid driving licence exists corresponding to the driving licence details input, or driver identified. Alternatively, external checks may be conducted by the relevant driving authorities within that country, to ascertain if the driving licence is indeed valid. Accordingly, determining the authentication status may comprise sending a search request to a vehicle licensing authority to check the status of a driving licence associated with the driver. The driving licence details given may also need to match personal details input (e.g., name, date of birth, address, etc.). The processor 204 may be arranged to generate the authentication status message in dependence on the driving licence search result. If valid driving licence details are found in the database of valid driving licences corresponding to the driving licence details that have been provided by the user, the driving licence details input by the user may be deemed valid. If no valid driving licence details are found in the database of valid driving licences corresponding to the driving licence details that have been provided by the user, the driving licence details input by the user may be deemed invalid. If the driving licence is not valid, for example through a driving ban, driving disqualification or being a provisional licence holder only, the authentication status message may comprise an indication that the driver is not authenticated to drive the vehicle. The authentication status message may also comprise an indication that the driver is not authorised to drive the vehicle if no driving licence details have been provided, or the driving licence details have not been provided sufficiently (e.g., with data missing). The processor of the controller may be arranged to generate a control signal comprising instructions to immobilise the vehicle. A vehicle immobiliser may be configured to immobilise the vehicle. For example, a transmitter (output) may be blocked from sending out signals/codes to immobilise the vehicle. If the driving licence is valid, the authentication status message may comprise an indication that the driver is authenticated to drive the vehicle. The processor of the controller may be arranged to generate a control signal comprising instructions to mobilise the vehicle.

The processor 204 may further be arranged to store the driving licence search result in a data store (e.g., indicating the driver is banned until a particular data so the system does not need to keep checking the register). Driving licence details associated with a user may be stored in the database which can be used once the driving ban has ceased or amended when a new licence following disqualification has been supplied, or a full licence has been issued to a new driver.

The user may also input their motor insurance details, and the authentication server may be configured to determine an authentication status of the driver comprising whether the user’s motor insurance is valid, for example by searching a register of insured vehicles in the country in which the user is based, such as the Motor Insurance Database in the UK (also known as the Motor Insurers Bureau), based on the driver identified or insurance details input. The processor may search for motor insurance details that correspond to the motor insurance details that have been input by the user, or that correspond with the user identified. Alternatively, external checks may be conducted to ascertain if the insurance policy is still active and valid. If the policy is not valid or does not exist through expiration or cancellation, the vehicle immobiliser system may be configured to immobilise the vehicle. If the driver does have a valid motor insurance policy the vehicle immobilisation system may be configured to mobilise the vehicle. If valid motor insurance details are found in the database of valid motor insurance corresponding to the motor insurance details input or the driver identified, the motor insurance of the user may be deemed valid. If no valid motor insurance details are found in the database of valid motor insurance corresponding to the motor insurance details input or the driver identified, the motor insurance of the user may be deemed invalid.

The authentication server 200 may access real time data from databases held by relevant authorities and agencies for any country, relating to that country’s driving requirements.

The processor 204 of the authentication server may be arranged to determine the authentication status by sending a search request to a vehicle insurance authority to check the status of motor insurance associated with the driver. The input may be arranged to receive a motor insurance search result from the vehicle insurance authority.

The authentication server 200 may access an external database of motor insurance in the country in which the user is based, such as the Motor Insurance Database of the Motor Insurers Bureau, which includes a record of all insured vehicles in the UK, and search for the motor insurance details that correspond to the motor insurance details that have been input by the user or that correspond to the driver identified. The processor 204 of the authentication server may be arranged to generate the authentication status message in dependence on the motor insurance search result. If valid motor insurance details are found in the database of valid motor insurance, indicating that the driving licence details input by the user are valid, the processor of the authentication server may generate the authentication status message comprising an indication that the driver is authenticated to drive the vehicle. The processor may generate a control signal, output to the vehicle immobilisation system, comprising instructions to mobilise the vehicle. If valid motor insurance details are not found in connection with the driver, the processor 204 of the authentication server may generate the authentication status message comprising an indication that the driver is not authenticated to drive the vehicle. The processor may generate a control signal, output to the vehicle immobilisation system, comprising instructions to immobilise the vehicle.

The authentication server 200 may be configured to check the external database(s) of valid driving licences and motor insurance to determine whether the provided driving licence and/or motor insurance are valid at repeating intervals (e.g., every 24 hours). This ensures that if a user’s driving licence becomes invalid (e.g. suspended, revoked or expires), or the user’s motor insurance is no longer valid, they cannot continue to drive (an instruction is sent to the controller of the vehicle to immobilise the vehicle and prevent it from starting).

A central database may be configured to receive and store data relating to vehicles and customers, such as but not limited to driving licence and motor insurance details and personal data (e.g., name, date of birth, address etc.). This may for example include driving licence and/or motor insurance details provided by the user, and/or driving licence and/or motor insurance search results. The central database may be external to the vehicle (e.g. such data may for example be stored in a remote database, or the cloud) or may be part of the vehicle.

The authentication server 200 may be configured to determine the authentication status by retrieving a driving licence search result from a data store. The driving licence search result may be required to have been received from a vehicle licensing authority within a pre-determined period and generate the authentication status message in dependence on the stored driving licence search result. For example, if the driving licence search result has been obtained within the last 24 hours or any other time frame, the authentication status may be obtained from the data store (or central database), whereas if more than this pre-determined period has passed (e.g., 24 hours) since the driving licence search results were obtained, a new search request may be sent to the vehicle licensing authority to check the status of a driving licence associated with the driver (e.g., in case it has been suspended or revoked since the last check was carried out).

The authentication server 200 may be configured to determine the authentication status by retrieving a motor insurance search result from a data store. The motor insurance search result may be required to have been received from a vehicle insurance authority within a pre-determined period and generate the authentication status message in dependence on the stored motor insurance search result. For example, if the motor insurance search result has been obtained within the last 24 hours or any other time frame, the authentication status may be obtained from the data store (or central database), whereas if more than this pre-determined period has passed (e.g., 24 hours) since the motor insurance search results were obtained, a new search request may be sent to the vehicle insurance authority to check the status of the motor insurance associated with the driver (e.g., in case it has lapsed since the last check was carried out).

If the user is found to have a valid driving licence and valid motor insurance, the user’s driving licence and motor insurance details may be stored, optionally with their personal details (personal data) at the central database. Checks on the driver’s driving licence and insurance policy may be conducted automatically, every 24 hours, without requiring further input from the user. The authentication server may be configured to determine an authentication status of the driver and whether the user’s driving licence and insurance policy is valid periodically, such as every 24 hours.

The central database may also be configured to receive vehicle data, for example provided by the vehicle manufacturer.

Vehicle data provided by the manufacturer of the vehicle may for example comprise the chassis number (Vehicle Identification Number), make, model, specifications, colour, date built, and/or number plate. This data may be received and held within the central database. The chassis number can identify a vehicle and so even if a criminal changes the number plate of a vehicle it is still possible to identify the vehicle and its rightful owner. Storing the vehicle data therefore can prevent criminals trying to clone a vehicle by using a number plate already in circulation by another user or vehicle. Each vehicle that leaves the factory may be assigned a number plate (or a series of number plates for a customer to select from) attributed to that chassis number once selected. A user may input a number plate and chassis number for the vehicle they wish to drive into a website or application associated with the vehicle immobilisation system. If a user tries to input a number plate and chassis number for a particular vehicle, the authentication server may be configured to crosscheck the input vehicle data with the vehicle data stored in the database. If the input number plate is determined to be associated with a different chassis number, the authentication server may be configured to generate an authentication status message indicating that the driver is not authenticated to drive the vehicle and output the authentication status message to the requesting device. The vehicle immobiliser system may be configured to prevent that user from mobilising the vehicle. Accordingly, by asking users to provide and/or storing the chassis number, it is far less likely that chassis numbers will be copied and "cloned". Since chassis numbers are only associated with particular number plates, when a user inputs a number plate or chassis number only, the associated chassis number or number plate may be available for selection.

Customer data may also be input by a vehicle owner (for example users owning a newly manufactured or second-hand vehicle) into a website or application and may for example comprise the name, date of birth, telephone number, e-mail address and/or home address of the vehicle owner. This data may be stored at the central database. The vehicle owner may also input the number plate of their vehicle into the website as discussed above, which may auto populate the vehicle details stored within the database, such as the chassis number.

All data may be stored securely at the central database. The data may be accessible by a user via their password-protected account profile on an application associated with the vehicle immobilisation system. They may also extract the data from their account and store it within their smartphone.

The vehicle may comprise a GPS tracker configured to track the location of the vehicle. The GPS tracker can be active or passive or both, for example depending on the preference of the owner of the vehicle. An active GPS tracker transmits location data in real-time and a passive GPS tracker records where the vehicle has been and does not report real-time data. The passive GPS tracker may for example be activated once a vehicle or other property fitted with a GPS tracker has been stolen. The immobiliser can prevent the vehicle from starting again once the engine has been switched off and the GPS tracker can transmit the location of the vehicle allowing local authorities to recover the vehicle by visiting the location determined by the GPS tracker.

The GPS tracker may be part of the controller or the vehicle. The GPS tracker may for example be located within the immediate proximity of the receiver (input). The GPS tracker and receiver may be encased together. The GPS tracker can be active or passive, for example depending in the customer’s preference. The GPS tracker may allow the vehicle to be immobilised once the engine or battery has been shut down and the vehicle is stationary. For example, the GPS tracker can house a remote vehicle disabling system which prevents the engine being started irrespective if the driver has the key or the personal device associated with a driver meeting the specified criteria. This is useful if criminals steal an already-mobilised vehicle or a personal device (e.g., smartphone or wearable device) containing the data required to mobilise the vehicle (i.e., a device associated with a driver meeting the specified criteria). If a user has been a victim of crime where the vehicle was already mobilised prior to the theft, or the personal device associated with a user authorised to drive the vehicle has been stolen alongside the vehicle, the immobiliser can still be activated once requested by the user. The controller can block any coded signals the transmitter is transmitting and, once recovered, all codes may be changed. If criminals identify the GPS tracker and remove it, the controller may be configured to immobilise the vehicle.

The controller 100 may comprise a pre-coded Near-field communication (NFC) card which may come as standard with the vehicle. This is to make sure the customer can still mobilise a vehicle if the smartphone or wearable device is lost, stolen, damaged or out of battery. Once this NFC card is activated (e.g., presented to an NFC reader within the vehicle), the controller 100 may determine that the usual method to mobilise the vehicle (e.g., through confirming their identity via the user’s personal device) has not been used and allow the vehicle to mobilise the vehicle for a limited time (e.g. 8 hours). Once this card has been used, it may have a life span of a pre-defined period (e.g. 7 days) before a new card is issued with a different code. If the pre-coded NFC card is used, the user may receive an alert via a notification on their mobile device, for example via an application, short message service (SMS) and/or E-mail). If the user did not use the NFC card (and therefore it is an unauthorised driver who is trying to mobilise the vehicle), the vehicle may be immobilised at the next opportunity when the engine or battery is shut off and the vehicle is stationary. If the user confirms that they have used the NFC card, the NFC card may remain active until the user has set up a new personal device to verify that they are entitled to mobilise the vehicle such that going forwards it can become the main device used to mobilise the vehicle, rather than the NFC card. The NFC card can be disposed of, and a new card delivered or collected from a dealership.

Figure 3 shows a method 300 for controlling a vehicle immobilisation system. The method comprises at Step 302 receiving, at an input, an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle. The method also comprises at Step 304 generating, at a processor, a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle. The method also comprises at Step 306 outputting, at an output, the control signal to the immobilisation system.

Figure 4 shows a method 400 for determining an authentication status of a driver of a vehicle the authentication status indicating whether the driver is authenticated to drive the vehicle. The method comprises at Step 402 receiving, at an input, an authentication request from a requesting device, the authentication request requesting the authentication status of the driver and the requesting device being associated with the vehicle. The method also comprises at Step 404 determining, at a processor, the authentication status and generating, at the processor, an authentication status message, the authentication status message comprising an indication ofwhetherthe driver of the vehicle is authenticated to drive the vehicle. The method also comprises at Step 406 outputting, at an output, the authentication status message to the requesting device. An example method of a driver being authenticated to drive will now be described. The method may involve a user providing customer (personal) details to a website or application associated with the vehicle immobilisation system, which may include their name, address, and contact details etc. The method may involve a user also providing their driving licence and motor insurance details to the website or application and the manufacturer of the vehicle providing vehicle data, which may include the vehicle chassis number. The method may comprise storing the vehicle data, customer data, driving licence data and/or motor insurance data at a central database. The method may comprise crosschecking the driving licence and insurance details provided against driving licence and insurance records in official registers and determining whether the driving licence and insurance details are valid. If the driving licence and insurance is found to be valid, the method may further involve transmitting a further signal indicating the user has been verified (e.g., because the user has successfully logged into the application or opened the “wallet” section of their smartphone using a password, facial recognition or touch identification and selected that they wish to drive the vehicle) and that their driving licence and/or motor insurance is valid to the engine control unit or battery management system and the vehicle can be mobilised. If the driving licence and/or insurance is found to be invalid, the method may involve transmitting a signal to the receiver indicating the vehicle should be immobilised and the engine control unit or battery management system sending a signal to the fuel supply or battery respectively to immobilise the vehicle.

Once it is determined that the user meets the criteria for driving lawfully on the roads (e.g., valid driving licence and motor insurance etc.) a signal may be sent by the transmitter to the controller indicating that the driver meets the criteria and the vehicle should be mobilised. The signal may be encrypted. Alternatively, a signal may only sent by the transmitter to immobilise the vehicle if it is determined that the user does not meet the criteria for driving lawfully on the roads. The signal, which may be encrypted, may indicate that the driver does not meet the criteria and that the vehicle should be immobilised.

Additional Users

Once the user, who may be the owner or registered keeper, has associated their driving licence, insurance and personal data with their vehicle, third party users can also request to be a driver of the vehicle and enter their personal details, driving licence number and/or insurance policy details. If the central database already has data for an owner of that vehicle, the third-party user may request to be an additional driver to that vehicle. The third-party users can be authorised to mobilise the vehicle if they have a valid driving licence, valid motor insurance and/or their request has been approved by the owner or registered keeper of the vehicle. The third party may be required to have insurance that allows them to drive other vehicles and the vehicle they wish to drive may need to have fully comprehensive cover. The owner of a vehicle that the third-party is trying to align themselves to, may receive a notification within the smartphone application or wearable device application. They may also be sent an SMS or e-mail to alert them that another person would like access to their vehicle. The owner may be given an option to accept the request or deny the request. If accepted, the owner may have the right to remove any third-party users from their vehicle at any time. Alternatively, if denied, the third-party user may have an option to request access another time. If the owner does not know of the third-party who is trying to seek access to their vehicle, they can report the third-party user and they may no longer be able to send a drive request to the owner.

Multi-Vehicle Use

A person may for example be able to store multiple vehicles on their personal account (e.g., up to eight). They may then have an option to select which vehicle they wish to mobilise at any time. The system may be configured such that that person can only mobilise one vehicle at a time, to prevent a person from mobilising vehicles and giving them to third parties fortheir use. The third-party members may need to register as discussed above.

If a person, who has a valid driving licence, works for an organisation that allows them to drive one of many from a fleet of vehicles, then the person may have a commercial account. The person may have a personal account (fortheir own vehicle(s)) and a commercial account. The commercial account may be somewhat similar to the personal account. Vehicle data may be received from vehicle manufacturers and stored within the central database. Users, such as members of a management or human resources team, may input their employee’s driving licence into the website or application, on the commercial account. Vehicle data, driving licence data, motor insurance data and/or other input data can be provided by the driver or company, and compared in real time with stored vehicle data, driving licence data, motor insurance data and/or other stored data in one or more databases or official registers to determine whether the input data is valid. The insurance details to be input may be that of the organisation and may be a multi-fleet vehicle policy. If the driver’s driving licence and the insurance policy is valid the employee may be given an NFC card, which can allow the driver to mobilise the vehicle belonging to the organisation. The NFC card may also double up as relevant employee documentation and identification.

The authentication server may also ascertain if the employee has passed additional tests which may include the ability to drive light commercial vehicles (LCV), Heavy Goods Vehicles (HGV) or minibuses/buses/coaches. This will prevent employees from driving a vehicle they have not had an approved test to certify they are fit to drive such vehicles.

Advantages An advantage of the described system is that the roads will become safer. Drivers will have been checked for relevant driving documents, optionally daily. This, overtime (as more and more vehicles are manufactured to include the described system), prevents banned, disqualified, provisional only licence holders (unless supervised) and uninsured drivers from driving on the roads. All vehicles have a shelf life, and, if newly manufactured vehicles are fitted with an immobiliser as described herein, as the older vehicles get scrapped, more and more newly manufactured vehicles will enter the roads with the new immobiliser. As time goes by, criminals will realise that newly manufactured vehicles have a remote, smart immobiliser, and that the vehicle will be recovered. This has a massive positive impact on the public, as homes will become less likely to be burgled for car keys, there will be less car thefts thereby improving the security of vehicles, people will be less likely to succumb to violence to steal vehicles, and house and vehicle insurance are likely to decrease.

The described system further assists law enforcement in battling serious and organised crime. Persons may attribute themselves to a vehicle and provide data indicating who is driving the vehicle. Any person may be permitted to sit inside the vehicle, however, only drivers who meet certain criteria such as having a valid driving licence and/or driving insurance policy may be able to drive it. By having a system that identifies the driver that has mobilised the vehicle criminals are essentially putting themselves at the scene of a crime. This is because the user may need to be verified to mobilise the vehicle and/or the system may be configured such that only people registered to the vehicle can mobilise it - the vehicle owner and third parties the vehicle owner has granted access to the vehicle, who may have had to provide a valid driving licence which will identify them. The controller may also be configured to determine which user the personal device which emitted the control signal allowing the vehicle to be mobilised is associated with. The criminal may have had to provide a valid driving licence in order to mobilise the vehicle and the driving licence will likely have photographic identification on it. The transmitter of the driver’s personal device (such as a smart phone) may also emit radio signals to transmit data such as the identity of the driver to the controller, which further helps to identify criminals who have committed crimes while driving a vehicle with the described immobilisation system.

Allowing the owner to remove third party access may further reduce the number of domestic related theft of motor vehicles, where all parties in the relationship may have once had legitimate access to the vehicle and may also find themselves with a car key each. If that relationship breaks down, an abuser’s controlling behaviour may be reduced by removing the abuser’s access to a vehicle they once shared with a partner, irrespective of if they still have a car key.

A further advantage of the described system is that it can prove who the driver was when an offence took place, even when multiple people are registered with a particular vehicle (e.g. a couple who share a car). For example, it can prove who was driving the vehicle when a vehicle was driven through a red traffic light. This is because the driver’s identity may be required to be determined for the vehicle to be mobilised. Data relating to the identity of the driver and the time at which the vehicle was driven by that driver may be stored in a database.

Law enforcement officers may also receive a signal indicating who the last person to drive the vehicle within a timeframe was.

Claims

1 . A controller for a vehicle immobilisation system, the controller comprising: an input arranged to receive an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle; a processor arranged to generate a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle; an output arranged to output the control signal to the immobilisation system.

2. A controller as claimed in Claim 1 , wherein, prior to receiving the authentication status message, the processor is arranged to generate an authentication request for an authentication server, the authentication request requesting confirmation of the authentication status of the driver and the output is arranged to output the authentication request to the authentication server.

3. A controller as claimed in Claim 2, wherein the input is arranged to receive driver identification data.

4. A controller as claimed in Claim 3, wherein the driver identification data comprises biometric data and/or data associated with a mobile device of the driver.

5. A controller as claimed in Claim 4, wherein the authentication request comprises the driver identification data.

6. A controller as claimed in Claim 3 or Claim 4, wherein the processor is arranged to verify the identity of the driver from the received driver identification data and the authentication request comprises the identity of the driver.

7. A controller as claimed in Claim 6, wherein the processor is arranged to generate a driver identification request and the output is arranged to output the driver identification request to an identification server.

8. A mobile phone device comprising a controller according to any one of claims 1 to 7.

9. A vehicle comprising a controller according to any one of claims 1 to 7.

10. A vehicle as claimed in Claim 9, comprising a vehicle immobilisation system.

11. A vehicle as claimed in Claim 9 or 10, comprising an NFC reader configured to interact with an NFC authentication card.

12. A vehicle as claimed in Claim 11 , comprising a processor and a communications output wherein in the event a driver interacts with the NFC reader using the NFC authentication card, the processor is arranged to generate the authentication request and the output is arranged to output the authentication request to the authentication server.

13. An authentication server for determining an authentication status of a driver of a vehicle, the authentication status indicating whether the driver is authenticated to drive the vehicle; the authentication server comprising: an input arranged to receive an authentication request from a requesting device, the authentication request requesting the authentication status of the driver and the requesting device being associated with the vehicle; a processor arranged to determine the authentication status and to generate an authentication status message, the authentication status message comprising an indication of whether the driver of the vehicle is authenticated to drive the vehicle; an output arranged to output the authentication status message to the requesting device.

14. An authentication server as claimed in Claim 13, wherein determining the authentication status comprises sending a search request to a vehicle licensing authority to check the status of a driving licence associated with the driver and wherein, the input is arranged to receive a driving licence search result from the vehicle licensing authority.

15. An authentication server as claimed in Claim 14, wherein the processor is arranged to generate the authentication status message in dependence on the driving licence search result.

16. An authentication server as claimed in Claim 14 or 15, wherein the processor is arranged to store the driving licence search result in a data store.

17. An authentication server as claimed in Claim 13, wherein determining the authentication status comprises retrieving a driving licence search result from a data store, the driving licence search result having been received from a vehicle licensing authority within a pre-determined period and the processor is arranged to generate the authentication status message in dependence on the stored driving licence search result.

18. Au authentication server as claimed in of Claims 13 to 17, wherein determining the authentication status comprises sending a search request to a vehicle insurance authority to check the status of motor insurance associated with the driver and wherein, the input is arranged to receive a motor insurance search result from the vehicle insurance authority.

19. An authentication server as claimed in Claim 18, wherein the processor is arranged to generate the authentication status message in dependence on the motor insurance search result.

20. An authentication server as claimed in Claim 18 or 19, wherein the processor is arranged to store the motor insurance search result in a data store.

21 . An authentication server as claimed in Claim 13 to 17, wherein determining the authentication status comprises retrieving a motor insurance search result from a data store, the motor insurance search result having been received from a vehicle insurance authority within a pre-determined period and the processor is arranged to generate the authentication status message in dependence on the stored motor insurance search result.

22. An authentication server as claimed in Claim 19 or 21 , wherein the authentication status message is configured to indicate the driver is authenticated to drive the vehicle in the event that both the driving licence search result corresponds to a valid driving licence and the motor insurance search result corresponds to a valid motor insurance policy.

23. An authentication server as claimed in Claim 19 or 21 , wherein the authentication status message is configured to indicate the driver is not authenticated to drive the vehicle in the event that the driving licence search result corresponds to an invalid driving licence and/or the motor insurance search result corresponds to an invalid motor insurance policy.

24. An authentication server as claimed in any of Claims 13 to 23, wherein the input is arranged to receive a notification that the vehicle has been stolen, the processor is arranged to generate a tracking signal to a tracker on the vehicle and the output is arranged to output the tracking signal in order for the authentication server to track the vehicle.

25. An authentication server as claimed in any of Claims 13 to 24, wherein the processor is arranged to generate an authentication status message indicating that the driver is not authenticated to drive the vehicle in the event that the input has received a notification that the vehicle has been stolen.

26. An authentication server as claimed in Claim 25, wherein the processor is arranged to generate an immobilisation signal for the vehicle immobilisation system and the output is arranged to output the immobilisation signal to the vehicle.

27. An authentication server as claimed in any of claims 13 to 26, wherein the requesting device is the controller according to any one of claims 1 to 7.

28. An authentication server as claimed in any one of Claims 13 to 27, wherein the requesting device is the vehicle, the authentication request comprising an indication that it has been generated in response to a vehicle user interacting with an NFC reader within the vehicle using an NFC authentication card.

29. Au authentication server as claimed in Claim 28, wherein the processor is arranged to perform one or both of the following: generate a tracking signal to a tracker on the vehicle and to output the tracking signal via the output; generate a notification message to the vehicle owner to notify them that the NFC authentication card has been used and to output the notification message via the output.

30. An authentication server as claimed in any of claims 13 to 29, wherein the input is arranged to receive driver identification data from the requesting device.

31 . An authentication server as claimed in claim 30, wherein the processor is arranged to identify the driver from the received driver identification data and to include the identity of the driver in any search requests sent to a vehicle licensing authority or vehicle insurance authority.

32. A method of controlling a vehicle immobilisation system, the method comprising: receiving an authentication status message from an authentication server, the authentication status message comprising an indication of whether a driver of the vehicle is authenticated to drive the vehicle; generating a control signal for the vehicle immobilisation system in dependence on the received authentication status message, the control signal comprising instructions to either mobilise the vehicle if the driver is authenticated to drive the vehicle or immobilise the vehicle if the driver is not authenticated to drive the vehicle; outputting the control signal to the immobilisation system.

33. A method of determining an authentication status of a driver of a vehicle, the authentication status indicating whether the driver is authenticated to drive the vehicle; the authentication server comprising: receiving an authentication request from a requesting device, the authentication request requesting the authentication status of the driver and the requesting device being associated with the vehicle; determining the authentication status and generating an authentication status message, the authentication status message comprising an indication of whether the driver of the vehicle is authenticated to drive the vehicle; outputting the authentication status message to the requesting device

34. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claim 32 or 33.

35. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 32 or 33.