WO2012174590A1

WO2012174590A1 - Digital identification device for vehicles

Info

Publication number: WO2012174590A1
Application number: PCT/AU2012/000707
Authority: WO
Inventors: Myong Gil LEE
Original assignee: Lee Myong Gil
Priority date: 2011-06-21
Filing date: 2012-06-20
Publication date: 2012-12-27
Also published as: AU2011203016A1

Abstract

Disclosed is a vehicle licence plate (804) comprising a plate (802) containing first vehicle information (805) that is visually perceivable by a person, the first information being applied to the plate as part of a registration procedure, and an identification device (803) either in or on the licence plate, the identification device being configured to electronically store second vehicle information (1 100) and to communicate the stored second vehicle information to a receiving device (1609, 1614) that is remote from the licence plate.

Description

DIGITAL IDENTIFICATION DEVICE FOR VEHICLES

Technical Field of the Invention

The present invention relates generally to motor vehicle transport systems, and in particular, to a digital identification device to enable vehicle and driver information to be retrieved quickly and efficiently.

Background

In Australia alone, 15 million cars are used for transport. As cars have become an integral part of modern life, so have vehicles become involved in criminal activities and motor vehicle accidents. Vehicle information can be an important element in solving certain crimes. This information can, in some instances, assist in identification of possible suspects.

Turning to motor vehicle accidents, driver and vehicle information is crucial and an initial task in processing information about an accident is to collect such information. Current license plates can be difficult to read if there is sparse light or if the orientation of the plate obscures the licence number.

Summary

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

Disclosed are arrangements, referred to as Digital Identification Device arrangements (or as DID arrangements), which seek to address the above problems by recording vehicle and/or driver information in digital form in what is referred to in this specification as an "identification device" having one or more of data storage, processing and communication capabilities, thus enabling rapid and accurate retrieval of the vehicle and/or driver information as required. According to a first aspect of the present disclosure, there is provided a vehicle licence plate comprising:

a plate containing first vehicle information that is visually perceivable by a person, said first information being applied to the plate as part of a registration procedure; and

an identification device being one of in and on the licence plate said identification device being configured to electronically store second vehicle information and to communicate said stored second vehicle information to a receiving device that is remote from the licence plate.

According to a second aspect of the present disclosure, there is provided a system for reporting vehicle incidents involving a vehicle having a vehicle licence plate according to the above paragraph, said system comprising:

a mobile communication device comprising a processor and a memory having stored therein a program for directing the mobile communication device to perform a method comprising the steps of:

communicating with an identification device being one of in or on the licence plate;

retrieving second vehicle information stored in the identification device; and enabling a user of the mobile communication device to communicate with another communication device while the retrieved information is presented to the user; wherein the steps communicating, retrieving and enabling can be performed when the user of the mobile communication device sees the vehicle involved in a vehicle incident

According to another aspect of the present disclosure, there is provided method for detecting non-compliance of vehicles, said method comprising the steps of: communicating, by one of a plurality of region communication devices distributed throughout a region in which said non-compliance is to be detected, with an identification device being one of in and on a licence plate of a vehicle, to thereby receive compliance status information for the vehicle stored in the identification device;

communicating by a server with the plurality of region communication devices over a network;

receiving, by the server, the compliance status information from said one of a plurality of region communication devices;

matching, by the server, the received compliance status information against compliance requirement information for said vehicle stored in a database; and

detecting that the vehicle is non-compliant if a mismatch is detected in the matching step.

According to another aspect of the present disclosure there is provided a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.

Other aspects of the invention are also disclosed.

Brief Description of the Drawings

At least one embodiment of the present invention will now be described with reference to the drawings, in which:

Fig. 1 depicts a chip scanner positioned in the car handle;

Fig. 2 depicts an augmented reality representation of two vehicles incorporating corresponding DID arrangements, as viewed on the display of a remote scanner;

Fig. 3 depicts a region scanning device configured to communicate with DID equipped vehicles, mounted on a street lighting pole; Fig. 4 depicts a region scanning device configured to communicate with DID equipped vehicles, mounted on a pavement mounted parking meter;

Fig. 5 depicts a vehicle registration sticker, incorporating a DID;

Fig. 6 depicts a representation of several vehicles incorporating corresponding DID arrangements, as viewed on the display of a remote scanner;

Fig. 7 depicts a menu of selectable software applications on the display of a remote scanner, one of which applications can be used by a user of the scanner to practice the DID method;

Fig. 8 depicts a current licence plate, and a licence plate incorporating a DID arrangement;

Fig. 9 depicts another augmented reality representation of a number of vehicles incorporating corresponding DID arrangements, as viewed on the display of a scanner 1609 implemented, for example, using a smart phone as depicted in Fig. 7.

Fig. 10 shows a functional block diagram of a system for generating and displaying the augmented reality representation depicted in Fig. 9;

Fig. 1 1 depicts how information communicated by a DID arrangement can be constructed in layers, with some layers being encrypted;

Fig. 12 depicts a number of alternate DID mounting arrangements on a vehicle; Fig. 13 depicts the range of information accessible;

Fig. 14 depicts a functional block diagram of one example of a DID arrangement;

Figs. 15A and 15B form a schematic block diagram of a general purpose computer system upon which DID arrangements described can be practiced;

Fig. 16 is a functional block diagram of one DID arrangement;

Fig. 17 shows a flow chart representation of a method for reporting a vehicle incident using a DID arrangement; Fig. 18 shows a flow chart representation of a method for checking compliance status of various types for a vehicle using a DID arrangement; and

Fig. 19 is a functional block description of how a DID identification device can be implemented.

Detailed Description including Best Mode

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

