SYSTEMS AND METHODS FOR GENERATING GRAPHICAL USER INTERFACES RELATING TO DETERMINED PARAMETRIC EVENTS

Abstract

Systems and methods are disclosed for generating one or more smart contracts for deployment onto a blockchain. The systems and methods may include (1) receiving vehicle sensor data generated from sensors mounted on or within (a) one or more vehicles, or (b) electronic devices; (2) analyzing the vehicle sensor data to determine one or more parametric events, wherein each of the parametric events is associated with a corresponding severity of loss; (3) generating, for each of the one or more parametric events, a corresponding smart contract that is configured to (i) receive a transaction from a computing device, and (ii) automatically execute on the blockchain when the transaction indicates that a parametric event corresponding to the smart contract has occurred; and (4) deploying the smart contract at a particular address on the blockchain.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a claims the benefit of U.S. Patent Application No. 63/332,764, entitled “Systems and Methods for Generating a Smart Contract for a Parametric Event”, filed Apr. 20, 2022, U.S. Patent Application No. 63/336,400, entitled “Systems and Methods for Generating a Smart Contract for a Parametric Event”, filed Apr. 29, 2022, U.S. Patent Application No. 63/423,341, entitled “Systems and Methods for Generating a Smart Contract for a Parametric Event”, filed Nov. 7, 2022, the entire contents of which are hereby expressly incorporated herein by reference.

TECHNICAL FIELD

The present disclosure generally relates to generating smart contracts for a distributed ledger that governs vehicle transactions or events, and more particularly, generating smart contracts based upon analysis of vehicle sensor data that indicates various parametric events associated with vehicle loss.

BACKGROUND

Conventionally, when an operator of a vehicle suffers vehicle loss (e.g., theft of items inside the vehicle, a vehicle collision, a major collision resulting in a vehicle beyond repair, etc.), the operator manually contacts (e.g., via a phone call) an insurer entity of the vehicle to first report the loss, which may be referred to as First Notice of Loss (FNOL). The operator (and/or passengers, witnesses to the loss, etc.) may provide the insurer entity with details of the vehicle loss, such as the time and location of the vehicle loss, parties involved, etc., for the insurer entity to act (e.g., initiate a claims process).

Generally speaking, the insurer entity may rely on reporting from the operator to initiate the FNOL process, and thus may be considered to employ a reactive approach for assisting the operator. The operator may also contact other entities, such as emergency response entities, tow servicing entities, taxi or ride-share service entities, vehicle repair service entities, vehicle salvage entities, rental car entities, etc. depending on the severity of the vehicle loss. Various entities may also contact each other. For example, an insurer may rely on a vehicle repair entity to assess repair costs for damage incurred in a collision, and these entities may need to agree on damages calculations and a payment amount to settle an insurance claim.

In some situations, loss information reported by the operator to a particular entity may not be accurate, such as when the operator's cognition is impaired during an accident, when the operator is suffering from emotion distress caused by an accident, when the operator forgets details by waiting too long to report the accident, or when the operator does not properly document the accident (e.g., with pictures) to name a few scenarios, and thus such loss information may be considered highly subjective, and in some cases, entirely inaccurate. Various entities may need to verify such information, such as by manually inspecting the vehicle involved in the loss, contacting parties involved in the loss or any witnesses, etc.

Accordingly, to assist the operator, various entities may need to exchange and/or verify information relating to the loss, e.g., where the loss occurred, severity of the loss, facts to determine which party was at fault, etc. This exchange and/or verification of information may be cumbersome and time consuming. Delays for various reasons (e.g., the operator delays reporting of the vehicle loss, verifying the operator's account of the vehicle loss, etc.) may further delay assistance for the operator.

BRIEF SUMMARY

The disclosed embodiments generally relate to determining vehicle loss based upon vehicle sensor data received from the sensors installed on, or within, the vehicle to initiate an “Instantaneous” Notice of Loss (INOL) for proactively assisting an operator of the vehicle, prior to receiving any notice from the operator of the occurrence of the loss. The vehicle sensor data can be interpreted to be the “ground truth” of the vehicle loss, and thus need not be necessarily verified with manual inspections of the vehicle, for example. Advantageously, for example, an insurer of the vehicle may instantaneously determine that a vehicle loss occurred based upon the received vehicle sensor data, prior to receiving any report of loss information (e.g., phone call from the operator, pictures documenting the loss, police report, etc.) from the operator of the vehicle. In this way, the insurer of the vehicle may employ a proactive approach to initiate processes on behalf of the operator, such as initiating INOL rather than waiting for the operator to initiate FNOL, anticipating that the operator may need assistance, and contacting appropriate entities (e.g., emergency medical technicians (EMTs), police, towing services, taxi or ride-share services, repair shops, body shops, salvage vendors, etc.) that the operator has authorized the insurer to contact in advance if the operator was to experience vehicle loss.

To employ the proactive approach, a blockchain-based solution is described herein. A large dataset of vehicle sensor data from numerous vehicles may be analyzed to determine one or more parametric events. For example, analysis of the large dataset of vehicle sensor data from numerous vehicles may indicate that a broken window of vehicles correlates to a parametric event of theft of item(s) in vehicles. As another example, analysis of vehicle sensor data may indicate that isolated damage of vehicles (e.g., the front but not the back) correlates to a parametric event of a relatively small collision (e.g., the vehicles drove into trees, mailboxes, etc.), whereas extensive damage of vehicles (e.g., body of vehicles severely damaged) correlates to a parametric event of a relatively large collision (e.g., the vehicles suffered total loss beyond repair). For each parametric event determined from the large dataset of vehicle sensor data, a corresponding smart contract is generated for deployment onto a shared leger (i.e., the blockchain), to define action(s) (e.g., initiating an INOL process, contacting an emergency response entity, towing service entity, taxi or ride-share services entity, vehicle repair service entity, vehicle salvage entity, etc.) when the parametric event involving a vehicle actually occurs.

The blockchain operated by a group of network entities according to a set of consensus rules manages and resolves vehicle loss according to the generated smart contracts. Evidence regarding the vehicle loss (i.e., vehicle sensor data) and in some cases, any supplementation information (e.g., weather data indicating weather conditions at the moment of the vehicle loss, image data indicating photographic evidence of the vehicle loss) is sent to the blockchain by one or more entities (e.g., sensors installed on or within the vehicle, supplemental sources), which are routed to any of the smart contracts described above that are deployed on the blockchain. Upon execution of these smart contracts, assistance may be provided to the operator of the vehicle prior to receiving any report of loss information from the operator of the vehicle.

In some embodiments, a computer-implemented method for generating one or more smart contracts for deployment onto a blockchain may be provided. The method may be implemented via one or more local or remote processors, transceivers, sensors, servers, memory units, and/or other electronic or electrical components. The method may include: (1) receiving, at one or more processors, vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) analyzing, by the one or more processors, the vehicle sensor data to determine one or more parametric events, wherein each of the parametric events is associated with a corresponding severity of loss; (3) generating, by the one or more processors and for each of the one or more parametric events, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction received from a computing device indicates that a parametric event corresponding to the smart contract has occurred; and/or (4) deploying, by the one or more processors, the smart contract at a particular address on the blockchain. The method may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In other embodiments, a computer system for generating one or more smart contracts for deployment onto a blockchain may be provided. The computing system may include one or more processors and associated transceivers, and a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: (1) receive vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) analyze the vehicle sensor data to determine one or more parametric events, wherein each of the parametric events is associated with a corresponding severity of loss; (3) generate, for each of the one or more parametric events, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction received from a computing device indicates that a parametric event corresponding to the smart contract has occurred; and/or (4) deploy the smart contract at a particular address on the blockchain. The computing system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In yet other embodiments, generating one or more smart contracts for deployment onto a blockchain may be provided. The executable instructions, when executed by one or more processors of a computer system, cause the computer system to: (1) receive vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) analyze the vehicle sensor data to determine one or more parametric events, wherein each of the parametric events is associated with a corresponding severity of loss; (3) generate, for each of the one or more parametric events, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction received from a computing device indicates that a parametric event corresponding to the smart contract has occurred; and/or (4) deploy the smart contract at a particular address on the blockchain. The executable instructions may include additional, less, or alternate functionality, including that discussed elsewhere herein.

Advantages will become more apparent to those of ordinary skill in the art from the following description of the preferred embodiments, which have been shown and described by way of illustration. As will be realized, the present embodiments may be capable of other and different embodiments, and their details are capable of modification in various respects. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures described below depict various embodiments of the system and methods disclosed herein. It should be understood that each figure depicts a particular embodiment of the disclosed system and methods, and that each of the figures is intended to accord with a possible embodiment thereof. Further, wherever possible, the following description refers to the reference numerals included in the following figures, in which features depicted in multiple figures are designated with consistent reference numerals.

There are shown in the drawings arrangements which are presently discussed, it being understood, however, that the present embodiments are not limited to the precise arrangements and instrumentalities shown, wherein:

FIG. 1A depicts an exemplary computing system including components and entities associated with creating, deploying, and utilizing smart contracts on a blockchain to assist an operator of a vehicle involved in a vehicle loss prior to receiving any report of loss information from the operator, in accordance with some embodiments;

FIG. 1B depicts exemplary smart contracts generated by the exemplary computing system of FIG. 1A, in accordance with some embodiments;

FIG. 2 depicts an exemplary transaction on a blockchain for assisting the operator of the vehicle, in accordance with some embodiments;

FIG. 3 depicts an exemplary smart contract for assisting the operator of the vehicle; and

FIG. 4 depicts an exemplary computer-implemented method for generating smart contracts deployed onto a blockchain for assisting the operator of the vehicle.

FIG. 5A depicts an exemplary GUI executing on a mobile computing device for notifying the operator of the vehicle that a collision has been detected.

FIG. 5B depicts an exemplary GUI executing on a mobile computing device for requesting the dispatch of emergency medical technicians (EMTs).

FIG. 5C depicts an exemplary GUI executing on a mobile computing device for requesting the dispatch of police.

FIG. 5D depicts an exemplary GUI executing on a mobile computing device for requesting the dispatch of a tow truck.

FIG. 5E depicts an exemplary GUI executing on a mobile computing device for requesting the dispatch of a taxi or ride-share.

FIG. 5F depicts an exemplary GUI executing on a mobile computing device for requesting the contact of a repair shop or a body shop.

FIG. 5G depicts an exemplary GUI executing on a mobile computing device for requesting the contact of a vehicle salvage vendor.

FIG. 5H depicts an exemplary GUI executing on a mobile computing device for opting-out of the techniques, systems, and methods disclosed herein

FIG. 6 depicts an exemplary computer-implemented method for generating one or more GUIs.

The figures depict the present embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternate embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION

Traditionally, business entities and central authorities involved in resolving vehicle loss (e.g., theft of items inside the vehicle, a vehicle collision, a major collision resulting in a vehicle beyond repair, etc.) react to a report of the vehicle loss from a customer (e.g., operator of the vehicle involved in the vehicle loss), by storing loss information (e.g., transcription of a phone call from an operator of a vehicle involved in the vehicle loss, pictures documenting the vehicle loss, police report, etc.) in databases or ledgers. Often these databases and ledgers are held by the business entities and must be reconciled to achieve consensus as to the validity of the information stored therein. Alternatively, a central authority may be responsible for determining the validity of information stored in a database or a ledger and functioning as an arbiter of consensus for interested parties.

