AU2019101519A4 - System for providing verifiable and secure vehicle information - Google Patents

Abstract

A system for providing verifiable and secure information relating to vehicles is provided. The system includes: an electronic ledger, the electronic ledger including a plurality of events from a plurality of different entities and relating to a vehicle. The events are stored in a plurality of blocks forming the electronic ledger, wherein each block of the ledger is linked to an earlier block of the ledger to thereby provide an ordered and verifiable list of the plurality of events. -U Li, 0 1u uJ z) u <C LLD HO- LU 0i zU:) - 0 uJ u~

Description

SYSTEM FOR PROVIDING VERIFIABLE AND SECURE VEHICLE INFORMATION

TECHNICAL FIELD [0001] The present invention relates to information about vehicles, such as motor vehicles. In particular, although not exclusively, the invention relates to the provision of verifiable information about the history of motor vehicles.

BACKGROUND ART [0002] It is well established that the history of a second-hand vehicle is an important factor to consider when purchasing the vehicle. In particular, a vehicle that has been serviced according to schedule, not been in any accidents, and has only had a single owner is generally going to be more desirable, and thus have a higher value, than a vehicle that has not been properly serviced, has been in an accident, and has had many owners, all other factors being the same.

[0003] A service history of a vehicle is thus generally documented in a service book using stamps, signatures, dates and mileage information. As the service history, if timely and complete, is a generally positive attribute of the vehicle, the owner of the vehicle is generally careful in ensuring that such history stays associated with the vehicle, as it is in his or her interest to do so. However, it is not in the interest of an owner of the vehicle to maintain historical information that is not positive, such as a history at a car rental company, accident repairs, or the like. As such, this type of history is often difficult to ascertain from sellers of a motor vehicle, who themselves may not be fully aware of the entire history of the vehicle, particularly if they have purchased the vehicle without knowing such information.

[0004] Attempts have been made to provide registers that include historical information about vehicles, such as the written-off vehicle register (WOVR) in Australia, which provides information regarding whether a vehicle has previously been recorded as being “written off” and been repaired. Furthermore, regulations are provided that require parties to record vehicles in the WOVR under certain circumstances.

[0005] A problem, however, with such registers is that they generally relate to a single aspect of the vehicle (e.g. whether the vehicle has been written off), and it is difficult to get an accurate historical overview of all aspects of a vehicle.

[0006] Certain centralised vehicle history registers exist, which provide the user with a more detailed history of the vehicle, such as service history (from participating service centres), accident information, and title information. A problem, however, with such registers is that they

2019101519 05 Dec 2019 are generally based upon automatically collated information from multiple registers, which can be erroneous, only include information from certain sources, and it can be relatively easy to modify or falsify vehicle history reports therefrom.

[0007] As a result, it is very difficult for an individual, such as a potential buyer, to obtain an accurate and complete history of a vehicle. This became apparent in the Takata airbag recalls of 2013 and onwards, as it was very difficult for a vehicle owner to determine whether the airbag had already been replaced, particularly if they were not the owner of the vehicle for the entire period since the recall was initiated. As a result, vehicle owners may unknowingly be driving a vehicle that has a faulty airbag or other issue.

[0008] As such, there is clearly a need for an improved vehicle information system.

[0009] It will be clearly understood that, if a prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art in Australia or in any other country.

SUMMARY OF INVENTION [0010] The present invention is directed to a system for providing vehicle information, which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

[0011] With the foregoing in view, the present invention in one form, resides broadly in a system for providing verifiable and secure information relating to vehicles, the system including: an electronic ledger, the electronic ledger including a plurality of events from a plurality of different entities and relating to a vehicle, the events stored in a plurality of blocks forming the electronic ledger, wherein each block of the ledger is linked to an earlier block of the ledger to thereby provide an ordered and verifiable list of the plurality of events.

[0012] Advantageously, the system enables users to obtain verifiable and secure information about a vehicle, which in turn enables them to make better decisions about the vehicle.

[0013] The events may include sale events, relating to the sale of the vehicle.