It is to be noted that the discussions contained in the "Background" section and the section above relating to prior art arrangements relate to discussions of devices which may form public knowledge through their use. Such discussions should not be interpreted as a representation by the present inventor(s) or the patent applicant that such devices in any way form part of the common general knowledge in the art.

The DID arrangements can be used to improve safety on roads at a relatively low cost by enabling people to report traffic incidents, as described in more detail in regard to Fig. 17. The DID arrangements also can facilitate vehicle registration processes my making the processes quicker and easier for both the owner and the registering authority. Specialised service agencies can also be formed in order to take advantage of the capabilities provided by the DID arrangements, as described, for example, in regard to Fig. 14.

Available technology and trends favour the introduction and utilisation of the disclosed DID arrangements. Thus a growing number of examples of conversion from analogue to digital arrangements can be found, including printed texts being converted to electronic books for online access. Furthermore, a significant number of people in today's society carry electronic devices, in the form of mobile communication devices such as smart phones that have the ability to receive and send information through Wi-Fi (IEEE Standard 802.1 1 n) or Bluetooth protocols for example.

The DID arrangements can be implemented using a variety of identification device architectures, transmission protocols, and data encoding standards, depending upon regulatory and other requirements. The DID arrangements have driver and vehicle information digitally recorded thus enabling the information to be retrieved efficiently using various digital communication methods such as Wi-Fi, Radio Frequency Identification Devices (RFID) or Bluetooth through use of compatible devices.

DID arrangements can be effective as they can carry more information about vehicles and drivers than current methods, and facilitate easy retrieval of information.

DID arrangements typically can store the following information, referred to as vehicle information, in the identification device in regard to the vehicle:

License plate number;

- colour of vehicle;

manufacturing company of the vehicle;

model of the vehicle;

- performance capacity of the vehicle;

- code on the engine;

- types of vehicle; and

- release date and registration date of the vehicle.

DID arrangements typically can store the following information, referred to as driver information, in the identification device in regard to the vehicle owner:

- Owner's name;

- Address; - contact number and further details;

- driver's license information;

information about additional drivers who may use the vehicle; and

insurance company information.

Fig. 8 shows one DID arrangement in which the identification device is implemented as an optical Quick Response (QR) code depicted as 803. Fig. 8 depicts a current licence plate 801 , and a licence plate 804 incorporating a DID arrangement.

The current licence plate 801 has registration information 806, visually perceivable by a person, painted on the plate 801. The registration information 806 is assigned to the vehicle to which the licence plate 801 is to be affixed as part of the registration procedure in which the owner of the vehicle has to participate when first registering the vehicle.

The DID licence plate 804 comprises a plate 802 upon which registration information 805, visually perceivable by a person, is painted. In addition, the DID plate 804 has an identification device 803 affixed to the plate, this being implemented using a QR code 803 in the present example. The identification device 803 stores vehicle information and driver information. The registration information 805 and the identification device 803 are assigned to the vehicle to which the licence plate 804 is to be affixed as part of the registration procedure in which the owner of the vehicle has to participate when first registering the vehicle. Alternately, or in addition, the driver information stored on the identification device 803 can be updated on a more frequent basis. Thus for example, as described in more detail in regard to Figs. 16 and 15 A, the DID arrangement in a vehicle can incorporate a driver ID scanner such as 1620. When entering the vehicle the driver can place his driver's license in readable proximity to the ID scanner 1620, enabling the scanner 1620 to read the driver's licence information and to communicate the information to the identification device 803.

Fig. 19 shows another DID arrangement in which the identification device is implemented as an integrated circuit (IC) comprising a solid state memory 1901 , a communications module 1903, a processor 1905, a Global Positioning System (GPS) module 191 1 and a power module 1908, communicating over a mixed power / data bus 1909 using respective connections 1902, 1904, 1906, 1907 and 1912. The memory 1901 stores a program 1910 for directing the processor 1905 to control the other modules to achieve, for example, communication with scanners 1609, 1612 as depicted by respective dashed arrows 1573, 1576 as depicted in Fig. 15A. The memory 1901 also stores vehicle information and driver information.

In another DID example (not shown), the identification device can be implemented using a Radio Frequency Identification Device (RFID) or Near Field Communication (NFC) chip, storing the desired information about the vehicle, and driver, and other information of interest.

Fig. 5 depicts a vehicle registration sticker 501 , incorporating a DID 502 in which the identification device is implemented using a QR code 502. Registration information 503 is assigned to the vehicle to which the registration sticker 501 is to be affixed as part of the registration procedure in which the owner of the vehicle has to participate when first registering the vehicle. Alternately, or in addition, the driver information stored on the identification device 502 can be updated on a more frequent basis using a driver ID scanner as described in regard to Fig. 8.

Fig. 12 depicts a number of alternate DID mounting arrangements 1200 on a vehicle 1202. In one DID arrangement an identification device 803 of the type depicted in Fig. 19 is affixed to a licence plate 802. This arrangement is suitable for a scenario in which the vehicle and driver information stored in the identification device 803 is accessed by a digital scanner such as 1609 or 1612 as depicted in Fig. 15A. "Smart phones", which are portable communication devices having touch screen multi -protocol communication capabilities are becoming popular, and enable wireless communication using a variety of protocols including, but not limited to, Wi-Fi (IEEE Standard 802.1 1η), Wi-Bro (IEEE 802.16e), Bluetooth and LTE (a Global mobile Suppliers Association standard). The proliferation of such devices facilitates development of software applications for use in retrieving information from DID identification devices such as 1615 in Fig. 16, enabling use of the aforementioned smart phones as scanner receivers.