A blockchain (also referred to herein as a distributed ledger or a shared ledger) is a way of achieving a distributed consensus on the validity or invalidity of information in the chain. In other words, the blockchain provides a decentralized trust to participants and observers. As opposed to relying on a central authority, a blockchain is a decentralized database in which a transactional record of changes to the ledger is maintained and validated by each node of a peer-to-peer (P2P) network. The blockchain may be comprised of groupings of transactions organized together into a “block,” and ordered sequentially (thus the term “blockchain”). Nodes may join and leave the blockchain network over time, and may obtain blocks that were propagated while the node was gone from peer nodes. Nodes may maintain addresses of other nodes, and exchange addresses of known nodes with one another to facilitate the propagation of new information across the network in a decentralized, P2P manner.

In one application of the blockchain, each new block may be cryptographically linked to the previous block in order to form the blockchain. More particularly, to create a new block, each transaction within a block may be assigned a hash value (i.e., an output of a cryptographic hash function, such as SHA-2 or MD5). These hash values may then be combined together utilizing cryptographic techniques (e.g., a Merkle Tree) to generate a hash value representative of the entire new block. This hash value may then be combined with the hash value of the previous block to form a hash value included in the header of the new block, thereby cryptographically linking the new block to the blockchain. To this end, the precise value utilized in the header of the new block is dependent on the hash value for each transaction in the new block, as well as the hash value for each transaction in every prior block.

According to some embodiments, the hash value generated for the new block may be used as an input to a cryptographic puzzle that manipulates a nonce value. When a solution to the cryptographic puzzle is found, the solving node publishes the solution and the other nodes then verify that the solution is the correct solution. Because the solution may also depend on the particular hash values for each transaction within the blockchain, if the solving node attempted to modify any transaction, the solution would not be verified by the other nodes.

More particularly, if a single node attempts to modify a prior transaction within the blockchain, a cascade of different hash values may be generated for each tier of the cryptographic combination technique. This may result in the header for one or more blocks being different than the corresponding header(s) in every other node that did not make the exact same modification. As a result, the solution generated by the modifying node would not solve the cryptographic puzzle presented to any node without the identical modification. Thus, the version of the new block generated by the modifying node may be readily recognized as including an improper modification and rejected by the consensus. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and/or immutable.

The nodes that share the blockchain form what is referred to herein as the blockchain network. The nodes in the blockchain network validate changes to the blockchain (e.g., when a new transaction and/or block is created) according to a set of consensus rules. The consensus rules depend on the information being tracked by the blockchain and may include rules regarding the chain itself. For example, a consensus rule may include that the originator of a change supplies a proof-of-identity such that only approved entities may originate changes to the chain. A consensus rule may require that blocks and transactions adhere to format requirement and supply certain meta information regarding the change (e.g., blocks must be below a size limit, transactions must include a number of fields, etc.). Consensus rules may include a mechanism to determine the order in which new blocks are added to the chain (e.g., through a proof-of-work system, proof-of-stake, etc.).

Additions to the blockchain that satisfy the consensus rules may be propagated from nodes that have validated the addition to other nodes that the validating node is aware of. If all the nodes that receive a change to the blockchain validate the new block, then the distributed ledger reflects the new change as stored on all nodes, and it may be said that the distributed consensus has been reached with respect to the new block and the information contained therein. Any change that does not satisfy the consensus rule may be disregarded by validating nodes that receive the change and is not propagated to other nodes. Accordingly, unlike a traditional system which uses a central authority, a single party cannot unilaterally alter the distributed ledger unless the single party can do so in a way that satisfies the consensus rules. The inability to modify past transactions leads to blockchains being generally described as trusted, secure, and immutable. Third-party intermediaries who assist in the resolution of vehicle loss may thus be disintermediated from the process by a decentralized blockchain.

The validation activities of nodes applying consensus rules on a blockchain network may take various forms. In some embodiments, the validating nodes execute code contained in “smart contracts” and distributed consensus is expressed as the network nodes agreeing on the output of the executed code.

Blockchains may be deployed in a public, decentralized, and permissionless manner meaning that any party may view the blockchain, submit new information to be added to the blockchain, or join the network as a validating node. Other blockchains are private (e.g., permissioned ledgers) that keep chain data private among a group of entities authorized to participate in the blockchain network.

The present embodiments generally relate to systems and methods for using a blockchain to record and manage information related to proactive resolution of vehicle loss. The blockchain may be either a public or permissioned ledger.

Exemplary Smart Contract Functionality

In particular, the present embodiments may relate to, inter alia, creating and deploying smart contracts onto a blockchain that are used to enforce agreements related to proactive resolution of vehicle loss, made between a node (interchangeably referred herein as an “entity” or “party” or “participant”) and an operator of the vehicle involved in the vehicle loss, or between/among nodes (interchangeably referred herein as “entities” or “parties” or “participants”) of a blockchain system (interchangeably referred herein as a “blockchain network”). Potential nodes may include an insurer entity, emergency response entity, towing services entity, taxi or ride-share services entity, vehicle repair service entity, vehicle salvage entity, vehicle manufacturer entity, and a State Department of Motor Vehicles (DMV) entity, just to name a few.

Each smart contract described herein may be a set of code that is deployed at a particular address on the blockchain, that when executed causes action(s) defined in the smart contract to be automatically initiated when certain parametric events) defined in the smart contract occur. These action(s) may involve initiating processes for servicing the vehicle, and one or more entities exchanging information about the vehicle with an operator of the vehicle (e.g., driver of the vehicle, owner of the vehicle, policy holder of the vehicle) or one or more other entities. For instance, the smart contracts may relate to (1) initiating an INOL process, (2) tracking maintenance or repair work that has been, or is to be, performed on a vehicle, (3) contacting first responders, (4) contacting towing services, repair services, taxi services, ride-share services, and/or the like. As such, the blockchain may have various usages, and may allow for the introduction of new capabilities. By using the blockchain, the exchange of information included in transactions is sped up, and by utilizing smart contracts deployed onto the blockchain, actions related to the vehicle may be automated.

When a vehicle is involved in a vehicle loss, a node (i.e., the vehicle or sensors installed on or within the vehicle) generates and transmits a transaction associated with the vehicle's unique identifier to a blockchain network, which compiles the transaction into a block of the blockchain. Potential data included in the blockchain and/or each blockchain transaction, block, or update may include identity data (e.g., VIN number of the vehicle), vehicle sensor data (e.g., indicative of driving, braking, speed, cornering, stop/start, acceleration, theft of items inside the vehicle, collisions, etc.) collected from one or more sensors installed on or within the vehicle, supplemental data collected from other sources (e.g., mobile device sensor data, smart infrastructure sensor data, image data from cameras in the vicinity of an accident), a license plate number, state of issuance, operator information (e.g., social security number, name, contact information like address, phone, email address, etc.), insurance carrier information (e.g., insurer name, insurance policy ID or number; an indication of whether the policy remains in force, effective dates of the policy, expiration date of the insurance coverage; and/or insurance policy coverages, terms, limits, deductibles, conditions, etc.). Any of the data listed above, or a hash or encrypted version thereof, may serve as a key to access and/or update the blockchain for the vehicle. Each of the blockchain entities, or only a subset, may be validation entities that validate the transaction and any of the data contained in the transaction on the blockchain network.

A server, which can be any one of the entities described above that generated a particular smart contract, may subscribe to one or more transactions including data related to vehicle loss. Accordingly, the server may route the transactions to the particular smart contract so that the particular smart contract may determine that the data related to the vehicle loss indicates that a parametric event defined by the particular smart contract has occurred, and direct the server or other entity associated with the particular smart contract to perform one or more actions. In some embodiments, routing the transactions may include extracting identity data (e.g., VIN number) from the transactions and utilizing the identity data to query one or more smart contracts. The smart contract that matches the identity data may be considered to be the “particular smart contract.” Accordingly, routing may further include the server inputting the transaction data described above into the particular smart contract. To this end, based upon the transaction data, the particular smart contract may then direct the performance of an action to enforce the particular smart contract.

As an example, a server (e.g., insurer) may generate a smart contract to perform an action (e.g., initiate an INOL on behalf of the driver of the vehicle), when a parametric event as defined in the smart contract occurs (e.g., the extent of damage to the vehicle exceeds a certain level). Thus, when the server receives a transaction including vehicle sensor data, the smart contract may automatically analyze the vehicle sensor data to determine whether the extent of vehicle damage as indicated in the vehicle sensor data exceeds the level (i.e., whether the parametric event occurred). Accordingly, the smart contract may direct the performance of an action to automatically initiate an INOL on behalf of the driver of the vehicle when the parametric event occurs based upon the vehicle sensor data.

As another example, a server (e.g., tow service company, taxi or ride share company, repair shop, body shop, first responders, etc.) may generate a smart contract to perform a certain action (e.g., provide services such as towing services, taxi or ride-share services, vehicle repair services, or medical assistance) on behalf of the driver of the vehicle, when a parametric event as defined in the smart contract occurs (e.g., the extent of damage to the vehicle exceeds a certain level and the location of the vehicle is within an operating range of the services).

In yet another example, a server (e.g., insurer) may generate one or more smart contracts, each to perform a certain action (e.g., coordinate with other entities to provide services such as towing services, taxi or ride-share services, vehicle repair services, medical assistance, etc.) on behalf of the driver of the vehicle, when a parametric event as defined in the smart contract occurs (e.g., the extent of damage to the vehicle exceeds a certain level and the location of the vehicle is within an operating range of the entity).

Thus, for each particular parametric event, a server may generate a respective smart contract for handling a specific action when a specific parametric event occurs. When the server receives a transaction including vehicle sensor data, the smart contract may automatically analyze the vehicle sensor data to determine whether the parametric event has occurred. Accordingly, the smart contract may direct the performance of an action to automatically provide a certain service on behalf of the driver of the vehicle based upon the vehicle sensor data.

The blockchain may be leveraged to record each generated smart contract, the vehicle sensor data included in transaction(s) provided by the vehicle, and/or other data related to the parametric events defined in the smart contracts. In one aspect, vehicle sensor data and/or other supplemental data (e.g., mobile device sensor data, smart infrastructure sensor data, image data from cameras in the vicinity of an accident) included in transaction(s) and utilized to determine the occurrence of parametric events to determine actions defined in smart contracts may be recorded on the blockchain. By recording this data in the blockchain, there is a public and trusted record of the transaction(s) and smart contracts, and the logic behind any actions performed as directed by the respective smart contracts.

As a result, the parties that generated the smart contracts may automatically enforce their smart contracts in a transparent and objective manner. For at least this reason, an entity that regularly generates smart contracts, such as an insurer, may establish a blockchain to govern and enforce or maintain one or more smart contracts. According to some embodiments, the blockchain may either be a public ledger (each node may readily view the underlying data of each transaction) or a private ledger (the underlying data needs an encryption key to be viewed), or a combination of public and private ledger embodiments.

According to some embodiments, sensors (e.g., original equipment manufacturer (OEM) sensors) installed on or within a vehicle, and in some cases, other sources such as an electronic device associated with each vehicle and smart infrastructure sensors may each execute an application to monitor vehicle sensor data that is relevant to the enforcement of a smart contract such as vehicle operational data, vehicle telematics data, vehicle sensor data, vehicle condition data, mileage data, maintenance data, parts data, system data, system or software version data, mobile device data, GPS data, etc. For example, an application may process vehicle sensor data from an airbag sensor to determine a parametric event (e.g., that the vehicle was involved in a collision).

As another example, the application may process vehicle sensor data from a glass break sensor to determine another parametric event (e.g., that the windows of the vehicle were broken and theft of items included in the vehicle took place). The application may interpret the vehicle sensor data to generate a transaction that includes the vehicle sensor data or a portion thereof. In some embodiments, the transaction may be timestamped and/or include the location of the vehicle.

Exemplary Environments for Creating & Deploying Smart Contracts onto a Blockchain

