Transportation vehicle software update management

Abstract

Example operations can include one or more of receiving the software update at a subset of the vehicles, verifying the software update based on one or more of a time period when the software update was in use and a number of times the subset of vehicles utilized the software update, propagating the software update to another subset of the vehicles based on the verifying, where the another subset of vehicles is greater than the subset of vehicles.

Description

Background Technology

[0001] Vehicles or means of transport, such as cars, motorcycles, trucks, airplanes, and trains, typically provide transportation services for passengers and / or goods in various ways. The functions associated with these means of transport can be recognized and utilized by various computing devices such as smartphones, computers, or tablets.

[0002] Software updates for transportation vehicles are typically performed from a central server that delivers one or more software updates to each individual vehicle's client computer. This usually requires a network connection to the cloud. However, the widespread use of WANs to distribute software updates is inefficient and potentially insecure. Furthermore, software updates may not be adequately tested on a sufficiently large number of transportation vehicles before being sent to the server. There is no centralized system available that can collect and securely and efficiently track information related to software updates from millions of transportation vehicles.

[0003] Therefore, it is desirable to have secure dissemination of transportation software updates based on extensive testing across a large number of transportation vehicles. It is also desirable to log information related to software updates on shared storage devices. Summary of the Invention

[0004] An example embodiment may provide a method comprising: receiving a software update at a vehicle of a subset of vehicles; verifying the software update based on one or more of the following: a period of time during which the software update was in use, and the number of times the subset of vehicles utilized the software update; and propagating the software update to another subset of vehicles based on the verification, wherein the other subset of vehicles is larger than the subset of vehicles.

[0005] Another example embodiment may provide a method comprising one or more of the following: sending a first portion of a software update to a first subset of vehicles via a master vehicle; sending a second portion of a software update to a second subset of vehicles via the master vehicle when the first vehicle of the first subset of vehicles and a second vehicle of another subset of vehicles are close together; causing the first vehicle to send the first portion of the software update to the second vehicle, and causing the second vehicle to send the second portion of the software update to the first vehicle.

[0006] Another example embodiment may provide a method comprising one or more of the following: receiving a software update at a vehicle; performing a first verification of the software update in a first environment, wherein the first environment includes a minimum number of potential interactions; and performing another verification of the software update in a second environment, wherein the second environment includes a greater number of potential interactions than the first environment, when the first verification is successful.

[0007] Another example embodiment may provide a system including a processor and memory, wherein the processor of a subset of the transport vehicles is configured to perform one or more of the following: receiving a software update; verifying the software update based on one or more of the following: the time period during which the software update is in use, and the number of times the subset of transport vehicles utilizes the software update; and propagating the software update to another subset of the transport vehicles based on the verification, wherein the other subset of the transport vehicles is larger than the subset of the transport vehicles.

[0008] Another example embodiment may provide a system including a processor and memory, wherein the processor of the main transport vehicle is configured to perform one or more of the following: sending a first portion of a software update to a first subset of the transport vehicles; sending a second portion of a software update to the other subset of the transport vehicles when the first transport vehicle of the first subset of the transport vehicles and the second transport vehicle of the other subset of the transport vehicles are close together; causing the first transport vehicle to send the first portion of the software update to the second transport vehicle, and causing the second transport vehicle to send the second portion of the software update to the first transport vehicle.

[0009] Another example embodiment may provide a system including a processor and memory, wherein the processor is configured to perform one or more of the following: receiving a software update at a vehicle; performing a first verification of the software update in a first environment, wherein the first environment includes a minimum number of potential interactions; and performing another verification of the software update in a second environment, wherein the second environment includes a greater number of potential interactions than the first environment, when the first verification is successful.

[0010] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor of a subset of the means of transport, cause the processor to perform one or more of the following: receive a software update; verify the software update based on one or more of the following: the time period during which the software update is in use, and the number of times the subset of the means of transport utilizes the software update; and propagate the software update to another subset of the means of transport based on the verification, wherein the other subset of the means of transport is larger than the subset of the means of transport.

[0011] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: sending a first portion of a software update to a vehicle of a first subset of vehicles; sending a second portion of a software update to a vehicle of the other subset of vehicles when the first vehicle of the subset of vehicles and a second vehicle of another subset of vehicles are close together; causing the first vehicle to send the first portion of the software update to the second vehicle, and causing the second vehicle to send the second portion of the software update to the first vehicle.

[0012] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a software update; performing a first verification of the software update in a first environment, wherein the first environment includes a minimum number of potential interactions; and, when the first verification is successful, performing another verification of the software update in another environment, wherein the other environment includes a greater number of potential interactions than the first environment. Attached Figure Description

[0013] Figure 1A The illustration depicts a network diagram of one or more means of transport according to an example embodiment.

[0014] Figure 1B The illustration shows an example network diagram including transportation node according to an example embodiment.

[0015] Figure 1C The illustration shows another example network diagram including transportation node according to an example embodiment.

[0016] Figure 1D The illustration shows another example network diagram including transportation node according to an example embodiment.

[0017] Figure 2A The diagram illustrates a blockchain architecture configuration according to an example embodiment.

[0018] Figure 2B Another blockchain configuration according to an example embodiment is illustrated.

[0019] Figure 2C The illustration shows a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0020] Figure 3A A flowchart according to an example embodiment is illustrated.

[0021] Figure 3B Another flowchart according to an example embodiment is illustrated.

[0022] Figure 3C Another flowchart according to an example embodiment is illustrated.

[0023] Figure 3D Another flowchart according to an example embodiment is illustrated.

[0024] Figure 3E Another flowchart according to an example embodiment is illustrated.

[0025] Figure 3F Another flowchart according to an example embodiment is illustrated.

[0026] Figure 4A The illustration shows an example blockchain vehicle configuration for managing blockchain transactions associated with a vehicle, according to an example embodiment.

[0027] Figure 4B The illustration shows another example blockchain vehicle configuration for managing blockchain transactions between a service center and a vehicle, according to an example embodiment.

[0028] Figure 4C The illustration shows yet another example blockchain vehicle configuration for managing blockchain transactions between various vehicles, according to an example embodiment.

[0029] Figure 5 An example data block according to an example embodiment is illustrated.

