Method and system for sharing detected change in road by employing block chain

Abstract

To provide a method and a system for sharing a detected change in a road by employing a block chain in a network.SOLUTION: A network includes a vehicle operable to detect a change in a road, a plurality of local block chains, and a global block chain. The vehicles are divided into groups of local vehicles. The plurality of local block chains contains local blocks of changes; and after a first vehicle publishes a change in the road among a group of local vehicles, if at least a local threshold number of local vehicles approves the change, then a block of the change is integrated into the local block chain. The global block chain contains blocks of changes; and if at least a global threshold number of vehicles approve the change, then a block of the change is integrated into the global block chain. A token is given to the first vehicle.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to data sharing techniques, and more particularly, to data sharing techniques for vehicles. [Background technology]

[0002] Sharing data between vehicles can be used to improve vehicle operation, increase efficiency, and improve customer service with personalized information and support. Barriers to vehicle-to-vehicle sharing include uncertain value of the data and potential incompatibilities between different vehicle platforms. Thus, a need exists for systems to effectively share data between vehicles. Summary of the Invention

[0003] In a first embodiment, the network includes vehicles operable to detect road changes and a global blockchain including a block of changes. The change is detected by a first vehicle that first publishes the change in the network, and the block of changes is incorporated into the global blockchain when at least a threshold number of vehicles approve the change. A token is awarded to the first vehicle.

[0004] In a second aspect, the network includes a vehicle operable to detect road changes, a plurality of local blockchains, and a global blockchain. The vehicles are divided into groups of local vehicles. The plurality of local blockchains include local blocks of changes, and the block of changes is incorporated into the local blockchain after a first vehicle publishes a road change among the group of local vehicles if at least a local threshold number of local vehicles approve the change. The global blockchain includes blocks of changes, and the block of changes is incorporated into the global blockchain after the change is included in the local block and at least a global threshold number of vehicles approve the change.

[0005] In a third aspect, a method includes publishing a change detected by a first vehicle in the network to a static characteristic of a road in the network, receiving an acknowledgement of the change from the vehicles in the network, determining whether at least a threshold number of vehicles in the network acknowledge the change, and incorporating a block of the change into a global blockchain of the network after determining that at least the threshold number of vehicles in the network have acknowledged the change.

[0006] These and additional features provided by the embodiments described herein will be more fully understood when considered in conjunction with the drawings and the following detailed description. [Brief description of the drawings]

[0007] The embodiments illustrated in the drawings are illustrative and exemplary in nature and are not intended to limit the subject matter defined by the claims. The following detailed description of exemplary embodiments can be understood when read in conjunction with the following drawings, in which like structure is indicated with like reference numerals and in which:

[0008] [Figure 1] FIG. 1 illustrates a schematic diagram of an example of a distributed vehicular network having multiple vehicles and a blockchain, according to one or more embodiments shown and described herein. [Figure 2A] FIG. 2 is a schematic diagram illustrating an example of grouping vehicles in a distributed vehicular network into divided vehicle groups having a peer-to-peer communication scheme, according to one or more embodiments shown and described herein. [Figure 2B] FIG. 2 is a schematic diagram illustrating an example of grouping vehicles in a distributed vehicular network into divided vehicle groups having an inter-group communication scheme, according to one or more embodiments shown and described herein. [Diagram 3] FIG. 2 is a schematic diagram illustrating non-limiting components of an apparatus onboard a vehicle of a distributed vehicular network, according to one or more embodiments shown and described herein. [Figure 4]FIG. 1 illustrates an example of a graphical representation of the operation of a distributed vehicular network, according to one or more embodiments shown and described herein. [Figure 5A] FIG. 2 is a schematic diagram illustrating an example of a graphical representation of the operation of a distributed vehicular network having divided vehicle groups with a peer-to-peer communication scheme, according to one or more embodiments shown and described herein. [Figure 5B] FIG. 2 is a schematic diagram illustrating an example of a graphical representation of the operation of a distributed vehicular network having divided vehicle groups with an inter-group communication scheme, according to one or more embodiments shown and described herein. [Figure 6] FIG. 1 illustrates a flow diagram of example steps for implementing a block on a blockchain of a distributed vehicular network, according to one or more embodiments shown and described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The embodiments described herein are directed to a method and system for sharing detected changes in roads using a blockchain in a distributed vehicular network. The distributed vehicular network, including a plurality of vehicles equipped with sensors to detect changes in roads and a blockchain, includes a block of changes. The first vehicle to publish a change in roads, such as a geometric feature of the road, a traffic sign, or a road construction, may be rewarded with a token after the reported change is approved by a portion of the other vehicles in the network and incorporated into the blockchain.