FIG. 1A depicts an exemplary computing system 100 (interchangeably referred herein as a “blockchain network”) for creating and deploying smart contracts onto a blockchain, the execution of which would assist an operator of a vehicle involved in a vehicle loss, prior to an entity in the computing system 100 receiving any report of loss information from the operator. Although FIG. 1A depicts certain entities, components, and devices, it should be appreciated that additional or alternate entities and components are envisioned.

As illustrated in FIG. 1A, the computing system 100 may include one or more vehicles 105a-f. These vehicles may be cars, motorcycles, hikes, or any other suitable vehicles. These vehicles may be conventional vehicles, autonomous vehicles, smart vehicles, connected vehicles, etc. Each of the vehicles 105a-f may include one or more sensors 101a-b (as shown on or within vehicle 105a) that generate vehicle sensor data, including telematics data, that indicate an operational status of the vehicle (e.g., location, speed, idling time, harsh acceleration or braking, fuel consumption, vehicle faults, cornering, direction or heading, etc.). The sensors 101a-b may include, for example, a pressure sensor, a gyroscope, an accelerometer, an odometer, a vibration sensor, a microphone, an image sensor, a temperature sensor, glass break sensors, a radar or LIDAR sensor, and/or other suitable sensors. In some embodiments, some of the sensors 101a-b can be OEM sensors installed on or in the vehicle by a manufacturer of the vehicle, and in other embodiments, some of the sensors 101a-b may be retrofitted onto the vehicle at some point after manufacture. in some embodiments, these sensors 101a-b may be configured to wirelessly communicate vehicle sensor data generated by the sensors 101a-b via a wireless interface (e.g., a Wi-Fi interface, a cellular interface, or other known wireless communication interfaces) to a server 115 via one or more communication networks 110 (e.g., via wireless communication or data transmission over one or more radio links or digital communication channels).

in some embodiments, the vehicle 105a (as well as any of the other vehicles 105b-f) may further include an electronic device 103 configured to collect vehicle sensor data generated by the sensors 101a-b. The electronic device 103 can be a processing unit of the vehicle 105a interconnected to the sensors 101a-b via a communication bus of the vehicle 105a, or a personal electronic device (e.g., a mobile phone, a tablet, a laptop computer, a smart watch, smart glasses, augmented reality glasses or headset, virtual reality glasses or headset, other types of wearable electronics, an on-board diagnostic monitor, and so on) associated with an operator of the vehicle 105a. In these embodiments, the electronic device 103 may receive, from the sensors 101a-b, the vehicle sensor data via a wireless interface (e.g., a Bluetooth interface, a Wi-Fi interface, or other known wireless communication interfaces) or a wired interface (e.g., an OBD port, a USB interface, an auxiliary interface, or other known wired communication interfaces), and transmit the vehicle sensor data to the server 115 via one or more communication networks 110.

The server 115 may include a database 120 to store the vehicle sensor data generated by the sensors 101a-b and collected from vehicles 105a-f. The server 115 may also include one or more processors configured to execute a sensor data analysis application (not pictured) that is programmed to analyze the vehicle sensor data stored in the database 120. More particularly, the sensor data analysis application may be configured to analyze the vehicle sensor data to detect or identify one or more parametric events, each of which corresponds to a certain vehicle loss. For example, the sensor data analysis application may analyze at least a portion of the vehicle sensor data (e.g., generated by glass break sensors 101a-b adhered to the vehicles 105a-f) that indicates that a broken window of vehicles 105a-f correlates to a parametric event of theft of item(s) in vehicles 105a-f (e.g., as confirmed by dashcam sensors 101a-b located in the interior of vehicles 105a-f that capture video data conveying items being stolen).

As another example, analysis of at least a portion of the vehicle sensor data (e.g., generated by sensors 101a-b adhered to the front-side and back-side of body panels of the vehicles 105a-f) may indicate that isolated damage of vehicles 105a-f (e.g., the front but not the back) correlates to a parametric event of a relatively small collision (e.g., the vehicles 105a-f drove into trees, mailboxes, etc.), whereas extensive damage of vehicles 105a-f (e.g., the front and back of vehicles severely damaged) correlates to a parametric event of a relatively large collision (e.g., the vehicles 105a-f suffered total loss beyond repair).

In sonic embodiments, the sensor data analysis application may analyze other data in addition to the vehicle sensor data to identify parametric events. For example, the sensor data analysis application may analyze supplemental data (e.g., image data showing that the vehicles 105a-f collided into a tree, or was involved in a more serious accident) originating from other sources (e.g., camera installed at a traffic light nearby the site of an accident) to identify or confirm identification of a parametric event.

After determining or identifying one or more parametric events based upon analysis of vehicle sensor data collected from vehicles 105a-f, the one or more processors of the server 115 may execute a smart contract generator 116 (or alternatively, the same sensor data analysis application) to generate an executable smart contract for each of the identified parametric events. The generated smart contracts may be stored in database 130. Generally speaking, the smart contracts include executable code that defines a function for initiating INOL, personal assistance (e.g., calling the police, EMTs, etc.), and/or vehicle assistance (e.g., calling towing services, taxi or ride-share services, vehicle repair services, vehicle salvage services, and/or the like) in response to the occurrence of an underlying parametric event.

For example, and with reference to FIG. 1B, the smart contract generator 116 may generate (i) smart contract 121 for handling/resolving the parametric event of theft of item(s) in a vehicle; (ii) smart contract 122 for handling/resolving the parametric event of a relatively small collision; and/or (iii) smart contract 123 for handling/resolving the parametric event of a relatively large collision. Each of the smart contracts 121-123 may have several elements.

As shown in FIG. 113, each of the smart contracts 121-123 may include identity data 140 of vehicles to which the smart contracts 121-123 apply. The identity data 140 may include a listing of all applicable vehicle unique identifiers (e.g., VIN of vehicle, serial numbers of sensors included in vehicle), each of which can be used to query the database 130 to locate the applicable smart contract. When a node of the blockchain network receives a transaction including identity data for a vehicle, the node can extract the identity data and route the transaction to the smart contract(s) having an identity of the vehicle as part of the identity data 140.

Also shown in FIG. 1B, each of the smart contracts 121-123 may include a description or ID 141 of the corresponding parametric event that pertains to the smart contract. In some embodiments, the description 141 of the corresponding parametric event may include an analysis function that receives, as an input, vehicle sensor data and optionally supplemental data extracted from an incoming transaction, and sets a flag only if the vehicle sensor data and optional supplemental data are assessed to exhibit the corresponding parametric event. The analysis function may be code that is configured to process the vehicle sensor data to identify whether particular aspects (e.g., broken windows of vehicle 106, destruction of body panels of the vehicle 106) are reflected in the vehicle sensor data, and/or to identify a severity level based upon the extent of damage to vehicles 105a-f (e.g., (i) a “low” or numerically equivalent severity level corresponding to the parametric event of theft of item(s) in vehicles 105a-f; (ii) a “medium” or numerically equivalent severity level corresponding to the parametric event of a relatively small collision; and/or (iii) a “high” or numerically equivalent severity level corresponding to the parametric event of a relatively large collision).

As shown in FIG. 1B, each of the smart contracts 121-123 may also include a defined action 142 for a designated entity When the corresponding parametric event actually occurs. For example, the smart contract generator 116 may define an action for an entity to initiate INOL and contact police, where the action corresponds to the “low” severity level and/or the parametric event of theft of item(s) in vehicles 105a-f. As another example, the smart contract generator 116 may define an action for an entity to initiate INOL and contact vehicle repair services, where the action corresponds to the “medium” severity level and/or the parametric event of a relatively small collision. As yet another example, the smart. contract generator 116 may define an action for an entity to initiate INOL and contact vehicle salvage services, emergency response services, and towing services, where the action corresponds to the “high” severity level and/or the parametric event of a relatively large collision. Thus, using various elements (e.g., 140-142), the smart contract generator 116 may generate smart contracts 121-123, each specifying a parametric event and a corresponding action to be performed by an entity when the parametric event. actually occurs. Although FIG. 1B depicts certain parametric events and actions, it should be appreciated that additional or alternate parametric events and actions are envisioned.

Having one or more smart contracts in place (e.g., stored in database 130), the server 115 is equipped to deploy the smart contracts onto the blockchain, and subsequently assess new vehicle sensor data from new vehicles. Referring back to FIG. 1A, the server 115 may be equipped to assess new vehicle sensor data received from vehicle 106. Vehicle 106 may be similar to any one of vehicles 105a-f, and thus have any one or more of sensors 101a-b and/or electronic device 103.

According to some embodiments, the vehicle 106 (e.g., by way of a computing device, such as one or more of sensors 101a-b and/or electronic device 103) may send an electronic transmission (i.e., a transaction 108) to the server 115 via the one or more communication networks 110. The transaction 108 may include at least vehicle identity data (e.g., VIN number of the vehicle 106, serial number of any one or more of sensors 101.a-b and/or electronic device 103, username or number of an account associated with the operator of the vehicle 106) and vehicle sensor data (or at least a portion thereof) generated by sensors 101a-b and/or electronic device 103 on or within the vehicle 106. In some embodiments, the vehicle sensor data may include location information and time stamp information to indicate when and where vehicle loss occurred.

Upon receiving the transaction 108, the server 115 may route the transaction 108 to one or more applicable smart contracts by extracting vehicle identity data from the transaction 108 and utilizing the vehicle identity data to find only those smart contracts deployed on the blockchain where the corresponding identity data 140 accounts for the vehicle identity data. In turn, the one or more smart contracts that account for the vehicle identity data each execute to determine whether the vehicle sensor data or other data included in the transaction 108 indicates a respective parametric event that would trigger a corresponding action.

In some embodiments, the transaction 108 may include the ID of the parametric event, which may be detected by an application executing on the one or more of sensors 101a-b and/or electronic device 103 associated with the vehicle 106 based upon an analysis of the vehicle sensor data. In such embodiments, when the server 115 receives the transaction 108 including the ID of the parametric event, the server 115 need only match the ID of the parametric event with ID 141 of a smart contract to determine whether the transaction 108 indicates the parametric event, thereby conserving processing of resources that would otherwise be needed to analyze the vehicle sensor data included in the transaction 108 to determine whether the transaction 108 indicates a parametric event. In some embodiments, the transaction 108 may include supplemental data (e.g., provided by electronic device 103) that indicates additional information that may be relevant to the parametric event, such as third-party weather data, traffic data, image data, etc. As an example, a parametric event may be related to a weather condition at the time vehicle loss occurred (e.g., the presence of rain when vehicle loss occurred).

In some embodiments, the supplemental data may originate from another source (interchangeably referred herein as an “evidence oracle”) that can provide supporting evidence of a parametric event, such as a weather application server, infrastructure smart sensors, traffic cameras, environmental conditions sensors, Internet of Things (IoT) devices, etc. Generally speaking, an evidence oracle is connected to the internet that records supplemental data occurring during the parametric event, and may transmit that supplemental data to the blockchain network where it may be used in various processes.

For example, an evidence oracle may collect supplemental data on a traffic intersection at which the parametric event took place. As illustrated in FIG. 1A, such an evidence oracle 107 may provide a transaction 109 including the supplemental data (and a cryptographic hash of the supplemental data) to the server 115 via the one or more communication networks 110. In some embodiments, the transaction 109 may include other data elements, such as transaction ID, unique identifier of the evidence oracle, a data type (e.g., video and audio data), etc. In the following description, any reference to transaction 108 may also include transaction 109.

