GB2614242A

GB2614242A - A device for displaying vehicle status information

Info

Publication number: GB2614242A
Application number: GB2118675.4A
Authority: GB
Inventors: Steven Piacun Anthony; Charles Piacun Nicholas; Alan Wood Trevor
Original assignee: Vehicle Smart Disc Uk Ltd
Current assignee: Vehicle Smart Disc Uk Ltd
Priority date: 2021-12-21
Filing date: 2021-12-21
Publication date: 2023-07-05

Abstract

A device 100 for displaying vehicle status information has a controller configured to receive information indicating a status of a vehicle from a transceiver. An output means 102 provides an output based on the received vehicle status information. Preferably, the vehicle status information is a tax expiry date and a vehicle safety certificate (MOT) expiry date, and the output means uses LED indicators 102 to output different colours based on the expiry dates. For example, the colours may be green, orange and red. The device also displays vehicle identification information, such as a vehicle registration number, on its display 101. Preferably, the device requests and receives the vehicle status information from a server via its transceiver. The device may have a visual indication of its unique identification number 103 on its housing.

Description

A device for displaying vehicle status information

FIELD

Embodiments described herein relate generally to a device and method for displaying vehicle status information.

BACKGROUND

In order for a vehicle to be driven legally, various requirements relating to the vehicle status must be met. For example, vehicle tax (also referred to as road tax) is a payment required by an owner of a road-using vehicle in the United Kingdom (UK). Vehicle tax is paid for a period of time (e.g. for one year) in relation to the vehicle. At the end of the period, the tax must be renewed (e.g. by paying for another year's worth of road tax) in order for the vehicle to be driven legally. The vehicle tax is said to have expired when the period for which tax has been paid has elapsed. In order for a vehicle to be driven legally, the tax status of the vehicle must be "unexpired". Furthermore, in order for a vehicle to be driven legally in the UK, the vehicle must have been certified as being safe, or roadworthy, within a certain previous time period. For example, the vehicle must have passed a test certifying the vehicle safety, roadworthiness and/or exhaust emissions within the previous year. In the UK, this test is referred to as an 'MOT' test (Ministry of Transport test). In order for a vehicle to be driven legally, the vehicle safety status of the vehicle must be "unexpired".

Currently, the status of vehicles on the road in the UK is monitored using camera vans employing automatic number plate recognition (ANPR) cameras, as well as personnel such as traffic wardens or police performing road-side checks. This system of monitoring is resource intensive.

Furthermore, it can be challenging to use this system to monitor large numbers of vehicles, which can lead to road users continuing to use a vehicle for which the vehicle safety status is "expired", or for which the tax status is "expired", without being detected. Furthermore, it is difficult for users of vehicles themselves to stay updated as to the tax status or vehicle safety status of their vehicle, which can lead to road users unintentionally using a vehicle for which the vehicle safety status is "expired", or for which the tax status is "expired".

BRIEF DESCRIPTION OF DRAWINGS

Arrangements will now be described by way of example only, with reference to the accompanying drawings in which: Fig. 1A shows a perspective view of a device according to an example; Fig. 1B shows a side view of the device according to an example; Fig. 2 shows a device according to example; Fig. 3 shows a system according to a first example; Fig. 4A shows a method performed by a device according to an example; Fig. 4B shows a method performed by a second server according to an example; Fig. 4C shows an example of a database maintained by the second server according to an

example;

Fig. 4D shows a method of processing second vehicle status information according to an example Fig. 5A shows an example of a database maintained by the first server; Fig. 5B shows a method of registering a device performed by the first server according to an example; Fig. 5C shows a method of registering a device performed by the device according to an example; Fig. 6A shows a method performed by a device according to a second example; Fig. 7A shows a system according to a second example; Fig. 7B shows a method performed by a first server according to a further example; Fig. 8 shows a second method performed by the device according to an example; Fig. 9A shows an implementation of a controller in a device according to an example; Fig. 9B shows an implementation of a first server according to an example; Fig. 10 shows a method of manufacturing the device according to an example.

DETAILED DESCRIPTION

According to a first aspect there is provided a device for displaying vehicle status information comprising: a transceiver; an output means; a display; and a controller communicatively coupled to the transceiver, the output means and the display, the controller being configured to: receive information indicating a status of a vehicle from the transceiver; control the display to display vehicle identification information; and control the output means to provide an output based on the information indicating the status of the vehicle.

In an embodiment the device further comprises a positioning module configured to determine the position of the device. Optionally the device is configured to transmit position information obtained from the positioning module.

In an embodiment, the device is mountable within the vehicle. In an embodiment, the vehicle is for use on the road.

In an embodiment, the output means is configured to provide a visual output.

In an embodiment the output means comprises a light emitting diode, and the controller is configured to control an output colour of the light emitting diode based on the information indicating the status of the vehicle.

In an embodiment the information indicating the status of the vehicle comprises a tax expiry date and a vehicle safety certificate expiry date; and wherein the controller is configured to control the output colour of the light emitting diode based on the tax expiry date and the vehicle safety certificate expiry date.

In an embodiment the controller is further configured to cause the light emitting diode to: output a first colour in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; output a second colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; and output a third colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.

In an embodiment the information indicating the status of the vehicle has one of a plurality of values, the plurality of values comprising a first value, a second value and a third value. In an example the information indicating the status of the vehicle equals one of the plurality of levels. In an embodiment the controller is configured to cause the output means to: output a first colour when the information indicating the status of the vehicle has the first value; output a second colour when the information indicating the status of the vehicle has the second value; and output a third colour when the information indicating the status of the vehicle has the third value.

In an embodiment the device comprises a housing; and a visual indication of the identification number on the housing.

In an embodiment the controller is further configured to transmit a request for information indicating the status of the vehicle.

In an embodiment the request comprises the vehicle identification information and/or an identification number associated with the device. In an embodiment the vehicle identification information comprises a vehicle registration number and the identification number associated with the device comprises a unique serial number.

In an embodiment the controller is further configured to receive the vehicle identification information from the transceiver.

According to a second aspect there is provided a system comprising: a device as described above; and a first server configured to: transmit information to the device indicating the status of the vehicle.

In an embodiment the first server is further configured to: receive a first request for information indicating the status of the vehicle from the device.

In an embodiment the system further comprises a second server and wherein the first server is further configured to: transmit a second request to the second server in response to receiving the first request; receive a second response from the second server; and transmit the information to the device indicating the status of the vehicle, wherein the information is based on the second response.

In an embodiment the second response from the second server comprises a tax expiry date and a vehicle safety certificate expiry date.

In an embodiment the first server is further configured to: set the status of the vehicle to a first value in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; set the status of the vehicle to a second value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; and set the status of the vehicle to a third value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.

In an embodiment the information indicating the status of the vehicle comprises the tax expiry date and the vehicle safety certificate expiry date.

In an embodiment the first request comprises an identification number of the device; and wherein the first server is further configured to: determine vehicle identification information associated with the device based on the identification number of the device; and transmit the second request to the second server, the second request comprising the vehicle registration number.

In an embodiment the first server is configured to: receive a third request to update a database maintained by the first server, the third request comprising an identification number and vehicle identification information; update the database to associate the identification number with the vehicle identification information; and transmit a message to the device associated with the identification number, the message comprising the vehicle identification information.

According to a third aspect there is provided a method for displaying vehicle status information, the method comprising: receiving information indicating a status of a vehicle from a transceiver; controlling a display to display vehicle identification information; and controlling an output means to provide an output based on the information indicating the status of the vehicle.

In an embodiment the method is performed by a device.

In an embodiment the method further comprises determining a position of the device using a positioning module.

In an embodiment the output means comprises a light emitting diode, and the method further comprises controlling an output colour of the light emitting diode based on the information indicating the status of the vehicle.

In an embodiment the information indicating the status of the vehicle comprises a tax expiry date and a vehicle safety certificate expiry date; and wherein the method further comprises controlling the output colour of the light emitting diode based on the tax expiry date and the vehicle safety certificate expiry date.

In an embodiment the method further comprises causing the light emitting diode to: output a first colour in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; output a second colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; and output a third colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.

In an embodiment the information indicating the status of the vehicle has one of a plurality of values, the plurality of values comprising a first value, a second value and a third value.

In an embodiment the method further comprises causing the output means to: output a first colour when the information indicating the status of the vehicle has the first value; output a second colour when the information indicating the status of the vehicle has the second value; and output a third colour when the information indicating the status of the vehicle has the third value.

In an embodiment the method further comprises transmitting a request for information indicating the status of the vehicle.

In an embodiment the request comprises the vehicle identification information and/or an identification number associated with the device.

In an embodiment the method further comprises receiving the vehicle identification information from the transceiver.

In an embodiment the method further comprises transmitting, by a first server, information to the device indicating the status of the vehicle In an embodiment the method further comprises receiving, by the first server, a first request for information indicating the status of the vehicle.

In an embodiment the method further comprises: transmitting, by the first server, a second request to a second server in response to receiving the first request; receiving, by the first server, a second response from the second server; and transmitting, by the first server, the information indicating the status of the vehicle, wherein the information is based on the second response.

In an embodiment the method further comprises: setting, by first server, the status of the vehicle to a first value in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; setting, by the first server, the status of the vehicle to a second value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; and setting, by the first server, the status of the vehicle to a third value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.

In an embodiment the first request comprises an identification number of the device; and wherein the method further comprises: determining, by the first server, vehicle identification information associated with the device based on the identification number of the device; and transmitting, by the first server, the second request to the second server, the second request comprising the vehicle registration number.

In an embodiment the method further comprises receiving, by the first server, a third request to update a database maintained by the first server, the third request comprising an identification number and vehicle identification information; updating, by the first server, the database to associate the identification number with the vehicle identification information; and transmitting, by the first server, a message to the device associated with the identification number, the message comprising the vehicle identification information.

According to a fourth aspect there is provided a non-transitory computer-readable medium comprising computer program instructions suitable for execution by a processor, the instructions configured, when executed by the processor, to: receive information indicating a status of a vehicle from a transceiver; control a display to display vehicle identification information; and control an output means to provide an output based on the information indicating the status of the vehicle.

According to a fifth aspect there is provided a non-transitory computer-readable medium comprising computer program instructions suitable for execution by a processor, the instructions configured, when executed by the processor, to: transmit information to a device indicating the status of a vehicle.

According to a sixth aspect there is provided a device for outputting vehicle status information comprising: a transceiver; an output means; and a controller communicatively coupled to the transceiver and the output means, the controller being configured to: receive information indicating a status of a vehicle from the transceiver; and control the output means to provide an output based on the information indicating the status of the vehicle.

In order for a vehicle to be driven legally, various requirements must be met.

For example, vehicle tax (also referred to as road tax) is a payment made by an owner of a road-using vehicle in the UK. Vehicle tax is paid for a period of time (e.g. for one year). At the end of the period the tax must be renewed (e.g. by paying for another year's worth of road tax) in order for the vehicle to be driven legally. The vehicle tax is said to have expired when the period for which tax has been paid has elapsed. In order for a vehicle to be driven legally, the tax status of the vehicle must be "unexpired". A tax disc is a certificate that is used as evidence to show that the tax has been paid for a vehicle to use the road for a period of time. In the United Kingdom (UK), paper tax discs were previously provided to show that a vehicle had vehicle tax paid up to an expiry date printed on the disc. In the United Kingdom, paper discs were abolished in 2014.

Instead, details of the current tax status of a vehicle are recorded on a centralised database maintained by the Driver and Vehicle Licensing Agency (DVLA).

Furthermore, in order for a vehicle to be driven legally, the vehicle must have been certified as being safe, or roadworthy, within a certain previous time period. For example, the vehicle must have passed a test certifying the vehicle safety, roadworthiness and/or exhaust emissions within the previous year. In the UK this test is referred to as an 'MOT' test. In order for a vehicle to be driven legally, the vehicle safety status of the vehicle must be "unexpired". Details of the current MOT status of a vehicle are also recorded on a centralised database maintained by the DVLA.

Currently, the status of vehicles is monitored using camera vans employing automatic number plate recognition cameras, as well as personnel such as traffic wardens or police performing road-side checks. This system of monitoring is resource intensive. Furthermore, it can be challenging to monitor this information for large numbers of vehicles, which can lead to road users continuing to use a vehicle for which the vehicle safety status is "expired", or for which the tax status is "expired". Furthermore, it is difficult for users of vehicles themselves to stay updated as to the tax status or vehicle safety status of their vehicle, which can lead to road users unintentionally using a vehicle for which the vehicle safety status is "expired", or for which the tax status is "expired". In particular, without paper tax discs, it has become difficult for users of vehicles to stay updated as to the tax status of their vehicle.

In the following description reference is made to a vehicle. A vehicle includes: a car, a motorcycle, a van, a Heavy Goods Vehicle (HGV).

Fig. 1A shows a perspective view of a device according to an example. In particular, Fig. 1A shows a device 100 comprising a display 101, an output means 102 in the form of a light tube coupled to one or more coloured Light Emitting Diodes (LEDs). Optionally the device 100 also comprises information identifying a unique identification number of the device 100, in the form of a OR code 103. The device 100 comprises further components as will be discussed in more detail below. As will also become apparent from the description below, the display 101 is configured to display vehicle identification information (e.g. a vehicle registration number). Optionally the display 101 is also configured to display other vehicle information (e.g. a tax expiry date, a vehicle safety certificate expiry date and/or information indicating insurance information).

In this example the display 101 is an electronic-paper ('e-paper') display. An e-paper display is a low power display. Furthermore an e-paper display has the advantage of longevity in that the information outputted to the display is retained on the display for a long period of time in the absence of any input power. In another example the display 101 uses a different technology. In a further example the display is a Liquid Crystal Display (LCD).

The output means 102 is configured to output information indicating a vehicle status. The output means provides a visual alert that changes appearance depending on the vehicle status information. In this example, the output means 102 comprises one or more multicolour Light Emitting Diodes (LEDs) together with a light pipe, where each LED has green, amber and red output colour options. In another example the output means 102 comprises a plurality of LED's, where each LED is configured to output one colour from: green, amber and red. The output means 102 is configured to indicate one or more vehicle statuses. The output means 102 may indicate a combined vehicle status, based on a tax status and a vehicle safety status of the vehicle for example. For example, a green light is output when the vehicle is fully taxed and has a valid road safety certificate (e.g. a valid MOT), in other words the vehicle tax status is unexpired and the vehicle safety status is unexpired. An orange light (also referred to as 'amber light' throughout the description) is output if the tax or the road safety certificate is due for renewal in the next 30 days, in other words the vehicle tax status is "nearly expired" and/or the vehicle safety status is "nearly expired". A red light is output if either of the tax or the road safety certificate has expired, in other words the vehicle tax status is "expired" and/or the vehicle safety status is "expired".

Although in this example, different colours are used to indicate different vehicle status, alternative visual outputs could be used, for example a flashing light could indicate an expired or nearly expired status.

In this example, the device 100 is cylindrical and disc shaped, in other words the height of the cylinder is less than the radius of the cylinder. The device 100 is a smart disc for a vehicle. The device 100 is of an appropriate size to be displayed in a vehicle, e.g. of a size that can be placed on a dashboard and/or affixed to a windscreen of vehicle. In an example the device 100 has a diameter d of 75 mm and a height h of 8 mm.

Fig. 1B shows a side view of the device according to an example. Fig. 1B uses same reference numbers as Fig. 1A to show same components. Fig. 1B also shows an input/output connector 104. In this example, the connector 104 is a Micro Universal Serial Bus (USB) connector. As will become more apparent from the description below, the input/output connector 104 is configured to provide power to the device 100. In the example shown in Fig. 1B the input/output connector 104 is provided in order to allow an electrical cable to be connected and disconnected to the device 100 (i.e. provides an interface for a removable power cable). In another example (not shown), a power cable is wired into the device 100. Although the specific example shown in Fig. 1B uses a Micro USB connector for conveying power, it is emphasised that other connector forms suitable for conveying electrical power could be used instead including, but not limited to, two wires (e.g. conveying a supply voltage and a ground).

In an example the device 100 is enclosed in a housing. The housing is cylindrical and disk shaped as discussed above. As will be discussed in more detail in relation to Fig. 2, the device 100 contains multiple components. In an example these components are mounted on a Printed Circuit Board (PCB) located within the housing and fixed to the housing. In an example the housing includes a first aperture through which the display 101 is visible. Optionally the housing comprises a second aperture through which a unique serial number etched on the Printed Circuit Board is visible. Optionally the housing comprises a vent on the rear of the housing (i.e. on a side opposing the side of the housing with the aperture for the display 101).

Fig. 2 shows a schematic illustration of various components of the device according to an example. The same reference numerals are used in Fig. 2 as in Fig. 1A and Fig. 1B to denote the same components.

As discussed in relation to Fig. 1B, the device 100 comprises an input/output connector 104. The input/output connector 104 is configured to receive an electrical power cable for powering the device 100. In this example, an electrical cable is wired into the device 100 and the input/output connector 104 comprises the connection to the electrical cable. In this example, the connection is not readily removable, in other words the input/output connector 104 does not comprise a removable plug and socket arrangement. Rather, the cable is connected by means of solder or a clamp for example. In this example, power is supplied to the device 100 from an external power source 206 via the input/output connector 104. Optionally the external power source 206 is a battery of a vehicle, e.g. the car battery of the vehicle in which the device is located In this example the electrical cable is used to electrically couple the external power source 206 to the input/output connector 104.

Optionally, the device 100 comprises a surge protector and filter component 204. The Input/Output connector 104 is electrically coupled to the surge protector and filter component 204.

The surge protector and filter component 204 is configured to protect the components of the device 100 from surges in the supplied voltage. The output of the surge protector and filter component is electrically coupled to the power supply 205.

The power supply 205 is configured to supply electrical power to the controller 201 at a predetermined voltage/current, e.g. as determined by the voltage requirements of the controller 201. The output of the power supply 205 is electrically coupled to the controller 201. Optionally the power supply 205 is also configured to supply power to one or more other components of the device, for example the display 101, the first transceiver 202, the output means 102 and/or the positioning module 203, either directly or indirectly (i.e. via the controller 201).

In an example the surge protector and filter component 204 and the power supply 205 are provided in a single component, optionally in an Integrated Circuit (IC). In an example, the surge protector and filter component 204 and the power supply 205 are provided in a Texas Instruments® LMR36015FBRNXT Integrated Circuit.

Although in this example, the device is powered directly by the vehicle battery, in an alternative example the device comprises a re-chargeable battery. The device may further comprise a solar panel which charges the device battery. Alternatively, the device may comprise a cable which connects to the vehicle battery and charges the device battery from the vehicle battery. The cable may connect to the input/output connector 104. The input/output connector 104 may be a MicroUSB socket (i.e. a Micro-USB female connector) that is configured to connect to a Micro-USB plug (i.e. a Micro-USB male connector) of the electrical cable.

In this example, the controller 201 is a microcontroller, comprising one or more processing components and one or more memory components. The processing components may comprise logic circuitry that responds to and processes instructions in code stored in the memory components. Execution of program code by the processing components will cause methods as described herein to be implemented. As discussed further below, the memory components of the controller 201 are configured to store information associated with the vehicle (e.g. registration number). In an example the controller 201 is a NXP Semiconductors® LPC4322JBD144E.

The controller 201 is communicatively connected to the display 101, the output means 102 and a first transceiver 202. As will be discussed in more detail below, the controller 201 is configured to communicate with a remote server via the first transceiver 204 to receive vehicle status information. Vehicle status information in this example includes one or more of: information associated with a tax status (e.g. a tax expiry date) and information associated with a vehicle safety status (e.g. a vehicle safety certificate expiry date). The controller 201 may be further configured to communicate with the remote server via the first transceiver 204 to receive other information, for example vehicle insurance information and/or vehicle identification information. The controller 201 is further configured to store a unique identification number associated with the device 100 for the purpose of identifying the vehicle information associated with the device 100.

In one example, the controller 201 is configured to receive vehicle status information by transmitting a request to a remote server via the first transceiver 202 and receiving a response via the first transceiver 202. In an alternative example, the controller 201 is configured to receive vehicle status information by receiving information from a remote server via the first transceiver 202 without transmitting a request.

The controller 201 is configured to display vehicle identification information, for example the vehicle registration number, on the display 101, for example, by transmitting information indicating the registration number to the display 101. In a further example the controller 201 is configured to display other pieces of vehicle status information such as the tax expiry date and/or the vehicle safety certificate expiry date on the display 101 in addition, or alternatively to, the vehicle registration number.

The controller 201 is further configured to provide an output based on the obtained vehicle status information using the output means 102. In this example, the controller 201 is configured to output a signal that controls the colour of light outputted by the output means 102.

In one example, the vehicle status information includes a tax expiry date and the controller 201 is configured to determine a tax status based on the obtained vehicle status information and output the tax status via the output means 102. In an example the controller 201 is configured to cause the output means 102 to: 1) output a green light when the vehicle tax associated with the vehicle does not expire for at least 31 days (i.e. when there are 31 days or more before the vehicle tax expires); 2) output an amber light when then the vehicle tax associated with the vehicle expires in 30 days or less; and 3) output a red light when the vehicle tax associated with the vehicle has expired. A vehicle tax associated with a vehicle has expired when the time period for which tax has been paid has elapsed.