In another DID arrangement an identification device 1201 of the type depicted in

Fig. 19 is affixed to a module (not shown) on the vehicle engine. This arrangement is suitable for a scenario in which the vehicle and driver information stored in the identification device 1201 is communicated, as depicted by an arrow 1582, to an onboard communication module 1616 which can communicate, as depicted by a dashed arrow 1578 with a server 1603 over a network 1605.

Fig. 1 1 depicts how vehicle and driver information 1 100 communicated by a DID arrangement can be constructed in layers, with some layers being encrypted. The information 1 100 in the example comprises an unencrypted layer of information 1 101 , such as the vehicle licence number, which can be freely accessed by a suitable receiver / scanner. A number of further layers 1 102. 1 103, using the same or different encryption methods, can be used for more sensitive information such as the driver's address.

Digitally recorded information sent from the DID arrangements can thus be graded according to the level of security required. For example, Level A (1 101) can consist of vehicle information such as those on a vehicle registration slip. Level B (1 102) can include the owner/driver's information such as license registration and past driving history (demerit points, history of license suspension and so on). Level C ( 1 103) can include information related to the identification of the owner/driver such as name, photograph, social insurance number, health insurance information, residential address, work address and so on.

As is clear from the above description, the information used in DID arrangements can be personal and the amount of information to be recorded should be carefully considered. To prevent unauthorised dissemination of private information, data should be suitably encrypted.

Fig. 16 is a functional block diagram of one DID system 1600. The system 1600 comprises a DID server 1603 communicating with a DID database 1 01 as depicted by an arrow 1602. The server communicates with the network 1605 as depicted by an arrow 1604. A vehicle 1617 which is equipped with a DID arrangement in the form of an identification device 1615 also has an on board communication module 1616 in the present example. Scanner / receiver devices 1609, 1612 can communicate, as depicted by respective arrows 1610, 1613, with the identification device 1615, in order to retrieve vehicle and driver information stored in the identification device 1615, subject to authorization and decryption constraints such as those depicted in Fig. 1 1 . The scanner / reader 1609 is referred to as a "public" device, indicating that it is typically used by a member of the public without requiring official authorisation. The device 1609 can be implemented using, for example, a smart phone 1609 (see Fig. 16) or other suitable mobile communication device, provided that the device 1609 is running a suitable software application 1618.

The scanner / reader 1612 is referred to as an "authorised" device, indicating that it is typically used by an official body such as the police, road and traffic authority etc,. The device 1612 can be implemented using proprietary equipment (not shown) running suitable software 1619. Authorized devices can be used as region communication devices which are distributed throughout a region in which capabilities of the DID arrangement in question are to be used. Examples of such uses are described in regard to Figs. 17 and 18.

The receiver / scanners 1612. 1609 can communicate with the DID server 1603 over the network 1605 as depicted by respective arrows 1607, 1608. An authorised user 1614, having authorization to access the server 1603 for maintenance purposes for example, can access the server 1603 over the network 1605 as depicted by an arrow 1606 using a suitable device such as a Personal Computer (PC) or mobile or fixed-line communication device.

The server 603 performs various DID methods, as depicted in Figs. 17 and 18 for example, in conjunction with one or more scanner readers such as 1612 and 1609, as directed by DID software 1533 running on the server 1603 and corresponding DID software 1619 and 1618.

The driver information stored on the identification device 1615 can be updated by incorporating a driver ID scanner such as 1620 in the vehicle 1617. When entering the vehicle the driver can place his driver's license in readable proximity to the ID scanner

1620, as depicted by a dashed arrow 1622, thereby enabling the scanner 1620 to read the driver's licence information and to communicate the information, as depicted by an arrow

1621 , to the identification device 1615.

Figs. 15A and 15B depict a general -purpose computer system 1500, upon which the various DID arrangements described can be practiced.

As seen in Fig. 15 A, the computer system 1500 includes: a computer module 1603 (which is the server in Fig. 16); input devices such as a keyboard 1502, a mouse pointer device 1503, a scanner 1526, a camera 1527, and a microphone 1580; and output devices including a printer 1515, a display device 1514 and loudspeakers 1517. An external Modulator-Demodulator (Modem) transceiver device 1516 may be used by the server 1603 for communicating to and from a communications network 1605 via a connection 1521.

The server 1603 can communicate over the network 1605 with the authorised user 1614, the public receiver / scanner 1609, the authorised receiver / scanner 1612, and the on-board communication module 1616 on the vehicle 1617 as depicted by respective arrows 1606, 1608, 1607, and 161 1 respectively.

An identification device 803 in a DID equipped vehicle 1617 can communicate directly, using short range communication technologies such as Bluetooth, RFID or NFC as depicted by dashed arrows 1573, 1576, with suitably equipped mobile communication devices 1609 and 1612 respectively. The identification device 803 (as depicted in Fig. 19), or the vehicle itself 1617, can incorporate Global Positioning System (GPS) information into the aforementioned communications, to augment the information provided to the mobile communication devices 1609, 1612. Alternately, the identification device can communicate, as depicted by an arrow 1582, with a more powerful on-board communication module 1616 which can extend the range of the identification device 803. This enables longer range communications, as depicted by an arrow 161 1.

The communications network 1605 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN; Where the connection 1521 is a telephone line, the modem 1516 may be a traditional "dial-up" modem. Alternatively, where the connection 1521 is a high capacity (e.g., cable) connection, the modem 1516 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1605.