As illustrated in FIG. 1A, the server 115 may include a blockchain manager 117. The blockchain manager 117 may be a software program, engine, and/or a module that is executed by one or more processors interconnected within the server 115 and configured to (i) compile one or more transactions (e.g., transactions 108, 109) into blocks; (ii) update a blockchain to include the blocks; (iii) route the transactions to applicable smart contracts; and/or (iv) automatically execute the smart contracts if the transactions meet certain conditions defined by the smart contracts. In some embodiments, the blockchain manager 117 may (i) receive and compile transaction 108 into a block; (ii) update blockchain 145 to include the block; (iii) route transaction 108 (or data thereof) to a smart contract deployed onto the blockchain 145 that corresponds to a specific parametric event indicated by or otherwise associated with the transaction 108; and/or (iv) automatically execute the smart contract.

In certain embodiments, the blockchain manager 117 may identify the blockchain 145 to add new blocks to using the unique identifier of the vehicle 106, or otherwise use the unique identifier to access the blockchain 145 or update the blockchain 145. As described above, each of the smart contracts may include a listing of all vehicles (e.g., unique identifiers) that are applicable to the smart contract, and the blockchain manager 117 may identify which smart contract to route the transaction 108 to using a unique identifier of the vehicle 106 as an access key. To this end, the blockchain manager 117 may extract the unique identifier from transaction 108 and route the transaction 108 to a respectively corresponding smart contract that governs the unique identifier.

In some embodiments, prior to updating the blockchain 145 with the block, the server 115 may transmit the block to one more entities 135a-e via one or more communication networks 110 to generate a solution to incorporate the block into the blockchain 145, and/or to form a consensus on the solution. The one or more entities may include an insurer entity 135a, emergency response entity 135b, towing services entity 135c, vehicle repair services entity 135d, vehicle salvage entity 135e, and/or a taxi or ride-share services entity 135f to name a few. Other entities are contemplated, such as a vehicle manufacturer entity, a State Department of Motor Vehicles (DMV) entity, a vehicle dealership entity, a vehicle rental company entity, and other suitable entities that may generally relate to maintaining and/or servicing vehicles.

Although FIG. 1A illustrates the one more entities 135a-e as being separate from the server 115, it should be appreciated that the server 115 may itself include a module dedicated to generating a solution to the cryptographic puzzle and/or forming a consensus on the solution. The blockchain 145 may be maintained via a network of nodes, including vehicles 105a-f, vehicle 106, server 115, and/or entities 135a-e. The nodes may have access to the blockchain 145, generate data included in the blockchain 145, and/or store local copies of the blockchain 145.

When the blockchain manager 117 identifies which particular smart contract to route the transaction 108 to, the particular smart contract may direct the server 115 to perform an action defined by the particular smart contract to enforce the particular smart contract. For example, the action defined by a particular smart contract may be to initiate INOL with insurer entity 135a. The insurer entity 135a may use the vehicle sensor data or other data included in transaction 108 to initiate the INOL.

As another example, the action defined by a particular smart contract may be to communicate with emergency response entity 135b to dispatch a first responder to a location of the vehicle involved in a vehicle collision. As yet another example, the action defined by a particular smart contract may be to communicate with towing services entity 135c, vehicle repair services entity 135d, vehicle salvage entity 135e, and/or taxi or ride-share services entity 135f to dispatch a tow truck to a location of the vehicle, schedule an appointment for fixing the vehicle, schedule an appointment to salvage the vehicle, and/or dispatch a taxi or ride-share service to a location of the vehicle respectively.

According to some embodiments, an administrator of the server 115 may interact with a management interface 119 to control embodiments of the blockchain 145 and/or set control parameters associated with the blockchain manager 117. For example, a period for which blocks are generated may be set via the management interface 119. In some embodiments, the administrator of the server 115 may also interact with the management interface 119 to control embodiments of the smart contract generator 116, e.g., by editing, add, or deleting elements or parameters used by the smart contract generator 116 to generate smart contracts. Although FIG. 1A depicts the database 130 as a part of the server 115, the database 130 may be maintained within the blockchain 145.

The communication networks 110 may facilitate any data communication between/among the one or more vehicles 105a-f, vehicle 106, entities 135a-e, and server 115 via any standard or technology (e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, CMS, EV-DO, UWB, IEEE 802 including Ethernet, WiMAX, and/or others). According to some embodiments, the one or more vehicles 105a-f, vehicle 106, and/or entities 135a-e may transmit generated transactions to the server 115 via the communication networks 110.

It should be appreciated that although the server 115 and entities 135a-f are shown as separate entities, in some embodiments, any one or more of the entities 135a-f may be, or otherwise include functionality of, the server 115. For example, the insurer entity 135a may include or be communicatively coupled to databases 120, 130, smart contract generator 116, blockchain manager 117, and management interface 119.

Although FIG. 1A illustrates a single server 115, several vehicles 105a-f, 106, and several entities 1135a-e, it should be appreciated that more or less servers, vehicles, and entities may be contemplated. In some embodiments, the server 115 may be one or more interconnected servers, for example, in a cloud computing environment. The exemplary computing system 100 may include additional, fewer, or alternate equipment or components, including those discussed elsewhere herein.

Exemplary Transaction Including Vehicle Sensor Data on a Blockchain

FIG. 2 depicts an exemplary transaction 200 (e.g., transaction 108 of FIG. 1A) recorded on a blockchain (e.g., blockchain 145 of FIG. 1A) associated with vehicle 106. An originating node (e.g., vehicle 106, sensors 101a-b, and/or electronic device 103) of the transaction 200 may broadcast the transaction 200 to other nodes (e.g., server 115, one or more entities 135a-e) on the blockchain network, and the transaction 200 may be included in a block on the blockchain if deemed a valid transaction by one or more nodes of the blockchain network. The transaction 200 may include various information associated with vehicle loss, which is potentially a parametric event as defined by a smart contract deployed on the blockchain, that occurred involving the vehicle 106.

In some embodiments, the transaction 200 may include identity data 201 (e.g., VIN number of the vehicle 106, serial number of any one or more of sensors 101a-b and/or electronic device 103, username or number of an account associated with the operator of the vehicle 106). The identity data 201 may be used to route the transaction 200 to one or more smart contracts associated with the identity data 201. The transaction 200 also includes vehicle sensor data 202 (e.g., indicative of driving, braking, speed, cornering, stop/start, acceleration, theft of items inside the vehicle, collisions, etc.) collected from one or more sensors installed on or within the vehicle 106.

The transaction 200 may have several additional data, including (1) operator information 203 (e.g., name, user preferences, an indication of acceptance of terms and conditions of smart contracts, social security number, contact information like address, phone, email address, etc.); (2) build data 204 (e.g., vehicle features); (3) supplemental data 205 (e.g., third-party weather data, traffic data, image data, etc.) collected from other sources (e.g., mobile device sensor data, smart infrastructure sensor data, image data from cameras in the vicinity of an accident) that indicates additional information that may be relevant to a parametric event; (4) parametric event ID 206; (5) insurance carrier information 207 (e.g., insurer name, insurance policy ID or number, an indication of whether the policy remains in force, effective dates of the policy, expiration date of the insurance coverage, and/or insurance policy coverages, terms, limits, deductibles, conditions, etc.); (6) maintenance and repair data 208; and/or (7) other data elements, including those discussed elsewhere herein.

The operator information 203 in the transaction 200 may be created or updated, and subsequently accessed or read by entities 135a-e and/or other entities, such as manufacturers, dealerships, DMVs, insurers, individual smart vehicles 105a-f, and/or authorized third parties 125. Some use cases for this type of information in transaction 200 is to determine if the operator of the vehicle 106 has provided authorization for an entity to associate the vehicle 106 to one or more smart contracts, to determine if the operator has provided authorization for an entity to initiate INOL on the operator's behalf, to determine a preferred physician, hospital, tow services, taxi or ride-share services, and/or repair shop or body shop in case the operator needs medical and/or vehicle assistance, etc.

The build data 204 (e.g., vehicle features or technology) in the transaction 200 may be created or updated by the manufacturer of vehicle 106, and subsequently read by other vehicles, insurers, consumers, other manufacturers, repair shops, etc. Use cases tor this type of information in the transaction 200 may include improved parametric event assessments and improved repair cost estimates.

The supplemental data 205 in the transaction 200 may be analyzed by a node to identify or confirm identification of a parametric event. If the parametric event ID 206 is included in the transaction 200, a node need only match the parametric event ID 206 with an 11D (e.g., ID 141 illustrated in FIG. 1B) of a smart contract to determine whether the transaction 200 indicates a parametric event, thereby conserving processing of resources that would otherwise be needed to analyze the vehicle sensor data 202 included in the transaction 200 to determine whether the transaction 200 indicates a parametric event.

The insurance carrier information 207 in the transaction 200 may be created for an insurer (e.g., entity 135a), and subsequently accessed or read by the insurer. The use cases for this type of information in the transaction 200 may be providing evidence of insurance by the vehicle 106.

The maintenance and repair data 208 in the transaction 200 may be created or updated, and subsequently read or accessed by vehicle repair shops, body shops, repair facilities, insurers, individual smart or connected vehicles, etc. A use case for this type of information in the transaction 200 may include maintaining the vehicle history.

Exemplary Smart Contract for a Parametric Event

FIG. 3 depicts an exemplary smart contract 300 (e.g., smart contract 121, 122, 123) having several elements. As shown in FIG. 3, smart contract 300 may include identity data 301 of vehicles to which the smart contract 300 applies, a parametric event ID or description 302 of the corresponding parametric event that pertains to the smart contract, and action data 303 to enforce a certain action when the corresponding parametric event actually occurs. Smart contract 300 may also include entity data 304 indicating which entities (e.g., any one or more of entities 135a-e) are obligated to perform actions as defined by actions data 303.

The identity data 301 may include a listing of all applicable vehicle unique identifiers (e.g., VIN of vehicle 106, serial numbers of sensors included in vehicle 106), each of which can be used to query the database 130 to locate smart contract 300. When a node receives a transaction 200 including identity data 201 that designates vehicle 106, the node can extract the identity data 201 and route the transaction 200 to the smart contract 300 if the identity data 301 of the smart contract 300 includes the identity of the vehicle 106.

The parametric event ID or description 302 identifies the corresponding parametric event that pertains to the smart contract 300. In some embodiments, the description 302 of the corresponding parametric event may include an analysis function that receives, as an input, vehicle sensor data 202 and optionally supplemental data 205 extracted from the transaction 200, and sets a flag only if the vehicle sensor data 202 and optional supplemental data 205 are assessed to exhibit the corresponding parametric event. The analysis function may be code that is configured to process the vehicle sensor data 202 and optional supplemental data 205 to identify whether particular aspects (e.g., broken windows of vehicle 106, destruction of body panels of the vehicle 106) are reflected in the vehicle sensor data 202, or to identify a severity level based upon the extent of damage to vehicle 106.

The action data 303 specifies a particular action to be performed by a designated entity (e.g., any one or more of entities 135a-e) when the corresponding parametric event identified by the parametric event ID 302 actually occurs. In some embodiments, action data 303 specifies an output generated by smart contract 300, such as a transaction for transmission to the designated entity, where the transaction includes any information to be used by the designated entity upon receipt of the transaction to carry out the particular action. The transaction may include an ID of the particular action to be performed by the designated entity corresponding to an ID of the designated entity, the location of vehicle 106, and any one or more of the data described in reference to FIG. 2. The transaction may only be generated when the parametric event identified by the parametric event, ID 302 actually occurs. Thai is, when smart contract 300 determines that the vehicle sensor data 202 and optionally supplemental data 205 extracted from the transaction 200 does not indicate a parametric event, smart contract 300 need not generate the transaction.