In another example however, the vehicle status information includes a vehicle safety certificate expiry date and the controller 201 is configured to determine a vehicle safety status based on the obtained vehicle status information. In this example the controller 201 is configured to cause the output means 102 to: 1) output a green light when the vehicle safety certificate associated with the vehicle does not expire for at least 31 days; 2) output an amber light when then the vehicle safety certificate associated with the vehicle expires in 30 days or less; and 3) output a red light when the vehicle safety certificate associated with the vehicle has expired.

In another example which will be described below, the vehicle status information includes a tax expiry date and a vehicle safety certificate expiry date and the controller 201 is configured to determine a combined vehicle status (i.e. a value that indicates vehicle tax information and vehicle safety information). In this example the controller is configured to cause the output means 102 to: 1) output a green light when the vehicle tax and the vehicle safety certificate (e.g. MOT test certificate) associated with the vehicle does not expire for at least 31 days; 2) output an amber light when the vehicle tax associated with the vehicle and/or the vehicle safety certificate expires in 30 days or less; and 3) output a red light either of the vehicle tax or the vehicle safety certificate associated with the vehicle has expired.

Optionally the controller is configured to activate the output means at a predetermined frequency. For example, where the output means comprises a LED the controller is configured to cause the output means to flash red light in the third state at a predetermined frequency.