[0030] Figure 6 An example system supporting one or more example embodiments is illustrated. Detailed Implementation

[0031] It will be readily understood that the components described and illustrated herein, as generally presented in the figures, can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transitory computer-readable media, and systems shown in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments.

[0032] The features, structures, or characteristics described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the phrases "example embodiment," "some embodiments," or other similar language refer to the fact that a particular feature, structure, or characteristic described in connection with that embodiment can be included in one embodiment. Therefore, the phrases "example embodiment," "some embodiments," "in other embodiments," or other similar language appearing throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the various figures, even if the connections drawn are unidirectional or bidirectional arrows, any connection between elements may allow unidirectional and / or bidirectional communication. In the present application, means of transport may include one or more of automobiles, trucks, motorcycles, scooters, bicycles, ships, recreational vehicles, aircraft, and any object that can be used to transport people and / or goods from one location to another.

[0033] Furthermore, although the term "message" may have been used in the description of the embodiments, this application can be applied to many types of network data, such as packets, frames, datagrams, etc. The term "message" also includes packets, frames, datagrams, and any equivalent forms thereof. Moreover, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to a specific type of message, and this application is not limited to a specific type of signaling.

[0034] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of the following: a transportation vehicle (also referred to herein as a vehicle) data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status data received in the form of communication update messages (such as wireless data network communications and / or wired communication messages) can be received and processed to identify vehicle / transportation vehicle status and provide feedback on changes in the status of the transportation vehicle. In one example, a user profile can be applied to a specific transportation vehicle / vehicle to authorize current vehicle events, service stops at service stations, and authorization of subsequent vehicle rental services.

[0035] Within communication infrastructure, a decentralized database is a distributed storage system comprising multiple nodes that communicate with each other. A blockchain is an example of a decentralized database, comprising an append-only, immutable data structure (i.e., a distributed ledger) capable of maintaining records between untrusted parties. These untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage entries, group storage entries into blocks, and construct a hash chain via these blocks. For consistency, this process forms the ledger by ordering storage entries as needed. In public or permissionless blockchains, any party can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide a system that can secure interactions between a group of entities sharing common goals but not fully trusting or unable to fully trust each other (such as businesses exchanging funds, goods, information, etc.). This application can work in both licensed and / or permissionless blockchain settings.

[0036] Smart contracts are trusted, distributed applications that leverage the tamper-proof properties of a shared or distributed ledger (i.e., possibly in the form of a blockchain) database and a fundamental protocol among member nodes known as endorsement or endorsement policy. Generally, blockchain entries are "endorsed" before being submitted to the blockchain, while unendorsed entries are ignored. A typical endorsement policy allows the smart contract's executable code to specify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to the peers specified in the endorsement policy, the entry is executed to verify it. After verification, the entry enters a sorting phase, where a consensus protocol is used to produce an ordered sequence of endorsed entries grouped into blocks.

[0037] A node is a communication entity in a blockchain system. In the sense that multiple nodes of different types can run on the same physical server, a "node" can perform logical functions. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or commit client nodes, which submit entry requests to endorsers (e.g., peers) and broadcast entry suggestions to the ordering service (e.g., ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit entries, and maintain the state and copies of the ledger of blockchain entries. Peers can also have the role of endorser, but this is not required. Ordering service nodes, or orderers, are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasts to every peer in the system when an entry is submitted and the world state of the blockchain is modified (it is another name for the initial blockchain entry, which typically contains control and setup information).

[0038] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be caused by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, etc. The ledger includes a blockchain (also called a chain), which is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Each channel typically has its own ledger. Each peer node maintains a copy of the ledger for each channel for which it is a member.

[0039] A chain is a log of entries constructed as a hashed chain of blocks, with each block containing a sequence of N entries, where N is equal to or greater than 1. The block header includes the hash of the block's entries, as well as the hash of the header of the previous block. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash chain. The hash of the most recently added blockchain block represents every entry that arrived on the chain before it, ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer-to-peer file system (i.e., local, attached storage, cloud, etc.) to efficiently support the append-only nature of blockchain workloads.

[0040] The current state of an immutable ledger represents the latest value of all keys contained in the chain's entry log. Because the current state represents the latest key-value pair known to the channel, it is sometimes referred to as the world state. Smart contract executables invoke execution entries based on the ledger's current state data. To enable efficient interaction between these smart contract executables, the latest value of the key can be stored in a state database. The state database can simply be an indexed view of the chain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) when peers start up and before entries are accepted.

[0041] The difference between blockchain and traditional databases is that blockchain is not a centralized store, but a decentralized, immutable, and secure store, where nodes must share changes to the records in the store. Some inherent properties of blockchain that contribute to its implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0042] Example embodiments provide a method for providing vehicle services to a specific vehicle and / or a requesting user associated with a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or the operator of a vehicle owned by another party. The vehicle may need to be serviced at certain intervals, and service requests may require authorization before service can be received. Furthermore, a service center may provide services to vehicles in a nearby area based on the vehicle's current route plan and relative service level requirements (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand may be monitored via one or more sensors, which report the sensed data to a central controller computer device in the vehicle, and the vehicle demand is then forwarded to a management server for review and action.

[0043] Sensors can be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object separate from the vehicle, and on another vehicle near the vehicle. Sensors can also be associated with the vehicle's speed, braking, acceleration, fuel level, service demand, gear shifting, steering, etc. The concept of a sensor can also be a device, such as a mobile device. Similarly, sensor information can be used to identify whether a vehicle is operating safely and whether occupants have been involved in any unexpected vehicle conditions, such as during vehicle entry. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger determined by a licensing group, thus being "decentralized," such as via a blockchain membership group. Each stakeholder (i.e., corporations, agents, etc.) may wish to restrict the disclosure of private information; therefore, the blockchain and its immutability can limit public information and manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when services are needed, identify conflict and / or degrade events, identify safety-related issues, identify parties to an event, and distribute the data to registered entities seeking access to such vehicle event data. Similarly, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on a blockchain-associated "consensus" approach. Such methods cannot be implemented on traditional centralized databases.

[0044] Every autonomous driving system is built on a complete suite of software and sensor arrays. Machine learning, LiDAR projectors, radar, and ultrasonic sensors work together to create a vivid world map that the self-driving car can navigate. Most companies competing for full autonomy rely on the same basic technological foundation of LiDAR + radar + camera + ultrasonic sensors, but there are some notable exceptions.