[0014] The events may include service events, relating to the servicing of the vehicle. As such, the system may be used to provide a verifiable and secure logbook I written service history of the vehicle.

2019101519 05 Dec 2019 [0015] The events may include accident and/or repair events, relating to accidents or repairs relating to the vehicle.

[0016] Preferably, the system includes a hash of each block, to enable later modification of the block to be identified. Each block may be linked to an earlier block using the hashes, and to thereby form a verifiable chain of blocks and thus events. The validity of each block may be dependent on the validity of one or more previous blocks.

[0017] The hash may be configured to take the data of the block as input, and generate a standard-length output based thereon.

[0018] At least one block may include data corresponding to the hash of the previous block. The at least one block may directly include the hash. The at least one block may indirectly include the hash.

[0019] Each block may be configured to store data of one or more events.

[0020] An initial block may store vehicle identification data. The vehicle identification data may include a Vehicle Identification Number (VIN). The initial block may further include a vehicle description. The vehicle description may include make, model, configuration, colour, manufacturer, and/or compliance data.

[0021] Each block may include a timestamp. A chronology of the system may be defined according to the timestamp.

[0022] The events may comprise events of a plurality of different registered entities. The registered entities may be each associated with a key to provide a digital signature. The key may be used to authenticate data of the block. The key may be a key of a public key I private key authentication system.

[0023] The system may include a central authority responsible for registering entities. The central authority may issue public and private keys to the entities.

[0024] The central authority may provide different permissions to different entities. The first block may include a digital signature of the central authority.

[0025] The central authority may control what is entered onto the ledger. The plurality of blocks may each include a digital signature of the central authority.

[0026] The system may be configured to generate a report based upon the event data.

2019101519 05 Dec 2019 [0027] The system may be configured to analyse event data to generate at least part of the report.

[0028] The system may be configured to search for vehicles across multiple ledgers, and generate the report based thereon. The system may be configured to search according to VIN.

[0029] When adding a new vehicle, the system may be configured to ensure that the same VIN has not been previously used.

[0030] The electronic ledger may comprise a distributed ledger, distributed across a network of computers (nodes). The nodes may be configured to verify the ledgers. The nodes may verify the ledgers for a transaction fee.

[0031] Blocks may be added to the ledger when there is consensus among a plurality of nodes.

[0032] Preferably, the ledger comprises a blockchain ledger. The events may be stored in blocks of the blockchain ledger.

[0033] In another form, the invention resides in a method for providing verifiable and secure information relating to vehicles, the method including:

generating an initial block of an electronic ledger that is associated with a vehicle; and adding one or more events to the electronic ledger as blocks, the blocks each linked to an earlier block of the ledger to thereby provide an ordered and verifiable list of the plurality of events.

[0034] The method may include distributing the blocks on a distributed ledger.

[0035] The method may include verifying the blocks, both individually and as a whole (i.e.

the sequence or chain of blocks).

[0036] The method may include generating a vehicle history report according to the blocks.

[0037] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the invention.

[0038] The reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

2019101519 05 Dec 2019

BRIEF DESCRIPTION OF DRAWINGS [0039] Various embodiments of the invention will be described with reference to the following drawings, in which:

[0040] Figure 1 illustrates a system for providing verifiable and secure vehicle information, according to an embodiment of the present invention.

[0041] Figure 2 schematically illustrates a ledger of the system of Figure 1, according to an embodiment of the present invention.

[0042] Figure 3 illustrates a screenshot vehicle history report of the system of Figure 1, according to an embodiment of the present invention.

[0043] Figure 4 illustrates a method for providing verifiable and secure vehicle information, according to an embodiment of the present invention.

[0044] Figure 5 illustrates a method of creating a distributed ledger for a new vehicle, according to an embodiment of the present invention.

[0045] Figure 6 illustrates a method of adding a new event to an existing vehicle ledger, according to an embodiment of the present invention.

[0046] Figure 7 illustrates a method of generating a report relating to a vehicle, according to an embodiment of the present invention.

[0047] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way.