As discussed above, the controller 201 is communicatively coupled to the first transceiver 202 and is configured to communicate with a server remote from the device 100 via the first transceiver 202 to obtain vehicle status information.

The first transceiver 202 is configured to communicate with the server using a first communication link. In an example the first communication is a wireless communication link. In a further example the first communication link is part of a cellular telecommunications network. Optionally, the first transceiver 202 is configured to transmit and receive data according to one or more of: the GSM (Global System for Mobile Communications) standard, the GPRS (General Packet Radio Service) standard, the 3G standard and/or the 4G LTE standard. In an example first transceiver 202 is a u-blox® TOBY-L2 series controller.

In an example the device 100 comprises a Subscriber Identity Module (SIM) card for communicating via the telecommunication network. In this case each device 100 is associated with an identifier (e.g. a mobile number) that allows the device 100 to be contacted. Optionally the device comprises an e-SIM (i.e. a programmable SIM that is embedded directly into the device).

Optionally the device 100 comprises a positioning module 203. The positioning module 203 is communicatively coupled to the controller 201 and is configured to monitor and determine the position of the device 100. Optionally the positioning module 203 uses the Global Positioning System (GPS) to determine the device's location. As will be apparent from the description below, the position information can be subsequently used for many purposes including, for example, for reporting to an insurance company and for determining when payments (e.g. congestion zone or car parking payments) are due. In a further example the positioning module 203 is used to obtain a time reference (i.e. information indicating the date and time). This information may be subsequently used when determining whether a tax expiry date or a vehicle safety certificate expiry date has passed. Optionally the time and date from the positioning module 203 is used to update a time and date reference maintained by the controller 201. In an example the positioning module 203 is a u-blox® UBX-M9340 chip.

In an example the device 100 is tamper-resistant so as to mitigate against an unauthorised user maliciously interfering with the operation the device 100. In an example the device 100 is provided with tamper-prevention means. In an example tamper resistance is provided by a housing that is configured to at least partially enclose the electronic components of the device 100. In an example the housing comprises two parts and the parts fit together to enclose the components. In this case the two parts are secured by tamper resistant means including at least one of: a security bit (i.e. a screw with un-common head that cannot be unscrewed without a specialist bit), strong adhesive, and/or ultrasonic welding. In a further example one or more components of the device are encapsulated in resin. Advantageously, each of these tamper prevention means mitigates against a malicious third party from interfering with the device 100 and manipulating the information displayed by the device 100 (for example, by modifying the vehicle registration number displayed by the device). As a result, a level of trust that the information displayed by the device has not been interfered with and is accurate can be provided.