[0045] In another embodiment, GPS, mapping, and other cameras and sensors are used in autonomous vehicles without LiDAR, as LiDAR is generally considered expensive and unnecessary. Researchers have determined that stereo cameras are a low-cost alternative to the more expensive capabilities of LiDAR.

[0046] In some embodiments, the application includes authorizing a vehicle to provide service via an automated and rapid authentication scheme. For example, a vehicle operator may drive to a charging station or fuel pump, and authorization to receive charge or fuel can be performed without delay as soon as the service station receives authorization. The vehicle may provide a communication signal that identifies it with a current activity profile linked to an authorized account for receiving service, which can then be corrected through compensation. Other measures may be used to provide further authentication, such as another identifier that can be wirelessly transmitted from the user's device to the service center to replace or supplement the initial authorization process between the vehicle and the service center through additional authorization work.

[0047] Shared and received data can be stored in a database that maintains the data in a single location (e.g., a database server). This location is typically a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database can usually be accessed from multiple different points. Centralized databases are easy to manage, maintain, and control, especially for security purposes, because they are located in a single location. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a given set of data has only one master record.

[0048] According to an exemplary embodiment, a method for propagating software updates to vehicles without using WAN technology is provided. One exemplary embodiment allows the software update to be propagated only after testing has been performed by a first group of vehicles. Testing can be performed over a period of time or in multiple executions of the software update code. When the software test fails, the vehicle receives an alert, and the software on the vehicle can be reverted to a previous software version.

[0049] In another embodiment, the primary transportation system can allow for additional security when the software update is split into at least two parts and distributed to vehicles by sending the software update parts at different times and / or from different sources. In one exemplary embodiment, the software update may first be sent from the primary transportation vehicle. Exemplary embodiments may provide decentralized distribution of the software update, wherein the update is authenticated via blockchain technology.