For example, upon receiving the transaction and using any of the extracted information included in the transaction, the designated entity (e.g., insurer entity 135a) may be triggered to (1) initiate INOL (e.g., populating an INOL report with any of the extracted information included in the transaction); (2) determine coverage and policy conditions; (3) vehicle triage; (4) send an assignment (e.g., including description of the vehicle, location of the vehicle, user preferences of the vehicle operator) to emergency response entity 135b, towing services entity 135c, vehicle repair services entity 135d, vehicle salvage entity 135e for servicing, and/or taxi or ride-share services entity 135f; (5) authorize a rental vehicle if applicable; (6) resolve any prior issues; (7) send an estimate and parts brochures to the vehicle operator; (8) perform a vehicle inspection if and when required; and/or (9) pay the final repair and any vehicle rental bills.

As another example, upon receiving the transaction and using any of the extracted information included in the transaction, the designated entity (e.g., emergency response entity 135b) may be triggered to (1) receive an assignment from insurer entity 135a; (2) provide medical assistance to the operator and any occupants of the vehicle; (3) Fill out a police report; (4) contact a physician or hospital according to the user preferences of the vehicle operator; and/or (5) send a medical bill to the insurer entity 135a.

As yet another example, upon receiving the transaction and using any of the extracted information included in the transaction, the designated entity (e.g., towing services entity 135c, vehicle repair services entity 135d, vehicle salvage entity 135e, and/or taxi or ride-share services entity 135f) may be triggered to (1) receive an assignment from insurer entity 135a; (2) take possession of vehicle; (3) arrange for rental/substitute transportation; (4) secure authorization to repair; (5) salvage the vehicle; (6) develop a repair plan; (7) prepare an estimate; (8) send a listing of necessary parts to suppliers; (9) finalize parts order and ordering parts; (10) upload an estimate; (11) check delivered parts versus parts ordered; (12) repair the vehicle; (13) provide a repair status updates to the vehicle operator; (14) deliver the vehicle; (15) provide the vehicle operator with a repair warranty; (16) send a final repair bill to the insurer entity 135a; and/or (17) perform other trigger events, including those discussed elsewhere herein.

Exemplary Method of Generating Smart Contracts for Respective Parametric Events Associated with Vehicle Loss

FIG. 4 depicts an exemplary computer-implemented method 400 for generating one or more smart contracts for deployment onto a blockchain (e.g., blockchain 145). The method 400 depicted in FIG. 4 may employ any of the blockchain techniques, methods, and systems described above with respect to FIGS. 1A-3.

The method 400 may begin at block 402 by receiving, at one or more processors (e.g., of server 115 or any one or more of the entities 135a-e), vehicle sensor data generated from sensors (e.g., sensors 101a-b) mounted on or within one or more vehicles (e.g., vehicles 105a-f).

The method 400 may proceed to block 404 by analyzing, by the one or more processors, the vehicle sensor data to determine one or more parametric events, wherein each of the parametric events is associated with a corresponding severity of loss. In some embodiments, a parametric event may be any one of theft involving a vehicle (corresponding to a “low” severity of loss), a collision involving the vehicle (corresponding to a “medium” severity of loss), or total loss of the vehicle (corresponding to a “high” severity of loss). However, generally speaking, a parametric event may relate to vehicle damage, and/or the extent or type of vehicle damage. In some embodiments, the one or more processors may receive supplemental data generated from one or more sources (e.g., smart infrastructure sensor, an electronic device located in one or more of the one or more vehicles, a camera located in an area in which the one or more of the one or more vehicles are located, or a third-party server, such as a weather server) and analyze the supplemental data to determine the one or more parametric events.

The method 400 may proceed to block 406 by generating, by the one or more processors and for each of the one or more parametric events, a corresponding smart contract that is configured to (i) receive a transaction from a computing device (e.g., any one or more of sensors 101a-b and/or electronic device 103) and (ii) automatically execute on the blockchain When the transaction indicates that a parametric event corresponding to the smart contract has occurred. In some embodiments, the transaction may include vehicle sensor data generated from sensors mounted on or within a vehicle (e.g., vehicle 106). In some embodiments, each of the generated smart contracts may define an action that is triggered when the corresponding parametric event occurs. For example, the action that is triggered may be one of the following: (1) initiating an instantaneous notice of loss (INOL), or other FNOL, with or by an insurer entity (e.g., insurer entity 135a); (2) communicating with the insurer entity 135a (e.g., a car insurance company and/or the like); (3) communicating with an emergency response entity 135b (e.g., police, fire department, EMTs, and/or the like); (4) communicating with a towing service entity 135c (e.g., a towing company and/or the like); (5) communicating with a vehicle repair service entity 135d (e.g., a repair shop, a body shop, and/or the like); (6) communicating with a vehicle salvage entity 135e (e.g., a vehicle salvage company and/or the like); (7) communicating with a taxi or ride-share service entity 135f (e.g., a taxi company, a ride-share service company, and/or the like); and/or additional actions, including those discussed elsewhere herein.

The method 400 may proceed to block 408 by deploying, by the one or more processors, the smart contract at a particular address on the blockchain. The method 400 may include additional, less, or alternate actions, including those discussed elsewhere herein.

Exemplary Graphic User Interface

FIGS. 5A-5H depict exemplary graphic user interfaces (GUIs) presented by an electronic device (e.g. electronic device 103) for (i) initiating an instantaneous notice of loss (INOL); (ii) requesting the dispatch of an emergency response entity; (iii) requesting the dispatch of a towing service entity; (iv) requesting the dispatch of a taxi or ride-share service entity; (v) requesting the dispatch of a vehicle repair service entity; (vi) requesting the dispatch of a vehicle salvage entity, and/or (vii) opting-out of the techniques, methods, and systems described herein.

In some embodiments, in the event of a collision being detected by the INOL methods and systems described herein, a notification from the insurer entity might be sent to the electronic device. The notification may be in the form of a text, email, a push notification from an application and/or the like. When the operator follows a link from the notification and/or interacts with the notification, the operator's computing device may open the application. The exemplary GUIs may alert the operator that a collision has been detected and may request the operator tier confirmation of the detection 510 (as depicted in FIG. 5A); may ask the operator if they require the dispatch of emergency medical technicians 520 (as depicted in FIG. 5B), police 530 (as depicted in FIG. 5C), a tow truck 540 (as depicted in FIG. 5D), a taxi or ride-share service 550 (as depicted in FIG. 5E), and/or a vehicle salvage vendor 570 (as depicted in FIG. 5G); may ask the operator if they would like the insurer entity to contact a repair shop or body shop on their behalf 560 (as depicted in FIG. 5F); and/or ask the operator if they want to opt-out of the INOL methods and systems described herein 580 (as depicted in FIG. 5H).

In some embodiments, the exemplary GUIs may have a means for the operator to select either an affirmative or negative response to the requests and/or questions posed by the application (e.g., touch-screen sensitive “Yes” and “No” button elements on the application as depicted in FIGS. 5A-5H). The exemplary GUIs may have a means of closing the current screen (e.g., a touch-screen sensitive “X” element as depicted in FIG. 5A). The exemplary GUIs may transfer data to execute any of the related INOL systems and/or methods described herein (for example, as depicted in FIG. 5B, if the user selects the “Yes” button element on their mobile device, a token may be sent to the insurer entity's servers that the operator has been in a collision and requests the dispatch of EMTs, whereby the INOL methods and systems described herein would execute in one or more of the exemplary embodiments described herein). The exemplary GUI may relate data ordering the cancellation of the INOL methods and systems described herein (for example, when the user selects either the “No” button element or the “X” element depicted in FIG. 5A, a token may be sent to the insurer entity's servers to halt the automated processes of the INOL methods and systems described herein).

In some embodiments, the application and/or the exemplary GUIs may have a timing mechanism that may be either visible or invisible to the operator. The timing mechanism may trigger after a certain length of time the operator has not opened the application after the notification was sent and/or after a certain length of time the operator does not make any registered selections on the application after the notification was sent and the application was opened (e.g., either an affirmative or negative response to the requests and/or questions posed by the application, selecting the “X” element, etc.). When the timing mechanism triggers, the INOL methods and systems described herein may start operating automatically and autonomously from the application as disclosed herein.

In some embodiments, the application may have a settings window for altering the default settings of the application, and the ability to opt-out of the INOL methods and systems may be located within the settings window. The settings window may be accessible from the exemplary GUI from a selectable element (e.g., a touch-screen sensitive cog element). If the operator chooses to opt-out of the INOL methods and systems described herein using the exemplary GUI, the INOL methods and systems described herein may not trigger until after the operator decides to opt-in using the exemplary GUI and/or other means (e.g., calling the insurer entity).

In some embodiments, the exemplary GUIs may appear in succession upon opening the application. For example, when the application is opened after the notification was sent, a first exemplary GUI may be displayed (e.g., the exemplary GUI as illustrated in FIG. 5A). The first exemplary GUI may have an interactive means for the operator to instruct the first exemplary GUI to transition to a second exemplary GUI (e.g., the exemplary GUI as illustrated in FIG. 5B). For example, the first exemplary GUI may have a touch-screen sensitive arrow element that when activated will cause the second exemplary GUI to appear. Similarly, the second exemplary GUI may have an interactive means for the operator to instruct the second exemplary GUI to transition to a third exemplary GUI as well as go back to the first exemplary GUI. For example, the second exemplary GUI may have a rightward facing touch-screen sensitive arrow element and a leftward facing touch-screen sensitive arrow element, and when the rightward facing touch-screen arrow element is activated the third exemplary GUI will appear and when the leftward facing touch-screen arrow element is activated the first exemplary GUI will appear. Additionally, other interactive elements on any of the exemplary GUIs may allow the operator to switch between the various exemplary GUIs. For example, activating the “Yes” button element on the first exemplary GUI may instruct the first exemplary GUI to transition to a second exemplary GUI. As another example, additional interactive elements such as touch-screen sensitive “First” and “Last” button elements on the application, when activated may instruct the current exemplary GUI to transition to the first exemplary GUI or last exemplary GUI respectfully.

The exemplary GUIs are not limited to the aforementioned and/or illustrated exemplary embodiments. For example, the illustrated GUIs are formatted for an electronic device in the form of a mobile phone; however, other exemplary GUIs may be designed for other devices (e.g., vehicle consoles, etc.). Additionally, the layout of the exemplary GUI may include more or less detail, different language, various placement of interactive elements, and/or the like. Further, the exemplary GUIs described herein are not exhaustive, nor should their inclusion be interpreted as a necessary or unnecessary function of the techniques, methods, and systems disclosed herein.

Exemplary Method of Generating Graphic User Interfaces in Response to Parametric Events Associated with Vehicle Loss

FIG. 6 depicts an exemplary computer-implemented method 600 for generating one or more graphic user interfaces (GUIs). The method 600 depicted in FIG. 6 may employ any of the blockchain techniques, methods, and systems described above with respect to FIGS. 1A-3 and may produce any of the exemplary graphic user interfaces (GUIs) depicted in FIGS. 5A-H.

The method 600 may begin at block 602 by receiving, at one or more processors (e.g., of server 115 or any one or more of the entities 135a-e), vehicle sensor data generated from sensors (e.g., sensors 101a-b) mounted on or within one or more vehicles (e.g., vehicles 105a-f).

