Blog Details

Invented by William J. Leise, Douglas A. Graff, Anthony McCoy, Jaime Skaggs, Shawn M. Call, Stacie A. McCullough, Wendy H. Clayton, Melinda Teresa Magerkurth, Kim E. Flesher, Travis Charles Runge, State Farm Mutual Automobile Insurance Co

The State Farm Mutual Automobile Insurance Co invention works as follows

The disclosure relates to a system and method for using a blockchain to manage the subrogation claims process in relation to a vehicle accident, with evidence oracles being used as part of that process. One embodiment involves receiving data recorded from one or multiple connected devices located at a geographical location, analyzing that data to determine if a collision has taken place involving at least one vehicle; creating a transaction based on the analysis and sending it to at lease one other participant of the distributed ledger.

Background for Evidence oracles

The insurance claim process can involve an enormous number of interactions and communications between the parties involved. Potential parties to the claim process may be insurance companies, repair shops, lawyers, arbitrators, government agencies, hospitals, drivers, and collection/collections agency. Subrogation may be pursued by parties when the cost of repairs is disputed. When an insured person experiences a covered loss an insurer can pay the costs and seek subrogation against another party. In the event that an insured vehicle is in a collision, and the loss occurs, the insurer can compensate the vehicle owner under the terms of the insurance contract. The insurer can pursue damages against another party if, for instance, the vehicle owner wasn’t at fault. In an insurance contract, an insured may be required to transfer their claim against the party responsible to the insurer. The insurer can then collect the claim for the insured.

Subrogation payments can be complicated and lengthy to settle. The different parties (e.g. parties at fault in an accident, owners of vehicles, insurers etc.) To determine who was at fault, it may be necessary to exchange information about the collision. Information about parties involved in the loss may be used to determine fault and/or payment of subrogation. Other sources include vehicle data, forensic data, or information on the parties. Information from various sources may be shared and verified by the parties, such as information held by insurers and parties involved in losses, or information obtained from third-parties (e.g. independent contractors, government entities, etc .).

The parties (insurers, for example) to a subrogation can make proposals to each other to settle the claim. The proposal can include an accounting for damages, like the cost to a vehicle owner who had their vehicle damaged. In the event that an insured person was injured in a collision and had to seek medical attention, their health care costs could be included in an accounting of damages. Subrogation claims can be assessed by independent third parties, for example an automotive repair service provider authorized to provide estimates of repair costs. The parties can agree on a settlement amount and damages calculation to settle a subrogation claim. The parties may hire a third party to help with subrogation negotiation and resolution.

Systems and Methods are disclosed for using a distributed ledger or blockchain to manage a claim process in insurance, specifically a subrogation process. The systems and methods reveal using evidence oracles to input information into the Blockchain, machine learning to suggest amount for the subrogation, a dispute mechanism for line items, and/or creating/managing distributed ledger as a response to an accident. The systems and methods may use smart contracts and secure transactions stored on the Blockchain.

The present embodiments also relate to insurance and the handling of insurance claims.” Sensor, image or other data can be collected by various sources such as mobile phones, vehicles (such a smart or autonomous vehicle), smart infrastructures, satellites or drones and/or interconnected or smart homes. The data collected can be analyzed using artificial intelligence and machine learning algorithms in order to determine whether a collision took place, determine a percentage fault (for drivers or autonomous cars), determine the veracity or potential fraud of an insurance claim, identify potential fraud, or identify buildup.

The method may include, via one or more local or remote processors, servers and sensors as well as associated transceivers: (1) receiving recorded data from one of more connected devices at a geographic location; (2) analyzing the recorded data by the one or multiple processors. This analysis can include determining that a collision has occurred involving a vehicle. The method can include one or multiple local or remote processors or servers, sensors and/or transceivers. It may also include: (1) receiving recorded data at one of more processors from one connected device at a geographical location; (2) analysing the recorded information at one processor or processors; analyzing the recorded information may include determining a collision has taken place involving one vehicle; (3) generating a transaction at one processor or processors based on the analysis; (4) transmitting the transaction at one processor or processor to at The method can include other, less or alternative actions, such as those described elsewhere.

The method may include, via one or more local or remote processors, servers and sensors as well as associated transceivers: (1) receiving a request for recorded data from at least one other participant in the distributed ledger network; (2) verifying an access level of the at least one other participant by using these same processors; (3) analyzing this request by using those same processors. This analysis can include determining data relevant to the request. The method can include one or multiple local or remote processors or servers, sensors and/or transceivers. It may include: (1) receiving a request for data recorded from another participant of the distributed ledger; (2) verifying an access level, by the one/more processors; (3) analyzing the request, which may include determining the data relevant for the request. The method can include additional, fewer, or alternative actions, such as those described elsewhere in this document.

In a third aspect, an insurance claim processing system using a shared ledger is provided. The system can include one or multiple processors, servers and sensors. The system can include more, less or alternative components and actions. These are discussed elsewhere in this document.