[0010] Vehicles use different map systems for navigation. For example, some vehicles may have built-in navigation systems that use their own map data, while other vehicles may rely on smartphone applications or standalone Global Positioning System (GPS) devices that use different map systems. A particular platform may face compatibility issues in sharing data, such as detected road conditions and road static features, between different vehicles using different map systems. Furthermore, vehicles traveling on roads are generally private, and therefore the data collected by the vehicles is also private. While sharing information can benefit all drivers on the road, some prefer to keep their data within their own collection. For example, after a vehicle encounters and passes a traffic accident scene, the vehicle has nothing to gain by sharing information with other vehicles that may be heading to the scene but will be delayed due to road conditions.

[0011] Utilizing blockchain technology in vehicles allows for the sharing of road condition data and road feature updates between vehicles of different models and map systems. This improves the accuracy, consistency, and cost-effectiveness of map updates across various map systems, resulting in more reliable and up-to-date navigation information for drivers. Additionally, blockchain technology can be used to provide incentives for people to share information by rewarding vehicles for sharing their detections.

[0012] The method and system of sharing road detected changes using blockchain disclosed herein provides universal road detected changes for all map systems, so that all drivers have access to the latest maps. Furthermore, the method and system of sharing road detected changes using blockchain disclosed herein creates a reward system that motivates individuals to actively contribute to sharing road detected changes, which improves the quality and quantity of available data. This can result in more accurate and up-to-date map information. Furthermore, the use of blockchain and blockchain tokens or other forms of potential currency helps ensure the integrity and security of shared data, as the decentralized and immutable nature of blockchain makes it difficult to change or manipulate data once it is recorded.

[0013] Various embodiments of methods and systems for sharing detected changes in roads using blockchain are described in further detail herein. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.

[0014] As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, a reference to "a" element includes aspects having two or more such elements, unless the context clearly dictates otherwise.

[0015] As disclosed herein, a blockchain refers to a constantly growing set of data blocks. Each block can record a chunk of data, such as an approved road change. The blockchain may distribute these approved changes across a group of vehicles equipped with member computers or controllers that can process and store the blocks of the blockchain. Each vehicle may keep a copy of the approved changes. The blockchain may continuously grow a list of cryptographically linked and secured blocks. The blockchain may be resistant to data modification. The blockchain may implement a public distributed ledger that can record transactions between parties in an efficient, verifiable, and persistent manner.

[0016] FIG. 1 generally illustrates one embodiment of a distributed vehicular network 100. The distributed vehicular network 100 includes a number of vehicles 101. Each vehicle 110 is an independent node of the distributed vehicular network 100. Each vehicle 110 connects to any other vehicle 110 through a connection 120, where any vehicle 110 is a peer of another vehicle 110. The connections 120 allow the vehicles to communicate with each other. The vehicles 110 that connect to each other are neighboring nodes or neighboring vehicles. In an embodiment, the communication may follow a gossip protocol or a transmission control protocol. In a gossip protocol, a vehicle 110 communicates only to its neighbors through the connection 120 to send a block or operation. Once a vehicle 110 communicates a detected change or other data with one of its neighbors, the neighboring vehicle may continue to communicate with other neighbors as well until all vehicles 110 in the distributed vehicular network 100 have received the same detected change or data. In a transmission control protocol, the vehicles 110 communicate with each other directly through the Internet or a wireless network.