The method 600 may proceed to block 604 by comparing, by the one or more processors, the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain. In some embodiments, the parametric event data may be generated from an analysis of the vehicle sensor data, wherein the parametric event data is related to a parametric event. In some embodiments, a parametric event may be any one of theft involving a vehicle (corresponding to a “low” severity of loss), a collision involving the vehicle (corresponding to a “medium” severity of loss), or total loss of the vehicle (corresponding to a “high” severity of loss). However, generally speaking, a parametric event may relate to vehicle damage, and/or the extent or type of vehicle damage. In some embodiments, the one or more processors may receive supplemental data generated from one or more sources (e.g., smart infrastructure sensor, an electronic device located in one or more of the one or more vehicles, a camera located in an area in which the one or more of the one or more vehicles are located, or a third-party server, such as a weather server) and analyze the supplemental data to determine the one or more parametric events. In some embodiments, the smart contract is configured to (i) receive a transaction from a computing device (e.g., any one or more of sensors 101a-b and/or electronic device 103) and (ii) automatically execute on the blockchain. when the transaction indicates that a parametric event corresponding to the smart contract has occurred. In some embodiments, the transaction may include vehicle sensor data generated from sensors mounted on or within a vehicle (e.g., vehicle 106). In some embodiments, each of the generated smart contracts may define an action that is triggered when the corresponding parametric event occurs. For example, the action that is triggered may be one of the following: (1) initiating an instantaneous notice of loss (INOL), or other FNOL, with or by an insurer entity (e.g., insurer entity 135a); (2) communicating with the insurer entity 135a (e.g., a car insurance company and/or the like); (3) communicating with an emergency response entity 135b police, fire department, EMTs, and/or the like); (4) communicating with a towing service entity 135c (e.g., a towing company and/or the like); (5) communicating with a vehicle repair service entity 135d (e.g., a repair shop, a body shop, and/or the like); (6) communicating with a vehicle salvage entity 135e (e.g., a vehicle salvage company and/or the like); (7) communicating with a taxi or ride-share service entity 135f (e.g., a taxi company, a ride-share service company, and/or the like); and/or additional actions, including those discussed elsewhere herein.

The method 600 may proceed to block 606 by automatically executing, by the one or more processors in response to the comparing of the vehicle sensor data, an action directed by the smart contract. In some embodiments, the action may be generating a notification.

The method 600 may proceed to block 608 by transmitting the notification to a client device. In some embodiments, the notification may cause the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss. In some embodiments, each of the generated graphic user interfaces (GUIs) may correspond to a parametric event recorded on the smart contract and perform an action in response to the smart contract. For example, the action that is triggered may be one of the following: (1) initiating an instantaneous notice of loss (INOL), or other FNOL, with or by an insurer entity (e.g., insurer entity 135a); (2) communicating with the insurer entity 135a (e.g., a car insurance company and/or the like); (3) communicating with an emergency response entity 135b (e.g., police, fire department, EMTs, and/or the like); (4) communicating with a towing service entity 135c (e.g., a towing company and/or the like); (5) communicating with a vehicle repair service entity 135d (e.g., a repair shop, a body shop, and/or the like); (6) communicating with a vehicle salvage entity 135e (e.g., a vehicle salvage company and/or the like); (7) communicating with a taxi or ride-share service entity 135f (e.g., a taxi company, a ride-share service company, and/or the like); and/or additional actions, including those discussed elsewhere herein. The method 600 may include additional, less, or alternate actions, including those discussed elsewhere herein

Additional Exemplary Embodiments

The present embodiments may relate to, inter alia, blockchains associated with FNOL and/or INOL. For instance, telematics data may be collected from smart vehicles or mobile devices having applications that collect vehicle telematics data during vehicle use. The present embodiments may employ one or more local or remote processors to assess sensor data (including vehicle sensor data), data reliability, and/or validate a vehicle crash or collision. The sensor data may also be analyzed by the local or remote processors to determine if a damaged vehicle is a total loss, salvageable, or repairable. The sensor data may be used to determine which vehicle sensors and/or vehicle parts are in need of repair or replacement.

The sensor data from before, during, and/or after a vehicle collision may also be collected and analyzed by one or more processors to determine which technologies or systems (such as autonomous vehicle technologies or systems, or advanced vehicle safety systems) operated correctly, or deficiently and contributed, at least in part, to the vehicle collision. The sensor data associated with a vehicle collision may be analyzed and/or transmitted to tow trucks or first responders, such as police or ambulances, such as to facilitate first responders with performing mitigating actions that mitigate further injuries due to the vehicle collision. The sensor data associated with the vehicle collision may also be analyzed (such as by using machine learning techniques) to determine the severity and amount of injuries, and/or if ambulances are required; determine fault for the vehicle collision; and/or the extent of vehicle damage (and also what portions of the vehicle need to be repaired, what the cost of vehicle repairs is predicted to be, what parts a repair shop or body shop should order or have in stock to perform repair work, etc.).

For instance, one parametric or trigger event may be the detection of a vehicle collision from processor analysis (such as by using machine learning techniques or other pattern recognition techniques) of vehicle sensor data and/or other vehicle data (including vehicle telematics data), as well as processor analysis of electronic device, smart infrastructure, and/or third-party data (again, for instance, such as by using machine learning techniques or applying other pattern recognition techniques on the data collected).

After a vehicle collision is detected, the vehicle sensor data and/or other data generated or collected may be analyzed by one or more remote or local processors for other parametric or trigger events (again, for instance, such as by using machine learning techniques or other pattern recognition techniques on the data collected). For instance, once a vehicle collision is detected, the severity of the vehicle collision may be determined, and based upon the level of the severity of the vehicle collision (e.g., as determined from machine learning models or pattern machine techniques), a number of actions may be implemented or otherwise started by one or more processors.

For example, based upon the level of the severity of the vehicle collision determined from processor analysis of the vehicle sensor data and/or other data collected (such as by using machine learning techniques or applying other pattern recognition techniques on the data collected), the actions implemented may include (1) automatically creating a smart contract associated with a blockchain, the smart contract being used to initiate, handle, and/or process an auto insurance claim; (2) automatically contacting a tow vehicle, such as transmitting the damaged vehicle's location and owner information to the tow vehicle or to a towing service; (3) automatically contacting emergency services, such as transmitting the damaged vehicle's location, the number of injured persons, and the severity of the injuries to a nearby ambulance, hospital, or police station; (4) automatically preparing an insurance claim for the vehicle owner's review, modification, and/or approval; (5) automatically identifying the necessary parts to repair the damaged vehicle, and transmitting information detailing the damaged vehicle and necessary parts to a repair shop server and/or scheduling an appointment with the repair shop to repair the damaged vehicle; (6) automatically identifying the necessary parts to repair the damaged vehicle, and locating the nearest repair shop with the needed parts on hand and having immediate availability to repair the vehicle, and/or transmit repair options, such as available repair shops and body shops and available times for the repair work to be performed, to the vehicle owner's mobile device for their review and selection of a repair shop or body shop/time; (7) automatically contacting a vehicle salvage company if the vehicle is deemed a total loss, such as transmitting the damaged vehicle's location to the salvage company's server such that the vehicle salvage company may send a vehicle to retrieve the damaged vehicle; (8) automatically contacting a taxi service or ride-share service if the vehicle is too damaged or dangerous to drive, such as transmitting the damaged vehicle's location to the taxi service or ride-share service's server such that the taxi service or ride-share service may send a taxi or ride-share to transport the operator and any passengers of the damaged vehicle to another location; (9) automatically reconstructing the vehicle collision and determining a percentage fault for the vehicle collision for each driver and/or autonomous vehicle involved in the collision; and/or (10) automatically initiating call to the insured or driver to see what, if any, immediate assistance is needed at the scene of the vehicle collision.

In some embodiments, all of the data collected (e.g., the vehicle sensor data, electronic device data, smart infrastructure data, and other data mentioned elsewhere herein) may be fed into one or more trained machine learning models (or software programs, algorithms, etc.) that are trained with historical data, such as historical data associated with past vehicle collisions, vehicle damage, damaged parts, personal injuries, etc. The trained machine learning models may each be trained to identify vehicle collisions, vehicle damage, type of vehicles, extent of vehicle damage, estimated cost of vehicle damage or estimated cost to repair the vehicle, total loss vehicles, and the other parametric events or actions mentioned elsewhere herein.

In one aspect, a computer-implemented method for generating one or more smart contracts for deployment onto a blockchain may be provided. The method may include (1) receiving, at one or more local or remote processors (and/or associated transceivers), vehicle sensor data and/or electronic device data generated from sensors mounted on or within (a) a vehicle, and/or (b) an electronic device located within the vehicle; (2) analyzing, by the one or more processors, the vehicle sensor data and/or electronic device data to determine a parametric event (for instance, such as by inputting the vehicle sensor data, electronic device data, and/or other data generated or collected into a trained machine learning model that is trained (by using historical vehicle collision data, for example) to identify or otherwise determine (i) a vehicle collision occurred, and/or (ii) a severity level of the vehicle collision (or otherwise apply another pattern recognition techniques on the vehicle sensor data received to identify a vehicle collision and/or severity thereof)), wherein the parametric event is associated with a corresponding severity of loss/vehicle damage or other vehicle-related event (the vehicle-related events may include contacting emergency services, tow vehicles, police, repair shops or body shops, taxi or ride-share services, and/or insurance providers; generating or initiating an insurance claim; generating one or more smart contracts; determining the extent vehicle damage; identifying and/or ordering parts necessary for vehicle repair; determining fault for the vehicle collision; and/or other vehicle-related events discussed elsewhere herein); (3) generating, by the one or more processors and for the parametric event, a corresponding smart contract that is configured to (i) receive a transaction from a computing device, and/or (ii) automatically execute on the blockchain when the transaction and/or vehicle sensor data and/or electronic device data indicates that the parametric event corresponding to the smart contract has occurred; and/or (4) deploying, by the one or more processors, the smart contract at a particular address on the blockchain. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

For instance, generating the smart contract may include generating the smart contract to define the parametric event as any one of (i) theft involving a vehicle; (ii) a collision involving the vehicle; or (iii) total loss of the vehicle. The transaction may include vehicle sensor data and/or electronic device data generated from sensors mounted on or within the vehicle, and/or from sensors mounted on or within an electronic device, such as a mobile device, smart glasses, augmented reality glasses, or virtual or extended reality headsets or glasses.

Generating the smart contract may include generating the smart contract to define an action including any one of: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and/or (vii) communicating with a vehicle salvage entity.

The method may further include (i) receiving, at one or more processors, supplemental data generated from one or more sources; and (ii) analyzing, by the one or more processors, the supplemental data to determine, confirm, or verify the parametric event. For instance, the parametric event may be determined from initial vehicle sensor data collected from vehicle-mounted sensors and/or an electronic device, and the parametric event may be confirmed from processor analysis from supplemental data, such as data from other vehicles, electronic devices of other people or third parties, drones, and/or smart infrastructure, for instance. The method may also include updating the smart contract based upon analyzing the supplemental data.

Additionally or alternatively, the sources of supplemental data may include any one or more of (i) smart infrastructure sensors; (ii) an environmental conditions sensor; (iii) an electronic device located in the vehicle; (iv) a camera located in an area in which the vehicle is located; and/or (v) a third-party server.

In another aspect, a computer system for generating one or more smart contracts for deployment onto a blockchain may be provided. The computer system may include (i) one or more local or remote processors, transceivers, servers, and/or sensors; and (ii) a non transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: (1) receive vehicle sensor data and/or electronic device data generated from sensors mounted on or within (a) a vehicle, and/or (b) an electronic device located within the vehicle; (2) analyze the vehicle sensor data and/or electronic device data to determine a parametric event, wherein the parametric event is associated with a corresponding severity of loss (or severity of vehicle damage) or other vehicle-related event; (3) generate, for the parametric event, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction received from a computing device, and/or the vehicle sensor data and/or electronic device data indicates that the parametric event corresponding to the smart contract has occurred; and/or (4) deploy the smart contract at a particular address on the blockchain. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