The server 1603 typically includes at least one processor unit 1505, and a memory unit 1506. For example, the memory unit 1506 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 1603 also includes an number of input/output (I/O) interfaces including: an audio- video interface 1507 that couples to the video display 1514, loudspeakers 1517 and microphone 1580; an I/O interface 1513 that couples to the keyboard 1502, mouse 1503, scanner 1526, camera 1527 and optionally a joystick or other human interface device (not illustrated); and an interface 1508 for the external modem 1516 and printer 1515. In some implementations, the modem 1516 may be incorporated within the computer module 1603, for example within the interface 1508. The server 1603 also has a local network interface 151 1 , which permits coupling of the computer system 1500 via a connection 1523 to a local-area communications network 1522, known as a Local Area Network (LAN). As illustrated in Fig. 15 A, the local communications network 1522 may also couple to the wide network 1605 via a connection 1524, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 151 1 may comprise an Ethernet™ circuit card, a Bluetooth™ wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 151 1.

Although the Fig. 15A shows the server 1603 in more detail than other DID system modules such as the public reader / scanner 1609, devices such as 1609 and other modules which communicate with the server 1603 can have structural and functional elements similar to those described in relation to the server 1603.

The I/O interfaces 1508 and 1513 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 1509 are provided and typically include a hard disk drive (HDD) 1510. The server database 1601 may, in some DID arrangements, be implemented as a memory partition in the storage device 1509. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1512 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1500.

The components 1505 to 1513 of the computer module 1603 typically communicate via an interconnected bus 1504 and in a manner that results in a conventional mode of operation of the computer system 1500 known to those in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using a connection 1518. Likewise, the memory 1 06 and optical disk drive 1512 are coupled to the system bus 1504 by connections 1519. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple Mac™ or a like computer systems.

The DID methods may be implemented using the computer system 1500 wherein the DID processes, such as those depicted in Figs. 17 and 18, to be described, may be implemented as one or more software application programs 1533 executable within the computer system 1500. In particular, the steps of the DID methods are effected by instructions 1531 (see Fig. 15B) in the software 1533 that are carried out within the computer system 1500. The software instructions 1531 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the DID methods and a second part and the corresponding code modules manage a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1500 from the computer readable medium, and then executed by the computer system 1500. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 1500 preferably effects an advantageous apparatus for implementing the DID arrangements.

The software 1533 and the DID database are typically stored in the HDD 1510 or the memory 1506. The DID software 1533 is loaded into the computer system 1500 from a computer readable medium, and executed by the computer system 1500. Thus, for example, the software 1533 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1525 that is read by the optical disk drive 1512. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer system 1500 preferably effects an apparatus for implementing the DID arrangements.

In some instances, the application programs 1533 may be supplied to the user encoded on one or more CD-ROMs 1525 and read via the corresponding drive 1512, or alternatively may be read by the user from the networks 1-605 or 1522. Still further, the software can also be loaded into the computer system 1500 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1500 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1603. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1603 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs 1533 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1514. Similar software in the applications 1618, 1619 may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented on the receiver / scanners 1609, 1612 as depicted, for example, in Figs. 2, 6, 9, and 10. Through manipulation of typically the keyboard 1502 and the mouse 1 03, a user of the computer system 1500 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 1517 and user voice commands input via the microphone 1580.

Fig. 15B is a detailed schematic block diagram of the processor 1505 and a "memory" 1534. The memory 1534 represents a logical aggregation of all the memory modules (including the HDD 1509 and semiconductor memory 1506) that can be accessed by the computer module 1603 in Fig. 15 A.

When the computer module 1603 is initially powered up, a power-on self-test (POST) program 1550 executes. The POST program 1550 is typically stored in a ROM 1549 of the semiconductor memory 1506 of Fig. 15A. A hardware device such as the ROM 1549 storing software is sometimes referred to as firmware. The POST program 1550 examines hardware within the computer module 1603 to ensure proper functioning and typically checks the processor 1505, the memory 1534 (1509, 1506), and a basic input-output systems software (BIOS) module 1551 , also typically stored in the ROM 1549, for correct operation. Once the POST program 1550 has run successfully, the BIOS 1551 activates the hard disk drive 1510 of Fig. 15A. Activation of the hard disk drive 1510 causes a bootstrap loader program 1552 that is resident on the hard disk drive 1510 to execute via the processor 1505. This loads an operating system 1553 into the RAM memory 1506, upon which the operating system 1553 commences operation. The operating system 1553 is a system level application, executable by the processor 1505, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system 1553 manages the memory 1534 (1509, 1506) to ensure that each process or application running on the computer module 1603 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 1500 of Fig. 1 A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1534 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1500 and how such is used.

As shown in Fig. 15B, the processor 1505 includes a number of functional modules including a control unit 1539, an arithmetic logic unit (ALU) 1540, and a local or internal memory 1548, sometimes called a cache memory. The cache memory 1548 typically include a number of storage registers 1544 - 1546 in a register section. One or more internal busses 1541 functionally interconnect these functional modules. The processor 1505 typically also has one or more interfaces 1542 for communicating with external devices via the system bus 1504, using a connection 1518. The memory 1534 is coupled to the bus 1504 using a connection 1519.

The application program 1533 includes a sequence of instructions 1531 that may include conditional branch and loop instructions. The program 1533 may also include data 1532 which is used in execution of the program 1533. The instructions 1531 and the data 1532 are stored in memory locations 1528, 1529, 1530 and 1535, 1536, 1537, respectively. Depending upon the relative size of the instructions 1531 and the memory locations 1528- 1530, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1530. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1528 and 1529.

In general, the processor 1505 is given a set of instructions which are executed therein. The processor 1 105 waits for a subsequent input, to which the processor 1505 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1502, 1503, data received from an external source across one of the networks 1605, 1502, data retrieved from one of the storage devices 1506, 1509 or data retrieved from a storage medium 1525 inserted into the corresponding reader 1512, all depicted in Fig. 15 A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 1534.