[0017] The vehicles 110 of the distributed vehicular network 100 may be, for example, automobiles, motorcycles, scooters, buses, recreational vehicles, boats, or other vehicles. The vehicles 110 may each include sensors 308, such as position sensors, proximity sensors, cameras, radar, or ultrasonic sensors (e.g., as shown in FIG. 3), to detect and record various states and conditions of the road and environment around the vehicle. For example, the sensors 308 may detect and store data corresponding to road changes, the location of the changes (e.g., GPS coordinates), temperature, rain, snow, light levels, and sun position (e.g., as shown in FIG. 3). Road changes relate to static features of the road, such as road geometry, traffic signs, lane lines, traffic patterns, and medium-term and long-term road construction. Medium-term construction may span from a few months to two years. Long-term construction may span years or decades and include large-scale infrastructure development. Medium-term and long-term construction activities may include residential or commercial construction, renovation and remodeling projects, and infrastructure development such as highways, bridges, tunnels, and airport construction. Data collected by sensors 308 (eg, as shown in FIG. 3) may be stored and / or analyzed by each vehicle 110.

[0018] The distributed vehicular network 100 includes a global blockchain 130. The global blockchain 130 includes multiple blocks 131. The blocks 131 may be cryptographically linked and secured. Each block 131 may include a cryptographic hash of the previous block, a timestamp, and information. Each block 131 stores changes to the road that are approved by at least a threshold number of vehicles 110 in the distributed vehicular network 100. The changes may relate to static characteristics of the road. The threshold number of vehicles 110 may be a specific number of vehicles or a percentage number of vehicles.

[0019] The data of a block, e.g., road changes, may be shared with multiple vehicles 101 of the distributed vehicular network 100. Each vehicle 110 may store a copy of the global blockchain 130 on the vehicle 110. However, a vehicle 110 may not write to its copy of the global blockchain 130 without approval from at least some of the multiple vehicles 101. The global blockchain 130 may be managed by multiple vehicles 101, who collectively follow a protocol for inter-node communication and validate new blocks. Once recorded, the data of a given block cannot be retroactively changed without modifying all subsequent blocks, which requires consensus among the multiple vehicles 101. The global blockchain 130 may include a main chain, which is the longest sequence of blocks from the start block to the current block, which was last added. The global blockchain 130 may include orphan blocks outside of the main chain. In some cases, an orphan block may be incorporated into a primary chain linked to a main chain block if the orphan block contains a verified record of a detected change corresponding to the same event and location as the data stored in the main chain block.

[0020] 2A and 2B, examples of partitioned groups 201 of a plurality of vehicles 101 of a distributed vehicular network are shown. A plurality of vehicles 101 of the distributed vehicular network 100 (e.g., as shown in FIG. 1) may be divided into partitioned groups 201 of vehicles 110. Each partitioned group 201 may include at least one vehicle 110. If the grouping is based on the location of the vehicles, the vehicles 110 of the partitioned group 201 are indicated as local vehicles. The grouping may be based on vehicle type, service provider, communication network, equipped sensors, or other similar criteria. As disclosed further below, the distributed vehicular network 100 (e.g., as shown in FIG. 1) may select a grouping strategy, e.g., based on the location of the vehicles 110, that allows the vehicles 110 of the partitioned group 201 to have more opportunities to verify the reported changes.

[0021] The split groups of vehicles may have different communication schemes, such as peer-to-peer and inter-group communication schemes, between vehicles belonging to different split groups. In some embodiments, the vehicles 110 of a split group 201 may directly communicate with the vehicles 110 of other split groups 201 (i.e., peer-to-peer communication scheme). For example, as shown in FIG. 2A, a number of vehicles 101 are split into three split groups 201. There are connections 120 between the vehicles 110 at the edge of a split group and other vehicles belonging to another split group. In such a case, communication across group boundaries may not require agreement between the vehicles 110 in the split group 201. In other embodiments, the vehicles 110 of a split group 201 may be restricted to communicate with the vehicles 110 in the split group, and the split group communicates with other split groups as a whole (i.e., inter-group communication scheme). For example, as shown in FIG. 2B, the vehicles of a split group 201 do not directly connect with other split groups 201. Instead, the split groups 201 connect to each other through group connections 220. In such cases, group conditions may need to be met. For example, when a vehicle 110 of a split group 101 detects a change in the road, such as a change in lane driving direction (e.g., as shown in FIG. 4), the vehicle 110 cannot communicate to vehicles outside the network until the group conditions are met. Such group conditions may be met by a majority vote or consensus algorithm on whether to communicate with other split groups 201. Once the group conditions are met, the vehicles 110 of a split group 201 can communicate with the vehicles 110 of other split groups 201.