[0050] According to an exemplary embodiment, the master vehicle can determine which part of the software update is given to which vehicle based on the characteristics of the vehicle (e.g., the vehicle's security level, the vehicle's age, the hardware in the vehicle capable of correctly executing the software, the vehicle's condition, the characteristics of the vehicle's users / occupants, and the use of features in or related to the vehicle). The update can be provided based on its potential use, such as which vehicle is better able to test / utilize the software update. In one example, vehicle 1 may receive the first part of the update (ABC), and vehicle 2 may receive another part of the update (ABC') from the same master vehicle. The software update may be divided into more than two parts—for example, some vehicles may receive two parts, some three parts, and some n parts. The master vehicle may have a higher security level than a subset of the vehicles and another subset of the vehicles. Any problems with the software update can be reported back to the master vehicle (which can then report it back to a central server). When any part of the update or the first and second parts of the assembly have a problem, the master vehicle can be moved to the vicinity of the problematic vehicle and can monitor the vehicle to identify and resolve the problem.

[0051] In yet another exemplary embodiment, once one or more software updates are received, assembled, and executed, the vehicle continues to run the old software version and intermittently uses the new updated software with minimal potential problems. For example, if a brake software update is made, the vehicle can use the updated software when traffic is minimal in the driving environment (and there are no pedestrians and / or objects). Once the updated software has been validated in such a driving environment, the vehicle can use the updated software in different potentially problematic driving environments (e.g., with more traffic, pedestrians, and / or objects). According to the exemplary embodiment, the driver of the vehicle may not be aware of the functionality of the software update management application. The vehicle's system can progressively test one or more software updates in different environments and, if necessary, revert to a previous version of the software.

[0052] In yet another embodiment, the primary vehicle determines which part is given to which vehicle based on vehicle characteristics (e.g., vehicle safety level, vehicle age, hardware in the vehicle capable of correctly executing the software, vehicle condition, characteristics of the vehicle's users / occupants, and the use of features in or related to the vehicle). Updates may be based on the possible uses of the update, for example, which vehicle is better able to test / utilize the software.

[0053] In yet another embodiment, different vehicles may assemble parts of the software based on the time or date of submission, vehicle and / or software and / or user characteristics. For example, vehicle 1 may obtain a first part (ABC), and the next vehicle to vehicle 2 may obtain a first part (ABC') from the same main vehicle (i.e., the first parts may be different).

[0054] In yet another embodiment, the software update can be divided into more than two parts. Some vehicles can receive two parts, some receive three parts, and some receive n parts.

[0055] In yet another embodiment, the main vehicle includes one or more of the security levels of a subset of the vehicle and another subset of the vehicle, a first portion of the software update, and a second portion of the software update.

[0056] In yet another embodiment, any problems with the software are reported back to the main transport vehicle (which may be reported back to the central server).

[0057] In yet another embodiment, when any part of the update or the first and second parts of the assembly have a problem, the main transport vehicle can approach the transport vehicle in problem and monitor and access the problem.

[0058] Figure 1A A network diagram 100 of one or more transportation vehicles according to an exemplary embodiment is illustrated. According to one exemplary embodiment, a processor 104' of a subset of transportation vehicles (e.g., 105) can be configured to receive software updates. The software updates can be provided by a master transportation vehicle node (e.g., 102). The processor 104' can validate the software update based on the time period during which the software update is used by the transportation vehicle (e.g., 105). In one example, the processor 104' can validate the software update based on the number of times the software update is used by the subset of transportation vehicles (e.g., 105). Based on the validation, the processor 104' can propagate the software update to another subset of transportation vehicles (e.g., 107). The subset 107 of transportation vehicles is larger than the subset 105 of transportation vehicles.

[0059] According to another exemplary embodiment, the processor 104 of the main vehicle 102 can be configured to send a first portion of the software update to vehicles of a first subset of vehicles 105. The processor 104 of the main vehicle 102 can also send a second portion of the software update to vehicles of another subset of vehicles 107. Then, when the first vehicles of the subset of vehicles 105 and the second vehicles of the other subset of vehicles 107 approach each other, the processor 104 can send a command to the first vehicle 105 to send the first portion of the software update to the second vehicle 107. Then, the processor 104 can send a command to the second vehicle to send the second portion of the software update to the first vehicle 105. Therefore, the processors 104' and 104'" of each vehicle 105 and 107 can assemble a complete software update.

[0060] According to yet another exemplary embodiment, processor 104' (or 104") may be configured to receive a software update (e.g., from master vehicle node 102) and perform a first verification of the software update in a first environment. The first environment may include a minimum amount of potential interactions (minimal traffic, no pedestrians, normal weather conditions, etc.). Then, when the first verification is successful, processor 104' (or 104") may perform another verification of the software update in another environment. The other environment may include a greater amount of potential interactions than the first environment (e.g., more traffic, pedestrians, severe weather conditions, etc.).

[0061] Figure 1B The diagram illustrates a network used to manage software updates. (Reference) Figure 1B Network diagram 111 includes a subset of transportation nodes 102 connected to another subset of transportation node 105 via blockchain network 106. Transportation nodes 102 and 105 may represent transportation vehicles. Blockchain network 106 may have a ledger 108 for storing data, such as software update-related data including timestamps of software updates. Transportation node 102 may be connected to other subsets of transportation nodes (not shown).

[0062] Although this example describes only one transportation node 102 in detail, multiple such nodes can be connected to the blockchain 106. It should be understood that the transportation node 102 may include additional components, and some components described herein may be removed and / or modified without departing from the scope of the transportation node 102 disclosed herein. The transportation node 102 may have computing devices or server computers, and may include a processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or other hardware device. Although a single processor 104 is depicted, it should be understood that the transportation node 102 may include multiple processors, multiple cores, etc., without departing from the scope of the transportation node 102 system.

[0063] The transport node 102 may also include a non-transitory computer-readable medium 112 on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 114-118 and discussed further below. Examples of the non-transitory computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store the executable instructions. For example, the non-transitory computer-readable medium 112 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0064] Processor 104 can execute machine-readable instructions 114 to receive software updates at vehicle 104. Each of vehicles 102 and 105 can serve as a network peer (i.e., node) on blockchain 106. As described above, blockchain ledger 108 can store transactions related to software updates. The blockchain 106 network can be configured to use one or more smart contracts located on vehicle (i.e., node) 102, which can manage transactions of other participating vehicle nodes 105. Vehicle node 102 can provide information to blockchain 106 for storage on ledger 108.

[0065] Processor 104 can execute machine-readable instructions 116 to verify a software update. The software update can be verified based on the time period in which it was used and the number of times it was utilized by a subset of transport vehicles 102. Processor 104 can execute machine-readable instructions 118 to propagate the software update to another subset of transport vehicles (e.g., 105) based on the verification. This other subset of transport vehicles 105 is larger than the subset of transport vehicles 102.

[0066] Figure 1C The diagram illustrates a network used to manage software updates for transportation vehicles. (Reference) Figure 1CNetwork diagram 121 includes a transportation node 102 serving as the primary transportation node, connected to other transportation nodes 105 and 107 via a blockchain network 106, which has a ledger 108 for storing software update-related transactions 110. Transportation nodes 102, 105, and 107 can also serve as peers of blockchain 106. While this example describes only one primary transportation node 102 in detail, multiple such nodes can be connected to blockchain 106. It should be understood that the primary transportation node 102 may include additional components, and some components described herein may be removed and / or modified without departing from the scope of the primary transportation node 102 disclosed herein. The primary transportation node 102 may have computing devices or server computers, and may include a processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or other hardware device. Although a single processor 104 is depicted, it should be understood that the main transport node 102 may include multiple processors, multiple cores, etc., without departing from the scope of the main transport node 102.

[0067] The main transport node 102 may also include a non-transitory computer-readable medium 112' on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 113-117 and discussed further below. Examples of non-transitory computer-readable medium 112' may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, non-transitory computer-readable medium 112' may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0068] Processor 104 can execute machine-readable instructions 112' to send a first portion of the software update to a first subset of the vehicles of vehicle 113. Blockchain 106 can be configured to use one or more smart contracts that manage transactions among multiple participating nodes (e.g., 105 and 107). Master vehicle node 102 can provide software update-related information to blockchain 106, and the transaction can be stored on ledger 108.

[0069] Processor 104 can execute machine-readable instructions 115 to send a second portion of the software update to another subset of the vehicles (e.g., 107). When a first vehicle of a subset of vehicles 105 and a second vehicle of another subset of vehicles 107 approach each other, processor 104 can execute machine-readable instructions 117: causing the first vehicle to send a first portion of the software update to the second vehicle, and causing the second vehicle 107 to send a second portion of the software update to the first vehicle 105.

[0070] Figure 1D The diagram illustrates a network used to manage software updates for transportation vehicles. (Reference) Figure 1D Network diagram 130 includes a transportation node 102 (e.g., a vehicle) connected to other transportation nodes 105 via a blockchain network 106, which has a ledger 108 for storing software verification data and transactions 110. Transportation nodes 102 and 105 can also serve as peers of blockchain 106. While this example describes only one transportation node 102 in detail, multiple such nodes can be connected to blockchain 106. It should be understood that transportation node 102 may include additional components, and some components described herein may be removed and / or modified without departing from the scope of transportation node 102 disclosed herein. Transportation node 102 may have computing devices or server computers, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or other hardware device. Although a single processor 104 is depicted, it should be understood that transportation node 102 may include multiple processors, multiple cores, etc., without departing from the scope of transportation node 102.

[0071] The transport node 102 may also include a non-transitory computer-readable medium 112”, on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 132-136 and discussed further below. Examples of the non-transitory computer-readable medium 112” may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer-readable medium 112” may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0072] Processor 104 can execute machine-readable instructions 132 to receive software updates at vehicle 102. Blockchain 106 can be configured to use one or more smart contracts that manage transactions involving multiple participating nodes 105 of the vehicle. Vehicle 102 can provide verification information related to the software update to blockchain 106, and the transaction can be stored on ledger 108.

[0073] Processor 104 can execute machine-readable instructions 134 to perform a first verification of the software update in a first environment, wherein the first environment includes a minimal number of potential interactions. When the first verification is successful, processor 104 can execute machine-readable instructions 136 to perform another verification of the software update in a different environment. The other environment may include a greater number of potential interactions than the first environment.

[0074] Figure 2A The illustration shows a blockchain architecture configuration 200 according to an example embodiment. (Reference) Figure 2A The blockchain architecture 200 may include certain blockchain elements, such as a group of blockchain member nodes 202-206 as part of blockchain group 210. In one example embodiment, the permissioned blockchain is not accessible to all parties, but only to those members with permitted access rights to the blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processes (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and attempt to write to the immutable blockchain ledger stored in the blockchain, copies of which may also be stored on the underlying physical infrastructure.

[0075] When blockchain transaction 220 is received and approved by the consensus model defined by the member nodes, the transaction is stored in the computer's memory. Approved transactions 226 are stored in the current block of the blockchain and submitted to the blockchain via a submission process that includes hashing the data content of the transactions in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 230 may exist, whose definitions include terms of transaction protocols and actions in the smart contract executable application code 232, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. This code can be configured to identify whether requesting entities are registered to receive vehicle services, which service characteristics they are entitled to / required to receive given their profile status, and whether their actions are monitored in subsequent events. For example, when a service event occurs and a user is riding in the vehicle, sensor data monitoring can be triggered, and a parameter (e.g., vehicle charging level) can be identified as being above / below a specific threshold for a specific time period. The result might then be a change to the current state, which requires sending an alert to management (e.g., vehicle owner, vehicle operator, server, etc.) so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's state. Sensor data can also form the basis of vehicle event data 234, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, whether there have been any collisions, whether the expected route has been taken, the next destination, whether safety measures are in place, whether the vehicle has sufficient battery / fuel, etc. All this information can serve as the basis for smart contract terms 230, which are then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary and when and where the service should be performed.

[0076] Figure 2B The illustration shows a shared ledger configuration according to an example embodiment. (Reference) Figure 2B Blockchain logic example 250 includes a blockchain application interface 252, which serves as an API or plug-in application linked to computing devices and execution platforms for specific transactions. Blockchain configuration 250 may include one or more applications linked to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.) that can be created according to a customized configuration sought by the participants, and can maintain its own state, control its own assets, and receive external information. This can be deployed as entries and installed on all blockchain nodes via attachment to the distributed ledger.

[0077] Smart contract application code 254 provides the foundation for blockchain transactions by establishing application code that, upon execution, activates the terms and conditions of the transactions. Smart contract 230, upon execution, causes the generation of certain approved transactions 226, which are then forwarded to the blockchain platform 262. This platform includes security / authorization 268, computing devices for transaction management 266, and a storage component 264 that serves as a repository for storing transactions and smart contracts within the blockchain.

[0078] A blockchain platform can include blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and various layers of underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain can expose interfaces that provide access to the processing code and the virtual execution environment required to interface with the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and keep information confidential.

[0079] Figure 2A and Figure 2B The blockchain architecture configuration can process and execute program / application code through one or more interfaces and services exposed by the blockchain platform. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications regarding changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, this information may include a new entry, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The result may include deciding to reject or approve the new entry based on criteria defined in the smart contract and / or the consensus of the peers. Any data or information described herein can be retrieved using physical infrastructure.

[0080] Within the executable code of a smart contract, smart contracts can be created using high-level applications and programming languages ​​and then written into blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of smart contract code, which can be executed in response to the satisfaction of conditions associated with the smart contract. The execution of a smart contract can trigger one or more trusted modifications to the state of the digital blockchain ledger. The modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0081] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by smart contracts is maintained in memory by the provisioned execution environment and is then deleted once the data required by the blockchain is identified.

[0082] Executable code for a smart contract can include a code interpretation of the smart contract, as well as additional features. As described herein, executable code for a smart contract can be program code deployed on a computing network, where it is executed and verified together by chain validators during consensus processing. The executable code receives hashes and retrieves hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created from the stored identifier template data, the executable code for the smart contract sends an authorization key to the requested service. The executable code for the smart contract can also write data associated with cryptographic details to the blockchain.

[0083] Figure 2C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Reference) Figure 2C Example configuration 270 provides information sharing with a distributed ledger (i.e., blockchain) 278 for vehicle 272, user equipment 274, and server 276. The server may represent a service provider entity that, in the event that a known and established user profile is attempting to lease a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 276 may be receiving and processing data related to vehicle service requests. As service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 280 is stored for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., age of 18, qualified candidates, valid driver's license, etc.), compensation level, distance traveled during the event, recipient of registration to allow entry into the event and preside over vehicle service, permissions / permissions, sensor data retrieved during the vehicle event, details of recording the next service event and operations to identify the vehicle's condition status, and thresholds for determining whether the service event has been completed and whether the vehicle's condition status has changed.