The disclosed DID arrangements use input variables 1554, which are stored in the memory 1534 in corresponding memory locations 1555, 1556, 1557. The DID arrangements produce output variables 1561 , which are stored in the memory 1534 in corresponding memory locations 1562, 1563, 1564. Intermediate variables 1558 may be stored in memory locations 1559, 1560, 1566 and 1567.

Referring to the processor 1505 of Fig. 15B, the registers 1544, 1545, 1546, the arithmetic logic unit (ALU) 1540, and the control unit 1539 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 1533. Each fetch, decode, and execute cycle comprises:

(a) a fetch operation, which fetches or reads an instruction 1531 from a memory location 1528, 1529, 1530;

(b) a decode operation in which the control unit 1539 determines which instruction has been fetched; and

(c) an execute operation in which the control unit 1539 and/or the ALU 1540 execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 1539 stores or writes a value to a memory location 1532.

Each step or sub-process in the DID processes such as the processes of Figs. 17, 18 is associated with one or more segments of the program 1533 and is performed by the register section 1544, 1545, 1547, the ALU 1540, and the control unit 1539 in the processor 1505 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1533.

The DID methods may alternatively be implemented in dedicated hardware such as one or more gate arrays and/or integrated circuits performing the functions or sub functions of the DID arrangements. Such dedicated hardware may also include graphic processors, digital signal processors, or one or more microprocessors and associated memories. If gate arrays are used, the process flow charts in Figs. 17, 18 are converted to Hardware Description Language (HDL) form. This HDL description is converted to a device level netlist which is used by a Place and Route (P&R) tool to produce a file which is downloaded to the gate array to program it with the design specified in the HDL description.

Fig. 14 depicts a functional block diagram 1400 of one example of a DID arrangement. An informant 1609 having a mobile communication device equipped with the DID public receiver / scanner software application communicates, as depicted by an arrow 1610 with an identification device (not shown) in the DID equipped vehicle 1617 in order to retrieve vehicle and driver information for which the informant is authorised. In many cases the informant will only be able to access the publicly available information 1 101. The informant then communicates, as depicted by an arrow 1608, with a receiving department 1401 which has access to the server 1603. If the DID arrangement in question relates to traffic violations, for example, the receiving department 1401 might be associated with the local traffic police. A responding department 1402 can communicate, as depicted by the arrow 161 1 with the owner driver 1614" of the vehicle 1617 in question. The responding department 1402 can also communicate, as depicted by an arrow 1404 with an insurance company 1614' or with a police mobile unit 1614 as depicted by an arrow 1403.

Police, or anyone who requires vehicle information can scan the identification device in the DID arrangement to obtain information related to the vehicle 1617 such as driver's license information, past maintenance records and so on. As a result, existing driver's license related tests and examination can be completed more efficiently depending on how the DID arrangements are used. DID arrangements have the potential to achieve savings in time and cost for such activities.

The DID arrangements can be used to find car thieves as it can provide the registered owner/driver's information with one scan to be used when identifying the vehicle owner. The DID arrangements can also be used by the police when creating a suspect list through the use of Level A information (see 1 101 in Fig. 1 1 ). Real-time spot checks of insurance registration, vehicle tax payment or even emission tests can also be performed.

Fig. 4 depicts a region scanning device (being an authorised reader / scanner such as 1612) configured to communicate with DID equipped vehicles, the scanning device being mounted on a pavement mounted parking meter. The reader / scanner can be integrated into a parking monitoring system in the parking lot in order to issue parking tickets and monitor overstaying vehicles.

Fig. 3 depicts a region scanning device (being an authorised reader / scanner such as 1612) configured to communicate with DID equipped vehicles, mounted on a street lighting pole. Such systems can be used to retrieve vehicle and driver information from identification devices 803 in DID equipped vehicles as they drive past. Such information can include overdue registration, unpaid licences, lost and stolen vehicles, and this can be sent to the appropriate receiving authority (eg 1401 in Fig. 14) for appropriate action. The aforementioned capability can also be incorporated into traffic light poles, telegraph poles and the like.

Fig. 7 depicts a menu of selectable software applications on the display of a smart phone remote scanner (such as 1609 which can be used as a public reader / scanner), one of which applications (eg 1618) can be downloaded and used by a user of the scanner to practice the DID method. Fig. 2 depicts an augmented reality representation, generated by the DID software application 1533, of two vehicles incorporating corresponding DID arrangements, as viewed on the display of a remote scanner such as 1609 (implemented, for example, using a large screen display smart mobile phone). Utilising a similar function as Augmented Reality (AR) provided on smart phones, an application can be developed to present information of vehicles through photographs. Thus, for example, a user of the smart phone 1609 having a DID software application 1533 running can point the camera, which is typically incorporated into such smart phones, at a car that is behaving erratically. Fig. 2 shows three cars 202, 203 and 204 in view. The smart phone 1609 downloads, as depicted by the arrow 1610 in Fig. 16, driver and vehicle information, as well as GPS information, from the DID devices that are mounted on the license plates of the vehicles 202 and 204. The DID software application 1533 running on the smart phone 1609 displays respective licence plate information 201 and 205 for the aforementioned vehicles 202, 204. If the vehicle 202 is the vehicle that is behaving erratically, the user of the smart phone 1609 taps the touch sensitive screen of the smart phone over the licence information 201 , and then taps the circle 206 to indicate that the erratic behaviour is serious and that the matter is urgent. The finger tap on the "urgent" soft key 206 then sends the photograph, with the identification of the vehicle 202 as being the offending vehicle, to a receiving department 1401 for their attention. A "normal" soft key 207 can be used to send the photograph without an urgent flag, indicating that the receiving department 1401 should look into the matter but that it is not urgent.

