In another aspect, to further reduce the size of the blocks, the systems and methods disclosed may reduce duplicate and/or correlated transaction generated by one or more vehicles. To this end, when one or more autonomous vehicles collide with one another, the applications monitoring the operation of the respective autonomous vehicles may exchange operational data for a period of time leading up to the collision. Based upon the operational data respectively corresponding to each of the one or more vehicles, one of the applications may generate a single transaction that includes the condition of each of the one or more autonomous vehicles involved in the collision. In some embodiments, this transaction may include decision condition data indicating a relative fault for each of the one or more autonomous vehicles based upon the analysis of the respectively corresponding sets of operational data. Accordingly, the single transaction may be routed to a plurality of smart contracts associated with any one of the one or more autonomous vehicles involved in the collision.

Exemplary Environments for Maintaining Distributed Ledger

FIG. 1A depicts an exemplary environment 100 maintaining a distributed ledged for the enforcement of a plurality of smart contracts. Although FIG. 1 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 environment 100 may include a plurality of autonomous vehicles 105a-f. As it is generally used herein, the term “autonomous vehicle” refers to any vehicle with autonomous (or even semi-autonomous) capabilities. Thus, “autonomous vehicle” is not limited to fully autonomous vehicles (SAE level 5) and includes even partially automated vehicles (SAE level 2). It should be appreciated that in fully autonomous vehicles, an “operator” may include a person that provides navigational input to the autonomous vehicle and/or a person located within the vehicle at a location wherein the person is capable of engaging manual control should the need and/or desire arise. As illustrated on the autonomous vehicle 105a, the autonomous vehicle 105a may include one or more sensors 101a-b that monitor the operational status of the autonomous vehicle 105a. The sensors 101 may include, for example, a pressure sensor, a gyroscope, an accelerometer, an odometer, a vibration sensor, a microphone, an image sensor, a temperature sensor, and/or a radar or LIDAR sensor. Some of the sensors 101 may be included in the autonomous vehicle 105a by a manufacturer of the vehicle 105a and others of the sensors 101 may be retrofitted onto the vehicle 105a at some point after manufacture. For example, a fleet manager may retrofit the vehicle 105a with a particular type of sensor that relates to a smart contact frequently generated by the fleet manager.

The autonomous vehicle 105a may further include an electronic device 103 configured to interpret operational data generated by the sensors 101. Although FIG. 1A illustrates the electronic device 103 as a processing unit of the vehicle 105a interconnected to the sensors 101 via a communication bus of the vehicle 105a, in other embodiments the electronic device 103 may be a personal electronic device (e.g., a mobile phone, a tablet, a laptop computer, a smart watch, smart glasses, 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 personal electronic device may receive the operational 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). Additional information describing the operation of autonomous vehicles may be found in co-owned U.S. patent application Ser. No. 14/713,249 entitled “AUTONOMOUS VEHICLE OPERATION FEATURE MONITORING AND EVALUATION OF EFFECTIVENESS,” the entire disclosure of which is hereby incorporated by reference.

Regardless of the particular type of electronic device, the electronic device 103 may include an application configured to analyze the operational data generated by the sensors 101. More particularly, the application may be configured to analyze the operational data to detect a plurality of conditions (e.g., trigger conditions or decision conditions) associated with the vehicle 105a. Periodically and/or in response to a change in condition, the application may generate a transaction that incorporates one or more of the detected conditions. According to certain aspects, the transaction may include indications of the one or more conditions, an identifier of the vehicle 105a and/or the operator of the vehicle 105a, a timestamp, an indication of a priority, and/or a portion of the operational data upon which the one or more detected conditions may be based. The electronic device 103 may transmit generated transactions via an antenna 104. Although FIG. 1 illustrates the antenna 104 as being separate from the electronic device 103, it should be appreciated that for some types of electronic devices, such as a mobile phone, the antenna 104 may be included in the electronic device 103 itself.

According to certain aspects, the electronic device 103 may also be configured to receive control signals from a command center and/or other remote computing device (not depicted) to remotely control the operation of the vehicle 105a. In some scenarios, the control signals are indicative of a remote user actively controlling the vehicle 105a (e.g., the remote user is piloting the vehicle 105a as a drone operator would pilot a drone). In other scenarios, the control signals are indicative of particular actions the autonomous systems of the vehicle 105a should undertake. For example, an ambulance may broadcast a control signal to nearby autonomous vehicles to cause the autonomous vehicles to yield to the ambulance and/or pull over to the side of the road.

The plurality of autonomous vehicles 105a-f may be configured to communicate with an enforcement server 115 via one or more communication networks 110. The networks 110 may facilitate any data communication between the plurality of autonomous vehicles 105a-f and an enforcement server 115 via any standard or technology (e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS, EV-DO, UWB, IEEE 802 including Ethernet, WiMAX, and/or others). According to present embodiments, the plurality of autonomous vehicles 105a-f transmit generated transactions to the enforcement server 115 via the networks 110. In some embodiments, the networks 110 may include a mesh or ad hoc network wherein a portion a of the plurality of autonomous vehicles 105a-f function as nodes of the mesh or ad hoc network. Thus, in some embodiments, a transaction generated at the autonomous vehicle 105a may be routed to, for example, the autonomous vehicle 105c and the autonomous vehicle 105f prior to the enforcement server 115. It should be appreciated that standard or technology used to communicate between and among the plurality of autonomous vehicles 105a-f is not necessarily the same standard or technology utilized to communicate between one of the plurality of autonomous vehicles 105a-f and the enforcement server 115. In addition to the transaction, in some embodiments, one or more of the plurality of autonomous vehicles 105 may exchange operational data over the mesh or ad hoc network in response to the one or more of the plurality of autonomous vehicles being involved in a collision.

According to certain aspects, the enforcement server 115 may be configured to compile new blocks to add to a blockchain and to enforce a plurality of smart contracts. Although FIG. 1A illustrates a single enforcement server 115, it should be appreciated that in some embodiments, the enforcement server 115 may be a plurality of interconnected servers, for example, in a cloud computing environment. In one aspect, the enforcement server 115 may periodically compile a plurality of transactions received from the plurality of autonomous vehicles 105. The enforcement server 115 may also aperiodically compile a plurality of transactions received from the plurality of autonomous vehicles 105 in response to receiving an urgent transaction. After the new block is compiled, the enforcement server 115 may transmit the new block to the plurality of autonomous vehicles 105 and/or dedicated validation entities 135 to generate a solution to incorporate the block into blockchain and/or to form a consensus on the solution. Although FIG. 1 illustrates that the dedicated validation entities as being separate from the enforcement server 115, it should be appreciated that the enforcement server 115 may itself include a module dedicated to generating a solution to the cryptographic puzzle and/or forming a consensus on the solution.

In another aspect, the enforcement server 115 may analyze a smart contract database (not depicted) to determine whether any transactions compiled into the new block are associated with a smart contract. To this end, the enforcement server 115 may extract from each transaction one or more indications identifying an autonomous vehicle and/or an operator of the autonomous vehicle and route the transaction to a respectively corresponding one or more smart contracts that govern the identified autonomous vehicle and/or operator. In one scenario, the transaction may include a plurality of data relating to the status of a trigger condition and/or one or more decision conditions. In response, the particular smart contract may direct the enforcement server 115 to perform an action to enforce the particular smart contract. For example, the action may be to generate and/or file an insurance claim. Depending on the action, the enforcement server 115 may execute one or more third party applications 125 to carry out the action. In the insurance claim example, a third party insurer may include an application configured to generate and/or process the insurance claim based upon data included in the transaction. As another example, an emergency response entity (e.g., an EMT) may include an application in the third party applications 125 to dispatch a responder to a location of an autonomous vehicle.