In a further example, the device 100 is provided with tamper detection means. In an example the device 100 comprises a switch, optionally a microswitch, preferably a hinge lever microswitch such as OMRON® SSG-5L1 H. In an example the switch is configured to change states (e.g. from a first state to a second state) when the housing of the device 100 is opened. This is achieved, for example, by arranging the switch such that the lever of the switch is in a first state when the housing encloses the components, and moves to a second state when the housing is removed. The controller 201 is configured to monitor the state of the switch. In response to determining that the state of the switch has changed the controller 201 is configured to transmit an indication to an external server via the first transceiver 202 that the housing has been opened and the device is potentially compromised.

Fig. 3 shows a system according to a first example. In particular, Fig. 3 shows a system comprising a device 100, a first server 301, and a second server 302. The device 100 is configured to communicate with the first server 301 to obtain configuration information (for example to determine what vehicle registration number is associated with the device 100). In an example the device 100 is configured to communicate with the first server 301 via a first communication link 303 using the first transceiver 202. As will be discussed in more detail below, the first server 301 is configured to store information associating a unique identification number of the device 100 (e.g. a serial number) with vehicle identification information, for example a registration number of a vehicle. Optionally the first server 301 is a cloud computing server.

The device 100 is also configured to communicate with the second server 302 via a second communication link 304. As will be discussed in more detail below, the second server 302 may be operated by an external organisation, optionally a government organisation (such as the Driver and Vehicle Licensing Agency (DVLA) in the UK) and is configured to store information associating a vehicle registration number with vehicle status information such as: a current tax status, a tax expiry date (i.e. a date up to which tax has been paid for the vehicle), and/or a safety status. The second server 302 may store additional vehicle information such as vehicle insurance information.

In an example each of the first communication link 303 and the second communication link 304 include at least a part on which data is communicated wirelessly via a telecommunication network.

Fig. 4A shows a method performed by a device according to an example. In an example the method is performed by the device 100 discussed in relation to Fig. 2.

In Fig. 4A the device 100 has already completed a setup process. The setup process will be discussed in more detail below. However, in brief during the set up process, vehicle identification information (in this example a vehicle registration number) is associated with the unique identification number of the device 100 and this vehicle registration number is communicated to the device 100. In response the device 100, specifically the controller 201, stores the vehicle registration number (e.g. in non-volatile memory) so that the device 100 can subsequently obtain the vehicle status information.

The method begins in step 401 by transmitting a request for vehicle status information to the second server 302. The request is transmitted via the second communication link 304. Optionally the method of Fig. 4A is performed periodically. In an example the method of Fig. 4A is performed by the device 100 once or twice a day. In this case a request is transmitted by the device 100 once or twice a day. In alternative examples, the step of transmitting a request (i.e. step 401) may be omitted, and the device simply receives the vehicle status information from the second server 302 in step 402 without sending a request. Again, the vehicle status information may be transmitted periodically by the second server 302, for example once or twice a day.

During the setup process each device 100 is configured to store a vehicle registration number associated with the device 100. In step 401, the request transmitted by the device 100 comprises the vehicle registration number associated with the device 100. The request is subsequently received by the second server 302. The operation of the second server 302 will be discussed in more detail below. The method proceeds to step 402.

In step 402 the device 100 receives data from the second server 302 comprising vehicle status information. As discussed above, in an example vehicle status information includes a tax expiry date and/or a vehicle safety certificate expiry date. In the specific example discussed below, vehicle status information includes both the tax expiry date and the vehicle safety certificate expiry date.

In an example the second server 302 is maintained by an external organisation, optionally a government department (e.g. Driver & Vehicle Licensing Agency (DVLA) in the UK).

In an example the data of the second server 302 is accessed (e.g. by the device 100) using an API (Application Programming Interface) provided by the second server 302 for this purpose. In an example the request to the second server 302 comprises a registration number and the response body (i.e. the contents of the response provided by the second server 302) comprises information indicating when the current tax period expires and information identifying a safety status of the vehicle.

In an example the information indicating when the current tax period expires contains a tax expiry date (i.e. the date on which tax has expired). A tax expiry date is equivalent to a tax due date.

The tax due date indicating when the next tax payment is due (i.e. because the previously paid tax has expired). In an example the information indicating when the current tax period expires comprises a first key value pair indicating when the next tax payment is due. In an example the first key is named "taxDueDate" and the value associated with the first key comprises an indication (e.g. in date form YYYY-MM-DD) of when the tax is next due (i.e. the day after which the current tax period expires).

In a specific example the API provided by the second server 302 is the "DVLA Vehicle Enquiry API".

The request is received by the second server 302 after the device 100 transmits the request in step 401. The method performed by the second server 302 will be discussed in more detail with reference to Fig. 4B and Fig. 4C.

Fig. 4B shows a method performed by a second server according to an example. In step 480 the second server 302 receives a request (e.g. from the device 100) for vehicle status information. The request comprises a vehicle registration number. The method proceeds to step 481. In step 481 the second server 302 obtains vehicle status information (i.e. vehicle status information such as tax status, tax expiry date, vehicle safety information) that is associated with the received vehicle registration number. Optionally the second server 302 maintains a database that associates the vehicle registration number with vehicle status information and the second server 302 is configured to obtain the vehicle status information by looking up the vehicle registration number in the database.