The methods can be implemented by computer systems and include more, less or alternative actions or functionality. In some aspects, systems or computer-readable mediums storing instructions to implement all or part the method described above can also be provided. One or more of: a special purpose computing device; a personal electronics device; a mobile device or wearable device; a processing module of a vehicle or a remote server. Also included are one or several sensors, one- or two-way communication modules that communicate wirelessly over radio frequency links or wireless channels and/or one of more program memory coupled to the processor of the personal electronics device or processing unit of the remote server. These program memories can store instructions that cause one or more processors of the personal electronic device, processing unit of a vehicle, or remote server to implement all or part the method described above. Some aspects may include additional or alternative features.

This summary is intended to provide a simplified version of a number of concepts that are described further in the Detailed Descriptions. This summary does not aim to identify the key features or essential elements of the claimed object matter. Nor is it meant to be used as a tool to limit the scope.

The following description and illustration of the preferred aspects will make the advantages more obvious to those with ordinary knowledge of the art. The present aspects can be modified in many ways. The drawings and descriptions are intended to be used as illustrations and not as a guide.

Traditionally, businesses and customers as well as central authorities involved in insurance claims have stored records and information about transactions in databases and ledgers. These databases and ledgers are often held by participants, and they must be reconciled in order to reach consensus on the validity of information contained therein. A central authority can be in charge of determining the validity and establishing consensus among interested parties. This could include a deed recorder, asset exchange or other central authority.

A blockchain” (also known as a distributed or shared ledger in this context) is a method of reaching a consensus among participants and observers on the validity of the information contained within the chain. The blockchain, in other words provides decentralized trust for participants and observers. A blockchain, which is decentralized and does not rely on a central authority to maintain the ledger’s transactional records is a database where each peer is responsible for validating these changes. The distributed ledger consists of groups of transactions that are organized into a “block.” The blocks are ordered in a sequential order (hence the name ‘blockchain’). Nodes can join and leave the network at any time, and they may receive blocks propagated by peer nodes while the node is gone. Nodes can exchange addresses with other nodes to help propagate new information in a peer-to-peer, decentralized manner.

The nodes who share the ledger are referred to as the distributed ledger. The distributed ledger nodes validate changes made to the blockchain according to consensus rules (e.g. when a transaction or block is created). Consensus rules are based on the information that is tracked by the blockchain, and can include rules about the chain. A consensus rule could, for example, require that the person who initiates a change provide a proof of identity so that only authorized entities can make changes to the blockchain. A consensus rule can require blocks and transactions to adhere to certain format requirements and provide meta information about the change (e.g. blocks must not exceed a specific size, transactions must have a specified number of fields). Consensus rules can include a mechanism that determines the order of adding new blocks to the chain.

Additions that comply with the consensus rules to the blockchain are propagated by nodes who have validated that addition to other nodes the validating node knows about. The distributed ledger will reflect the change if all the nodes receiving the change validate it. Validating nodes will ignore any change that doesn’t satisfy the consensus rule and it won’t be propagated to the other nodes. Contrary to a traditional system that relies on a central authority for its administration, a single entity cannot unilaterally change the distributed ledger, unless it can do so by following the consensus rules. Blockchains are described as immutable, trusted and secure because they cannot be altered. A decentralized blockchain can disintermediate third party intermediaries that assist in the resolution subrogation claims.

The validation activities performed by nodes that apply consensus rules to a blockchain can take many forms. In one implementation, a blockchain can be seen as a shared sheet that tracks information such as asset ownership. In a second implementation, validating nodes run code from’smart contracts’. Distributed consensus is the result of network nodes agreeing to the outputs of the code executed.

A smart contract” is a protocol for computers that allows the automatic execution or enforcement of an agreement by different parties. The smart contract can be a computer code located at a specific address on the Blockchain. In some cases, the smart contracts may be run automatically when a participant on the blockchain sends funds (e.g. a cryptocurrency like bitcoin, ether or another digital/virtual money) to the address at which the smart contract is located. Smart contracts can also keep track of the funds stored at their addresses. When this balance is zero, the smart contract will no longer function.

The smart contract can include one or multiple trigger conditions that, if satisfied, will correspond to one of more actions. In some smart contracts, the decision condition(s) may determine which action is performed from one or more actions. Data streams can be sent to the smart contracts in some cases so that they can detect if a trigger condition or a decision condition has been met.

Blockchains can be deployed in a decentralized and permissionless way, meaning that anyone may view the ledger or submit new data to be added. They may also join the network to act as a validating member. Some blockchains (e.g. permissioned ledgers), keep chain data confidential amongst a small group of authorized participants in the blockchain network. Some blockchain implementations are permissioned or permissionless, where participants need to be verified but only information they want to make public is made available.

The present embodiments relate, inter alia to systems and methods of using a Blockchain to record and manage data related to the resolution of a claim for subrogation (e.g. a “subrogation” blockchain). blockchain). The subrogation ledger may be public or permissioned. Certain embodiments described herein are related to the use “evidence oracles.” As part of a blockchain for subrogation. These evidence oracles can interact with the Blockchain and send information such as evidence related a subrogation claims to the blockchain.

Exemple Shared Ledger” for Subrogation Claims

Click here to view the patent on Google Patents.