In some scenarios, a decision condition requires the analysis of data not generated at an autonomous vehicle. As an example, a decision condition may be related to a weather condition at the time liability occurred (e.g., the presence of rain when the liability was incurred). Accordingly, the smart contract may interact with one or more third party applications 125 to retrieve this additional decision condition data. In this example, one of the third party applications 125 may be a weather service application capable of outputting weather conditions at the location of the autonomous vehicle at the time indicated by the timestamp of the transaction. In one aspect, the smart contract may modify the transaction to include the additional condition data (assuming the transaction has not been compiled into a block) and/or generate a new transaction that indicates the additional condition data. The exemplary environment 100 may include additional, fewer, or alternate equipment or components, including those discussed elsewhere herein. Further, in some embodiments, the actions described as being performed by the enforcement server 115 may additionally or alternatively be performed at one or more of the autonomous vehicles 105a-f.

Turning now to FIG. 1B, depicted is another exemplary environment 150 for maintaining a distributed ledger associated with autonomous vehicles. Although FIG. 1B depicts certain entities, components, and devices, it should be appreciated that additional or alternate entities and components are envisioned.

As illustrated in FIG. 1B, the environment 150 may include a distributed ledger 145. The distributed ledger 145 may be maintained via a network of nodes, including one or more autonomous vehicles 105 and/or an enforcement server 115. The nodes may have access distributed ledger 145 and/or generate data included in the distributed ledger 145. As described above, the distributed ledger 145 may not be changed without first forming a consensus on the change. Accordingly, as depicted by FIG. 1B, the distributed ledger 145 may be considered separate from any individual node, even though the individual nodes may store local copies of the distributed ledger 145.

According to certain aspects, as described with respect to FIG. 1A, the autonomous vehicle 105 may include a plurality of sensors 101a-b, an electronic device 103, and/or an antenna 104. The autonomous vehicle 105 may communicate with the enforcement server 115 via the electronic device 103 and/or the antenna 104.

As illustrated, the enforcement sever 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 with the enforcement server 115. In one embodiment, the blockchain manager 117 may compile a plurality of transactions into a block, update the distributed ledger 145 to include a block, route transaction data to one or more smart contracts, and/or automatically enforce one or more smart contracts. According to certain aspects, an operator of the enforcement server may interact with a management interface 119 to control aspects of the distributed ledger 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 an aspect, the plurality of smart contracts associated with the distributed ledger 145 may be stored in a smart contracts database 130. Although FIG. 1B depicts the smart contract database 130 as a part of the enforcement sever 115, the smart contract database may be maintained within the distributed ledger 145.

According to certain aspects, one or more public devices 123 may access data stored at the enforcement server via a public interface 121. The public interface 121 may be a read only interface that prevents the one or more public devices 123 from writing transactions to the distributed ledger 145. To this end, the one or more public devices 123 may be used, for example, to view data maintained within the distributed ledger 145, to view the status of one or more smart contracts associated with the distributed ledger 145, compile statistics regarding data maintained in the distributed ledger, and so on.

Additionally or alternatively, one or more third party applications 125 may interact with the distributed ledger 145 via an API 127 of the enforcement server 115. The third party applications 125 may be associated with one or more entities associated with an autonomous vehicle. For example, the third party applications 125 may include an application to generate and/or file an insurance claim, send a repair request, send a tow request, contact an emergency service provider, and so on. It should be appreciated that although FIG. 1B depicts the third party applications 125 as separate from the enforcement sever 115, in some embodiments a portion of the third party applications 125 may be stored locally at the enforcement server 115. The exemplary environment 150 may include additional, fewer, or alternate equipment or components, including those discussed elsewhere herein. Further, in some embodiments, the actions described as being performed by the enforcement server 115 may additionally or alternatively be performed at one or more of the autonomous vehicles 105.

Exemplary Flow Diagrams for Maintaining Distributed Ledger

Turning now to FIG. 2A, illustrated is an exemplary flow diagram 200 associated with compiling a plurality of transactions into blocks. As illustrated, each transaction may include several components. A first component may include an identification of a vehicle and/or a driver associated with the transaction. The vehicle identification may be a VIN, an identifier assigned by a fleet operator, a license plate, or any other identifier that corresponds to a particular autonomous vehicle. The driver identification may be a name, a policy or account number, a username, or any other identifier that corresponds to a person operating the autonomous vehicle. Although the transaction illustrated by FIG. 2 only depicts a single vehicle or driver identification, it should be appreciated that some transactions may include an identification of a plurality of vehicles and/or drivers. For example, if multiple autonomous vehicles are involved in a collision, a single transaction may include a vehicle and/or driver identification for each autonomous vehicle involved in the collision. Further, each transaction may include a timestamp indicating a time the transaction was generated and/or a time the underlying data was measured.

Another component of each transaction may be a transaction information component. The transaction information may include a plurality of condition data that are analyzed by a smart contract associated with the vehicle and/or driver. In some aspects, the vehicle and/or driver identification and the timestamp may be viewed as a transaction header, whereas the transaction information may be viewed as the transaction payload. The transaction information may include an indication that a trigger condition occurred, an indication related to one or more decision conditions, and/or any underlying operational data generated by sensors within an autonomous vehicle that the condition indications are based upon. For example, the transaction information may include an indication that a liability inducing event occurred (e.g., a trigger condition) and/or an indication that the autonomous vehicle was operated in a manual operation mode (e.g., a decision condition).

According to illustrated embodiments, a plurality of transactions may be compiled into a block. In one scenario, a plurality of transactions generated by a plurality of autonomous vehicle 205a-z are compiled into a block 245a. For example, each of the plurality of autonomous vehicle may transmit transactions to an enforcement server (such as the enforcement server 115 as described with respect to FIG. 1) for compilation into the block 245a. In another example, an autonomous vehicle 205a compiles a plurality of transactions generated at the autonomous vehicle 205a into a block 245b that only includes transaction associated with the autonomous vehicle 205a. In this example, the autonomous vehicle 205a may transmit to the enforcement server the generated block 245b for distribution to a plurality of validation entities that attempt to solve a cryptographic puzzle based upon the header of the generated block 245b and/or form a consensus on said solution. The exemplary flow diagram 200 may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

Turning now to FIG. 2B, depicted is an example flow diagram 250 indicating the generation of transactions in response to an autonomous vehicle, such as the autonomous vehicle 105a as described with respect to FIG. 1A. The autonomous vehicle may be associated with a smart contract 230. In some embodiments, the smart contract 230 is stored within a distributed ledger and/or at an enforcement server. Although the smart contract 230 depicted by the flow diagram 250 is associated with assigning liability based upon autonomous or manual control of the autonomous vehicle, it is envisioned that other smart contracts may be associated with arrangements based upon the detection of other events.

The flow diagram 250 may begin at block 252 where an operator of the autonomous vehicle is manually operating the autonomous vehicle and no liability has been incurred. For example, the operator may have powered on the autonomous vehicle and began to drive towards a destination. An electronic device associated with the autonomous vehicle may generate a transaction to be included in a block 245c of the distributed ledger. The transaction information component of this transaction may include a flag that indicates that the autonomous vehicle is being operated manually (“Control: 0”) and/or a flag that indicates that the autonomous vehicle has not incurred liability (“Liability: 0”).

At block 254, the operator of the autonomous vehicle may have engaged autonomous control functionality associated with the autonomous vehicle. For example, the operator may have instructed the autonomous vehicle to automatically drive to the destination. In response, the electronic device may generate a transaction to be included in block 245d of the distributed ledger. The transaction information component of this transaction may include a flag that indicates that the autonomous vehicle is being operated autonomously (“Control: 1”) and/or a flag that indicates that the autonomous vehicle has not incurred liability (“Liability: 0”).

At block 256, the operator of the autonomous vehicle may have disengaged autonomous control functionality associated with the autonomous vehicle. For example, the operator may resume manual control by interacting with manual control (e.g., a steering wheel, brake pedal, etc.). In response, the electronic device may generate a transaction to be included in block 245e of the distributed ledger. The transaction information component of this transaction may include a flag that indicates that the autonomous vehicle is being operated manually (“Control: 0”) and/or a flag that indicates that the autonomous vehicle has not incurred liability (“Liability: 0”).

At block 258, the autonomous vehicle may have incurred liability. For example, the autonomous vehicle may have experienced a collision. In the illustrated scenario, the autonomous vehicle may have deployed an airbag in response to detecting the collision. According to aspects, the electronic device may generate a transaction to be included in block 245f of the distributed ledger. The transaction information component of this transaction may include a flag that indicates that the autonomous vehicle is being operated manually (“Control: 0”) and/or a flag that indicates that the autonomous vehicle has, in fact, incurred liability (“Liability: 1”).