[0084] Figure 3A A flowchart 300 according to an example embodiment is illustrated. (Reference) Figure 3A Example methods can be provided by transportation node 102 (see...) Figure 1B ) Execution. It should be understood that, Figure 3A The method 300 described herein may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of method 300. For illustrative purposes, reference is also made to... Figure 1B The features described herein are used to describe method 300. In particular, the processor 104 of the transport node 102 can perform some or all of the operations included in method 300.

[0085] refer to Figure 3A At block 302, processor 104 may receive software updates at the transportation vehicle. At block 304, processor 104 may verify the software update based on one or more of the following: the time period during which the software update was used and the number of times the software update was utilized by a subset of the transportation vehicle. At block 306, processor 104 may propagate the software update to another subset of the transportation vehicle based on the verification. This other subset of the transportation vehicle may be larger than the original subset of the transportation vehicle.

[0086] Figure 3B A flowchart 320 illustrating an example method according to an example embodiment is shown. (Reference) Figure 3B Method 320 may further include one or more of the following steps. At block 322, processor 104 may propagate the software update to a set of all remaining vehicles, wherein the set of all remaining vehicles is greater than another subset of vehicles. The subset of vehicles, the other subset of vehicles, and the set of all remaining vehicles are based on one or more of the following: existing software, existing hardware, geographic location, ambient temperature, vehicle brand, vehicle model, vehicle condition, road conditions, and vehicle destination.