[0022] 3, non-limiting components of an apparatus 300 onboard a vehicle of a distributed vehicular network are shown. A controller 301 of a vehicle of the distributed vehicular network may connect to a controller 301 of another vehicle through a connection 120. The controller 301 may include various components such as a memory 302, a processor 304, input / output hardware 305, network interface hardware 306, data storage elements 307, and a local interface 303. The controller 301 may include various sensors 308 such as proximity sensors, cameras, position sensors, temperature sensors, light sensors, and radar.

[0023] The controller 301 may be any device or combination of components comprising a processor 304 and a memory 302, such as a non-transitory computer-readable memory. The processor 304 may be any device capable of executing a set of machine-readable instructions stored in a non-transitory computer-readable memory. Thus, the processor 304 may be an electronic controller, an integrated circuit, a microchip, a computer, or any other computing device. The processor 304 may include any processing element configured to receive and execute programming instructions (e.g., from the data storage element 307 and / or the memory element 302). The instructions may be in the form of a set of machine-readable instructions stored in the data storage element 307 and / or the memory element 302. The processor 304 is communicatively connected to other components of the controller 301 by a local interface 303. Thus, the local interface 303 may communicatively connect any number of processors 304 to each other, enabling the components connected to the local interface 303 to operate in a distributed computing environment. The local interface 303 may be implemented as a bus or other interface to facilitate communication between the components of the controller 301. In some embodiments, each component may operate as a node that can transmit and / or receive data. Although the embodiment shown in FIG. 3 includes a single processor 304, other embodiments may include more than one processor 304.

[0024] The memory 302 (e.g., non-transitory computer readable memory elements) may include RAM, ROM, flash memory, hard disk, or any non-transitory memory device capable of storing machine readable instructions such that the machine readable instructions can be accessed and executed by the processor 304. The machine readable instruction set may include, for example, logic or algorithms written in any programming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, or 5GL), such as a machine language that can be directly executed by the processor 304, or an assembly language, object oriented programming (OOP), scripting language, microcode, etc. that can be compiled or assembled into machine readable instructions and stored in the memory 302. Alternatively, the machine readable instruction set may be written in a hardware description language (HDL), such as logic implemented via a field programmable gate array (FPGA) configuration or an application specific integrated circuit (ASIC), or equivalent thereof. Thus, the functionality described herein may be implemented in any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software elements. For example, memory element 302 may be a machine-readable memory (which may also be referred to as a non-transitory processor-readable memory or medium) that stores instructions that, when executed by processor 304, cause processor 304 to perform methods or control schemes as described herein. While the embodiment shown in FIG. 3 includes only one non-transitory computer-readable memory 302, other embodiments may include more than one memory module. Such program modules may include, but are not limited to, routines, subroutines, programs, objects, elements, and data structures for performing particular tasks or implementing particular abstract data types in accordance with the present disclosure, as described below.

[0025] Input / output hardware 305 may include a monitor, keyboard, mouse, printer, camera, microphone, speakers, and / or other devices for receiving, transmitting, and / or presenting data. Network interface hardware 306 may include any wired or wireless networking hardware, such as a modem, LAN port, WiFi card, WiMax card, mobile communication hardware, and / or other hardware for communicating with other networks and / or devices.

[0026] The data storage element 307 stores data such as the local blockchain 550, the global blockchain 130, changes 401, tokens 441, communication data between vehicles, and data generated by sensors.