At block 260, one or more actions associated with enforcing the smart contract may be performed. To this end, when transactions included in the block 245f are routed to the smart contract 230, the smart contract 230 may analyze the transaction generated at block 258; more particularly, the transaction information component of the transaction generated at block 258. Based on this transaction information, the smart contract 230 may determine one or more actions to enforce the smart contract 230. As an example, the smart contract 230 may cause the enforcement server to generate an insurance claim that assigns liability for damage incurred in the collision to the operator of the autonomous vehicle. It should be appreciated that although FIG. 2B depicts blocks 245c-f are depicted as separate blocks, in some scenarios, one or more of the blocks 245c-f may actually be the same block. For example, the events at blocks 254 and 256 may have occurred within the block compilation period associated with the distributed ledger. The exemplary environment 250 may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

For example, as described elsewhere herein, the autonomous vehicle may be operated remotely. Accordingly, the control state may include an indication that the autonomous vehicle is being remotely operated. In this example, when a liability-inducing event occurs, the smart contract 230 may cause the enforcement server to generate an insurance claim that assigns liability to an entity associated with a remote operator of the autonomous vehicle.

Exemplary Distributed Ledger Communication

Referring to FIG. 3, illustrated is an exemplary signal diagram 300 associated with maintaining a distributed ledger associated with a plurality of smart contracts. In particular, FIG. 3 may include a plurality of autonomous vehicles 305 (such as the plurality of autonomous vehicles 105a-f as described with respect to FIG. 1), an enforcement server 315 (such as the enforcement server 115 as described with respect to FIG. 1), dedicated validation entities 335 (such as the dedicated validation entities 135 as described with respect to FIG. 1), and/or a smart contracts database 330. Autonomous vehicles within the plurality of autonomous vehicles may be associated with an electronic device (such as the electronic device 103 as described with respect to FIG. 1) executing an application. It should be appreciated the electronic device may be any electronic device (e.g., an on-board computer, a smartphone, a desktop computer, a laptop, a tablet, phablet, netbook, notebook, a smart watch, smart glasses, smart contact lenses, wearable electronics device, other mobile device, etc.).

The signal diagram 300 may begin when one or more of the plurality of autonomous vehicles 305 detects (320) a change in a condition. In one scenario, the change in condition is associated with a decision condition of one or more smart contracts governing the autonomous vehicle. For example, the decision condition may relate to whether the vehicle is being operated in a manual or an autonomous mode as determined, for example, by detecting the presence of microvibrations in a steering wheel and/or a control signal communicated over a communication bus of the autonomous vehicle. In another example, the decision condition may relate to a distance traversed by the autonomous vehicle as determined, for example, by an odometer sensor. In another scenario, the change in condition is associated with a trigger condition of one or more smart contracts governing the autonomous vehicle. For example, the change in condition may be the autonomous vehicle incurring liability, such as a liability in response to damage to the autonomous vehicle. In this example, the trigger condition may be detected by detecting a deployment of an airbag, detecting an output from a front or side impact sensor, and/or detecting a malfunction or other abnormal condition for one or more sensors of the autonomous vehicle.

The one or more autonomous vehicles of the plurality of autonomous vehicles 305 may then generate (324) a transaction that indicates the detected change in condition. As described above with respect to the environment 200, the transaction may include an indication of an identity of one or more autonomous vehicles and/or operators thereof, a timestamp and/or a plurality of transaction data. According to certain aspects, when multiple autonomous vehicles of the plurality of autonomous vehicles 305 are involved in a collision, the involved autonomous vehicles may communicate with one another to generate a single transaction. To generate this single transaction, the involved autonomous vehicles may exchange operating data describing a time period straddling the collision to generate a transaction that indicates relative fault for the collision and/or one more amounts of liability incurred. In some further aspects, the autonomous vehicles may exchange diagnostic data to determine which autonomous vehicle should generate the transaction. For example, an antenna of a particular vehicle may have been damaged in the collision causing data transmissions therefrom to be susceptible to additional noise and/or data loss. Accordingly, a different autonomous vehicle involved in the collision may be assigned the task of generating the transaction.

According to other aspects, as part of generating the transaction, the autonomous vehicle may determine a priority of the transaction. To this end, not every transaction may have the same priority. For example, a transaction may indicate that significant damage occurred to a vehicle, rendering the vehicle inoperable and/or a passenger in a dangerous environment (e.g., the transaction indicates there is a leak in the gas tank). Accordingly, the autonomous vehicle may assign this transaction an urgent priority. On the other hand, in one example, for a transaction that indicates a shift between manual and autonomous control, or a transaction that indicates relatively minor damage (e.g., the autonomous vehicle experienced light damage to a bumper), the autonomous vehicle may assign the transaction a normal or other non-urgent priority.

After the one or more autonomous vehicles of the plurality of autonomous vehicles 305 generate the transactions, the one or more autonomous vehicles may transmit (328) the transactions to the enforcement server 315 via a communication network. In some embodiments, the communication network may include an ad hoc or mesh network comprised of the plurality of autonomous vehicles 305. At some point after receiving the transactions, the enforcement server 315 may compile (332) a new block of the distributed ledger that includes the transactions. As part of compiling the block, the enforcement server 315 may generate a hash value for each transaction included in the block. The enforcement server 315 may then cryptographically combine these hash values, such as through the use of a Merkle Tree, to generate a hash value of the block as a whole. The enforcement server 315 may include the hash value of the block as a whole in a header of the block.

In one embodiment, the enforcement server 315 may compile the block periodically (e.g., every five minutes, every ten minutes, etc.). It should be appreciated, that the period may change over time in an attempt to keep the block size below a threshold size. Generally, as more autonomous vehicles are included in the plurality of autonomous vehicles 305, more transactions are generated. As a result, over time, using a fixed period may result in more and more transactions being included in each block, thereby increasing the size of the average block. Accordingly, the enforcement server 315 may adjust (e.g., shorten) the compilation period to ensure that the average block size does not exceed the threshold size despite the reception of a greater volume of transactions. Further, according to aspects, the enforcement server 315 may compile the block aperiodically upon the reception of a transaction having an urgent priority.

The enforcement entity may transmit (336) the compiled block to one or more nodes of the distributed ledger. The nodes may include the dedicated validation entities 335 (236b) and/or a portion of the plurality of autonomous vehicles 305 (236a). The nodes that receive the block may attempt to generate (340) a solution to a cryptographic puzzle that is based upon the hash value included in the header in the block. After a particular node finds a solution to the cryptographic puzzle, the node may transmit the solution to the other nodes to verify the solution. The other nodes, such as the portion of the plurality of autonomous vehicles 305, the enforcement server 315, and/or the dedicated validation entities 335, may then form a consensus (344) on the solution found by the particular node. More particularly, the other nodes may vote to approve block's inclusion into the distributed ledger upon successfully verifying the solution. Consensus may be formed when over half of the nodes have voted for the inclusion of the block. It should be appreciated that finding the solution to the cryptographic puzzle involves significantly more processing power than verifying the solution. Accordingly, in some embodiments, pools of nodes may coordinate their processing power in an attempt to jointly find the solution to the cryptographic puzzle.

To this end, the enforcement server 315 may determine that a portion of the plurality of autonomous vehicles 305 participated in finding the verified solution to the cryptographic puzzle. To encourage participation in finding the solution, the enforcement server 315 may credit a respective account associated with each autonomous vehicle (and/or operator thereof) that participated in finding the verified solution with a currency. In some embodiments, the currency may be reward points. In other embodiments, the currency may be a cryptocurrency. It should be appreciated that in some scenarios, when multiple autonomous vehicles participated in finding the verified solution, each autonomous vehicle may have made an unequal contribution to the overall processing power. Accordingly, the enforcement server 315 may divide the credit between and among the portion of the plurality of autonomous vehicles 305 in accordance to the respective processing power contributed to finding the solution.