For instance, analyzing the vehicle sensor data and/or electronic device data to determine a parametric event may include inputting the vehicle sensor data, electronic device data, and/or other data received, collected or generated into a trained machine learning program that is trained to identify (i) vehicle collisions; (ii) severity of the vehicle collision; (iii) extent of vehicle damage; (iv) severity of personal injuries; (v) damaged vehicle parts that will need to be repaired or replaced; (vi) if emergency services are needed; (vii) if a tow vehicle is needed; (viii) if a taxi or ride-share is needed; (ix) if repair shop or body shop work is needed; (x) causes of the vehicle collision; and/or (xi) other vehicle-related events, corrective actions, or other actions mentioned elsewhere herein.

In another aspect, a computer-implemented method for generating one or more smart contracts for deployment onto a blockchain may be provided. The method may include (1) receiving, at one or more processors, vehicle sensor data and/or electronic device data generated from sensors mounted on or within (a) a vehicle, and/or (b) an electronic device located within the vehicle; (2) determining a parametric event associated with a vehicle collision or severity thereof from analysis of the vehicle sensor data and/or electronic device data by inputting, by the one or more processors, the vehicle sensor data and/or electronic device data into a trained machine learning model that is trained to identify vehicle collisions, severity of vehicle damage, and/or other vehicle-related events; (3) generating, by the one or more processors and for the parametric event, a corresponding smart contract that is configured to (i) receive a transaction from a computing device, and/or (ii) automatically execute on the blockchain when the transaction, and/or the vehicle sensor data and/or electronic device data indicates that the parametric event (a) associated with the vehicle collision or severity thereof, and/or (b) corresponding to the smart contract has occurred; and/or (4) deploying, by the one or more processors, the smart contract at a particular address on the blockchain. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

In another aspect, a computer system for generating one or more smart contracts for deployment onto a blockchain may be provided. The computer system may include one or more local or remote processors; and a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: (1) receive vehicle sensor data and/or electronic device data generated from sensors mounted on or within (i) a vehicle, and/or (ii) an electronic device located within the vehicle; (2) determine a parametric event associated with a vehicle collision or severity thereof from analysis of the vehicle sensor data and/or electronic device data by inputting the vehicle sensor data and/or electronic device data into a trained machine learning model that is trained to identify a vehicle collision, a severity of the vehicle collision, and/or other vehicle-related event; (3) generate, for the parametric event, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction received from a computing device, and/or the vehicle sensor data and/or electronic device data indicates that the parametric event (a) associated with the vehicle collision or severity thereof, and/or (b) corresponding to the smart contract has occurred; and/or (4) deploy the smart contract at a particular address on the blockchain. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for generating one or more smart contracts for deployment onto a blockchain may be provided. The method may include (1) receiving, at one or more local or remote processors, vehicle sensor data and/or electronic device data generated from sensors mounted on or within (a) a vehicle, and/or (b) an electronic device located within the vehicle; (2) determining a parametric event associated with a vehicle collision or severity thereof from analysis of the vehicle sensor data and/or electronic device data by inputting, by the one or more processors, the vehicle sensor data and/or electronic device data into a trained machine learning model that is trained to identify vehicle collisions, severity of vehicle damage, and/or other vehicle-related events or factors; (3) generating, by the one or more processors and for the parametric event, a corresponding smart contract that is configured to (i) receive a transaction and/or other data (such as the vehicle sensor and electronic device data) from one or more computing devices, and/or (ii) automatically execute on the blockchain; and/or (4) deploying, by the one or more processors, the smart contract at a particular address on the blockchain. The trained machine learning model may be trained using historical vehicle collision data, including telematics data associated with past vehicle collisions. The method may include additional, less, or alternate functionality, including that mentioned elsewhere herein.

For instance, the trained machine learning model may be trained to identify vehicle-related events or factors. The vehicle-related events or factors may include identifying one or more of: (i) a vehicle collision has occurred; (ii) an amount of vehicle damage; (iii) an estimated severity of the vehicle collision; (iv) an estimated severity of personal injuries; (v) an estimated cost to repair the vehicle or vehicle parts; (vi) an estimated cost to replace the vehicle or vehicle parts; (vii) that a tow vehicle is needed to tow a damaged vehicle; (viii) that a taxi or ride-share is needed to transport the operator and/or passengers of the damaged vehicle; (ix) that an ambulance is needed at the scene of the vehicle collision; (x) parts needed to repair the damaged vehicle; (xi) a nearby repair shop and/or body shop with the parts and expertise necessary to repair the vehicle; and/or (xii) other vehicle-related events or factors discussed elsewhere herein.

Additionally or alternatively, the trained machine learning model may identify one or more of the following vehicle-related events or factors as the parametric event from the vehicle sensor data and/or electronic device data input: (i) a vehicle collision has occurred; (ii) an amount of vehicle damage; (iii) an estimated severity of the vehicle collision; (iv) an estimated severity of personal injuries; (v) an estimated cost to repair the vehicle or vehicle parts; (vi) an estimated cost to replace the vehicle or vehicle parts; (vii) that a tow vehicle is needed to tow a damaged vehicle; (viii) that a taxi or ride-share service is needed to transport the operator and/or passengers of the damaged vehicle; (ix) that an ambulance is needed at the scene of the vehicle collision; (x) parts needed to repair the damaged vehicle; (xi) a nearby repair shop and/or body shop with the parts and expertise necessary to repair the vehicle; and/or (xii) other vehicle-related events or factors discussed elsewhere herein.

In another aspect, a computer system for generating one or more smart contracts for deployment onto a blockchain may be provided. The computer system may include one or more local or remote processors; and a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: (1) receive vehicle sensor data and/or electronic device data generated from sensors mounted on or within (i) a vehicle, and/or (ii) an electronic device located within the vehicle; (2) determine a parametric event associated with a vehicle collision or severity thereof from analysis of the vehicle sensor data and/or electronic device data by inputting the vehicle sensor data and/or electronic device data into a trained machine learning model that is trained to identify a vehicle collision, a severity of the vehicle collision, and/or other vehicle-related events or factors; (3) generate, for the parametric event, a corresponding smart contract that is configured to automatically execute on the blockchain when a transaction or other data is received from one or more computing devices, and/or configured to receive or store the transaction or other data that is received from the one or more computing devices; and/or (4) deploy the smart contract at a particular address on the blockchain. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for providing a graphic user interface to facilitate the generation of one or more smart contracts for deployment onto a blockchain may be provided. The method may include: (1) receiving, by one or more processors, vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) comparing, by the one or more processors, the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: (A) the parametric event data was generated from an analysis of the vehicle sensor data, (B) the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred; (3) automatically executing, by the one or more processors in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and (4) transmitting, by the one or more processors, the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.

Additionally or alternatively to the foregoing method, the method may include: receiving, by the one or more processors from the client device, an indication that a user interacted with the one or more graphic user interfaces (GUIs); receiving, from the client device, instructions to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity; and recording, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing method, the notification may be configured to cause the one or more graphic user interfaces (GUIs) to enable the client device to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity. The method may include receiving, from the client device; a first indication that the action was performed; and recording, to the smart contract; a second indication that the action was performed.

Additionally or alternatively to the foregoing method, the generating the notification may include: associating, by the one or more processors, the notification with a timer that measures an amount of time that has been elapsed since the transmission of the notification; detecting, by the one or more processors, that the timer reached a threshold amount of time without detecting a user interaction with the one or more graphic user interfaces (GUIs); performing, by the one or more processors, an action in response to the detection, wherein performing the action comprises: performing, by the one or more processors, an action selected of the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity, and recording, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing method, the parametric event may include any one of (i) theft involving a vehicle; (ii) a collision involving the vehicle; or (iii) total loss of the vehicle.

In another aspect, a computer system for providing a graphic user interface to facilitate the generation of a plurality of smart contracts for deployment onto a blockchain, the computer system may be provided. The computer system may include one or more processors; and a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: (1) receive vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) compare the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: (A) the parametric event data was generated from an analysis of the vehicle sensor data, (B) the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred; (3) automatically execute, in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and (4) transmitting the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.

Additionally or alternatively to the foregoing system, the instructions may further cause the system to: receive, from the client device, an indication that a user interacted with the one or more graphic user interfaces (GUIs); receive, from the client device, instructions to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity; and record, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing system, the notification may be configured to cause the one or more graphic user interfaces (GUIs) to enable the client device to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity. The instructions may further cause the system to: receive, from the client device, a first indication that the action was performed; and record, to the smart contract, a second indication that the action was performed.

Additionally or alternatively to the foregoing system, the generating the notification may further cause the system to: associate the notification with a timer that measures an amount of time that has been elapsed since the transmission of the notification; detect that the timer reached a threshold amount of time without detecting a user interaction with the one or more graphic user interfaces (GUIs); perform an action in response to the detection, wherein the action is selected of the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity; and record, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing system, the parametric event may include any one of: (i) theft involving a vehicle; (ii) a collision involving the vehicle; or (iii) total loss of the vehicle.

In another aspect, a tangible, a non-transitory computer-readable medium may store executable instructions for providing a graphic user interface to facilitate the generation of a plurality of smart contracts for deployment onto a blockchain. The executable instructions, when executed, may cause one or more processors to: (1) receive vehicle sensor data generated from sensors mounted on or within one or more vehicles; (2) compare the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: (A) the parametric event data was generated from an analysis of the vehicle sensor data, (B) the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred; (3) automatically execute, in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and (4) transmitting the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.

Additionally or alternatively to the foregoing executable instructions, the executable instructions may further cause the one or more processors to: receive, from the client device, an indication that a user interacted with the one or more graphic user interfaces (GUIs); receive, from the client device, instructions to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity; and record, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing executable instructions, the notification may be configured to cause the one or more graphic user interfaces (GUIs) to enable the client device to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity. The executable instructions may further cause the one or more processors to: receive, from the client device, a first indication that the action was performed; and record, to the smart contract, a second indication that the action was performed.

Additionally or alternatively to the foregoing executable instructions, the generating the notification may further cause the one or more processors to: associate the notification with a timer that measures an amount of time that has been elapsed since the transmission of the notification; detect that the timer reached a threshold amount of time without detecting a user interaction with the one or more graphic user interfaces (GUIs); perform an action in response to the detection, wherein the action is selected of the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity; and record, to the smart contract, an indication that the action was performed.

Additionally or alternatively to the foregoing executable instructions, the parametric event may include any one of: (i) theft involving a vehicle; (ii) a collision involving the vehicle; or (iii) total loss of the vehicle.

Exemplary Machine Learning

The present embodiments may involve the use of cognitive computing and/or machine learning techniques or algorithms, and/or other modeling techniques. For instance, vehicle sensor data, electronic device data, smart infrastructure, and other types of data generated or collected may be input into machine learning programs that are trained to (i) identify a vehicle collision or crash; (ii) severity of vehicle damage; (iii) damaged vehicle sensors, parts, and/or components; (iv) severity of potential injuries; and/or (v) other vehicle-related events or factors discussed elsewhere herein.

In certain embodiments, the cognitive computing and/or predictive modeling techniques discussed herein may heuristic engine and algorithms, and/or machine learning, cognitive learning, deep learning, combined learning, and/or pattern recognition techniques. For instance, a processor or a processing element may be trained using supervised or unsupervised machine learning, and the machine learning program may employ a neural network, which may be a convolutional neural network, a deep learning neural network, or a combined learning module or program that learns in two or more fields or areas of interest. Machine learning may involve identifying and recognizing patterns in existing data in order to facilitate making predictions for subsequent data. Models may be created based upon example inputs in order to make valid and reliable predictions for novel inputs.