[0087] At box 324, when a negative result is determined based on verification, processor 104 may perform one or more of the following: modifying a subset of the vehicles, another subset of the vehicles, and one or more of the set of all remaining vehicles; and restoring a subset of the vehicles, another subset of the vehicles, and one or more of the set of all remaining vehicles to one or more of the initial version of the software and previous software updates. At box 326, processor 104 may use the software update for: a subset of the vehicles reaching a first time value, and another subset of the vehicles reaching a second time value, wherein the first time value is greater than the second time value. The subset of vehicles may belong to a blockchain network. At box 328, processor 104 may execute a smart contract of the blockchain network to verify the software update and propagate the software update through multiple vehicles.

[0088] Figure 3C A flowchart 330 according to an example embodiment is illustrated. (Reference) Figure 3C Example methods can be provided by the main transport node 102 (see...) Figure 1C ) Execution. It should be understood that, Figure 3C Method 330 described herein may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of method 330. For illustrative purposes, reference is also made to... Figure 1C The features described herein are used to describe method 330. In particular, the processor 104 of the main transport node 102 can perform some or all of the operations included in method 330.

[0089] refer to Figure 3C At block 333, processor 104 can send a first portion of the software update to vehicles of a first subset of the vehicles. At block 335, processor 104 can send a second portion of the software update to vehicles of another subset of the vehicles. At block 337, processor 104 can, when vehicles of a first subset of the vehicles and vehicles of a second subset of the vehicles are close together, cause the first vehicle to send the first portion of the software update to the second vehicle, and cause the second vehicle to send the second portion of the software update to the first vehicle.

[0090] Figure 3D A flowchart 340 illustrating an example method according to an example embodiment is shown. (Reference) Figure 3DMethod 340 may further include one or more of the following steps. At block 342, processor 104 may determine a first portion and a second portion of the software update before it is transmitted to a subset of the transport vehicles and another subset of the transport vehicles. At block 344, when neither the subset of the transport vehicles nor the other subset of the transport vehicles is receiving one or more of the first and second portions of the software update, and when neither is executing one or more of the first and second portions of the software update, processor 104 may plan a route from the main transport vehicle to the geographic area.

[0091] At block 346, when a period of time has elapsed since receiving the first part of the software update, processor 104 can plan a route from the first vehicle to the vicinity of the second vehicle, and when a period of time has elapsed since receiving the first part of the software update, it can plan a route from the second vehicle to the vicinity of the first vehicle. At block 348, processor 104 can transmit the first and second parts of the software update via a transceiver in the main vehicle, receive the first and second parts of the software update via a transceiver at one or more locations in the first and second vehicles, store the first and second parts of the software update in the memory of one or more locations in the first and second vehicles, and combine the first and second parts by processors on the first and second vehicles.

[0092] Note that the main vehicle, a subset of vehicles, and another subset of vehicles can be connected via a blockchain network. At box 350, processor 104 can execute smart contracts to exchange parts of software updates between vehicles.

[0093] Figure 3E A flowchart 360 according to an example embodiment is illustrated. (Reference) Figure 3E Example methods can be provided by transportation node 102 (see...) Figure 1D ) Execution. It should be understood that, Figure 3E The method 360 described herein may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of method 360. For illustrative purposes, reference is also made to... Figure 1D The features described herein are used to describe method 360. In particular, the processor 104 of the transport node 102 can perform some or all of the operations included in method 360.

[0094] refer to Figure 3EAt block 362, processor 104 can receive software updates at the vehicle. At block 364, processor 104 can perform a first verification of the software update in a first environment, where the first environment includes a minimum number of potential interactions. At block 366, when the first verification is successful, processor 104 can perform another verification of the software update in another environment. The other environment can include a greater number of potential interactions than the first environment.

[0095] Figure 3F A flowchart 380 illustrating an example method according to an example embodiment is shown. (Reference) Figure 3F Method 380 may further include one or more of the following steps: At block 382, ​​when one or more of the first and second verifications fail, processor 104 may revert to a previous software version. At block 384, processor 104 may receive another verification of the software update from another vehicle. At block 386, processor 104 may invoke the software update based on analysis of another environment. At block 388, processor 104 may receive confirmation of another verification regarding the software update from multiple vehicles. The confirmation may constitute consensus on the blockchain to which the vehicle belongs. At block 390, processor 104 may execute a smart contract to record at least one data block reflecting the verified software update on the blockchain's ledger.

[0096] Figure 4A The illustration depicts an example blockchain vehicle configuration 400 for managing blockchain transactions associated with a vehicle, according to an example embodiment. (Reference) Figure 4A A specific means of transport / vehicle 425 participates in transactions, such as asset transfer transactions (e.g., access key exchange, vehicle service, dealer transactions, delivery / pickup, transportation services, etc.). Vehicle 425 can receive assets 410 and / or exclude / transfer assets 412 according to transactions(s) defined by smart contracts. Transaction module 420 can record information such as parties, credit, service description, date, time, location, results, notifications, unexpected events, etc. Transactions in transaction module 420 can be replicated to blockchain 430, which can be managed by a remote server and / or remote blockchain peers, where vehicle 425 itself can represent a blockchain member and / or blockchain peer. In other embodiments, blockchain 430 resides on vehicle 425. Received and / or transferred assets can be based on location and consensus as described herein.

[0097] Figure 4BThe illustration depicts an example blockchain vehicle configuration 440 for managing blockchain transactions between service nodes (e.g., gas stations, service centers, auto repair shops, rental centers, car dealerships, local service stations, delivery and pickup centers, etc.) and vehicles, according to an example embodiment. In this example, vehicle 425 may have driven itself to service node 442 because the vehicle requires service and / or needs to be parked at a specific location. Service node 442 may perform services (e.g., pumping air) or register vehicle 425 for service calls at specific times using specific strategies (e.g., oil change, battery charging or replacement, tire change or replacement), and any other transportation-related services. The provided services 444 may be executed based on smart contracts downloaded from or accessed via blockchain 430 and identified to allow such services to be executed at a specific exchange rate. Services may be recorded in the transaction log of transaction module 420, credit 412 is transferred to service center 442, and the blockchain may record transactions to represent all information about recent services. In other embodiments, blockchain 430 resides on servers for vehicle 425 and / or service center. In one example, a transportation incident might require refueling or other vehicle services, and passengers might then be responsible for an increase in the asset value of such services. Services can be provided via blockchain notifications, which are then used to redistribute the asset value to passengers based on their respective asset values. Responsibility for service center activities can be based on the asset transfers described herein.