The signal diagram 300 continues when the enforcement server 315 routes (348) the plurality of transactions compiled into the block to the smart contract database 330. The smart contract database 330 may be maintained at the enforcement server 315 and/or within the distributed ledger itself. In one embodiment, routing a transaction may include extracting the indication(s) of the autonomous vehicle and/or the operator from the transaction and utilizing the indication(s) to query the smart contract database 330. If a particular smart contract matches the query (e.g., the smart contract governs an autonomous vehicle and/or operator thereof indicated by the transaction), routing may further include the particular smart contract processing the transaction information included in the transaction. To this end, the particular smart contract may determine whether a trigger condition occurred and/or analyze a plurality of condition data to determine one or more actions to perform in response to the trigger condition occurring. It should be appreciated that a plurality of transactions may be routed to a plurality of smart contracts. Accordingly, the plurality of smart contracts within the smart contract database 330 may generate a plurality of actions to enforce the smart contracts.

In one example, a particular smart contract may govern a relationship between an insurer and a manufacturer of a particular autonomous vehicle. In particular, the insurer may agree to cover liability incurred while the particular autonomous vehicle is operated in a manual mode; whereas the manufacturer may agree to cover liability incurred while the particular autonomous vehicle is operated in a fully or semi-autonomous mode. In this example, if the particular autonomous vehicle incurs liability, the particular autonomous vehicle may generate a transaction indicating the liability. When the transaction is routed to the particular smart contract, the particular smart contract may detect the presence of a trigger condition (i.e., incurring liability). Accordingly, the particular smart contract may then analyze condition data to determine whether the particular autonomous vehicle was operated in a manual or autonomous mode (e.g., a decision condition). If the particular autonomous vehicle was operated in a manual mode, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the insurer and/or the operator of the particular autonomous vehicle. On the other hand, if the particular autonomous vehicle was operated in an autonomous mode, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the manufacturer.

In a similar example, a particular smart contract may govern a relationship between an insurer and a remote operator of a particular autonomous vehicle. In particular, the insurer may agree to cover liability incurred while the particular autonomous vehicle is operated in a manual mode; whereas the remote operator may agree to cover liability incurred while the particular autonomous vehicle is remotely operated. In this example, if the particular autonomous vehicle incurs liability, the particular autonomous vehicle may generate a transaction indicating the liability. When the transaction is routed to the particular smart contract, the particular smart contract may detect the presence of a trigger condition (i.e., incurring liability). Accordingly, the particular smart contract may then analyze condition data to determine whether the particular autonomous vehicle was operated in a manual or remote mode (e.g., a decision condition). If the particular autonomous vehicle was operated in a manual mode, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the insurer and/or the operator of the particular autonomous vehicle. On the other hand, if the particular autonomous vehicle was operated in a remote mode, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the remote operator.

In another example, a particular smart contract may govern a relationship between an insurer and an operator of a particular autonomous vehicle. In particular, the insurer may agree to only cover liability incurred while the particular autonomous vehicle is operated within a mileage limit. Similarly, in this example, if the particular autonomous vehicle incurs liability, the particular autonomous vehicle may generate a transaction indicating the liability. When the transaction is routed to the particular smart contract, the particular smart contract may detect the presence of a trigger condition (i.e., incurring liability). Accordingly, the particular smart contract may then analyze condition data to determine whether the particular autonomous vehicle traversed a distance that exceeds the mileage limit (e.g., a decision condition). If the particular autonomous vehicle traversed a distance that exceeds the mileage limit, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the operator of the particular autonomous vehicle. Conversely, if the particular autonomous vehicle has not traversed a distance that exceeds the mileage limit, the particular smart contract may determine that an action is to automatically generate an insurance claim that assigns liability to the insurer.

In any event, the plurality of smart contracts in the smart contract database may transmit (352) the one or more determined actions to the enforcement server 315, which executes (356) the actions. In one embodiment, the enforcement server 315 may include a plurality of third party applications (such as the third party applications 125 as described with respect to FIG. 1) that may assist in the execution of the actions. For example, a manufacturer or insurer may provide an application that enables the enforcement server 315 to generate, file, and/or subrogate a claim with the manufacturer or insurer. As another example, the enforcement server 315 may interact with an application provided by an incident response service provider (e.g., a police entity, an EMT, a tow service, a fire department, an autonomous vehicle dispatch, etc.) to execute one or more actions to ensure the safety of persons affected by the event that incurred liability.

According to certain aspects, the enforcement server 315 may analyze (360) the distributed ledger to determine that a particular block of the distributed ledger includes one or more transactions that are no longer relevant to the plurality of smart contracts in the smart contract database 330. For example, a transaction in the particular block may include transaction information relating to a decision condition when a trigger condition did not occur (e.g., an autonomous vehicle completed a trip without incurring liability). As another example, the transaction may be older than a threshold age (e.g., older than thirty days). In response, in order to reduce the overall size of the distributed ledger, the enforcement server 315 may prune the transaction that is no longer relevant from the particular block. As explained above, the corresponding to the particular block is dependent on the header for the transaction. Accordingly, pruning may involve deleting the underlying data from the transaction (e.g., raw transaction information) while maintaining the header of the transaction. Thus, the amount of data stored in each block may be reduced without impacting the cryptographic link that secures the distributed ledger. In some embodiments, the pruned transaction and/or the data associated therewith may be copied to an archival database for record-keeping. It should be appreciated that signal diagram 300 may include additional, less, and/or alternative actions, including those discussed elsewhere herein. For example, in some embodiments, some of the actions described with respect to the enforcement server 315 may be alternatively performed by one or more of the plurality of autonomous vehicles 305, and/or vice versa.

Exemplary Methods of Maintining Distributed Ledger

Referring to FIG. 4, depicted is a block diagram of an exemplary computer-implemented method 400 of processing transactions included in a distributed ledger. The method 400 may be facilitated by an electronic device associated with an autonomous vehicle, such as the electronic device 103 associated with the autonomous vehicle 105a as described with respect to FIG. 1, that may be in direct or indirect communication with an enforcement server, such as the enforcement server 115 as described with respect to FIG. 1.

The method 400 may begin by the electronic device monitoring a plurality of vehicle sensors (block 405). More particularly, the electronic device may monitor a plurality of data generated by the plurality of vehicle sensors. For example, the electronic device may monitor the output of an accelerometer, a gyroscope, a brake sensor, an impact sensor, an image/video sensor, an audio sensor, a pressure sensor, and/or any other sensor that monitors a condition associated with the autonomous vehicle. In some embodiments, the sensor data may be communicated over a communication bus associated with the autonomous vehicles. Additionally or alternatively, the sensor data may be communicated directly to the electronic device via a wireless or wired connection.

At block 410, the electronic device may analyze the sensor data to detect a change in a monitored condition. In one embodiment, the autonomous vehicle may be associated with one or more smart contracts, each associated with a trigger condition and/or a decision condition. An application executing on the electronic device may receive a subscription request to provide data streams relating to trigger conditions and/or decision conditions associated with one or more smart contracts. The application may be able to associate a trigger and/or decision condition with one or more sensors that are relevant to the requested data streams. For example, for a trigger condition of incurring liability, the application may cause the electronic device to monitor an impact sensor, an airbag deployment sensor, a gyroscope, an accelerometer, a window integrity sensor, or even a sensor of another autonomous vehicles and/or a smart infrastructure device proximate to the autonomous vehicle. In some embodiments, not only may the application associate the trigger and/or decision condition with the one or more relevant sensors, but also one or more expected ranges of values associated with one or more statuses associated with the trigger condition. In the above example, an accelerometer may be associated with a threshold value that, when exceeded, is indicative that the autonomous vehicle experienced a collision. Accordingly, for the accelerometer, an expected range of values for a status indicating no liability may be values below the threshold and an expected range of values for a status indicating liability may be values that exceed the threshold. For some sensors, for example a window integrity sensor, the expected range may be a Boolean value or another similar flag that indicates a status beyond raw measured statistics (e.g., the range includes, for example, TRUE or “SHATTERED,” as opposed to, say, 8 m/s²). In any event, the electronic device may monitor the data generated by the relevant sensors to detect whether a status for a trigger condition and/or a decision condition has changed. Additionally or alternatively, as described elsewhere herein, the status (and/or ranges of values indicative thereof) may be associated with an urgent, normal, low, and/or any other priority level.