[0027] 4, an example of a graphical representation of the operation of a distributed vehicular network is shown. A block 431 of a change 401 is incorporated into the global blockchain 130 when the change 401 is detected by a first vehicle 410 that first reports 411 the change in a distributed vehicular network 100 (e.g., as shown in FIG. 1) and at least a threshold number of vehicles 110 approve the change 401. In one example, a token 441 is awarded to the first vehicle 410. Another token 441 is awarded to a lucky vehicle 412. The lucky vehicle 412 is randomly selected from the approved vehicles 430 that approve the change 401.

[0028] A vehicle 110 of the plurality of vehicles 101 may include sensors 308, such as proximity sensors, cameras, light detection and ranging (LiDAR) sensors, etc., operable to automatically detect road changes 401 (e.g., as shown in FIG. 3). The changes 401 may relate to static features of the road. For example, the changes may relate to the geometric features of the road, traffic signs on the road, and medium-term and long-term road construction. The geometric features may include pavement width, horizontal and vertical alignment, lane separation of slope, intersections, and other features that affect the operation, safety, and capacity of the road. As shown in FIG. 4, a vehicle 410 detects a road change 401 in which the driving direction of the road has changed from one-way to two-way at a point. The vehicle 410 then decides to report the change 401 in the distributed vehicular network. When no other vehicle 110 in the distributed vehicular network has reported the change 401, the vehicle 410 becomes the first vehicle.

[0029] In an embodiment, a distributed vehicular network 100 (e.g., as shown in FIG. 1 ) publishes a change, which may be received by vehicles 110 of the distributed network through various methods. For example, under a transmission control protocol, the change may be received directly over the Internet or a wireless network, independent of connections 120 from neighboring vehicles. Under a gossip protocol, the data of the change may be first communicated through connections 120 to neighboring vehicles of the first vehicle, and then to neighboring vehicles of the vehicle that received the data of the change 401, until all vehicles 110 of the distributed vehicular network have received the data of the change 401.

[0030] After publishing and receiving the change 401, the vehicles 110 may vote for the change 401. The vote may be for, neutral, or against. The vehicles 110 that detect the same change 401 may vote for to approve the change 401. The vehicles 110 that vote for are the approving vehicles 430. In FIG. 4, there are four approving vehicles 430. The vehicles 110 other than the first vehicle 410 are operable to approve the change by detecting the change using a sensor, such as a proximity sensor. The first vehicle 410 may be operable to approve the change by redetecting the change using a sensor. The redetection may be accomplished by detecting the change while revisiting the site of the change. The redetection may be accomplished by detecting the change using a different sensor other than the sensor that originally discovered the change. For example, the first vehicle 410 may be equipped with a camera and a radar. The camera and the radar both detect the change 401 in the road. The same change detected by the radar may be used to approve the change detected by the camera.

[0031] Vehicles 110 that do not detect the same change 401 may cast a neutral or negative vote not approving the change. Vehicles 110 that cast a neutral or negative vote are non-approving vehicles 440. In FIG. 4, there are three non-approving vehicles 440. In some embodiments, the distributed vehicular network may take into account the negative votes against the change and reduce the total approval count accordingly. The total approval count may be equal to the total number of yes votes minus the total number of no votes. The distributed vehicular system may use the total approval count as well as the number of vehicles approving the change when deciding whether to include a block in the blockchain.

[0032] After all or at least a majority of the vehicles 110 vote in favor of the change, the distributed vehicular network may decide whether to incorporate the block 431 containing the change reported by the first vehicle into the global blockchain 130. If at least a threshold number of the vehicles 110 in the distributed vehicular network 100 approve (i.e., vote positively) the change, or if at least a threshold number of approvals is reached, the distributed vehicular network may agree to consolidate the block 431. The threshold number may be a specific number of vehicles or a percentage number of vehicles. The threshold number of vehicles may be set to a specific specific number or may be any number. In an embodiment, the specific number may range from 2 to 1,000. The specific number may be a specific set of values, such as, but not limited to, 2, 4, 6, 8, 10, 20, 40, 80, 100, 200, 400, 600, 800, 1000, or any number in between. Similarly, the threshold number of vehicles may be set as a percentage of the total number of vehicles in the network and may range from 1 to 100. In embodiments, the percentage number may be a particular set of values, such as 5, 10, 20, 30, 40, 50, 60, 70, 80, 90, or 100. Selecting a specific number or percentage number for the threshold number of vehicles may depend on various factors, such as the size of the distributed vehicular network 100, the density of nodes, the desired level of communication efficiency, and the reliability of the changes to be incorporated into the blockchain. In some embodiments, the threshold number of vehicles is based on the vehicles that may reach the site of the change.