DESCRIPTION OF EMBODIMENTS [0048] Figure 1 illustrates a system 100 for providing verifiable and secure vehicle information, according to an embodiment of the present invention. The system 100 enables users 105, such as potential purchasers, owners or insurance companies, to obtain verifiable and secure information about a vehicle 110, which enables them to make better decisions about the vehicle 110. This can in turn prevent fraud relating to vehicles, and reduce the likelihood that a vehicle has unknown issues.

[0049] As outlined below, the system 100 is based upon a distributed ledger 115, such as

2019101519 05 Dec 2019 a blockchain ledger, which is associated with the vehicle 110 and prevents the vehicle history information from being modified or removed. The blockchain ledger enables the user 105 to verify the vehicle information in a straightforward manner, and be able to trust that it has not been modified, e.g. by a seller.

[0050] The system 100 includes a plurality of registered entities 120, including vehicle manufacturers, government transport departments, insurers, repair shops and service centres, which enter event data into a ledger relating to the vehicle 110, which is distributed on the distributed ledger 115. In particular, when one of the registered entities 120 encounters the vehicle 110, details of the event are added to the ledger in a chain like manner and shared to the distributed ledger 115. In particular, and as outlined in further detail below, each event is added to the ledger as a block in a chain of blocks in chronological order, where the validity of each block is based upon the previous blocks, thus preventing manipulation of earlier blocks in the ledger.

[0051] Initially, the entities 120 register with a central authority 125. Such process may include verification of each of the entities 120, payment of registration fees and the like, upon which the central authority 125 registers the entities 120 into the system 100 and provides each of the entities 120 with a unique public I private key pair. The public key is associated with the entity and is made publicly available, whereas the private key is kept private by each registered entity 120, and is used to encode data of an event. As a result, the public keys can be used to authenticate the data provided by each of the registered entities 120, much like authentication using public key cryptography.

[0052] When the vehicle 110 is manufactured, an initial block is generated, which includes a description of the vehicle, such as make, model, configuration, colour, manufacturer data, compliance data, and identifiers identifying the vehicle, such as a Vehicle Identification Number (VIN). That block includes a timestamp, and a hash of the data contained therein is generated. The hash is linked to subsequent blocks, and enables an entity, such as the user 105, to verify that the data therein has not changed by generating a hash of the data and comparing the generated hash with the recorded hash. The block is the first block of the ledger associated with the vehicle and is distributed to the distributed ledger 115.

