Invention for Blockchain Vehicle Incident Documentation
Invented by Pasquale A. Catalano, Andrew G. Crimmins, Byron S. Green, Arkadiy O. Tsfasman, John S. Werner, International Business Machines Corp
Traditionally, documenting vehicle incidents has been a time-consuming and cumbersome process. Insurance companies, law enforcement agencies, and other stakeholders often rely on paper-based documentation, which can be easily lost or tampered with. This can lead to disputes and delays in settling claims, as well as increased administrative costs.
Blockchain technology provides a solution to these challenges by offering a transparent and tamper-proof system for recording and verifying vehicle incident data. When an incident occurs, relevant information such as the date, time, location, and details of the incident can be recorded on the blockchain. This information is then securely stored and cannot be altered or deleted without the consensus of the network participants.
One of the key advantages of using blockchain for vehicle incident documentation is the ability to establish trust and transparency among all stakeholders. Insurance companies can rely on the verified information recorded on the blockchain to assess claims accurately and efficiently. Law enforcement agencies can access the blockchain to gather evidence and investigate incidents more effectively. Vehicle owners can have peace of mind knowing that their incident documentation is secure and cannot be tampered with.
Moreover, blockchain technology can also enable the automation of certain processes, further enhancing efficiency and reducing costs. Smart contracts, which are self-executing contracts with the terms of the agreement directly written into code, can be utilized to automate claim settlements. For example, if an incident meets certain predefined criteria, the smart contract can automatically trigger the payment of the claim to the affected party, eliminating the need for manual intervention and reducing the time it takes to settle claims.
The market for blockchain vehicle incident documentation is not limited to insurance companies and law enforcement agencies. Other industries, such as fleet management and ride-sharing services, can also benefit from this technology. Fleet managers can use blockchain to track and verify vehicle incidents within their fleet, ensuring compliance with safety regulations and reducing liability. Ride-sharing services can leverage blockchain to enhance trust and transparency between drivers and passengers, as well as streamline the process of resolving disputes.
In conclusion, the market for blockchain vehicle incident documentation is poised for significant growth as more industries recognize the advantages of this technology. By leveraging blockchain’s transparency, immutability, and automation capabilities, stakeholders can streamline the process of documenting and verifying vehicle incidents, leading to faster claim settlements, reduced administrative costs, and increased trust among all parties involved. As blockchain continues to evolve and mature, we can expect to see even more innovative applications in the field of vehicle incident documentation.
The International Business Machines Corp invention works as follows
An example of an operation could include receiving primary data from a vehicle, extracting the first information from it, creating a document based on that information, generating a blockchain transaction based on this document, or committing one or two documents to the blockchain.
Background for Blockchain Vehicle Incident Documentation
A ledger is a book of entries in which transactions are recorded. Distributed ledgers are ledgers that have been replicated on multiple computers in their entirety or part. A Cryptographic Distributed Ledger can possess at least some of the following properties: irreversibility, accessibility, chronological and time stamping (all parties are aware when a particular transaction was recorded), consensus-based (a transaction can only be added if it has been approved by all parties, usually unanimously), and verifiability. A CDL is a blockchain. The description and figures are in terms of a Blockchain, but the application can be applied to any CDL.
A distributed ledger” is a list of records which are constantly growing. It uses cryptographic techniques, such as the storage of cryptographic hashes for other blocks. A distributed ledger is a common example and can be used to store information as a public ledger. A blockchain is primarily used to store financial transactions but can also be used to store information about goods and services, such as products, packages, or status. A decentralized scheme gives authority and trust to decentralized networks and allows its nodes record continuously and sequentially their transactions in a public “block”, creating a unique “chain”. This is referred to as blockchain. Hash codes are used for cryptography to authenticate a transaction and eliminate a central mediator. A blockchain is a distributed data base that keeps a list of records continuously growing in blocks. These blocks are protected from revision and tampering due to their immutable nature. Each block has a timestamp as well as a link back to the previous block. A blockchain is a way to store, track, transmit and verify data. Before adding a transaction, all peers must reach consensus.
Traditionally, incidents involving vehicles are investigated and analyzed based on facts to determine the incident cause and driver(s) fault. To overcome these limitations, a system and process based on blockchain is required.
One example embodiment provides a system including one or multiple vehicles, each with one or several sensors, as well as a plurality nodes configured to receive the primary data from one or many sensors. The plurality includes one of more servers configured to extract information from primary data, to create one document based upon the extracted information, to generate one or multiple blockchain transactions using the one-or-more documents, or to commit the one-or more documents to the blockchain.
An example of an operation could include receiving primary data from a vehicle, extracting the first information from it, creating a document based on that information, generating a blockchain transaction based on this document, or committing one or two documents to the blockchain.
The example embodiments may include a non-transitory, computer-readable medium that contains instructions which, when read by a processing unit, cause it to perform any of the following: receiving primary data from a vehicle, extracting information from the data, creating documents using the extracted information and generating blockchain transactions from the documents.
It will be understood that the components of the present invention, as described and illustrated herein in general, can be designed and arranged in many different ways. The following detailed description is not meant to limit the scope or application of the claimed invention, but rather is intended as a representative of certain embodiments.
The instant features or structures described in this specification can be combined in any way suitable in one or more embodiments. The use of phrases such as “example embodiments”, “some embodiments”, or similar language throughout this specification indicates that a feature, structure or characteristic described with respect to an embodiment can be included in other embodiments. The phrases “example embodiments”, “in some embodiments”, “in other embodiments” or similar language used throughout this specification does not always refer to the same group. Features, structures or characteristics described in connection with the embodiment may also be included in other embodiments.
In addition, the term’message’ may be used in the description of embodiments. While the term?message? may have been used to describe embodiments, the application can be applied to any type of network data such as packet, frame, or datagram. The term “message” can also be used. The term “message” can also refer to packet, frame, or datagram. While certain types of signals and messages may be shown in certain embodiments, they are not limited by a particular type of message and the application does not limit itself to that type of signaling.
A blockchain is distributed system that includes multiple nodes which communicate with one another. A blockchain operates programs called chaincode (e.g., smart contracts, etc. The blockchain holds ledger and state data and executes transactions. Some transactions are chaincode operations. Blockchain transactions must typically be “endorsed” by certain blockchain members. Only endorsed transactions can be added to the blockchain. Other transactions that are not endorsed will be ignored. “There may be one or more chaincodes that are specific to management functions and parameters. These are collectively known as system chaincodes.
Nodes are the communication units of the Blockchain system. A “node” is a computer. Nodes can perform a logical task in that they may run multiple nodes with different types on the same server. Nodes are organized into trust domains, and they are controlled by logical entities. Nodes may include different types, such as a client or submitting-client node which submits a transaction-invocation to an endorser (e.g., peer), and broadcasts transaction-proposals to an ordering service (e.g., ordering node). A peer node can also receive transactions from clients, commit them and maintain the state of the blockchain ledger and a copy. It is possible for peers to also play the role of endorsers, but it is not required. An ordering-service-node or orderer is a node running the communication service for all nodes, and which implements a delivery guarantee, such as a broadcast to each of the peer nodes in the system when committing transactions and modifying a world state of the blockchain, which is another name for the initial blockchain transaction which normally includes control and setup information.
A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.
A chain” is a log of transactions that is organized as blocks with hash links. Each block contains N transactions, where N is greater or equal to one. The block header contains a hash for the block’s transactions as well as the header of the previous block. All transactions in the ledger can be cryptographically linked and sequenced this way. It is therefore impossible to alter the ledger without destroying the hash links. A hash of the most recent blockchain block represents all transactions on the chain before it. This allows peer nodes to be in a trusted and consistent state. The chain can be stored in a peer-node file system, such as local storage, cloud storage, or attached storage. This allows the blockchain workload to be efficiently supported by appending only.
The current state is the most recent values of all keys in the chain transaction log. The current state is often referred to by the term “world state” because it represents the most recent key values that a channel has access to. Invocations of chaincodes perform transactions on the ledger’s current state. In order to make chaincode interactions more efficient, it is possible to store the most recent values of keys in a database. State databases can be an index view of the chain’s transactions. They can be generated from the chain whenever needed. “The state database can be automatically recovered (or created if necessary) at peer node startup and before transactions are accepted.
The instant application, in one embodiment, relates to blockchain network and further in another embodiment to vehicle incident documentation on a blockchain. Examples of embodiments include methods, devices and/or networks that support the creation and storage of documents on permissioned Blockchain networks. The choice of the blockchain implementation to be used will be discussed before the solution is described. There are many blockchain implementations for generic document transaction (e.g. Ethereum), but the current application prefers to use a permissioned network where the nodes of the blockchain are operated by whitelisted entities. An issuing authority grants the identities of these entities, which are often defined by public-private key pairs. Hyperledger Fabric is an opensource blockchain network that has permissions. Fabric’s modular architecture allows administrators to set up protocols according to their requirements. Fabric provides a number of special features. Some are listed here.
Chaincode is a new concept that extends traditional smart contracts. Apart from providing a mechanism to define assets and instructions (business logic) to modify the assets, chaincode is also immutable, may retain state, and inherits confidentiality/privacy. The network can restrict who can interact or view the environment at different levels (variable confidential). Even individual transactions can impose confidentiality rules. Although the network may obfuscate identity, it’s possible to have peers who are 100% anonymous but whose identities can be verified and unique using secure cryptographic techniques. An auditor can de-anonymize a user and their transactions if the users of the network give permission. This can be useful for regulatory analysis and inspection. Details of a transaction are encrypted, including but without limitation, chaincode, peers and assets. It eliminates the possibility of a pattern being recognized or private information being leaked to unauthorised actors in the network. Chaincode allows only specified actors to decrypt, interact/execute and view (with chaincode). Fabric can be used with virtually any consensus mechanism.
FIG. According to an example embodiment, FIG. 1 shows a logic diagram of a permissioned Blockchain system 100. Referring to FIG. The system 100 is comprised of one or more vehicles, as shown in FIG. Vehicles 116 can be any motor vehicle including cars, trucks and buses. Sensors 120 are included in each vehicle 116, ranging from sensors 120A for vehicle A 116A to sensors 120I for vehicle I 116I. Each vehicle 116 has an associated owner or driver.
Sensors 120 can be of different types or arrangements. Sensors 120 include cameras, microphones and light sensors. They also include pressure sensors and speed sensors. Many cars and trucks today include multiple cameras such as a side camera, a back camera and a front one. In some embodiments sensors 120 are part an intelligent vehicle monitoring systems, such as ONSTAR.
Vehicles from 116A to 116I are involved in at least one accident or incident. A breakdown of a vehicle can be an incident, but not necessarily an accident. A single-vehicle accident can occur when a vehicle 116 hits a non-vehicular item such as a pole, building or pedestrian. A collision between two or three vehicles can cause an accident. A single accident may happen or several accidents. Vehicles 116 provide primary data 124 autonomously to one or multiple nodes 104 in response to accidents. Primary data from vehicles A 116A and I 116I are denoted as primary data 124A, respectively. Primary data 124 are always directly related to vehicles 116. Other secondary data 132, not directly related to the vehicles 116 involved in an accident but from other sources 128, may be provided after an accident. Sources 128 can be cameras or other devices associated with drivers who are not involved in the accident, bystanders or first responders or red light cameras or traffic cameras. Sources 128 can also be a mobile computing device or another communication device (cellphone, smart phone PDA, smartwatch, etc.) that is used by a driver or passenger to record video or photos of an accident. This could include damage to a car or injuries of any person. Secondary data 132 can be audio, video or pictures. FIG. FIG. Snapshots) are secondary data 132N. “Any number of vehicles (including none) 116 may provide primary data, and any other sources 128 (including none) may provide secondary data.
FIG. Node 104C is shown in Figure 1 receiving all the primary 124 data and secondary 132. This is just one example of how primary 124 and second 132 data can be transferred from vehicles and other sources to a blockchain. In other embodiments multiple nodes receive primary 124 data and secondary 132 and act accordingly. In one embodiment, the node 104C acts as a server and receives both primary 124 data and secondary 132. Server 104C is responsible for the primary functions of the application. These are described here in greater detail. Each node 104 has a shared database 108. These are indicated as shared ledgers 108A and 108B for node A104A, shared leadgers 108C and 108N for node C104C, or shared ledgers 108C and 108N respectively. The shared ledgers 108 contain the documents for the current application. Nodes 104 that have been granted access to them by the blockchain network 112.
In one embodiment, receiving nodes 104 are a part of a blockchain network 112, including nodes A 104A and B 104B. Nodes C 104C and N 104N also form a part of the existing blockchain. In another embodiment, receiving node(s), 104 creates a new network 112 as a result of receiving primary data 124. In this instance, a node 104C that receives data may create a new blockchain network 112 after inviting nodes A 104A and B 104B to join. Each node 104 is responsible for creating and processing documents relating to incidents or accidents involving vehicles 116. Nodes 104 can be owned by insurance companies that cover each vehicle 116, law firms, police, fire departments, emergency medical services (EMS), city services, lawyers, towing companies or body shops, repair facilities or parts suppliers or other entities involved in the resolution of accidents or incidents involving vehicles 116. In some embodiments, the node 104C described herein may not be the actual server (i.e. The server is another node 104, and it has at least the role of receiving all primary 124 data and sending them to the server. The present application can provide a blockchain network 112 that is simpler for incidents which are not accidents. For example, a breakdown of one vehicle. Police, fire, EMS and city services, for example, may not be needed. Even though a blockchain network 112 is simpler, the benefits of blockchain are still there. These include immutability and a distributed ledger.
Click here to view the patent on Google Patents.