Fig. 6 depicts a representation, generated by the DID software application 1533 running on a smart phone scanner 1609, of several vehicles incorporating corresponding DID arrangements, as viewed on the display of the remote scanner 1609. This interface is useful in cases where a number of vehicles, one of which is behaving erratically, pass the user of the smart phone 1609 too quickly to enable the user to make use of the user interface depicted in Fig. 2. In this instance, the DID software presents a list of all the DID equipped vehicles in range of the smart phone 1609, providing the user with the opportunity of selecting the offending vehicle if this vehicle was identified by the user in the brief time the vehicle passed. The user of the smart phone 1609 can tap on the screen.

Fig. 9 depicts another augmented reality representation of a number of vehicles incorporating corresponding DID arrangements, as viewed on the display of a remote scanner such as 1609. The driver of a vehicle such as 1001 is able to receive, on the display of their smart phone scanner 1609, an aerial view of an area 903 surrounding their vehicle 1001. The view in Fig. 9 includes Avatar representations 901 , 904 of other DID equipped vehicles (with displays of associated vehicle ID information 902, 905 respectively) which are located within the area 903. The avatar representations 901 , 904 may be simple rectangles as shown in Fig. 9, or may be more complex avatars having the visual appearance of real motor vehicles. This is described in more detail with reference to Fig. 10.

Fig. 10 shows a functional block diagram of a system 1000 for generating and displaying the augmented reality representation depicted in Fig. 9. The system 1000 includes the vehicle 1001 having an associated identification device 1615. The driver of the vehicle 1001 has a scanner 1609 which can execute the DID software application 1618. The vehicle 1001 and the smart phone 1609 communicate, as depicted by respective arrows 1003, 1004 over a communications network 1005, with a location detection server 1008 and a management server 1009, over respective connections 1006, 1007.

The location detection server 1008 receives location information about the location of the vehicle 1001 from a GPS module 191 1 in the identification device 161 . The server 1008 communicates this to the management server 1009. A Location management module 1010 and a map creation module 1 12 in the managemen 1009 use the location information to create the map 900 including the roads showr 9 and other information. The location detection server 1008 also receives location information about the location of the vehicles 901 , 904 from GPS modules in their respective identification devices (not shown).

The location management module 1010 and the map creation module 1012 in the management server 1009 use the location information about the vehicles 1001 , 901 and 904 to plot the positions of the vehicles on the map 900. An avatar management module 101 1 generates avatars for the respective vehicles.

The location management module 1010 and the map creation module 1012 in the management server 1009 provide the location information about the vehicles 1001 , 901 and 904 to a service control module 1013, which also receives avatar descriptions from the avatar management module 101 1. The service control module 1013 processes this information and communicates associated processed information to the smart phone 1609 to produce the virtual reality display 900 on the driver's smart phone 1609.

Fig. 13 depicts the range of information stored within the Smart License plate. The range of information which may be stored and retrieved from within a Smart License plate include the plate registration number (eg 12345), vehicle details (make, model etc), driver's license details, car insurance, car registration, GPS location, car registry sticker, time and date and phone number.

Fig. 1 depicts a chip scanner positioned in the car handle.

The present invention enables driver's license chip scanning from a car handle.

1. Scan driver's license by chip scanner (B) from a car handle (D

2. Information such as driver's license details transmitted by a smart chip (F) placed in license plate (E) may be sent from a chip scanner by internet or Wi-Fi. Lower picture: smart chip detail

a. ROM read on memory

b. Temporary memory:driver license(need security password lock)

c. read write sms etc

Fig. 17 shows a flow chart representation of a method 1700 for reporting a vehicle incident using a DID arrangement. The method 1700 commences with a decision step 1701 in which a reader / scanner such as 1609 (eg a smart phone in the possession of a pedestrian) is in a wait state pending the detection, by the user of the smart phone, of a vehicle incident.

Vehicle incidents can include, for example, scenarios in which a driver is partially incapacitated, due to an unexpected medical condition such as a heart attack, or due to having too high a blood alcohol level.

If the step 1701 returns a logical FALSE, then the process 1700 follows a NO arrow 171 1 back to the step 1701 in a looping manner. If the step 1701 detects a vehicle incident, the process 1700 follows a YES arrow 1702 to a step 1703. In the step 1703, the reader 1609 communicates, under the control of the pedestrian, with the identification device 803 in the DID equipped vehicle 1617. The identification device 803 can be incorporated into the vehicle 1617 in a number of ways, as described, for example, in regard to Fig. 12.

The process 1700 then follows an arrow 1704 to a step 1705. In the step 1705 the reader 1609 retrieves vehicle and driver information from the identification device 803, depending upon the authorisation level of the pedestrian and the encryption level of the information (eg see Fig. 1 1 ). The process 1700 then follows an arrow 1706 to a step 1707. In the step 1707 the reader 1609 presents the vehicle and driver information to the pedestrian on a display of the reader 1609, as depicted in Figs. 2, 6, 9 or 10 for example.

While the aforementioned information is so displayed, the process 1700 follows an arrow 1708 to a step 1709 in which the reader 1609, under the control of the pedestrian, 5 communicates with a third party communication device such as the server 1603 (see Fig.

16), which communicates with the receiving department 1401 (see Fig. 14). The pedestrian user of the smart phone 1609 can communicate in the step 1709 by tapping the requisite icons on the display of the smart-phone 1609 as described in regard to Figs. 2 and 6 for example.

I o The process 1700 then follows an arrow 1710 back to the step 1701.