[0033] 4, the threshold number of vehicles may be four or 50% of the vehicles. After determining four approved vehicles 430, the distributed vehicular network detects that at least the threshold number of vehicles have approved the change and incorporates block 431 into the global blockchain 130, including the main chain of block 131.

[0034] At times, a distributed vehicular network may publish a change that was previously reported by another vehicle 110. In such cases, the published change may be incorporated into an orphan block that is connected to the main chain block containing the same change.

[0035] After the block 431 is incorporated, the global blockchain 130 may be updated across multiple vehicles 101 and provided to various vendors 491, map systems 492, or servers 493 for application of changes such as map updates. Additionally, a token 441 may be given to the first vehicle 410. Another token 441 may be given to a lucky vehicle randomly selected from the vehicles that have accepted the change. Sometimes, more than one token may be given to the first vehicle 410 when the change 401 is validated as a road infrastructure change. A road infrastructure change is a process that results in a change or improvement of the physical elements of the road system. A road infrastructure change may be related to the safety or efficiency of road use, such as widening or narrowing roads, adding or removing intersections, redirecting traffic flow, rearranging roads, improving road surfaces, changing speed limits, adding or removing motorcycle lanes or sidewalks, etc. The road infrastructure change may be validated by the distributed vehicle network in a similar manner to the change approval, or may be validated by an off-network system such as an Internet of Things (IoT) system. The decentralized vehicular network may publish and update the reputation of the vehicles 110 based on the tokens owned by each vehicle. The vehicles 110 may request that the decentralized vehicular network provide services in exchange for at least one token. The decentralized vehicular network may provide services such as improvements to the in-vehicle map system, voting, and access to the platform.

[0036] 5A and 5B, examples of graphical representations of the operation of a distributed vehicular network with divided groups of vehicles are shown. The distributed vehicular network divides a plurality of vehicles into a plurality of vehicle groups, and each divided vehicle group may have its own local blockchain 550 including a plurality of local blocks 551. In FIG. 5A, only a divided group can communicate with another divided group, and a vehicle in a divided group cannot directly communicate with a vehicle in another divided group (i.e., inter-group communication method), while in FIG. 5B, a vehicle in a divided group can directly communicate with a vehicle in another divided group (i.e., peer-to-peer communication method).

[0037] In FIG. 5A and FIG. 5B, the plurality of vehicles 101 are divided into three divided groups 201. The groups may be divided based on the vehicle's location, and the vehicles in the divided groups may be referred to as location vehicles. The division of the groups may be based on other conditions, such as sensors installed on the vehicle. When a first vehicle 410 first reports 411 a road change, the change is published in one of the divided groups 201 instead of the entire plurality of vehicles 101. The distributed vehicular network may select the divided group 201 where the local vehicles are more likely to corroborate or invalidate the change as a whole. For example, the distributed vehicular network may select the divided group based on location when the local vehicles of the divided group are more likely to pass the scene of the change.

[0038] Once selected, the local vehicles of the selected group may vote to approve the change. The local vehicles that vote in favor of approving the change are shown as local approving vehicles 530, and the local vehicles that vote neutral or against the change are shown as local non-approving vehicles 540. In FIG. 5A and FIG. 5B, the split group 201 has four local approving vehicles 530 and three local non-approving vehicles 540. The distributed vehicular network then decides whether to incorporate the local block containing the change into the local blockchain 550 based on the number of local approving vehicles 530. The local block 553 may be incorporated into the local blockchain 550 once at least the local threshold number of local vehicles approve the change. The local threshold number may have similar characteristics to the threshold number described in FIG. 4. For example, in FIG. 5A, the local threshold number may be 50% of the local vehicles of the split group 201. Because more than 50% of the local vehicles in the split group 201 approve the change (4 out of 7 local vehicles approve the change), the local block 553 is incorporated into the local blockchain 550.