Fig. 4C shows an example database maintained by the second server according to an example. Fig. 4C shows a database comprising a registration number entry (for storing an alpha-numeric registration number), a tax due date entry (for storing a date on which the next tax payment is due), a tax status (for indicating a state of the tax, e.g. 'Not Taxed for on Road Use', 'SORN', 'Taxed', 'Untaxed), an MOT status (i.e. a safety status) (e.g. 'Valid', 'Not Valid') and an MOT expiry date (for indicating a date on which the next safety test of the vehicle must be completed by). Although Fig. 4C shows specific pieces of vehicle status information it will be appreciated that different types and/or combinations of vehicle status information could be maintained by the second server 302.

Returning to Fig. 4B, after obtaining the vehicle status information in step 481, the method proceeds to step 482. In step 482 the second server 302 transmits a response to the received request (e.g. the request from the device 100). The response from the second server 302 comprises the vehicle status information, e.g. information indicating a tax status and information indicating a safety status associated with the vehicle registration number.

In an example the information indicating the tax status associated with the vehicle includes the tax due date (i.e. the date after which the current tax for the vehicle expires) and the information indicating a safety status associated with the vehicle comprises a date on which the vehicle safety certificate expires.

Returning to Fig. 4A, in step 402 the device 100 receives the response from the second server 302 comprising the vehicle status information (e.g. the tax due date in YYYY-MM-DD form and vehicle safety certificate expiry date in YYYY-MM-DD form). Optionally the device 100 stores the received information (e.g. the tax due date and the vehicle safety certificate expiry date in YYYYMM-DD form). The method proceeds to step 403 in response to receiving the response from the second server 302.

In step 403 the device 100 processes the received vehicle status information.

As discussed above, the vehicle status information obtained from the second sewer 302 may include a tax due date in the form YYYY-MM-DD and a vehicle safety certificate expiry date in YYYY-MM-DD form whereas part of the vehicle status information is outputted by the device using a multicolour LED (e.g. with green/orange/red colours). As discussed above, in an example the multicolour LED is used to indicate a combined vehicle status (e.g. tax and safety) in the form of one or more levels (e.g. level 1/'green' -31 days or more days until tax is due and the vehicle safety certificate expires, level 2/camber' -30 days or less until the vehicle tax expires and/or the vehicle safety certificate expires level 3/red' -the tax has expired and/or the vehicle safety certificate has expired). In order to convert the information between these formats the device 100 processes the received information in step 403.

Fig. 4D shows a method of processing the vehicle status information according to an example. In particular, Fig. 4D describes an example where the output means 102 is configured to output a combined vehicle status (i.e. tax and vehicle safety). The method begins in step 450 by obtaining information identifying a vehicle tax expiry date and a vehicle safety certificate expiry date. The tax expiry date being the day after the period for which tax has been paid and the vehicle safety certificate expiry date being the day after the period for which the current vehicle safety certificate is valid for. As discussed above, the vehicle tax expiry date and the vehicle safety certificate expiry date may be provided by the second server 302 in date form (e.g. YYYY-MM-DD) in the response received in step 402. After obtaining the vehicle tax expiry date and the vehicle safety certificate expiry date in step 450, the method proceeds to step 451.

In step 451 the device 100 determines whether the vehicle tax or the vehicle safety certificate expires within a first period. Optionally the first period is 30 days. If it is determined that the vehicle tax and the vehicle safety certificate does not expire within the first period the method proceeds to step 452.

In step 452 the first server 301 sets the combined vehicle status to a first state (e.g. level 1/'green').

If it is determined in step 451 that the vehicle tax and/or the vehicle safety certificate does expire within the first time period (e.g. within the next 30 days) then the method proceeds to step 453.

In step 453 it is determined whether the vehicle tax has expired (i.e. if the current date -maintained by the device 100-is after the tax expiry date).

If it is determined in step 453 that the vehicle tax and/or the vehicle safety certificate has expired then the method proceeds to step 456. In step 456 the first server 301 sets the combined vehicle status to a third state (e.g. level 3/'red').

If it determined in step 453 that the vehicle tax and/or the vehicle safety certificate has not expired then the method proceeds to step 454. In step 454 the first server 301 sets the combined vehicle status to a second state (e.g. level 2/'amber').

Returning to Fig. 4A, after processing the received data to generate a combined vehicle status in step 403, the method proceeds to step 404.

In step 404 the device 100 outputs the information indicating a vehicle status. In this step, the controller 201 configures the output means 102 according to the determined combined vehicle status. For example, the output means 102 is controlled to emit a colour according to the combined vehicle status, e.g. output green light in response to determining that the combined vehicle status is level 1/'green', output amber light in response to determining that the combined vehicle status is level 2/'amber', output red light in response to determining that the combined vehicle status level is 3/'red'.

Step 404 also comprises displaying the vehicle registration number on the display 101. As discussed in more detail below, the vehicle registration number is stored on the device 100 during the setup process when a device 100 is associated with a vehicle. In an example the vehicle registration number is retrieved from a memory component of the controller 201.

In the example above the information indicating the vehicle status that was generated by the device 100 comprised a combined vehicle status (i.e. combining tax and safety certificate information into one parameter for display by the output means 102).

In a further example the information indicating the vehicle status generated by the device 100 comprises a tax status and the device 100 is configured to output the tax status using the output means 102. In particular, the device 100 is configured to determine a tax status based on the data received from the second server 302. The tax status has a plurality of levels. In an example the tax status comprises three levels, for example, level 1/'green' for fully taxed, level 2/'orange' for currently taxed but expires within 30 days, and level 3/'red' for not currently taxed. A similar process is followed by the device 100 as discussed in relation to Fig. 4D above when a combined vehicle status is generated. However instead of determining whether the vehicle tax or the safety certificate expires within a first period or has expired (i.e. steps 451 and 453), the device 100 only checks whether the vehicle tax expires within the first period or has expired.

Likewise in a further example the device 100 is configured to output a vehicle safety status via the output means 102. In this case the device 100 is configured to generate information indicating a vehicle status that comprises a vehicle safety status (as opposed to a combined vehicle status -tax and vehicle safety). The device 100 is configured to generate a vehicle safety status as discussed in relation to Fig. 4D. However instead of determining whether the vehicle tax or vehicle safety certificate expires within a first period or has expired (i.e. steps 451 and 453), the device 100 makes these determinations based on only the whether the vehicle safety certificate has expired.

As discussed above, when a new device is deployed, a method of associating the device 100 with identification information of the vehicle (e.g. a vehicle registration number) in which the device is to be deployed is performed.

In an example a first server 301 is provided. The first server 301 is configured to maintain a database associating the device 100 (specifically the unique identification number of the device 100) with a vehicle registration number. During the setup up process entries in the database are populated.

Fig. 5A shows an example of a database maintained by the first server 301. In particular, Fig. 5A shows a database that associates an identification number (e.g. a serial number) with a vehicle registration number. The database also maintains contact information of the device 100. For example the contact information of the device 100 comprises the identifier associated with the SIM card of the device 100. Optionally, the database maintained by the server 301 also comprises contact information for an individual that is associated with the device and the vehicle registration number. In an example contact information includes an email address. The database maintained by the first server 301 is updated when registering a device 100.

Fig. 5B shows a method of registering a device performed by the first server 301 according to an 20 example.

In step 501 the first server 301 receives a request to update the details stored by the first server 301. In an example the request comprises the unique identification number of a device and a vehicle registration number. Optionally the unique identification number is obtained by scanning the information identifying the unique identification number, for example, by scanning the OR code 103 with a OR reader.

A user may use a separate user computing device to request to update the details. The user device may be a computer, smart phone, tablet or similar. For example, the user may generate the request online through a web-based portal. In this example, the user accesses the portal in a web browser running on the user computing device and inputs the unique identification number of the device and the vehicle identification information (for example registration number). The unique identification number may be entered automatically by the user scanning the information identifying the unique identification number using the user computing device. The vehicle registration number may be entered manually by the user, by using a keyboard input. Alternatively, the user may generate the request using an app, by sending an email to a specified email address, or by calling a specified number for example. The request is transmitted to the first server 301 from the user computing device via a communication network, such as the Internet for example.

The method proceeds to step 502. In step 502 the first server 301 determines whether the request is from a trusted user. Optionally a trusted source includes a car dealership (i.e. a retailer of vehicles) registered with the first server 301 or a government organisation (e.g. the Driver and Vehicle Licensing Agency (DVLA) in the UK). Optionally each trusted entity is provided with an Application Programming Interface (API) key that is included in the request received in step 501 and is used by the first server 301 to confirm that the request is from a trusted source (e.g. by comparing the received key to a list of keys associated with trusted sources). Other forms of authentication may be used in this step, for example requesting and confirming a password.

If it is determined in step 502 that the request is not from a trusted source then the method proceeds to step 504 where the request received in step 501 is ignored.

If it is determined in step 502 that the request is from a trusted source then the method proceeds to step 503. In step 503 the first server 301 updates the information stored in the first server 301 according to the request. For example, if the request comprised a request to add or update the vehicle registration number associated with the unique serial number, then the vehicle registration number is updated for the unique serial number.

In step 505 the first server 301 transmits vehicle identification information to the device 100 identified by the unique identification number. The vehicle identification information comprises the vehicle registration number in this example. As discussed above, the device 100 comprises a transceiver 202 for communicating via a telecommunications network. In an example data transmitted by the first server 301 is routed to the device 100 via the telecommunication network, and using the routing techniques employed by the telecommunication network.

In an example, before deployment of the device 100 (e.g. at manufacture stage) the database maintained by the first server 301 is updated to associate a unique identification number of the device 100 with contact information of the device (e.g. a phone number associated with the SIM card used by the device 100). Consequently, when the vehicle registration number is registered, the first server 301 transmits vehicle information to the phone number associated with the unique identification number, thereby providing the device 100 with the vehicle registration number.

The device 100 receives the vehicle identification information in response to the first server's 301 transmission in step 505 and displays the vehicle identification information on the display 101 as will be described in relation to Fig. 5C below.

Displaying the vehicle registration number on the display 101 allows a third party (e.g. a member of the police) to visually confirm that the tax status (as indicated by the output means 102) is associated with that physical vehicle. For example, the device 100 could be registered to a first vehicle registration number AAAAA1'. In this case the tax status obtained and displayed by the device 100 is the tax status of the vehicle with registration number AAAAA11. If a user was to attempt to physically move the device 100 such that it is now located on a dashboard of a vehicle with registration number IBBBBB2', then it would be immediately evident that the tax status being outputted by the output means 102 is not the tax status of the vehicle with the registration number BBBBB2', since the display 101 would be displaying registration number AAAAA1' (i.e. indicating that the tax status is for the vehicle associated with the registration number AAAAA1').

Fig. 5C shows a method of registering a device performed by the device 100 according to an example. In an example the method is performed by the device 100 discussed in relation to Fig. 2.

In step 506 the device 100 receives information from the first server 301 comprising vehicle identification information. As discussed above, vehicle identification information comprises a vehicle registration number in this example (i.e. a series of letters and/or numbers that uniquely identifies a vehicle). In this example, the vehicle identification information is stored in the nonvolatile storage of the controller 201.

In step 507 the device 100 displays the vehicle identification information. Displaying the vehicle identification information comprises displaying the vehicle registration number on the display 101. The device 100 continually displays the vehicle identification information on the display 101, for example as long as the device is able to draw power.

In the above described method, the first server 301 sends the vehicle identification information to the device 100 once, in response to an update of the database during a registration process. The device 100 then stores and continually displays the vehicle identification information. Alternatively however, the vehicle identification information may be sent to the device 100 in response to a request received from the device 100, as will be described below. The request may be sent from the device 100 once, when the device 100 is initially deployed. Alternatively, the request may be sent together with a request for vehicle status information for example, and the stored vehicle identification information updated on a regular basis.

In this case, a request for vehicle identification information is sent from the device 100 to the first server 301. The request is transmitted via the first communication link 303. The request transmitted by the device 100 comprises information identifying the identification number of the device 100 (e.g. a copy of the serial number). The request is subsequently received by the first server 301.

The first server 301 receives a request for vehicle identification information from the device 100. As discussed above, the request comprises information identifying the device 100 (e.g. a unique identification number). The first server 301 determines the vehicle registration number associated with the device 100. Each device 100 is associated with a vehicle and each vehicle is associated with a vehicle registration number. In an example the first server 301 maintains a database that associates the unique identification number of the device 100 with a vehicle registration number. The first server 301 determines the registration number associated with the device 100 by looking up an entry in the database associated with the unique identification number received. The method then proceeds as described above (i.e. the first server 301 transmits the vehicle registration number associated with the identification number and the device displays the vehicle identification information).

In the example above discussed in relation to Fig. 4A, the device 100 transmits a request for vehicle status information and outputs updated information based on the received vehicle status information. In some instances a communication link to the second server 302 may not exist. For example, when the car is stored in an underground car park it may not be possible to communicate with the second server 302 via the telecommunications network (e.g. due to a lack of reception). In a further example the method performed by the device 100 is configured to determine whether a communication link with the second server 302 exists (e.g. by determining whether the device 100 has an active connection to a telecommunication network) and, if not, update the output of the device 100 based on previously received information.

Fig. 6A shows a method performed by a device according to a second example. In step 601 it is determined whether a communication link to the second server 302 exists (e.g. if the device 100 has a connection to the telecommunications network). If it is determined in step 601 that a communication link does exist then the method proceeds to steps 401 and 402 as discussed in relation to Fig. 4A. As discussed above, in relation to step 402, when the device 100 receives vehicle status information, it stores the received information in memory (e.g. in a non-volatile memory of the controller 201). If it is determined that a communication link does not exist in step 601 then the method proceeds to step 602 where the controller 201 retrieves previous vehicle status information from memory (e.g. the last vehicle status information received by the device 100). The method proceeds to step 403, where the vehicle status information is processed as described above. If a communication link exists (i.e. if steps 401 and 402 are executed) then the vehicle status information being processed is the vehicle status information received in step 402 from the second server 302. If a communication link does not exist then the vehicle status information being processed is the vehicle status information retrieved from memory (e.g. the last vehicle status information that was received by the device 100). It will be appreciated that when the previous vehicle status information is processed some information (e.g. tax expiry date/vehicle safety certificate expiry date etc.) will not have changed from the last evaluation. However the current date and time will have changed, as a result, the output metric (e.g. the combined vehicle status being green/amber/red) may have changed. Steps 403 and 404 are performed as discussed in relation to Fig. 4A.

In the examples above the device 100 communicates directly with the server maintaining the vehicle status information (i.e. the second server 302). In another example the device 100 does not communicate directly with the second server 302, but instead transmits the request for vehicle status information to a first server 702 and the first server 702 relays the request to the second server 302. The second server 302 subsequently transmits the response to the first server 702 and the first server 702 transmits the response to the device 100.

Fig. 7A shows a system according to a second example. Same reference numerals are used as in Fig. 3 to denote same components. Fig. 7A shows a third communication link 701 between the first server 702 and the second server 302. Optionally the third communication link 701 is a wired communication link and the first server 702 and the second server 302 are configured to communicate via the internet. The first server 702 is configured to communicate with the device via the first communication link 303.

In an example the device 100 is configured to transmit the request comprising the vehicle registration number to the first server 702. In alternative examples, the step of transmitting a request from the device 100 may be omitted, and the device 100 simply receives the vehicle status information from the first server 702 without sending a request. The first server 702 is configured to transmit a second request comprising the vehicle registration number to the second server 302. The second server 302 is configured to transmit a second response to the first server 702 (as discussed in relation to Fig. 4B) and the first server 702 is configured to transmit a first response to the device 100. Optionally the first server 702 stores the response from the second server 302 for future use in case the second server 302 is offline.

In the example discussed above and in relation to Fig. 4A, the device 100 stores the vehicle registration number and transmits the vehicle registration number to obtain vehicle status information (e.g. a tax due date and a vehicle safety certificate expiry date). In this case the device 100 maintains the piece of information (i.e. the vehicle registration number) that allows vehicle status information to be retrieved from the second server 302. In a further example, the first server 702 is used as a relay and the device 100 transmits a request comprising its unique identification number to the first server 301, and the first server 702 then looks up, in a database maintained by the first server 301, the piece of information required to obtain the vehicle status information (e.g. the vehicle registration number). The first server 702 transmits a request to the second server 302 comprising the vehicle registration number, receives the response from the second server 302 comprising vehicle status information and relays the vehicle status information to the device 100.

Fig. 7B shows a method performed by a first server according to a further example. In an example, the database maintained by the first server 702 associates a unique identification number of the device 100 with contact information of the device (e.g. a phone number associated with the SIM card used by the device 100).

The method begins in step 754 with the first server 702 receiving a request for vehicle status information from the device 100. In this example the device 100 stores the unique identification number, optionally only the unique identification number, and the request transmitted by the device 100 to the first server 702 comprises information identifying the device 100 (e.g. the unique identification number). After receiving the request in step 754, the method proceeds to step 755.

In step 755 the first server 702 determines the vehicle registration number associated with the device 100. Each device 100 is associated with a vehicle and each vehicle is associated with a vehicle registration number. As discussed above, the first server 702 maintains a database that associates the unique identification number of the device 100 with a vehicle registration number.

In particular, Fig. 5A shows a database maintained by the first server 702 that associates an identification number (e.g. a serial number) with a vehicle registration number. In step 755 the first server 702 determines the vehicle registration number associated with the device 100 by looking up an entry in the database associated with the unique identification number received in step 754. After determining the vehicle registration number associated with the device 100, the method proceeds to step 756.

In step 756 the first server 702 transmits a request for vehicle status information to the second server 302. The request comprises the vehicle registration number associated with the device 100. In an example, the requested vehicle status information comprises information indicating a tax status of a vehicle and information indicating a vehicle safety status. In step 757 the first server 702 receives a response from the second server 302 comprising the vehicle status information.

The method proceeds to step 758. In step 758 the first server 702 transmits the vehicle status information to the device 100 and the device processes the received information as discussed in relation to Fig. 4A (specifically as discussed in relation to steps 403 and 404).

In a further example the first server 702 is configured to process the vehicle status information after receiving the information in step 757. In this example the first server 702 is configured to determine a status (e.g. a tax status, a vehicle safety certificate status, a combined vehicle status etc. as discussed in relation to Fig. 4D) and the first server 702 is configured to transmit an indication of the status to the device 100 for output. In this case the processing of the vehicle status information is performed by the first server 702, and the device 100 receives the information indicating the vehicle status and outputs this information. Optionally, in this example, after setting the combined vehicle status to the second state (i.e. in step 454) the first server 702 contacts the user to inform the user that the vehicle tax and/or the vehicle safety certificate is due to expire soon. The first server 702 contacts the user using the contact information maintained by the first server 702 that is associated with the unique identification number of the device 100 whose request is being processed. This information is determined using the database maintained by the first server 301. Advantageously, this functionality provides a reminder service to the user in order to ensure that a vehicle tax and/or a vehicle safety certification (e.g. an MOT) does not expire.

In a further example the device 100 is configured to communicate with a third server to obtain insurance information. Optionally, the device 100 is configured to communicate with a third server via the first server 301 (i.e. using the first server 301 as a relay).

In a further example the system comprises a single server that is configured to perform the functions of the first server 301 and the second server 302. Or put in other words, in an example there is provided a single server that is configured to perform the methods of Fig. 4B and Fig. 5B.

As discussed above, the device 100 may also comprise a positioning module 203. In an example where the positioning module 203 is present, the device 100 is configured to transmit position information to a server (e.g. a remote server such as the first server 301).

Fig. 8 shows a second method performed by the device according to an example. In step 850 the controller obtains position information (e.g. by determining a position using an output of the positioning module 203). Optionally the output of the positioning module 203 comprises GPS coordinates of the device 100. The method proceeds to step 851. In step 851 the position information is transmitted by the device 100 (e.g. using the first transceiver 202 via the first communication link 303). Optionally the position information is transmitted to the first server 301, where it is stored upon receipt. In an example the position information stored at the first server 301 is analysed by the first server 301 to determine whether the device was located in a zone/area where a fee is required to be paid (e.g. a congestion zone or a parking lot). In an example the first server 301 makes a payment in response to determining that the device 100 was located in an area where a payment is required. In another example the position data is provided to a third party (e.g. an insurance company) In a further example a time/date is obtained from the positioning module 203 and is used to update a time and/or date maintained by the controller 201 for the purpose of determining whether a tax or a vehicle safety certificate has expired.

Fig. 9A shows an implementation of an example controller 201 in a device 100 according to an example. The controller 201 comprises an input/output interface 910, a processor 920 and a nonvolatile memory 930. The input/output interface 910 is communicatively coupled to the first transceiver 202, the display 101 and the output means 102. The input/output interface 910 is also communicatively coupled to the positioning module 203 where present. The processor 920 is also coupled the non-volatile memory 930. The non-volatile memory 930 stores computer program instructions that, when executed, cause the processor 920 to execute program steps that causes the controller 201 to implement the functionality of the device 100 discussed above. In particular, the non-volatile memory 930 stores computer program instructions that, when executed, cause the processor 920 to implement the methods of any of: Fig. 4A, Fig. 4D, Fig. 5C, Fig. 6A and/or Fig. 8.

Fig. 9B shows an implementation of a first server according to an example. The first server 940 comprises a communication interface 950, a processor 960 and a non-volatile memory 970. The processor 960 is communicatively coupled to the communication interface 950 and the nonvolatile memory 970. The first server 950 is configured to communicate with the device 100 and optionally the second server 302 via the communication interface 950. The non-volatile memory 970 stores computer program instructions that, when executed, cause the processor 960 to execute program steps that implement the functionality of the first server. In particular, the nonvolatile memory 970 stores computer program instructions that, when executed, cause the processor 960 to implement the method of any of: Fig. 4D, Fig. 5B and/or Fig. 7B..

Also described is a second server implemented in a similar way to the first server of Fig. 9B. In this example the non-volatile memory 970 stores computer program instructions that, when executed, cause the processor 960 to implement the functionality of the second server as discussed above, in particular the method of Fig. 4B.

In the examples described above the device 100 is a stand-alone device that is placed, in use, in/on the vehicle (e.g. on the dashboard/windscreen of the vehicle). In another example there is provided a vehicle comprising the components of the device 100, such that device is integrated into the vehicle.

In a further example the vehicle status information received by the device 100 comprises at least one of: information indicating a tax status, information indicating a vehicle safety status, information indicating a combined status (i.e. a status that combines two or more pieces of information e.g. tax and safety) and the device is configured to display the received information on the display 101 in addition to, or instead of, the vehicle registration number received as part of the vehicle identification information.

Although in the above described example, the output means 102 is controlled based solely on the information indicating the status of the vehicle, in other examples, the output means 102 is controlled based on the information indicating the status of the vehicle as well as other information. For example, the output means 102 may be controlled based on the information indicating the status of the vehicle as well as vehicle insurance information. For example, the output means 102 may be controlled based on vehicle tax information, vehicle safety information and vehicle insurance information. In this example the controller is configured to cause the output means 102 to: 1) output a green light when the vehicle tax, the vehicle safety certificate (e.g. MOT test certificate) and vehicle insurance associated with the vehicle does not expire for at least 31 days (i.e. when there are 31 days or more before the vehicle tax expires); 2) output an amber light when the vehicle tax associated with the vehicle and/or the vehicle safety certificate and/or the vehicle insurance expires in 30 days or less; and 3) output a red light any of the vehicle tax or the vehicle safety certificate or the vehicle insurance associated with the vehicle has expired.