At block 415, the electronic device may generate a transaction that describes the detected change in status for a trigger condition and/or a decision condition. As described elsewhere herein, the transaction may include an indication of the autonomous vehicle and/or an operator thereof, a time stamp, and/or a plurality of transaction information. In some embodiments, the transaction information includes an indication of the status of trigger and/or decision condition. Additionally or alternatively, the transaction information may include at least a portion of the raw data that indicated that change in the trigger and/or decision condition.

At block 420, the electronic device may transmit the generated transaction to the enforcement server for processing and/or compilation into a block to be added to the distributed ledger. In some embodiments, instead of the enforcement server compiling the transactions into the block, the electronic device may instead compile a plurality of transaction the electronic device generated (and/or received from another autonomous vehicle) into the proposed block. In these embodiments, transmitting the transaction to the enforcement server may include transmitting the proposed block that includes the transaction to the enforcement server.

At block 425, in embodiments wherein the electronic device is also a validation entity, the electronic device may attempt to solve a cryptographic puzzle based upon the header of the proposed block. It should be appreciated that because there are typically several validation entities attempting to solve the same cryptographic puzzle, the electronic device may never actually solve the cryptographic puzzle. To this end, once one validation entity claims to have solved the cryptographic puzzle, that validation entity may transmit its solution to the other validation entities for verification.

At block 430, in embodiments wherein the electronic device is also a validation entity, the electronic device may attempt to form a consensus on the solution. In scenarios in which another validation claims to have solved the cryptographic solution, the electronic device may attempt to verify the received solution. If the solution is successfully verified, the electronic device may vote to include the block in the distributed ledger. In scenarios in which the electronic device solved the cryptographic puzzle, the electronic device may be considered to have attempted to form the consensus when the electronic device sent the proposed solution to the other validation entities. It should be appreciated that the method 400 may include additional, less, or alternative actions, including those described elsewhere herein.

Referring now to FIG. 5, depicted is a block diagram of an exemplary computer-implemented method 500 of processing transactions included in a distributed ledger. The method 500 may be facilitated by an enforcement server, such as the enforcement server 115 as described with respect to FIG. 1, that may be in direct or indirect communication with a plurality of autonomous vehicles, such as the plurality of autonomous vehicles 105a-f as described with respect to FIG. 1, and interconnected with a smart contract database that stores a plurality of smart contracts.

The method 500 may begin by the enforcement server receiving a plurality of transactions from the plurality of autonomous vehicles (block 505). As described elsewhere herein, the transactions may include an indication of an autonomous vehicle that generated the transaction and/or an operator thereof, a time stamp, and/or a plurality of transaction information. According to aspects, the enforcement server may continue to receive transaction until the expiration of a threshold amount of time has expired and/or an urgent priority transaction is received.

At block 510, the enforcement server may compile the received transactions into a proposed block. As described elsewhere, compiling the block may involve cryptographically combining, such as through the use of a Merkle Tree, a hash value associated with each of the transactions to form a hash value associated with the block as a whole. This hash value may be included in the header file of the proposed block.

At block 515, the enforcement server may distribute the proposed block to a plurality of validation entities that attempt to solve a cryptographic puzzle based upon the hash value included in the header and a nonce value. In some embodiments, the plurality of validation entities may include a portion of the plurality of autonomous vehicles. At some point, the plurality of validation entities may form a consensus on the proposed block. Upon consensus, the proposed block may be included in the distributed ledger.

At block 520, the enforcement server may route the transactions included in the now included block to the plurality of smart contracts. As described above, routing may involve extracting an indication of the autonomous vehicle and/or operator thereof, utilizing the indication to query the database of smart contracts, and/or inputting the transaction information from the transaction into the smart contracts that match the query. If the transaction indicated that a trigger condition occurred, the smart contract may output an action that is to be performed to enforce the smart contract.

At block 525, the enforcement server may automatically execute the action that is to be performed to enforce the smart contract. For some actions, the enforcement server may utilize one or more third party applications accessible by the enforcement server. As an example, an emergency response entity may make an application accessible that enables the enforcement server to initiate an emergency response. For other actions, the enforcement server may be able to perform the action without the assistance of a third party application. As an example, the enforcement server may be able to generate and transmit a text message to an emergency contact without the assistance of a third party application. It should be appreciated that the method 400 may include additional, less, or alternative actions, including those described elsewhere herein.

Exemplary Enforcement Server

FIG. 6 illustrates a diagram of an exemplary enforcement server 615 (such as the enforcement server 115 as discussed with respect to FIG. 1) in which the functionalities as discussed herein may be implemented. It should be appreciated that the enforcement server 615 may be associated with a distributed ledger that governs a plurality of smart contracts, as discussed elsewhere herein.

The enforcement server 615 may include a processor 622, as well as a memory 678. The memory 678 may store an operating system 679 capable of facilitating the functionalities as described herein. The enforcement server 615 may also store a set of applications 675 (i.e., machine readable instructions). For example, one application of the set of applications 675 may be a blockchain manager 684 configured to compile transactions into blocks and/or to route transactions to smart contracts. As another example, the set of applications 675 may include one or more third party applications 685 to assist in executing an action to enforce a smart contract. It should be appreciated that other applications may be included in the set of application 675.

The processor 622 may interface with the memory 678 to execute the operating system 679 and the set of applications 675. According to some embodiments, the memory 678 may also include a plurality of smart contracts 680. The blockchain manager 684 may access the smart contracts 680 to facilitate the enforcement of the smart contracts 680. The memory 678 may include one or more forms of volatile and/or non-volatile, fixed and/or removable memory, such as read-only memory (ROM), electronic programmable read-only memory (EPROM), random access memory (RAM), erasable electronic programmable read-only memory (EEPROM), and/or other hard drives, flash memory, MicroSD cards, and others.

The enforcement server 615 may further include a communication module 677 configured to communicate data via one or more networks 610. Network(s) 610 may include a mesh network comprised of one or more autonomous vehicles. According to some embodiments, the communication module 677 may include one or more transceivers (e.g., WWAN, WLAN, and/or WPAN transceivers) functioning in accordance with IEEE standards, 3GPP standards, or other standards, and configured to receive and transmit data via one or more external ports 676. In some embodiments, the communication module 677 may include separate transceivers configured to interact with the local and remote networks separately. The enforcement server 615 may further include a user interface 681 configured to present information to a user and/or receive inputs from the user. As shown in FIG. 6, the user interface 681 may include a display screen 682 and I/O components 683 (e.g., ports, capacitive or resistive touch sensitive input panels, keys, buttons, lights, LEDs, speakers, microphones). According to the present embodiments, the user may access the enforcement server 615 via the user interface 681 to monitor the distributed ledger, update software executing at the enforcement sever 615 and/or perform other functions. In some embodiments, the enforcement server 615 may perform the functionalities as discussed herein as part of a “cloud” network, or may otherwise communicate with other hardware or software components within the cloud to send, retrieve, and/or otherwise analyze data.

In general, a computer program product in accordance with an embodiment may include a computer usable storage medium (e.g., standard random access memory (RAM), an optical disc, a universal serial bus (USB) drive, or the like) having computer-readable program code embodied therein, wherein the computer-readable program code is adapted to be executed by the processor 622 (e.g., working in connection with the operating system 679) to facilitate the functions as described herein. In this regard, the program code may be implemented in any desired language, and may be implemented as machine code, assembly code, byte code, interpretable source code or the like (e.g., via C, C++, Java, Actionscript, Objective-C, Javascript, CSS, XML). In some embodiments, the computer program product may be part of a cloud network of resources.

Exemplary Autonomous Vehicle Event Distributed Ledger