[0039] After the local blockchain 550 is incorporated, the distributed vehicular network may decide whether to publish the change to the multiple vehicles 101. In a group-to-group communication scheme such as FIG. 5A, the decision 562 of whether to publish the change to the multiple vehicles 101 may depend on whether a condition 561 is satisfied. The condition is whether the local blockchain 550 containing the change is incorporated into the local blockchain 550. After the condition 561 is satisfied, the change is published to other partitioned groups and received by the local vehicles for voting. In a peer-to-peer communication scheme such as FIG. 5B, the change may be published to the multiple vehicles 101 without the satisfaction of the condition 561.

[0040] After the change is published to the plurality of vehicles 101, the vehicles 110 of the plurality of vehicles vote for, neutral, or against the change. The distributed vehicular network then determines whether to incorporate the block 554 into the global blockchain 130 based on the approval by the vehicles 110 in a manner similar to that described in FIG. 4. After all or at least a majority of the vehicles 110 vote for the change, the distributed vehicular network may agree to incorporate the block 554 if at least a global threshold number of vehicles in the distributed vehicular network approve (i.e., vote positively) the change. The global threshold number of vehicles may be less than a majority of the plurality of vehicles 101, such as 30% of the plurality of vehicles 101, or 6 vehicles. For example, as shown in FIGS. 5A and 5B, 7 vehicles, or 1 / 3 of the plurality of vehicles approve the change. The distributed vehicular network determines that is enough to satisfy the conditions for integration and incorporates the block 554 containing the change into the global blockchain 130 including the block 131. In a peer-to-peer communication scheme such as FIG. 5A, the inclusion of a local block may be used as an additional condition in determining whether to include block 554 in the global blockchain 130.

[0041] Comparing the peer-to-peer communication scheme as in FIG. 5B and the inter-group communication scheme as in FIG. 5A, the inter-group communication scheme requires that the local block be incorporated into the local blockchain before publishing the change to the multiple vehicles 101. The advantage of the inter-group communication scheme is that the communication between the local vehicles may be faster and more efficient. Once the selected group decides not to incorporate the local block, the vehicles of the other split groups 201 do not need to vote for the change. The advantage of the peer-to-peer communication scheme is that the communication is more decentralized and resilient to failures. For example, when more vehicles outside the selected group may have visited the site of the change and are able to approve the change, the global block may be incorporated under the peer-to-peer communication scheme rather than under the inter-group scheme. Ultimately, the distributed vehicular network may choose between the two schemes, taking into account the number of vehicles 101, the communication technology employed for data transfer, and other factors related to change detection.

[0042] Referring to FIG. 6, a flow diagram of example steps for implementing a block in a blockchain of a distributed vehicular network is shown. In block 601, the method for implementing a block in a blockchain of a distributed vehicular network includes publishing a change to a road to a group including a local vehicle. In block 602, the method for implementing a block in a blockchain of a distributed vehicular network includes receiving an acknowledgement of the change from the local vehicle. In block 603, the method for implementing a block in a blockchain of a distributed vehicular network includes determining whether at least a local threshold number of local vehicles acknowledge the change. In block 604, the method for implementing a block in a blockchain of a distributed vehicular network includes incorporating the local block of changes into the local blockchain after determining that at least a local threshold number of local vehicles acknowledge the change. In block 605, the method for implementing a block in a blockchain of a distributed vehicular network includes publishing a change to a static characteristic of the road in the network, the change being detected by a first vehicle of the network. In block 606, the method for implementing a block in a blockchain of a distributed vehicular network includes receiving an acknowledgement of the change from a vehicle of the network. At block 607, the method for implementing the block on a blockchain of the distributed vehicular network includes determining whether at least a threshold number of vehicles of the network approve the change. At block 608, the method for implementing the block on a blockchain of the distributed vehicular network includes incorporating the block of the change into the global blockchain of the network after determining that at least the threshold number of vehicles of the network approve the change.