In an example, a housing of the device 100 is formed using an additive manufacturing process. A common example of additive manufacturing is 3D printing; however, other methods of additive manufacturing are available. Rapid prototyping or rapid manufacturing are also terms which may be used to describe additive manufacturing processes.

As used herein, "additive manufacturing" refers generally to manufacturing processes wherein successive layers of material(s) are provided on each other to "build-up" layer-by-layer or "additively fabricate", a three-dimensional component. This is compared to some subtractive manufacturing methods (such as milling or drilling), wherein material is successively removed to fabricate the part. The successive layers generally fuse together to form a monolithic component which may have a variety of integral sub-components. In particular, the manufacturing process may allow the housing to be integrally formed and include a variety of features not possible when using prior manufacturing methods.

Suitable additive manufacturing techniques in accordance with the present disclosure include, for example, Fused Deposition Modeling (FDM), Selective Laser Sintering (SLS), 3D printing such as by inkjets and laserjets, Sterolithography (SLA), Direct Selective Laser Sintering (DSLS), Electron Beam Sintering (EBS), Electron Beam Melting (EBM), Laser Engineered Net Shaping (LENS), Electron Beam Additive Manufacturing (EBAM), Laser Net Shape Manufacturing (LNSM), Direct Metal Deposition (DMD), Digital Light Processing (DLP), Continuous Digital Light Processing (CDLP), Direct Selective Laser Melting (DSLM), Selective Laser Melting (SLM), Direct Metal Laser Melting (DMLM), Direct Metal Laser Sintering (DMLS), Material Jetting (MJ), NanoParticle Jetting (NPJ), Drop On Demand (DOD), Binder Jetting (BJ), Multi Jet Fusion (MJF), Laminated Object Manufacturing (LOM) and other known processes.