FIG. 7 depicts an exemplary computer-implemented method of building, using, and/or maintaining a distributed ledger and/or blockchain related to autonomous vehicle transactions and/or events 700. The method 700 may include recording autonomous vehicle or system transactions and/or events 702. The transactions and/or events may detail an amount of usage, and/or type of usage, for each autonomous or semi-autonomous system or technology on an autonomous or semi-autonomous vehicle. The transactions and/or events may also detail an amount of operation and usage of the autonomous or semi-autonomous vehicle, including operation or usage under (i) autonomous (or processor) control, and (ii) human control, as well as detail which human of a household or company was driving the autonomous or semi-autonomous vehicle, and include a timestamp of when they were driving.

The method 700 may include compiling the autonomous vehicle or system transactions and/or events recorded into a log of events 704. For instance, the log may include transactions and/or events directed or related to autonomous vehicle usage (time of day, type of operation, type of control (autonomous/processor vs. human), location or area driven, miles driven, type of weather or environment driven in, etc.). The log may include transactions and/or events directed to individual or specific autonomous or semi-autonomous system or technology usage (such as whether used or not, an amount or time of usage, a type of setting, etc.).

The transactions and/or events recorded in the distributed ledger and/or blockchain may be determined or sensed by various smart sensors and/or processors. The transactions and/or events may detail (i) a setting that an autonomous or semi-autonomous system or technology is used at; (ii) how long the autonomous or semi-autonomous system or technology was used or employed (or not used or employed); (iii) the time of day or year during which the autonomous or semi-autonomous system or technology was used or employed (or not used or employed); (iv) the type of road (such as highway, rural, or city) on which the autonomous or semi-autonomous system or technology was used or employed (or not used or employed); (v) an identification of the human driver and/or how many passengers where in the vehicle; (vi) the environmental or weather conditions (rain, ice, snow, etc.) during which the autonomous or semi-autonomous system or technology was used or employed (or not used or employed); (vii) whether the autonomous or semi-autonomous system or technology was used or employed (or not used or employed) when recommended to be employed by a smart vehicle controller or other processor; (viii) the status, operational status, or working condition of each autonomous or semi-autonomous system or technology of an autonomous or semi-autonomous vehicle; (ix) a maintenance log of each autonomous system or technology on the autonomous or semi-autonomous vehicle; (x) whether recommended periodic maintenance has been performed on the autonomous or semi-autonomous vehicle, and/or on individual autonomous or semi-autonomous systems mounted by the vehicle; (xi) whether each autonomous system or technology is working as intended or not, such as via system self-checks; (xii) autonomous vehicle and/or autonomous vehicle system warranty information; (xiii) make, model, type, and/or version of autonomous vehicle system or software; (xiv) a timestamp of switching events during which control of the vehicle went from manual operation to autonomous operation, or vice versa; and/or (xv) a timestamp of engagement events during which an autonomous system was engaged or disengaged.

The method 700 may use the transactions and/or events recorded and/or log of events recorded (for the vehicle as a whole, and for individual autonomous or semi-autonomous vehicle systems or technologies) for various actions. The actions may include generating a usage-based insurance quote based upon past or expected future autonomous system or technology usage (which may be determined or predicted based upon the transactions and/or events recorded and/or the log of events recorded). The actions may include generating or estimating a current or actual value of the autonomous or semi-autonomous vehicle based upon the events recorded and/or the log of events recorded. The actions may include determining that the autonomous or semi-autonomous vehicle was involved in a vehicle collision, and/or assign percentage of fault for the vehicle collision (such as to the driver, the autonomous vehicle or system, or another vehicle or driver) based upon the events recorded and/or the log of events recorded. The actions may include handling insurance claims based upon the events recorded and/or the log of events recorded.

In one embodiment, the method 700 may employ machine or deep learning techniques on the autonomous vehicle transactions and/or events recorded in the log of events, and/or the blockchain or distributed ledger to determine an action or end result. For instance, the recorded events may be input into a machine learning algorithm trained to determine a usage-based insurance quote, a vehicle actual or replacement valuation, and/or that the autonomous vehicle was involved in a vehicle collision based at least in part on the recorded events associated with the autonomous vehicle, such as events related to individual autonomous vehicle feature or system usage (and/or amount thereof).

The method 700 may use the transactions and/or events recorded and/or the log of events recorded to update a blockchain 708 or form a consensus among distributed nodes that the blockchain should be updated, such as a blockchain related to point-in-time operator control and/or to an individual autonomous or semi-autonomous vehicle. For instance, the autonomous vehicle related events and/or actions determined may be distributed among nodes in a public or private network via wireless communication or data transmission over one or more radio links. The method 700 may update the blockchain at each node using the events, the individual events recorded, and/or the actions determined (including those mentioned above), and use the events and/or actions to update or generate one or more smart contracts 710. For instance, the smart contracts may relate to insurance quote generation, usage-based insurance quotes and contracts, and/or insurance claim handling.

The types of transactions and/or events recorded may relate to autonomous or semi-autonomous vehicle-related functionality or technology that replace human driver actions, and may include and/or be related to the following types of functionality: (a) fully autonomous (driverless); (b) limited driver control; (c) vehicle-to-vehicle (V2V) wireless communication; (d) vehicle-to-infrastructure (and/or vice versa) wireless communication; (c) automatic or semi-automatic steering; (f) automatic or semi-automatic acceleration; (g) automatic or semi-automatic braking; (h) automatic or semi-automatic blind spot monitoring; (i) automatic or semi-automatic collision warning; (j) adaptive cruise control; (k) automatic or semi-automatic parking/parking assistance; (1) automatic or semi-automatic collision preparation (windows roll up, seat adjusts upright, brakes pre-charge, etc.); (m) driver acuity/alertness monitoring; (n) pedestrian detection; (o) autonomous or semi-autonomous backup systems; (p) road mapping systems; (q) software security and anti-hacking measures; (r) theft prevention/automatic return; (s) automatic or semi-automatic driving without occupants; and/or other functionality.

With the present embodiments, the events or transactions recorded may relate to autonomous or semi-autonomous vehicle technology or functionality directed toward: automatic or semi-automatic steering; automatic or semi-automatic acceleration and/or braking; automatic or semi-automatic blind spot monitoring; automatic or semi-automatic collision warning; adaptive cruise control; and/or automatic or semi-automatic parking assistance. Additionally or alternatively, the autonomous or semi-autonomous technology or functionality may include and/or be related to: driver alertness or responsive monitoring; pedestrian detection; artificial intelligence and/or back-up systems; navigation or GPS-related systems; security and/or anti-hacking measures; and/or theft prevention systems.

In one aspect, a computer-implemented method of building, utilizing, and/or maintaining an autonomous vehicle-related event blockchain may be provided. The method may include one or more of the following, and the sequence of actions may be rearranged: (1) detecting and/or recording, via one or more processors, sensors, and/or transceivers, autonomous vehicle events, the autonomous vehicle events including autonomous vehicle system or technology usage or operational events; (2) compiling, via the one or more processors, the autonomous vehicle events into a log of recorded autonomous vehicle events; (3) determining, via the one or more processors, an action to implement based upon the autonomous vehicle events recorded and/or the log of recorded autonomous vehicle events; (4) forming a consensus with other distributed nodes to update and/or otherwise updating, via the one or more processors, an autonomous vehicle-related blockchain to reflect or otherwise show (i) the autonomous vehicle events recorded, (ii) the log of recorded autonomous vehicle events, and/or (iii) the action to implement; and/or (5) distributing, via the one or more processors and/or transceivers, the log of recorded autonomous vehicle events and/or the autonomous vehicle-related blockchain to a public or private network of distributed nodes to facilitate maintaining the shared ledger of autonomous vehicle events up-to-date. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

For instance, the method may include updating a smart contract based upon the blockchain, events records, and/or actions determined to implement. The action determined to implement based upon the autonomous vehicle events recorded and/or the log of recorded autonomous vehicle events may be (i) estimating an actual value of the autonomous vehicle; (ii) estimating a replacement cost of the autonomous vehicle; (iii) generating a usage-based insurance quote for the autonomous vehicle and/or a specific trip; and/or (iv) to determine that the autonomous vehicle was involved in a vehicle collision, and to commence a claim handling process.

The autonomous vehicle events recorded may be related to at least one of the following autonomous vehicle systems, features, or technologies: driver alertness monitoring; driver responsiveness monitoring; pedestrian detection; artificial intelligence; a back-up system; a navigation system; a positioning system; a security system; an anti-hacking measure; a theft prevention system; and/or remote vehicle location determination.