The described DID arrangements thus enable the pedestrian, under circumstances as described above, to take photographs of the vehicle using their smart phone, and to send the photographs to the agency 1401 via the server 1603. GPS information is typically incorporated, thus providing location trace facilities.

15 DID arrangements can, by enabling processes such as 1700, increase safety on the road. Dangerous driving, drunk driving, dozing off at the wheel, missing license plates or unskilled driving can be reported as vehicle incidents. This information which is received at the Receiving Department (1401) can be transferred to relevant responding offices (1402) to keep the road safe.

20 DID arrangements can also be used in situations where a vehicle is shared by a number of drivers by incorporation of the driver ID scanner 1620 as described in regard to Figs. 16 and 15 A. Taking one example, ie when a speeding ticket is issued, it is essential to know who was driving the vehicle when the driving ticket is issued. The DID arrangement including the driver scanner 1620 can maintain a daily log of which drivers used the

25 vehicle at which times, thus facilitating issuance of the ticket to the correct driver. Fig. 18 shows a flow chart representation of a method 1800 for checking compliance status of various types for a vehicle using a DID arrangement. The method 1800 commences with a decision step 1801 in which a reader / scanner such as 1612 (eg a authorised reader / scanner mounted in a street light pole as depicted in Fig. 3) is in a wait state pending detection of an identification device 803 in a DID equipped vehicle 1617.

If the step 1801 returns a logical FALSE, then the process 1800 follows a NO arrow 1802 back to the step 1801 in a looping manner. If the step 1801 detects an identification device, the process 1800 follows a YES arrow 1803 to a step 1804. In the step 1804, the reader 1612 communicates with the identification device 803 in the DID equipped vehicle 1617, and retrieves vehicle and driver information from the identification device 803. This includes compliance information such as when the license fee for the vehicle 1617 was paid.

The process 1800 then follows an arrow 1805 to a step 1806. In the step 1806 the reader 1612 communicates the retrieved compliance information to the server 1603. The process 1800 then follows an arrow 1807 to a step 1808. In the step 1808 the server 1603 matches the compliance information retrieved from the vehicle against compliance requirements for the vehicle, these requirements being stored in the database 1601. If the compliance information retrieved from the vehicle matches the compliance requirement recorded in the database 1601 , then the vehicle is compliant in regard to that particular information item. The process 1800 then can in a following step 1810 record this compliance in the database. If there is a mismatch between the compliance information retrieved from the vehicle and compliance requirement recorded in the database 1601 , the server 1603 can record in the step 1810 this mismatch in the database 1601 and, if desired, communicate with the driver of the vehicle, as depicted by the dashed arrow 161 1, to let the driver know about the mismatch. The process 1800 then follows an arrow 181 1 back to the step 1801.

The DID arrangements can also be used to provide drivers of DID equipped vehicles with useful information. In one DID arrangement, region communication devices such as 1612 in Fig. 3 are distributed throughout a region in which this information communication is to be performed.

The server database 1601 stores useful information such as driving condition information for various areas, information about scheduled maintenance requirements for the vehicle in question, driving licence renewal information and other items of useful information.

The server 1603 can communicate with the database 1601 and with the region communication devices such as 1612 over the network 1605.

Region communication devices such as 1612 which communicate with the identification device 1615 of the vehicle in question 1617, retrieve a location of the vehicle 1617, and communicate this to the server 1603. The server correlates the vehicle driver and vehicle information and the vehicle location with the information in the database and communicates, to the vehicle communication device 1616 of the vehicle 1617, at least some of the information for the vehicle stored in the database.

Industrial Applicability

The arrangements described are applicable to the computer and data processing industries.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

Thus for example DID arrangements can be used when managing large parking lots where high security is crucial such as government buildings, major companies or even shopping centres. Inbuilt digital scanners such as 1612 in Fig. 4 can record information such as how many vehicles are in the parking lot, and can also identify the model of the vehicle, who is driving the vehicle (if the vehicle is equipped with a DID arrangement having a driver ID scanner 1620) and so on. Drivers of stolen cars would not be able to frequent such areas as to do so would lead to their detection and apprehension. Furthermore, the identification device can be implemented in other configurations including, for example, a USIM (Universal Subscriber Identity Module).

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

Claims The claims defining the invention are as follows:

1. A vehicle licence plate comprising:

2. A vehicle licence plate according to claim 1 , wherein the second vehicle information is stored either as part of the registration procedure, or during an update procedure in which the second information is input to a driver ID scanner is a vehicle to which the licence plate is affixed, the scanner communicating the input second information to the identification device.

3. A vehicle licence plate according to claim 1 , wherein the identification device comprises a processor, and a memory device storing a software program for directing the processor to communicate the first information and the second information to the receiving device.

4. A vehicle licence plate according to claim 1 , wherein the identification device further comprises a Global Positioning System module for (a) determining a location of the identification device and (b) incorporating the location into the second vehicle information.

5. A vehicle licence plate according to claim 1 , wherein the second vehicle information comprises one or more of:

license plate number of the vehicle;

colour of vehicle;

manufacturing company of the vehicle;

model of the vehicle;

performance capacity of the vehicle;

code on the engine;

type of vehicle;

release date and registration date of the vehicle.

6. A vehicle licence plate according to claim 1, wherein the second vehicle information comprises one or more of

vehicle owner's name;

vehicle owner's address;

vehicle owner's contact number;

vehicle owner's driver's license information;

information about additional drivers who may use the vehicle; and

vehicle owner's insurance company information.