[0043] While particular embodiments have been illustrated and described herein, it should be understood that various other changes and modifications can be made without departing from the spirit and scope of the claimed subject matter. Moreover, although various aspects of the claimed subject matter have been described herein, such aspects need not be utilized in combination. It is therefore intended that the appended claims cover all such changes and modifications that are within the scope of the claimed subject matter.

[0044] It will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments described herein without departing from the scope of the claimed subject matter. Thus, this specification is intended to cover modifications and variations of the various embodiments described herein, provided such modifications and variations come within the scope of the appended claims and their equivalents.

Claims

1. 1. A network comprising: a vehicle operable to detect changes in a road; and a global blockchain comprising blocks of changes, the change is detected by a first vehicle in the network that first published the change, and when at least a threshold number of the vehicles approve the change, the block of changes is incorporated into the global blockchain; A token is provided to the first vehicle.

2. The network of claim 1 , wherein the changes relate to static characteristics of the road, the static characteristics including geometric features of the road, traffic signs on the road, and construction of the road in the medium and long term.

3. The network of claim 1 , wherein the network publishes a reputation for each vehicle based on the tokens owned by the vehicle.

4. The network of claim 1 , wherein the network provides services to vehicles in exchange for at least one token.

5. The network of claim 1 , wherein a plurality of tokens are provided to the first vehicle when the change is verified as a road infrastructure modification.

6. The network of claim 1 , wherein a token is awarded to a lucky vehicle randomly selected from the vehicles that accept the change.

7. The network of claim 1 , wherein vehicles other than the first vehicle are operable to acknowledge the change by detecting the change using a sensor.

8. The network of claim 1 , wherein the first vehicle is operable to acknowledge the change by redetecting the change with a sensor.

9. The network of claim 1 , wherein the threshold number of vehicles is 50% of the vehicles.

10. vehicles operable to detect changes in a roadway, the vehicles being divided into a group of local vehicles; a plurality of local blockchains comprising local blocks of changes, the blocks of changes being incorporated into the local blockchains after a first vehicle publishes the road changes among a group of local vehicles and when at least a local threshold number of the local vehicles approve the changes; a global blockchain comprising a block of mutations, the mutations being included in a local block, and the block of mutations being incorporated into the global blockchain once at least a global threshold number of the vehicles have approved the mutations.

11. The network of claim 10 , wherein the changes of the road relate to static characteristics of the road, the static characteristics including geometric features of the road, traffic signs on the road, and construction of the road in the medium and long term.

12. The network of claim 10 , wherein vehicles other than the first vehicle are operable to acknowledge the change by detecting the change using a sensor.

13. The network of claim 10 , wherein the first vehicle is operable to acknowledge the change by redetecting the change with a sensor.

14. The network of claim 10 , wherein the global threshold number of vehicles is 50% of the vehicles and the local threshold number of local vehicles is 50% of the local vehicles.

15. publishing changes in static characteristics of roads in a network detected by a first vehicle in said network; receiving an acknowledgement of the change from a vehicle in the network; and determining whether at least a threshold number of the vehicles in the network approve the change; incorporating the block of changes into a global blockchain for the network after determining that at least a threshold number of the vehicles in the network have approved the changes.

16. Prior to publishing the changes in static characteristics of the road within the network, the method comprises: publishing the road changes to a group including the local vehicle; receiving an acknowledgement of the change from the local vehicle; and determining whether at least a local threshold number of said local vehicles approve said change; 16. The method of claim 15, further comprising incorporating the local block of changes into a local blockchain after determining that at least the local threshold number of the local vehicles have approved the changes.

17. The method of claim 15 , wherein approval from a vehicle other than the first vehicle is produced by detecting the change with a sensor.

18. The method of claim 15 , wherein the acknowledgement from the first vehicle is produced by redetecting the change with a sensor.

19. The method of claim 15, further comprising granting a token to the first vehicle after determining that at least a threshold number of the vehicles in the network have approved the change.

20. 16. The method of claim 15, further comprising, after determining that at least a threshold number of the vehicles in the network have accepted the change, awarding a token to a lucky vehicle randomly selected from the vehicles that accepted the change.

Images