In another aspect, a computer system configured to build and utilize an autonomous vehicle-related event distributed ledger and/or blockchain may be provided. The computer system may include one or more processors, sensors, and/or transceivers configured to perform one or more of the following, and the order of actions may be rearranged: (1) detect and/or record autonomous vehicle events, the autonomous vehicle events including autonomous vehicle system or technology usage or operational events; (2) compile the autonomous vehicle events into a log of recorded autonomous vehicle events; (3) determine an action to implement based upon the autonomous vehicle events recorded and/or the log of recorded autonomous vehicle events; (4) form a consensus with other distributed nodes to update and/or otherwise update an autonomous vehicle-related blockchain to reflect or otherwise show (i) the autonomous vehicle events recorded, (ii) the log of recorded autonomous vehicle events, and/or (iii) the action to implement; and/or (5) distribute the log of recorded autonomous vehicle events and/or the autonomous vehicle-related blockchain to a public or private network of distributed nodes to facilitate maintaining the shared ledger of autonomous vehicle events up-to-date. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In one aspect, a computer-implemented method for maintaining a distributed ledger and/or blockchain of autonomous vehicle-related transactions and/or events pertaining to one or more smart contracts and/or autonomous vehicles may be provided. The method may include the following actions, and the actions may be performed in various orders: (1) receiving, at one or more processors, one or more autonomous vehicle-related transactions and/or events from one or more autonomous vehicles, the autonomous vehicle-related transactions and/or events indicative of at least one of a trigger condition or a decision condition associated with one or more smart contracts; (2) compiling, by the one or more processors, the one or more autonomous vehicle-related transactions and/or events into a block of transactions and/or events; (3) distributing, by the one or more processors, the block of transactions and/or events to a plurality of validation entities via wireless or data transmission over one or more radio links or wireless communication channels to form a consensus on an update to (and/or whether or not to update) the distributed ledger and/or blockchain; (4) routing, by the one or more processors, the one or more autonomous vehicle-related transactions and/or events within the block to respective or corresponding smart contracts, wherein a particular transaction corresponding to a particular smart contract indicates that a trigger condition for the particular smart contract has occurred; and/or (5) automatically executing, by the one or more processors, an action the particular smart contract directs should be performed in response to the particular trigger condition, the action determined based upon a decision condition included in a transaction and/or event routed to the particular smart contract. The method may include additional, less, or alternate actions, including those discussed elsewhere herein, and may be implemented via computer systems and/or non-transitory computer readable medium.

In another aspect, a computer-implemented method for maintaining a distributed ledger or blockchain of transactions or events pertaining to autonomous vehicles may be provided. The method may include one or more of the following: (1) receiving, at one or more processors, one or more autonomous vehicle-related transactions or events from one or more autonomous vehicles, the transactions indicative of at least one of a trigger condition; (2) compiling, by the one or more processors, the one or more autonomous vehicle-related transactions or events into a block of transactions or events; (3) distributing, by the one or more processors, the block of autonomous vehicle-related transactions or events to a plurality of validation entities or nodes within a communication network to form a consensus on whether or not to update the distributed ledger; and/or (4) when a consensus is formed, updating, by the one or more processors, the distributed ledger at the plurality of validation entities or nodes to facilitate maintaining a distributed ledger or blockchain associated with autonomous vehicle-related transactions or events up-to-date. The method may include additional, less, or alternate actions, including those discussed elsewhere herein, and may be implemented via computer systems and/or non-transitory computer readable medium.

For instance, the method may include routing, by the one or more processors, the plurality of transactions or events within the block to a plurality of smart contracts, wherein a particular transaction or event corresponding to a particular smart contract may indicate that a trigger condition for the particular smart contract has occurred. The method may include automatically executing, by the one or more processors, an action the particular smart contract directs should be performed in response to the particular trigger condition, the action may be determined based upon a decision condition included in a transaction or event routed to the particular smart contract.

The trigger condition for the particular smart contract may be related to a particular autonomous vehicle incurring liability or being involved in a vehicle collision; and/or the particular transaction or event may indicate that the particular autonomous vehicle incurred liability or was involved in a vehicle collision. The decision condition for the particular smart contract may be a control state of the particular autonomous vehicle; and/or the particular transaction or event may indicate whether the particular autonomous vehicle was being autonomously or manually operated.

In another aspect, a computer-implemented method of building, utilizing, and/or maintaining an autonomous vehicle-related event distributed ledger or blockchain may be provided. The method may include one or more following, and in various order: (1) detecting and/or recording, via one or more processors, sensors, and/or transceivers, autonomous vehicle-related events, one or more autonomous vehicle-related events including autonomous vehicle system or technology usage or operational events; (2) compiling, via the one or more processors, the one or more autonomous vehicle events into a log of recorded autonomous vehicle-related events; (3) determining, via the one or more processors, an action to implement based upon the autonomous vehicle-related events recorded and/or the log of recorded autonomous vehicle events; and/or (4) distributing, via the one or more processors and/or transceivers, the log of recorded autonomous vehicle-related events and/or the action to implement to a public or private network of distributed nodes (such as via wireless communication or data transmission over one or more radio links or wireless communication channels) to facilitate maintaining a shared ledger of autonomous vehicle-related events up-to-date. The method may include additional, less, or alternate actions, including those discussed elsewhere herein, and may be implemented via computer systems and/or non-transitory computer readable medium.

Exemplary Autonomous Vehicle Embodiments

In one aspect, a computer-implemented method for maintaining a distributed ledger of transactions pertaining to a plurality of smart contracts may be provided. The method may include (1) monitoring, by one or more processors, a plurality of sensors associated with a vehicle; (2) detecting, by the one or more processors, a change in a condition of the vehicle, the condition being associated with a smart contract of the plurality of smart contracts that governs the vehicle and/or an operator of the vehicle; (3) generating, by the one or more processors, a transaction describing the detected change in the condition of the vehicle; and/or (4) transmitting, to a server, the transaction. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

For instance, the method may include compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger. Transmitting the transaction to the server may include transmitting, to the server, the block of transactions.

The method may include receiving, from the server, a subscription request indicating the condition of the vehicle; and associating, by the one or more processors, the condition of the vehicle with a set of the plurality of sensors associated with the vehicle. The subscription request may indicate one or more expected ranges of values for outputs of the set of the plurality of sensors, the expected ranges of values being associated with one or more states corresponding to the condition of the vehicle and/or one or more operational states of one or more autonomous vehicle systems or technologies, including those discussed herein.

Detecting the change in the condition of the vehicle may include detecting, by the one or more processors, that an output of a sensor (such as an autonomous vehicle system or technology sensor, or other vehicle-mounted sensor) the set of the plurality of sensors changed from a first expected range of values to a second expected range of values.

The change in the condition of the vehicle may be indicative of a collision with another vehicle. The method may include receiving, from the other vehicle, operating data generated by one or more sensors of the other vehicle, and the sensors of the other vehicle may be associated with an autonomous vehicle system of the other vehicle.

The method may include analyzing, by the one or more processors, the operating data to determine a relative fault between a party associated with the vehicle and a party associated with the other vehicle, and/or a relative fault between the vehicles if the vehicles are autonomous or semi-autonomous vehicles, or relative fault between different autonomous vehicle systems or technologies mounted on one or more vehicles.

The method may include analyzing, by the one or more processors, the operating data to determine that the vehicle, and not the other vehicle, should generate the transaction. The operating data may indicate that an antenna associated with the other vehicle is damaged.

The method may include receiving, from a node of the distributed ledger, a proposed block to add to the distributed ledger; and attempting, by the one or more processors, to solve a cryptographic puzzle based upon a header of the proposed block. When the one or more processors solve the cryptographic puzzle, the method may include transmitting, to one or more nodes of the distributed ledger, a solution to the cryptographic puzzle.

The method may include receiving, from a node of the distributed ledger, a proposed solution to the cryptographic puzzle; verifying, by the one or more processors, the proposed solution to the cryptographic puzzle; and/or communicating, with one or more nodes of the distributed ledger, whether or not the proposed solution to the cryptographic puzzle was verified in an attempt to from a consensus on the proposed solution.