The additive manufacturing processes described herein may be used for forming components using any suitable material. For example, the material may be plastic, metal, composite, concrete, ceramic, polymer, epoxy, photopolymer resin, or any other suitable material that may be in solid, liquid, powder, sheet material, wire, or any other suitable form or combinations thereof.

Although in this example the housing is constructed entirely by additive manufacturing processes, it should be appreciated that in alternate embodiments, all or a portion of these components may be formed via casting, machining, and/or any other suitable manufacturing process. Indeed, any suitable combination of materials and manufacturing methods may be used to form these components.

Additive manufacturing processes typically fabricate components based on three-dimensional (3D) information, for example a three-dimensional computer model (or design file), of the component. Accordingly, examples described herein not only include products or components as described herein, but also methods of manufacturing such products or components via additive manufacturing and computer software, firmware or hardware for controlling the manufacture of such products via additive manufacturing.

The structure of one or more parts of the product may be represented digitally in the form of a design file. A design file, or computer aided design (CAD) file, is a configuration file that encodes one or more of the surface or volumetric configuration of the shape of the product. That is, a design file represents the geometrical arrangement or shape of the product.

Design files can take any now known or later developed file format. For example, design files may be in the Stereolithography or "Standard Tessellation Language" (.stl) format which was created for stereolithography CAD programs of 3D Systems, or the Additive Manufacturing File (.amf) format, which is an American Society of Mechanical Engineers (ASME) standard that is an extensible markup-language (XML) based format designed to allow any CAD software to describe the shape and composition of any three-dimensional object to be fabricated on any additive manufacturing printer. Further examples of design file formats include AutoCAD (.dwg) files, Blender (.blend) files, Parasolid (.x_t) files, 3D Manufacturing Format (.3mf) files, Autodesk (3ds) files, Collada (.dae) files and Wavefront (.obj) files, although many other file formats exist. Design files can be produced using modelling (e.g. CAD modelling) software and/or through scanning the surface of a product to measure the surface configuration of the product.