Additionally or alternatively, the machine learning programs may be trained by inputting sample data sets or certain data into the programs, such as vehicle data or images, vehicle collision data or images, and/or de-personalized customer data, image, mobile device, insurer database, and/or third-party database data. The machine learning programs may utilize deep learning algorithms that may be primarily focused on pattern recognition, and may be trained after processing multiple examples. The machine learning programs may include Bayesian program learning (BPL), voice recognition and synthesis, image or object recognition, optical character recognition, and/or natural language processing—either individually or in combination. The machine learning programs may also include natural language processing, semantic analysis, automatic reasoning, and/or machine learning.

In supervised machine learning, a processing element may be provided with example inputs and their associated outputs, and may seek to discover a general rule that maps inputs to outputs, so that when subsequent novel inputs are provided the processing element may, based upon the discovered rule, accurately predict the correct output. In unsupervised machine learning, the processing element may be required to find its own structure in unlabeled example inputs. In one embodiment, machine learning techniques may be used to identify vehicle damage and customize vehicle retrieval and/or repair for individual customers.

Additional Considerations

As noted herein, after collection of the information regarding a vehicle by one or more nodes within a communication network, a transaction (and/or new block) including the vehicle information collected may be broadcast to the blockchain, and/or a new block verified and then added to the blockchain to reflect an updated state of the vehicle. For the computer-implemented methods discussed herein, in some embodiments, a transaction and/or new block may be generated and then broadcast to the blockchain network for verification once vehicle sensor data, and/or other data, have been generated and/or collected by one or more nodes within the communication network. As such, tracking the status of a vehicle may be more reliable and/or fraud-resistant as each node may include a proof-of-identity in its transaction modifying the state of the vehicle; and/or vehicle-related blocks or blockchain.

Further, with the computer-implemented methods discussed herein, network participants may function as full nodes that validate and/or generate new blocks and transactions, and/or compile transactions into blocks that are then added to the network. However, not all participants need be nodes that compile transactions into blocks, and/or validate transactions and blocks received from other network participants as some network participants may wish to rely on other network nodes to provide computer processing and/or storage services that enable usage of the system or blockchain.

In some scenarios, the blockchain may have public interfaces that allow visibility into the data. In certain embodiments, a private blockchain interface may also be used by auto manufacturers, law enforcement, insurers, and regulatory agencies.

An element of smart contracts may also be enabled in the system. Depending on the sequence of events in the blockchain, terms of the smart contract may be executed immediately.

In some embodiments, operators may opt-in to a rewards, loyalty, discount, or other program. The operator may allow a remote server, such as server 115, to collect vehicle sensor data, mobile device data, and other types of data discussed herein. With operator permission or affirmative consent, the data collected may be analyzed to provide certain benefits to operators, as discussed herein.

In some embodiments, the following method and/or system may occur: vehicle sensors may trigger to detect a parametric event; the trigger may send data to the insurer entity's servers indicating that a parametric event occurred; the insurer entity may then attempt to contact the operator of the vehicle directly (e.g., a phone call to the operator) and/or indirectly through an automated system (e.g., the insurer entity's servers send a push notification to an application on the operator's smart device) requesting for confirmation of the collision as well as any other serves to be performed on the operator's behalf (e.g., requesting dispatch of EMTs, police, tow trucks, taxi or ride-share services, vehicle salvage vendors or requesting to contact repair shops or body shops; etc.); receiving the operator's responses; and contacting the selected services and entities in response to the operator's responses. In some embodiments, a timing mechanism might be deployed in the event the operator is unable to respond via the application (e.g., the operator is unconscious or the operator's mobile phone received too much damage to function). When the timing mechanism is triggered, the insurer entity's servers will contact each entity from a set of default settings (for example, a default could be setting the system to call for the dispatch of EMTs, police, and a tow truck as well as a repair shop, but not setting the system to call for the dispatch of a taxi or rideshare or a vehicle salvage vendor or to call a body shop). In some embodiments, the insurer entity may monitor the status of each of the entities contact (e.g., ensuring the ride-share service reached the operator, checking on the status of a repair at a body shop, etc.).

Although the text herein sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the invention is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. One could implement numerous alternate embodiments, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Additionally, some embodiments are described herein as including logic or a number of routines, subroutines, applications, or instructions. These may constitute either software (code embodied on a non-transitory, tangible machine-readable medium) or hardware. In hardware, the routines, etc., are tangible units capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a module that operates to perform certain operations as described herein.

In various embodiments, a module may be implemented mechanically or electronically. Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which modules are temporarily configured (e.g., programmed), each of the modules need not be configured or instantiated at any one instance in time. For example, where the modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different modules at different times. Software may accordingly configure a processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

Modules can provide information to, and receive information from, other modules, Accordingly, the described modules may be regarded as being communicatively coupled. Where multiple of such modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices, and may operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

Unless specifically stated otherwise, discussions herein using words such as “receiving,” “analyzing,” “generating,” “creating,” “storing,” “deploying,” “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information. Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

As used herein any reference to “some embodiments” means that a particular element, feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment. The appearances of the phrase “some embodiments” in various places in the specification are not necessarily all referring to the same embodiment. In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description, and the claims that follow, should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or an other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

The patent claims at the end of this patent application are not intended to be construed under 35 U.S.C. § 112(f) unless traditional means-plus-function language is expressly recited, such as “means for” or “step for” language being explicitly recited in the claim(s).

This detailed description is to be construed as exemplary only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. One could implement numerous alternate embodiments, using either current technology or technology developed after the filing date of this application, Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for system and a method for assigning mobile device data to a vehicle through the disclosed principles herein.

Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those, skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

The particular features, structures, or characteristics of any specific embodiment may be combined in any suitable manner and in any suitable combination with one or more other embodiments, including the use of selected features without corresponding use of other features. In addition, many modifications may be made to adapt a particular application, situation or material to the essential scope and spirit of the present invention. It is to be understood that other variations and modifications of the embodiments of the present invention described and illustrated herein are possible in light of the teachings herein and are to be considered part of the spirit and scope of the present invention.

While the preferred embodiments of the invention have been described, it should be understood that the invention is not so limited and modifications may be made without departing from the invention. The scope of the invention is defined by the appended claims, and all devices that come within the meaning of the claims, either literally or by equivalence, are intended to be embraced therein. It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.

Claims

1. A computer-implemented method for providing a graphic user interface to facilitate the generation of one or more smart contracts for deployment onto a blockchain, the method comprising:

receiving, by one or more processors, vehicle sensor data generated from sensors mounted on or within one or more vehicles;

comparing, by the one or more processors, the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: the parametric event data was generated from an analysis of the vehicle sensor data, the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred;

automatically executing, by the one or more processors in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and

transmitting, by the one or more processors, the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.

2. The computer-implemented method of claim 1, further comprising:

receiving, by the one or more processors from the client device, an indication that a user interacted with the one or more graphic user interfaces (GUIs).

3. The computer-implemented method of claim 1, further comprising:

receiving, from the client device, instructions to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity.

4. The computer-implemented method of claim 3, further comprising:

recording, to the smart contract, an indication that the action was performed.

5. The computer-implemented method of claim 1, wherein the notification is configured to cause the one or more graphic user interfaces (GUIs) to enable the client device to perform an action selected from the group comprising:

(i) initiating an instantaneous notice of loss (INOL);

(ii) communicating with an insurer entity;

(iii) communicating with an emergency response entity;

(iv) communicating with a towing service entity;

(v) communicating with a taxi or ride-share service entity;

(vi) communicating with a vehicle repair service entity; and

(vii) communicating with a vehicle salvage entity.

6. The computer-implemented method of claim 5, further comprising:

receiving, from the client device, a first indication that the action was performed; and

recording, to the smart contract, a second indication that the action was performed.

7. The computer-implemented method of claim 1, wherein generating the notification comprises:

associating, by the one or more processors, the notification with a timer that measures an amount of time that has been elapsed since the transmission of the notification;

detecting, by the one or more processors, that the timer reached a threshold amount of time without detecting a user interaction with the one or more graphic user interfaces (GUIs); and

performing, by the one or more processors, an action in response to the detection.

8. The computer-implemented method of claim 1, wherein performing the action comprises:

performing, by the one or more processors, an action selected of the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity.

9. The computer-implemented method of claim 8, further comprising:

recording, to the smart contract, an indication that the action was performed.

10. The computer-implemented method of claim 1, wherein the parametric event includes any one of:

(i) theft involving a vehicle;

(ii) a collision involving the vehicle; or

(iii) total loss of the vehicle.

11. A computer system for providing a graphic user interface to facilitate the generation of one or more smart contracts for deployment onto a blockchain, the computer system comprising:

one or more processors;

a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to: receive vehicle sensor data generated from sensors mounted on or within one or more vehicles; compare the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: the parametric event data was generated from an analysis of the vehicle sensor data, the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred; automatically execute, in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and transmit the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.

12. The computer system of claim 11, wherein the executable instructions, when executed by the one or more processors, cause the computer system to:

receive, from the client device, an indication that a user interacted with the one or more graphic user interfaces (GUIs).

13. The computer system of claim 11, wherein the executable instructions, when executed by the one or more processors, cause the computer system to:

receive, from the client device, instructions to perform an action selected from the group comprising: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; and (vii) communicating with a vehicle salvage entity.

14. The computer system of claim 13, wherein the executable instructions, when executed by the one or more processors, cause the computer system to:

record, to the smart contract, an indication that the action was performed.

15. The computer system of claim 11, wherein the notification is configured to cause the one or more graphic user interfaces (GUIs) to enable the client device to perform an action selected from the group comprising:

(i) initiating an instantaneous notice of loss (INOL);

(ii) communicating with an insurer entity;

(iii) communicating with an emergency response entity;

(iv) communicating with a towing service entity;

(v) communicating with a taxi or ride-share service entity;

(vi) communicating with a vehicle repair service entity; and

(vii) communicating with a vehicle salvage entity.

16. The computer system of claim 15, wherein the executable instructions, when executed by the one or more processors, cause the computer system to:

receiving, from the client device, a first indication that the action was performed; and

recording, to the smart contract, a second indication that the action was performed.

17. The computer system of claim 11, wherein the generation of the notification further cause the computer system to:

associate the notification with a tinier that measures an amount of time that has been elapsed since the transmission of the notification;

detect that the timer reached a threshold amount of time without detecting a user interaction with the one or more graphic user interfaces (GUIs); and

perform an action in response to the detection.

18. The computer system of claim 17, wherein the action is selected of the group comprising:

(i) initiating an instantaneous notice of loss (INOL);

(ii) communicating with an insurer entity;

(iii) communicating with an emergency response entity;

(iv) communicating with a towing service entity;

(v) communicating with a taxi or ride-share service entity;

(vi) communicating with a vehicle repair service entity; and

(vii) communicating with a vehicle salvage entity.

19. The computer system of claim 18, wherein the executable instructions, when executed by the one or more processors, cause the computer system to:

record, to the smart contract, an indication that the action was performed.

20. A tangible, non-transitory computer-readable medium storing executable instructions for generating one or more smart contracts for deployment onto a blockchain, that when executed by one or more processors of a computer system, cause the computer system to:

receive vehicle sensor data generated from sensors mounted on or within one or more vehicles;

compare the vehicle sensor data to parametric event data stored on a smart contract deployed on the blockchain, wherein: the parametric event data was generated from an analysis of the vehicle sensor data, the parametric event data is indicative of a severity of loss, and the smart contract was configured to (i) receive a transaction from a computing device and (ii) automatically execute on the blockchain when the transaction indicated that a parametric event corresponding to the smart contract has occurred;

automatically execute, in response to comparing the vehicle sensor data to the parametric event, an action directed by the smart contract, wherein the action includes generating a notification; and

transmit the notification to a client device, wherein the notification causes the client device to display one or more graphic user interfaces (GUIs) based upon the severity of loss.