The vehicle may be an autonomous vehicle, and the change in a condition of the vehicle is a change in operation or operational state (such as on, off, hi, low, etc.) of an autonomous vehicle system or technology mounted on the autonomous vehicle. The autonomous vehicle system or technology may be associated with or related to: driver alertness monitoring; driver responsiveness monitoring; pedestrian detection; artificial intelligence; a back-up system; a navigation system; a positioning system; a security system; an anti-hacking measure; a theft prevention system; and/or remote vehicle location determination.

In another aspect, a computer system for maintaining a distributed ledger of transactions pertaining to a plurality of smart contracts may be provided. The computer system may include one or more processors; a communication module adapted to communicate with one or more nodes of the distributed ledger; 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) monitor a plurality of sensors associated with a vehicle; (2) detect a change in a condition of the vehicle, the condition being associated with a smart contract of the plurality of smart contracts that governs the vehicle and/or an operator of the vehicle, or governs an autonomous vehicle system or technology mounted on the vehicle; (3) generate a transaction describing the detected change in the condition of the vehicle; and/or (4) transmit, to a server, the transaction. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for maintaining a distributed ledger of transactions pertaining to one or more smart contracts may be provided. The method may include (1) monitoring, by one or more processors, one or more sensors associated with a vehicle; (2) detecting, by the one or more processors, a change in a condition of the vehicle, the condition being associated with a smart contract that governs the vehicle and/or an operator of the vehicle, or governs an autonomous vehicle system or technology mounted on the vehicle; (3) generating, by the one or more processors, a transaction describing the detected change in the condition of the vehicle; and/or (4) transmitting, to a server, the transaction. The method may include compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger, and/or transmitting, to the server, the block of transactions. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

In another aspect, a computer system for maintaining a distributed ledger of transactions pertaining to one or more smart contracts may be provided. The computer system may include one or more processors; a communication module adapted to communicate with one or more nodes of the distributed ledger; 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) monitor one or more sensors associated with an autonomous or other vehicle; (2) detect a change in a condition of the vehicle, the condition being associated with a smart contract that governs the vehicle and/or an operator of the vehicle; (3) generate a transaction describing the detected change in the condition of the vehicle; and/or (4) transmit, to a server, the transaction. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for maintaining a distributed ledger of transactions pertaining to an autonomous vehicle may be provided. The method may include (1) monitoring, by one or more processors, one or more sensors associated with an autonomous vehicle; (2) detecting, by the one or more processors, a change in a condition of the autonomous vehicle, the condition being associated with operation, or an operational state, of an autonomous vehicle system or technology mounted on the autonomous vehicle; (3) generating, by the one or more processors, a transaction describing the detected change in the condition of the vehicle; and/or (4) transmitting, to a server, the transaction. The method may include compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger, and/or transmitting, to the server, the block of transactions. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

In another aspect, a computer system for maintaining a distributed ledger of transactions pertaining to an autonomous vehicle may be provided. The computer system may include one or more processors; a communication module adapted to communicate with one or more nodes of the distributed ledger; 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) monitor one or more sensors associated with an autonomous vehicle; (2) detect a change in a condition of the vehicle, the condition being associated with operation, or an operational state, of an autonomous vehicle system or technology mounted on the autonomous vehicle; (3) generate a transaction describing the detected change in the condition of the autonomous vehicle; and/or (4) transmit, to a server, the transaction. The system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for maintaining a distributed ledger of transactions pertaining to one or more smart contracts may be provided. The method may include (1) monitoring, by one or more processors, a plurality of sensors associated with an autonomous vehicle; (2) detecting, by the one or more processors, a change in a condition of the autonomous vehicle, the condition being associated with a smart contract (such as a warranty, maintenance, service, or other contract) that governs an autonomous vehicle system or technology employed by or mounted on the autonomous vehicle; (3) generating, by the one or more processors, a transaction describing the detected change in the condition of the autonomous vehicle; and/or (4) transmitting, to a server, the transaction. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

In another aspect, a computer system for maintaining a distributed ledger of transactions pertaining to a one or more smart contracts may be provided. The computer system may include: one or more processors; a communication module adapted to communicate with one or more nodes of the distributed ledger; 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) monitor one or more sensors associated with an autonomous vehicle; (2) detect a change in a condition of the vehicle, the condition being associated with a smart contract that governs an autonomous vehicle technology or system employed by or mounted on the autonomous vehicle; (3) generate a transaction describing the detected change in the condition of the autonomous vehicle; and/or (4) transmit, to a server, the transaction. The system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

Additional Considerations

An authoritative, trusted, immutable, distributed, shareable, secure system may be needed to record if a human driver is controlling a vehicle, and/or if the vehicle is acting autonomously. The record may include crash sensor data to record crash information correlating to driver control information.

Blockchain technology may be used to store the transactions of control instances (from autonomous to human control to autonomous, for example). These control instances may be stored as they occur into blocks. Accordingly, this data may be included into the distributed ledger environment of the blockchain. In this environment, a consensus system may fix the events/blocks immutably and securely. At the same time and from separate systems, vehicle sensor data may also be stored into the block at various intervals by block management software (for example, an airbag deployed flag may remain at “0” prior to deployment, but becomes fixed to “1” after airbags deploy). This information may denote if a crash has occurred. In an aspect, this information is also synched to the same timestamps as the driver control events.

The data of automobile control and accident sensor flags may be streamed via the various systems in the car by existing technologies in the automobile. For example, a vehicle's steering wheel, when in autonomous mode, may be exposed to micro-vibrations; when a human driver grabs the wheel, the micro-vibrations may stop. This may be indicative of the steering system shifting to manual control. This shift may be logged in a control status event. The blockchain management software in the automobile may take this reported information (the status changing from autonomous to human control) and write into the block the timestamp, geolocation, speed, and any other data as prescribed (by the manufacturer, insurers, consumer groups, regulatory, law enforcement, and/or other organizations that may have input into what data should be reported).

The blockchain driver control and accident reporting system may be software composed of data aggregation from various automotive systems in a vehicle, a blockchain management system for writing driving control events to a block, and/or a means of passing this information (with the auto ID and user key signature/public ID) to a distributed ledger blockchain platform (such an Ethereum or similar system) via a mobile cellular, satellite, Wi-Fi, and/or other wireless data transmission technologies.

In some scenarios, the driver control and accident reporting blockchain may have public interfaces that allow visibility into the data. In an embodiment, 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, such as sending a tow truck to the geolocation if tow assistance is a part of the policy, filing a legal action by a subrogation team of an insurer is brought against an auto manufacturer (for example, if an accident occurs when the autonomous vehicle was in autonomous control), conducting a policy review, filing a police report request with the jurisdiction of the roadway, processing claims awards made (for example, a partial payment if deductible is met, to handle car rental or minor medical expense), sending a cancellation notice for the policy, and so on.

In embodiments in which the blockchain is associated with an automotive or insurance consortium, and in a two or more car collision with vehicles containing this blockchain driver control and accident monitoring systems, it is possible that information (geolocation, timestamps, other information) can be shared between and among actors. This data may indicate that two cars collided, and the insurance information may be contained in the blockchain. The smart contract may be enforced, for example, to dispatch insurance claims personnel, and/or begin an automatic process to contact the other insurance companies involved.

In some aspects, customers may opt-in to a rewards, loyalty, or other program. The customer may allow a remote server, such as an enforcement server, to collect sensor, telematics, vehicle, mobile device, and other types of data discussed herein. With customer permission or affirmative consent, the data collected may be analyzed to provide certain benefits to customers. For instance, insurance cost savings may be provided to lower risk or risk averse customers. As described herein, rewards, including cryptocurrency, may be awarded to accounts associated with the customer. The other functionality discussed herein may also be provided to customers in return for them allowing collection and analysis of the types of data discussed herein, as well as participating in the validation of the data discussed herein.

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.

It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based upon any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this disclosure is referred to in this disclosure in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based upon the application of 35 U.S.C. § 112(f).

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, certain 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.