Once obtained, a design file may be converted into a set of computer executable instructions that, once executed by a processer, cause the processor to control an additive manufacturing apparatus to produce a product according to the geometrical arrangement specified in the design file. The conversion may convert the design file into slices or layers that are to be formed sequentially by the additive manufacturing apparatus. The instructions (otherwise known as geometric code or "G-code") may be calibrated to the specific additive manufacturing apparatus and may specify the precise location and amount of material that is to be formed at each stage in the manufacturing process. As discussed above, the formation may be through deposition, through sintering, or through any other form of additive manufacturing method.

The code or instructions may be translated between different formats, converted into a set of data signals and transmitted, received as a set of data signals and converted to code, stored, etc., as necessary. The instructions may be an input to the additive manufacturing system and may come from a part designer, an intellectual property (IP) provider, a design company, the operator or owner of the additive manufacturing system, or from other sources. An additive manufacturing system may execute the instructions to fabricate the product using any of the technologies or methods disclosed herein.

Design files or computer executable instructions may be stored in a (transitory or non-transitory) computer readable storage medium (e.g., memory, storage system, etc.) storing code, or computer readable instructions, representative of the product to be produced. As noted, the code or computer readable instructions defining the product that can be used to physically generate the object, upon execution of the code or instructions by an additive manufacturing system. For example, the instructions may include a precisely defined 3D model of the product and can be generated from any of a large variety of well-known computer aided design (CAD) software systems such as AutoCADO, TurboCADO, DesignCAD 3D Max, etc. Alternatively, a model or prototype of the component may be scanned to determine the three-dimensional information of the component.

Accordingly, by controlling an additive manufacturing apparatus according to the computer executable instructions, the additive manufacturing apparatus can be instructed to print out one or more parts of the product. These can be printed either in assembled or unassembled form.

For instance, different sections of the product may be printed separately (as a kit of unassembled parts) and then subsequently assembled. Alternatively, the different parts may be printed in assembled form.

In light of the above, embodiments include methods of manufacture via additive manufacturing. This includes the steps of obtaining a design file representing the product and instructing an additive manufacturing apparatus to manufacture the product in assembled or unassembled form according to the design file. The additive manufacturing apparatus may include a processor that is configured to automatically convert the design file into computer executable instructions for controlling the manufacture of the product. In these embodiments, the design file itself can automatically cause the production of the product once input into the additive manufacturing device. Accordingly, in this embodiment, the design file itself may be considered computer executable instructions that cause the additive manufacturing apparatus to manufacture the product. Alternatively, the design file may be converted into instructions by an external computing system, with the resulting computer executable instructions being provided to the additive manufacturing device.

Given the above, the design and manufacture of implementations of the subject matter and the operations described in this specification can be realized using digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. For instance, hardware may include processors, microprocessors, electronic circuitry, electronic components, integrated circuits, etc. Implementations of the subject matter described in this specification can be realized using one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially-generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

Although additive manufacturing technology is described herein as enabling fabrication of complex objects by building objects point-by-point, layer-by-layer, typically in a vertical direction, other methods of fabrication are possible and within the scope of the present subject matter. For example, although the discussion herein refers to the addition of material to form successive layers, one skilled in the art will appreciate that the methods and structures disclosed herein may be practiced with any additive manufacturing technique or other manufacturing technology.

Fig. 10 shows a method of manufacturing a device according to an example. In step 1001 the components of the device 100 (e.g. the controller 201, the display 101 etc.) are obtained. In step 1002 the components of the device 100 are connected to each other as described in relation to Fig. 2. In an example the components are mounted a Printed Circuit Board (PCB). In step 1003 a housing of the device is obtained. As discussed above the housing of the device may be obtained by addifively manufacturing the housing. In step 1004 the device 100 is assembled by enclosing the components (e.g. as assembled on a Printed Circuit Board (PCB)) within the housing as shown in relation to Fig. 1A.

While certain arrangements have been described, the arrangements have been presented by way of example only, and are not intended to limit the scope of protection. The inventive concepts described herein may be implemented in a variety of other forms. In addition, various omissions, substitutions and changes to the specific implementations described herein may be made without departing from the scope of protection defined in the following claims.

Claims

CLAIMS1. A device for displaying vehicle status information comprising: a transceiver; an output means; a display; and a controller communicatively coupled to the transceiver, the output means and the display, the controller being configured to: receive information indicating a status of a vehicle from the transceiver; control the display to display vehicle identification information; and control the output means to provide an output based on the information indicating the status of the vehicle.
2. The device according to claim 1, further comprising a positioning module configured to determine the position of the device.
3. The device according to any preceding claim, wherein the output means comprises one or more light emitting diodes, and the controller is configured to control an output colour based on the information indicating the status of the vehicle.
4. The device according to claim 3, wherein the information indicating the status of the vehicle comprises a tax expiry date and a vehicle safety certificate expiry date; and wherein the controller is configured to control the output colour based on the tax expiry date and the vehicle safety certificate expiry date.
5. The device according to claim 4, wherein the controller is further configured to cause the output means to: output a first colour in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; output a second colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; output a third colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.
6. The device according to claim 3, wherein the information indicating the status of the vehicle has one of a plurality of values, the plurality of values comprising a first value, a second value and a third value.
7. The device according to claim 6, wherein the controller is configured to cause the output means to: output a first colour when the information indicating the status of the vehicle has the first value; output a second colour when the information indicating the status of the vehicle has the second value; output a third colour when the information indicating the status of the vehicle has the third value.
8. The device according to any preceding claim, wherein the device comprises a housing; and a visual indication of a device identification number on the housing.
9. The device according to any preceding claim, wherein the controller is further configured to transmit a request for information indicating the status of the vehicle.
10. The device according to claim 9, wherein the request comprises the vehicle identification information and/or a device identification number associated with the device.
11. The device according to any preceding claim, wherein the controller is further configured to receive the vehicle identification information from the transceiver.
12. A system comprising: a device according to any preceding claim; and a first server configured to: transmit information to the device indicating the status of the vehicle.
13. The system according to claim 12, wherein the first server is further configured to: receive a first request for information indicating the status of the vehicle from the device.
14. The system according to claim 13, wherein the system further comprises a second server and wherein the first server is further configured to: transmit a second request to the second server in response to receiving the first request; receive a second response from the second server; and transmit the information to the device indicating the status of the vehicle, wherein the information is based on the second response.
15. The system according to claim 14, wherein the second response from the second server comprises a tax expiry date and a vehicle safety certificate expiry date.
16. The system according to claim 15, wherein the first server is further configured to: set the status of the vehicle to a first value in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; set the status of the vehicle to a second value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; set the status of the vehicle to a third value in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.
17. The system according to claim 15, wherein the information indicating the status of the vehicle comprises the tax expiry date and the vehicle safety certificate expiry date.
18. The system according to any of claims 13 to 17, wherein: the first request comprises a device identification number and wherein the first server is further configured to: determine vehicle identification information associated with the device based on the identification number of the device; and transmit the second request to the second server, the second request comprising the vehicle registration number.
19. The system according to any of claims 12 to 18, wherein the first server is configured to: receive a third request to update a database maintained by the first server, the third request comprising a device identification number and vehicle identification information; update the database to associate the device identification number with the vehicle identification information; and transmit a message to the device associated with the device identification number, the message comprising the vehicle identification information.
20. A method for displaying vehicle status information, the method comprising: receiving information indicating a status of a vehicle from a transceiver; controlling a display to display vehicle identification information; and controlling an output means to provide an output based on the information indicating the status of the vehicle.
21. The method according to claim 20, wherein the output means comprises one or more light emitting diodes, and the method further comprises controlling an output colour based on the information indicating the status of the vehicle.
22. The method according to claim 21, wherein; the information indicating the status of the vehicle comprises a tax expiry date and a vehicle safety certificate expiry date; and wherein the method further comprises controlling the output colour based on the tax expiry date and the vehicle safety certificate expiry date.
23. The method according to claim 22, further comprising causing the output means to: output a first colour in response to determining that the tax expiry date and the vehicle safety certificate expiry date occurs more than a predetermined period from a current date; output a second colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date occurs less than the predetermined period from the current date; output a third colour in response to determining that the tax expiry date and/or the vehicle safety certificate expiry date precedes the current date.
24. The method according to any of claims 20 to 23, further comprising transmitting a request for information indicating the status of the vehicle.
25. A non-transitory computer-readable medium comprising computer program instructions suitable for execution by a controller, the instructions configured, when executed by the controller, to: receive information indicating a status of a vehicle from a transceiver; control a display to display vehicle identification information; and control an output means to provide an output based on the information indicating the status of the vehicle.