[0098] Figure 4C An example blockchain vehicle configuration 450 for managing blockchain transactions between various vehicles, according to an exemplary embodiment, is illustrated. When a vehicle reaches a state requiring the sharing of assets with another vehicle, vehicle 425 can engage with another vehicle 408 to perform various actions, such as sharing access keys, transferring keys, obtaining service calls, etc. For example, vehicle 408 may need to charge its battery and / or may have a tire problem and may be on a route picking up a package for delivery. Vehicle 408 can notify the other vehicle 425 operating in its network and on its blockchain member service. Vehicle 425 can then request to receive information via wireless communication to perform package retrieval from vehicle 408 and / or from a server (not shown). The transaction is recorded in transaction modules 452 and 420 of the two vehicles. Assets are transferred from vehicle 408 to vehicle 425, and the record of the asset transfer is recorded in blockchains 430 / 454 (assuming these blockchains are different from each other), or in the same blockchain used by all members. As described herein, liability for the transfer of assets can be based on asset value (e.g., access keys).

[0099] Figure 5The illustration shows a blockchain block 500 that can be added to a distributed ledger according to an example embodiment, and the contents of block structures 502A to 502n. (Reference) Figure 5 A client (not shown) can submit entries to a blockchain node to establish an activity on the blockchain. As an example, the client could be an application acting on behalf of a requester (such as a device, individual, or entity) to submit entries to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers may exist in a blockchain network, including endorsing peers that simulate and endorse entries submitted by clients, and submitting peers that verify endorsements, validate entries, and submit them to the distributed ledger. In this example, a blockchain node could act as an endorser node, a submitter node, or both.

[0100] This system comprises a blockchain that stores immutable, ordered records in blocks; and a state database (current world state) that maintains the current state of the blockchain. Each channel can have a distributed ledger, and each peer maintains its own copy of the distributed ledger for each channel for which it is a member. This blockchain is an entry log structured as hashed, linked blocks, where each block contains a sequence of N entries. Blocks can include various components, such as... Figure 5 The components shown are linked. Blocks can be linked by adding a hash of the previous block's header to the current block's header. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the latest block in the blockchain represents every entry that arrived before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports only attached blockchain workloads.

[0101] The current state of a blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest value of all keys ever contained in the blockchain's entry log. Smart contract executables invoke execution entries against the current state in the state database. To make these smart contract executable interactions highly efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after a peer initiates operations but before accepting entries (or generated when needed).

[0102] Endorsing nodes receive entries from clients and endorse them based on the mock results. The endorsing node holds a smart contract containing the mock entry proposal. When an endorsing node endorses an entry, it creates an entry endorsement, a signed response from the endorsing node to the client application indicating the endorsement of the mock entry. The method of endorsing entries depends on the endorsement policy, which can be specified in the smart contract's executable code. An example of an endorsement policy is "most endorsing peers must endorse." Different channels can have different endorsement policies. The client application forwards the endorsed entries to a sorting service.

[0103] The ordering service accepts endorsed entries, orders them into blocks, and delivers these blocks to submitting peers. For example, the ordering service can initiate a new block when a threshold of entries has been reached, a timer expires, or other conditions are met. In this example, the blockchain node is the submitting peer, which has received block 602A of data to be stored on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, it accepts endorsed entries and specifies the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

[0104] Entries are written to the distributed ledger in a consistent order. Establishing the order of entries ensures that updates to the state database are valid when they are committed to the network. Unlike cryptocurrency blockchain systems where ordering is achieved through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism best suited to the network.

[0105] refer to Figure 5Block 502A (also known as a data block) stored on the blockchain and / or distributed ledger may include multiple data segments, such as block headers 504A to 504n, transaction-specific data 506A to 506n, and block metadata 508A to 508n. It should be understood that the various blocks and their contents depicted, such as block 502A and its contents, are for illustrative purposes only and are not intended to limit the scope of the exemplary embodiments. In some cases, both the block header 504A and the block metadata 508A may be smaller than the transaction-specific data 506A that stores entry data; however, this is not required. Block 502A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 510A to 510n. Block 502A may also include links to previous blocks (e.g., on the blockchain) within its block header 504A. Specifically, the block header 504A may include a hash of the headers of previous blocks. Block header 504A may also include a unique block number, a hash of the block data 510A of the current block 502A, etc. The block number of block 502A can be unique and assigned incrementally / sequentially starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

[0106] Block data 510A can store entry information for each entry recorded within a block. For example, entry data can include entry type, version, timestamp, channel ID of the distributed ledger, entry ID, epoch, payload visibility, smart contract executable code path (deployment tx), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functionality), client (creator) identification (such as public key and certificate), client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkel tree query digest, etc. Entry data can be stored for each of N entries.

[0107] In some embodiments, block data 510A may also store transaction-specific data 506A, which adds additional information to the blockchain of hash-linked blocks in the blockchain. Thus, data 506A can be stored in the immutable log of blocks on a distributed ledger. Some benefits of storing such data 506A are reflected in the various embodiments disclosed and depicted herein. Block metadata 508A may store multiple fields of metadata (e.g., as byte arrays, etc.). Metadata fields may include a signature at the time of block creation, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, the last offset persisted by a sorting service that sorts the blocks, etc. The signature, the last configured block, and the sorter metadata may be added by the sorting service. Simultaneously, the block submitter (such as a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The entry filter may include a byte array of size equal to the number of entries in block data 510A and a verification code identifying whether an entry is valid / invalid.

[0108] The other blocks 502B through 502n in the blockchain also have a header, file, and value. However, unlike the first block 502A, the headers of each of the other blocks 504A through 504n include the hash value of the preceding block. The hash value of the preceding block can be simply the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, a trace from the Nth block to the genesis block (and the associated original file) can be performed block by block, as indicated by arrow 512, to establish an auditable and immutable chain-of-custody.

[0109] The above embodiments can be implemented using hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program can be implemented on a computer-readable medium, such as a storage medium. For example, the computer program can reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disks, removable disks, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0110] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as discrete components. For example, Figure 6 The illustration shows an example computer system architecture 600, which can be represented or integrated into any of the components mentioned above.

[0111] Figure 6 This is not intended to imply any limitation on the scope or functionality of the embodiments of this application described herein. In any case, the compute node 600 can be implemented and / or perform any of the function sets described herein.