[0053] Each time an event occurs in relation to the vehicle 110, the registered entity 120 responsible for that event records the event in the distributed ledger 115 by generating a new block, which includes a description of the event, such as event type (e.g. routine service, repair, accident), and data relating to the event, such as date of the event, and details of the event (e.g. the type of accident or repair performed. That block includes a timestamp and a hash of the

2019101519 05 Dec 2019 data contained therein and the hash of the previous block, which enables an entity to verify that the data therein has not changed, and that the link between the block and the previous block is valid.

[0054] The distributed ledger 115 grows as events occur, as blocks are added to the ledger each time an event is recorded. The blocks are added to the ledger in chronological order according to the timestamps. A timestamp server (not shown) may be administered by the central authority 125, such that when adding new blocks, the entities 120 may obtain a timestamp therefrom.

[0055] When an entity attempts to add an event to the ledger, it is shared across a network of computers (nodes) of the distributed ledger 115, where it is checked. One feature of the distributed ledger 115 is that it enables the multiple computers (nodes) of the distributed ledger 115 to check the details of the new event, including the chain on which it is based, to make sure it is valid.

[0056] If two entities 120 attempt to add an event to the same ledger (i.e. at about the same time), the entity 120 with the first timestamp will win, and its block will be added to the ledger 115. In particular, the second entity that is attempting to add the block to the chain of blocks will be informed that consensus is not reached for its block (and thus adding the event has failed), and may try again. This process may be similar to the process for determining whether a coin in a crypto currency, such as Bitcoin, has been spent twice.

[0057] Generally each vehicle is associated with a quite limited number of events, so while such clashes are theoretically possible, they are expected to be very rare. As such, the likelihood of multiple clashes in a row is expected to be very low.

[0058] The hash and/or a signature may be generated in part according to the private key of the entity 120 adding the event, to provide authentication that the event was actually added to the ledger by the entity 120. In one embodiment, an authentication signature of the block is generated, much like the hash, but using the private key of the entity that entered the event. As a result, the public key of the entity 120, which is publicly available, may be used by the user 105, the nodes of the distributed ledger, or any other entity, to verify that the entity actually added the event.

[0059] The central authority 125 may provide different permissions to different entities 120, and publish details of same, e.g. in association with their public keys. As an illustrative example, the central authority 125 may give permission to create new ledgers for new vehicles to manufacturers and government transport departments only, whereas repair shops, for example,

2019101519 05 Dec 2019 may not create such new ledgers. Similarly, different entities 120 may be provided with permissions to add different types of events to the ledger, such as an insurer may have permission to add an accident-type event to the ledger, and a service centre may have permission to add a service-type event to the ledger.

[0060] In addition to utilising the system 100 for new vehicles, the system 100 may be used to add verifiable and secure history of an existing vehicle from a particular point in time. In such case, the system 100 is used much like it has been described above in relation to new vehicles, but only providing a history of the vehicle from the point of time at which the first block was created. As such, a history of that vehicle can be easily verified from that point, with any earlier history being unverified.

[0061] When the user 105 wishes to obtain historical data of the vehicle 110, the ledger data associated with the vehicle 110 is retrieved from the distributed ledger for analysis.

[0062] Figure 2 schematically illustrates a ledger 200 of the system 100, according to an embodiment of the present invention. While some data is shown for illustrative purposes, the skilled addressee will readily appreciate that the data shown is merely a small subset of the data of a record.

[0063] The ledger 200 includes a plurality of blocks 205, each block corresponding to one or more events associated with the vehicle. The events include events associated with the creation (manufacture) of the vehicle, such as build data and identification (VIN) data, sale of the vehicle, service of the vehicle, and accident and repair data.

[0064] A date is associated with each event, and the block includes a timestamp (not shown). The date corresponds to the date on which the event occurred, and the timestamp relates to the creation of the block. Generally, the block will be created shortly after the event has occurred, but there may be delays for a variety of reasons. As an illustrative example, a vehicle may be involved in an accident, but details of the accident may be added days later by an insurance company when assessing the vehicle.

[0065] The blocks are ordered chronologically according to the timestamp. This ensures that all copies of the ledger are identical, as the order of the blocks is unambiguous, even when events are recorded well after the event has occurred.

[0066] Each block 205 is associated with a hash 210 of the data therein. The hash 210 is generated according to a known algorithm, that takes the data of the block 205 as input, and outputs a standard-length (e.g. 64-bit or 128-bit or256-bit) output. The hash 210 is deterministic,

2019101519 05 Dec 2019 which means that it may be used to later verify that the data in the block 205 hasn’t been modified.

[0067] Each block 205 also includes the hash of previous blocks, either directly or indirectly. As an illustrative example, the hash of a block may comprise a hash of the data in the block and the hash of the previous block. Alternatively, the hash of the previous block may be stored directly in the block 205. As a result, not only are each of the blocks 205 individually verifiable, but the chain of blocks is also verifiable.

[0068] As outlined above, each of the blocks may also include authentication data (e.g. certificate data) enabling authentication of the entity having created the block using the public key of the entity. As such, the user can be certain that the data has not been added maliciously by an unauthorised third party.

[0069] When the ledger is obtained by the user 105, it is verified using the hashes and the authentication data. Such process may be performed iteratively across all of the blocks 205, to both verify the data of each block, and for the ledger as a whole. Once the data is verified, it may be used to generate a vehicle history report.

[0070] Figure 3 illustrates a screenshot 300 vehicle history report of the system 100, according to an embodiment of the present invention.

[0071] The vehicle history report includes a vehicle detail element 305, includes details of vehicle from the initial block outlined above. Examples of such data include date of manufacture, make, model, registration, VIN number and the like. This enables the user to quickly see that the report relates to the correct vehicle.

[0072] An overview section 310 provides an overview of the events recorded, such as whether any structural damage, minor accident damage, theft or odometer tampering is recorded or evident from the event data. This enables the user to get a fast overview regarding important facts of the vehicle, without having to carefully analyse each of the events.

[0073] The vehicle history report includes a plurality of event elements 315, corresponding to the events of the distributed ledger. The event elements 315 enable the user to go through each of the individual events, with a view of obtaining further details of same.

[0074] Finally, each event element 315 is associated with a verification indicator 315a, which indicates that the event element 315 has not only been obtained from the distributed ledger, but also been verified.

2019101519 05 Dec 2019 [0075] As such, the user is able to have a better overview of the history of the vehicle compared to prior art systems, and therefore able to make more informed decisions about the vehicle. In the context of a purchase, the user is less likely to buy a vehicle with unknown issues (such as poorly repaired accident damage).

[0076] While the above description has focused on a single vehicle 110, a single user 105 and the like, the skilled addressee will readily appreciate that multiple ledgers will be provided for multiple vehicles 110, which a plurality of different entities may add events in relation to. The system 100 may operate across multiple states or countries, and as such, be used by multiple government agencies.

[0077] Similarly, while the above description relates to entities each adding data to the ledger, in an alternative embodiment, the central authority 125 may be used to add such information. In such case, the entities may provide event data to the distributed ledger, which is then either added to the ledger 115 by the central authority, or returned to the entity 120 in a form that is able to be added to the ledger 115 (e.g. digitally signed by the central authority 125).

[0078] For practical reasons, the central authority may establish policies defining rules regarding content of the ledger. As such, verification of the ledger may not only include verification of the hashes, timestamps and signatures, but also that the rules have been followed.

[0079] Figure 4 illustrates a method 400 for providing verifiable and secure vehicle information, according to an embodiment of the present invention. The method may be similar or identical to the method performed by the system 100.

[0080] At step 405, an initial block is generated and associated with the vehicle. The initial block may include a description of the vehicle, such as make, model, configuration, colour, manufacturer data, compliance data, and identifiers identifying the vehicle, such as a Vehicle Identification Number (VIN).

[0081] At step 410, the initial block is distributed on a distributed ledger. In particular, the initial block may be uploaded to one or more nodes of the distributed ledger, whereby the block forms a start of the ledger associated with the vehicle. This step may include verification of the initial block by the nodes, e.g. to ensure that the same VIN has not been previously used, or to perform any other suitable checks on the initial block.

[0082] At step 415, an event is added to the distributed ledger as a block, and the block linked to a previous block. By linking the block to a previous block, a chain of blocks is generated, meaning not only can each of the events be verified, but also the chain of events.

2019101519 05 Dec 2019 [0083] Step 415 may be repeated multiple times over a period of time as events occur.

[0084] At step 420, the blocks are retrieved from the distributed ledger, e.g. by a user wishing to obtain information about the vehicle. The blocks may be retrieved by making a request, or multiple requests, to the distributed ledger.

[0085] At step 425, the blocks are verified both individually and as a whole (i.e. the chain of blocks). This step can include verifying that the blocks have not been modified, and that the blocks have been generated by the entity that is claims to have added them.

[0086] At step 430, a vehicle history report is generated according to the blocks. The vehicle history report is advantageously generated to not only include all events of the blocks, but also a summary or overview of the events, to enable a user to quickly evaluate the history of the vehicle.

[0087] Figure 5 illustrates a method 500 of creating a distributed ledger for a new vehicle, according to an embodiment of the present invention. The method 500 may be performed as step 405 of the method 400 and at the time of manufacture (for a new vehicle), or at a later time for an existing vehicle.

[0088] At step 505, a request to add a new vehicle is made. This request may be made to a central authority, such as the central authority 125. Approval of the request may be provided in the form of a digital signature of the central authority or by any other suitable means. The approval process may include comparing the VIN of the vehicle to other vehicles already recorded, to prevent multiple or unauthorized entries.

[0089] At step 510, an initial block is generated for the vehicle. The initial block will generally include a description of the vehicle, such as make, model, configuration, colour, manufacturing data, compliance data, and identifiers identifying the vehicle, such as a Vehicle Identification Number (VIN).

[0090] At step 515, a hash of the block is generated. The hash may be generated according to a known algorithm, such that the hash may be re-generated at a later time to verify that the data has not been changed.

[0091] At step 520, the block is digitally signed using the private key of the entity creating the block. This step may include adding a digital signature to the block, the digital signature generated according to the data of the block so that the signature, much like the hash, is valid only for that data.

2019101519 05 Dec 2019 [0092] At step 525, the block is distributed on a distributed ledger, and thus becomes the ledger associated with the vehicle. The block may be uploaded to one or more nodes of the ledger which verify the block.

[0093] Figure 6 illustrates a method 600 of adding a new event to an existing vehicle ledger, according to an embodiment of the present invention. The new event would generally be added by a different entity than the entity that has created the vehicle, and the method 600 may be similar or identical to a method performed by the system 100.

[0094] At step 605, a ledger associated with the vehicle is retrieved. The ledger may be retrieved according to the VIN of the vehicle, or any other suitable identifier of the vehicle.

[0095] At step 610, a block is generated according to the event. The block includes a timestamp, which is used to order blocks chronologically.

[0096] At step 615, the block is linked to the ledger. This may comprise incorporating a hash of a previous block of the ledger into the block to thereby add the block to a chain of blocks of the ledger.

[0097] At step 620, a hash is generated for the block. As outlined above, the hash is deterministic and can be used to ensure that the data of the block has not been changed.

[0098] At step 625, the block is digitally signed using the private key of the entity adding the event. This enables others, at a later time, to authenticate that the event was added by the entity.

[0099] At step 630 the block is distributed on the distributed ledger, e.g. by uploading the ledger including the new block to one or more nodes of the distributed ledger.

[00100] These nodes then verify the status of the ledger, such as by checking the hashes and signatures, confirming that the hashes and outputs match exactly, and the timestamps. If the hash generated doesn't match the recorded hash, the node is able to reject the new block, as the mismatch may be due to an error or fraud. If the timestamp indicates that an older version of the ledger has been used (i.e. there is a collision with data entry), the block is also rejected, to avoid multiple conflicting ledgers.

[00101] At step 635, confirmation that the block has been added to the ledger is received. Such step may comprise receiving consensus from multiple nodes of the distributed ledger.

[00102] In case consensus is not reached, and thus the block cannot be added to the ledger,

2019101519 05 Dec 2019 the method may restart at step 605.

[00103] The method 600 is repeated each time an event occurs in relation to the vehicle.

[00104] Figure 7 illustrates a method 700 of generating a report relating to a vehicle, according to an embodiment of the present invention. The method 700 may be similar or identical to a method performed by the system 100.

[00105] At step 705, a ledger associated with the vehicle is retrieved. The ledger may be retrieved according to the VIN of the vehicle, or any other suitable identifier of the vehicle. A search tool may be provided to enable the user to search for the ledger associated with the vehicle using any suitable identifier(s).

[00106] At step 710, the chain of blocks is verified using the hash of each block, and the link of hashes between blocks. In particular, a hash is generated for each block in the same manner as originally used to generate the hash, and the generated hash is compared to the recorded hash.

[00107] At step 715, each event is retrieved from the ledger. Each block may include one or more events, and the events are retrieved by decoding the blocks.

[00108] At step 720, each event is authenticated using the public key of the entity that has added the event. In particular, a digital signature of the block is used together with a public key of the block to authenticate the block.

[00109] At step 725, a report is generated according to each of the events. The report may be generated by analysing event information to identify any information of particular importance, such as accident damage, or the like. Similarly, the report may include a comparison of odometer readings to determine whether there are any inconsistencies, or potential inconsistencies in same.

[00110] Finally, the report may include full details of each of the events, to enable the user to drill down on specific events to obtain further information.

[00111] Advantageously, the methods described above enable a user to quickly and easily obtain accurate, verifiable information about a vehicle.

[00112] EXAMPLE 1

EVENT 1: Car Manufactured

Entered by: Car Manufacturer

2019101519 05 Dec 2019

Blockchain action: Car created in Blockchain (VIN number, date, country, etc...)

EVENT 2: Car Sold to Individual

Entered by: Car Dealership

Blockchain action: Blockchain updated with new owner (location, etc..)

EVENT 3: Car Brought back for initial complementary Service

Entered by: Car Dealership

Blockchain action: Blockchain updated with work completed (odometer reading, date, etc...)

EVENT 4: Car Brought back for Recall I call-back (Takata Airbag)

Entered by: Car Dealership

Blockchain action: Blockchain updated with work completed (including model of part replaced)

EVENTS: Car Sold

Entered by: 2nd Hand Dealer

Blockchain action: Blockchain updated to register sale, removal of old owner as owner, and addition of new owner as owner (together with owner details) [00113] In Example 1, the new owner is able to easily verify that the airbag has been replaced, and see a full service history of the vehicle.

[00114] EXAMPLE 2

EVENT 1: Car Manufactured - Japan

Entered by: Car Manufacturer

Blockchain action: Car created in Blockchain (VIN number, date, country, etc...)

EVENT 2: Car Sold to Individual

Entered by: Car Dealership

Blockchain event: Update Blockchain with new owner (location, etc..)

EVENT 3: Private Sale overseas

Entered by: Special exporter (in Australia called Grey Imports, for low mileage Japanese cars)

Blockchain event: Blockchain updated with Sale / Transfer details

EVENT 4: Bought in Australia

Entered by: Special Grey Import dealer / private sale

Blockchain event: Register new owner / new country (new compliance plate, etc...)

EVENT 5: On-sold (in Australia)

Entered by: Seller

Blockchain action: Blockchain updated to register sale, removal of old owner as owner, addition of new owner as owner (together with owner details) [00115] In Example 2, the new owner is able to easily see a history of the vehicle, despite being initially sold overseas.

2019101519 05 Dec 2019 [00116] EXAMPLES

EVENT 1: Car Manufactured - Italy

Entered by: Car Manufacturer

Blockchain action: Car created in Blockchain (VIN number, date, country, etc...)

EVENT 2: Car Sold to Individual

Entered by: Car Dealership

Blockchain action: Update Blockchain with new owner (location, etc..)

EVENT 3: Car Stolen and attempted private sale in USA (NOT ENTERED ON BLOCKCHAIN) [00117] In Example 3, potential purchasers are able to see the history of the vehicle, determine that the vehicle is not being sold by its registered owner, and thus avoid the purchase.

[00118] EXAMPLE 4

EVENT 1: Truck Manufactured - Scandinavia

Entered by: Truck Manufacturer

Blockchain action: Truck created in Blockchain (VIN number, date, country, etc...)

EVENT 2: Truck sold to trucking company

Entered by: Truck Dealership

Blockchain action: Update Blockchain with new owner (location, etc..)

EVENT 2: Compliance Requirements Change for Trucks

Entered by: Government I Registering Body

Blockchain action: Requirement Added to Blockchain for Truck

EVENT 3: Compliance Requirement Addressed through registered repairer

Entered by: Trucking Company

Blockchain action: Blockchain updated to register the details of compliance I action taken [00119] In example 4, the trucking company, or any other user, is able to obtain full details of the compliance requirements for the vehicle, and confirm that they have been addressed.

[00120] EXAMPLES

EVENT 1: An existing motorbike (built before this system existed) is entered with an insurance policy renewal

Entered by: Insurer

Blockchain action: Motorbike created in Blockchain (Unique Identifiers, date, country, etc...) EVENT 2: Bike Serviced

Entered by: Registered Mechanic

Blockchain action: Update Blockchain with details (including KMs travelled)

2019101519 05 Dec 2019

EVENT 3: Bike odometer wound back by owner (NOT ENTERED ON BLOCKCHAIN)

EVENT 4: Owner attempts to sell motorbike (with lowered KMs) (NOT ENTERED ON BLOCKCHAIN) [00121] In Example 5, potential purchasers are able to see the (partial) history of the motorbike, and determine that the odometer has been tampered with, and thus avoid the purchase.

[00122] EXAMPLE 6

EVENT 1: Boat Manufactured in the USA

Entered by: Boat Manufacturer

Blockchain action: Create Boat in Blockchain (Unique Identifiers, date, country, etc...)

EVENT 2: Boat sold to private buyer

Entered by: Boat Dealer

Blockchain action: Update Blockchain with new owner (location, etc..)

EVENT 3: Shipping Company takes possession (fortransport)

Entered by: Logistics Company

Blockchain action: Updated Blockchain with temporary owner / shipper

EVENT 4: Boat never arrives to Owner (supposedly lost at sea, but fraudulent act) - Boat registered as unrecovered write-off

Entered by: Insurer

Blockchain action: Update Blockchain with unrecovered write-off status [00123] In example 6, the insurance company may interrogate the blockchain to understand a history of the boat, who had last possession and timeframes as part of their investigation.

[00124] If the boat is later attempted to be sold, any potential purchaser is able to see the history, and thus avoid the purchase.

[00125] The above description makes reference to the use of electronic ledgers, and blockchain is an example of such electronic ledger which can be used to create and maintain a secure chain-of-custody log associated with the vehicle.

[00126] While the above embodiments do not illustrate computing devices, the skilled addressee will readily appreciate that the all interaction with the system occurs using computing devices, such as personal computers, servers, smartphones, and the like. As an illustrative example, a user may retrieve, verify and view history data relating to a vehicle on a mobile computing device when inspecting the vehicle. The computing devices, servers, and the like,

2019101519 05 Dec 2019 need not be singular in nature, but instead may comprise a network of computing devices, and may be cloud based, where actual computer resources are allocated dynamically.

[00127] While not illustrated, miners may be used in the distributed ledger to verify transactions. The miners may be provided with transaction fees for verifying blocks, and thus ensuring that the ledger is up to date and verified. The miners may function in a similar manner to Bitcoin miners, but only with transaction fees, rather than being able to generate coins.

[00128] Advantageously, the systems and methods described above enables users, such as potential purchasers, owners or insurance companies, to obtain verifiable and secure information about a vehicle, which enables them to make better decisions about the vehicle. This can in turn prevent fraud relating to vehicles, and reduce the likelihood that a vehicle has unknown issues.

[00129] In the present specification and claims (if any), the word ‘comprising’ and its derivatives including ‘comprises’ and ‘comprise’ include each of the stated integers but does not exclude the inclusion of one or more further integers.

[00130] Reference throughout this specification to One embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[00131] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims (if any) appropriately interpreted by those skilled in the art.

Claims (5)

1. A system for providing verifiable and secure information relating to vehicles, the system including: an electronic ledger, the electronic ledger including a plurality of events from a plurality of different entities and relating to a vehicle, the events stored in a plurality of blocks forming the electronic ledger, wherein each block of the ledger is linked to an earlier block of the ledger to thereby provide an ordered and verifiable list of the plurality of events.

2. The system of claim 1, wherein the events include sale events, relating to the sale of the vehicle and service events, relating to the servicing of the vehicle.

3. The system of any one of the preceding claims, further including a hash of each block, to enable later modification of the block to be identified, wherein each block is linked to an earlier block using the hashes, and to thereby form a verifiable chain of blocks and thus events and wherein the validity of each block is dependent on the validity of one or more previous blocks.

4. The system of any one of the preceding claims, wherein each block includes a timestamp, wherein a chronology of the system is defined according to the timestamp.

5. The system of any one of the preceding claims, wherein the events comprise events of a plurality of different registered entities, and wherein the registered entities are each associated with a key to provide a digital signature, wherein the key is used to authenticate data of the block, the system including a central authority responsible for registering entities, and wherein the central authority issues the keys to the entities.