7. A system for reporting vehicle incidents in relation to a vehicle having a vehicle licence plate according to claim 1, said system comprising: a mobile communication device comprising a processor and a memory having stored therein a program for directing the mobile communication device to perform a method comprising the steps of:

(a) communicating with the identification device;

(b) retrieving the second vehicle information stored in the identification device; and

(c) enabling a user of the mobile communication device to communicate with another communication device ; wherein the steps (a), (b) and (c) can be performed when the user of the mobile communication device sees the vehicle involved in a vehicle incident.

8. A method for reporting vehicle incidents, said method comprising the steps of:

(a) communicating by a mobile communication device with an identification device in a licence plate on a vehicle when a user of the mobile communication device sees the vehicle involved in a vehicle incident;

(b) retrieving by the mobile communication device second vehicle information stored in the identification device; and

(c) communicating by the mobile communication device with another communication device in order to report the vehicle incident.

9. A system for detecting non-compliance of vehicles in relation to a vehicle having a vehicle licence plate according to claim 1 , wherein the second vehicle information includes compliance information for the vehicle, said system comprising:

a plurality of region communication devices distributed throughout a region in which said non-compliance is to be detected; a network;

a database storing compliance requirement information for said vehicle; and a server configured to communicate with the database and the plurality of region communication devices over the network, the server comprising a processor and a memory having stored therein a program for directing the server to perform a method comprising the steps of

(a) communicating with the plurality of region communication devices;

(b) receiving, from a said one of the plurality of region communication devices communicating with the identification device of the vehicle, the compliance status information for the vehicle;

(c) matching the received compliance status information against the compliance requirement information for the vehicle stored in the database; and

(d) detecting that the vehicle is non-compliant if a mismatch is detected in the step

(c).

10. A system according to claim 8, wherein the compliance information comprises at least one of:

information on whether the current licence fee for the vehicle has been paid; information on whether the current insurance fee for the vehicle has been paid; information on whether current traffic fines for the vehicle have been paid; and information on whether the vehicle has been serviced by a predefined date.

1 1. A method for detecting non-compliance of vehicles, said method comprising the steps of: (a) communicating, by one of a plurality of region communication devices distributed throughout a region in which said non-compliance is to be detected, with an identification device being one of in and on a licence plate of a vehicle, to thereby receive compliance status information for the vehicle stored in the identification device;

(b) communicating by a server with the plurality of region communication devices over a network;

(c) receiving, by the server, the compliance status information from said one of a plurality of region communication devices;

(d) matching, by the server, the received compliance status information against compliance requirement information for said vehicle stored in a database; and

(e) detecting that the vehicle is non-compliant if a mismatch is detected in the step

(d).

12. A system for communicating information to vehicles, said system comprising: a vehicle with a vehicle licence plate according to claim 1, said vehicle further comprising a vehicle communication device;

a plurality of region communication devices distributed throughout a region in which said information communication is to be performed;

a network;

a database storing information for said vehicle; and

a server configured to communicate with the database and the plurality of region communication devices over a. network, the server comprising a processor and a memory having stored therein a program for directing the server to perform a method comprising the steps of

(a) communicating with the plurality of region communication devices; (b) receiving, from a said one of the plurality of region communication devices communicating with the identification device of the vehicle, a location of the vehicle; and

(c) communicating, the vehicle communication device of the vehicle, at least some of the information for the vehicle stored in the database.

13. A system according to claim 9, wherein the information for the vehicle comprises at least one of:

driving condition information for an area at the location of the vehicle;

information about scheduled maintenance requirements for the vehicle; and driving licence renewal information.

14. A method for communicating information to vehicles, said method comprising the steps of:

(a) communicating, by one of a plurality of region communication devices distributed throughout a region in which said information is to be communicated, with an identification device being one of in and on a licence plate of a vehicle, to thereby determine location information for the vehicle;

(c) receiving, by the server, the location information from said one of the plurality of region communication devices; and

(d) communicating, the vehicle communication device of the vehicle, information for the vehicle stored in a database.

15. A vehicle licence plate according to claim 1 , wherein the identification device comprises:

a communications module;

a GPS module;

a processor; and

a memory configured to store a program; wherein the program is configured to direct the processor and the communication module to perform at least one of:

the method for reporting vehicle incidents according to claim 7;

the method for detecting non-compliance of vehicles according to claim 10; and the method for communicating information to vehicles according to claim 13.

16. A computer readable storage medium having a computer program recorded therein, the program being executable by a computer apparatus to make the computer perform a method for reporting vehicle incidents, said method comprising the steps of: communicating by a mobile communication device with an identification device in a licence plate on a vehicle when a user of the mobile communication device sees the vehicle involved in a vehicle incident;

retrieving by the mobile communication device second vehicle information stored in the identification device; and

communicating by the mobile communication device with another communication device in order to report the vehicle incident.

17. A computer readable storage medium having a computer program recorded therein, the program being executable by a computer apparatus to make the computer perform a method for detecting non-compliance of vehicles, said method comprising the steps of:

communicating, by one of a plurality of region communication devices distributed throughout a region in which said non-compliance is to be detected, with an identification 5 device being one of in and on a licence plate of a vehicle, to thereby receive compliance status information for the vehicle stored in the identification device;

receiving, by the server, the compliance status information from said one of a l o plurality of region communication devices;

15

18. A method for reporting vehicle incidents, substantially as described herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings.

19. A method for detecting non-compliance of vehicles, substantially as described 0 herein with reference to any one of the embodiments, as that embodiment is shown in the accompanying drawings.

20. A plate, system, method or program according to any one of the preceding claims wherein a chip scanner is positioned in a car handle.

21. A plate, system, method or program according to any one of the preceding claims 5 wherein a driving license icon is displayed in smart phones.