[0112] Within compute node 600, there is a computer system / server 602 that can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 602 include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the aforementioned systems or devices.

[0113] Computer system / server 602 can be described in the general context of computer system executable instructions, such as program modules, executed by the computer system. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 602 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0114] like Figure 6 As shown, a computer system / server 602 in a cloud computing node 600 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 602 may include, but are not limited to, one or more processors or processing units 604, system memory 606, and buses that couple various system components, including system memory 606, to processor 604.

[0115] A bus refers to any one or more of several types of bus architectures, including memory buses or memory controllers using any of the various bus architectures, peripheral buses, accelerated graphics ports, and processor or local buses. As an example and not a limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0116] Computer system / server 602 typically includes a variety of computer system readable media. Such media can be any available media accessible to computer system / server 602, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 606 implements a flowchart of another diagram. System memory 606 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 608 and / or cache memory 610. Computer system / server 602 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, memory 606 may be provided for reading and writing from non-removable non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, disk drives may be provided for reading and writing from removable non-volatile disks (e.g., "floppy disks"), and optical disk drives may be provided for reading or writing from removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media). In these cases, each drive may be connected to a bus via one or more data media interfaces. As will be further depicted and described below, memory 606 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of this application.

[0117] A program / utility having a set (at least one) of program modules may be stored in memory 606. By way of example and not limitation, such program modules include an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules typically perform functions and / or methods as described in the various embodiments of this application herein.

[0118] As those skilled in the art will recognize, aspects of this application can be implemented as systems, methods, or computer program products. Therefore, aspects of this application can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which can generally be referred to as "circuit," "module," or "system." Here, aspects of this application can take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0119] Computer system / server 602 can also communicate with one or more external devices via I / O adapter 612 (such as a keyboard, pointing device, display, etc.); one or more devices that enable a user to interact with computer system / server 602 and / or any device that enables computer system / server 602 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). Such communication can occur via the I / O interface of adapter 612. Again, computer system / server 602 can communicate with one or more networks (such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet)) via a network adapter. As shown, adapter 612 communicates with other components of computer system / server 602 via a bus. It should be understood that, although not shown in the figures, other hardware and / or software components can be used in conjunction with computer system / server 602. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, belt drives, and data archiving storage systems.

[0120] While exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are illustrated in the accompanying drawings and described in the foregoing detailed description, it should be understood that this application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions set forth and defined in the following claims. For example, the capabilities of the systems in the various figures can be executed by one or more of the modules or components described herein or in a distributed architecture, and may include transmitters, receivers, or pairs of both. For example, all or part of the functions performed by the various modules can be performed by one or more of these modules. In addition, the functions described herein can be performed at different times and in relation to various events inside or outside the modules or components. Moreover, information transmitted between the modules can be transmitted via at least one of the following: data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or via multiple protocols. Furthermore, messages transmitted or received by any module can be transmitted or received directly and / or via one or more other modules.

[0121] Those skilled in the art will recognize that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the foregoing functionality as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

[0122] It should be noted that some system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits including custom-designed very large-scale integration (VLSI) circuits or gate arrays, such as off-the-shelf semiconductors of logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0123] Modules can also be implemented at least partially in software so that they can be executed by various types of processors. The identified units of executable code can, for example, comprise one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together, but can include different instructions stored in different locations that, when logically connected, encompass the module and implement the module's stated purpose. Additionally, modules can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0124] In practice, a module of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data can be identified and represented within this module, and can be implemented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations including different storage devices, and can exist at least in part as electronic signals on a system or network.

[0125] It is readily understood that, as generally described and illustrated in the accompanying drawings, the components of this application can be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the application.

[0126] It will be readily understood by those skilled in the art that the above can be practiced using steps in a different order and / or using hardware components in a configuration different from the disclosed configuration. Therefore, while this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent.

[0127] While preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application is limited only by the appended claims when considering the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A system comprising: The processor of the main transport vehicle; as well as A memory communicatively coupled to the processor, wherein the processor: The selection of a vehicle to receive the software update is based on one or more characteristics of the vehicle and the possible use of the software update, wherein the characteristics of the vehicle include one or more of the following: the security level of the vehicle, the age of the vehicle, the hardware in the vehicle, the condition of the vehicle, and features included in the vehicle. Provide the software update to the selected means of transport; Receive software update problem reports based on the use of the software update by the means of transport; and In response to verification of the software update issue report, the software update is propagated to another subset of the vehicles, wherein the other subset of the vehicles is larger than the first subset of the vehicles.

2. The system of claim 1, wherein the processor propagates the software update to the set of all remaining vehicles, wherein the set of all remaining vehicles is greater than the other subset of vehicles.

3. The system of claim 1, wherein one or more of the subset of transport vehicles, the other subset of transport vehicles, and the set of all remaining transport vehicles are based on one or more of the following: Existing software; Existing hardware; Geographical location; Ambient temperature; Transportation vehicle brands; Transportation vehicle model; Condition of transportation vehicles; Road conditions; and Destination of the means of transport.

4. The system of claim 1, wherein when a negative result is determined based on the verification, the processor modifies one or more of the subset of vehicles, the other subset of vehicles, and the set of all remaining vehicles.

5. The system of claim 1, wherein when a negative result is determined based on the verification, the processor restores one or more of the subset of vehicles, the other subset of vehicles, and the set of all remaining vehicles to one or more of the initial version of the software and previous software updates.

6. The system of claim 1, wherein the processor updates the software for: The subset of the means of transport reaches the first time amount; and The other subset of the means of transport reaches a second time quantity, wherein the first time quantity is greater than the second time quantity.

7. The system of claim 1, wherein the subset of vehicles belongs to a blockchain network.

8. The system of claim 6, wherein the processor executes a smart contract of the blockchain network to verify software updates and propagate the software updates through multiple means of transport.

9. The system of claim 1, wherein the processor performs a first verification of the software update in a first environment, wherein the first environment includes a minimum number of potential interactions, and performs another verification of the software update in a second environment when the first verification is successful, wherein the second environment includes a greater number of potential interactions than the first environment.

10. The system of claim 9, wherein the processor receives the additional verification of the software update from another means of transport.

Images