Vehicle software update management

Vehicles or transports, such as automobiles, motorcycles, trucks, airplanes, trains, etc., typically provide transportation needs for occupants and/or goods in a variety of ways. Functions related to transportation devices can be identified and utilized by various processing devices such as smartphones, computers, tablets, and the like.

Software updates for transportation devices are typically performed by a central server that provides software updates to each individual transportation device client computer. This typically requires a network connection to the cloud. However, excessive use of WANs to distribute software updates is inefficient and may even be unsafe. Additionally, software updates may not have been thoroughly tested on a sufficiently large number of transport devices before being sent by the server. No centralized system exists that can collect and track software update information from millions of transportation devices securely and efficiently.

Therefore, it would be desirable to have a secure propagation method for vehicle software updates that is based on extensive testing with a large number of vehicles. It is also desirable to have information regarding software updates recorded on shared storage.

One example embodiment includes receiving a software update on a transportation device of a subset of transportation devices; and determining one or more of: a time period during which the software update was used; and propagating the software update based on the activation to a further subset of transportation devices that is larger than the subset of transportation devices. can be provided.

Another example embodiment provides that when a first transport device of a subset of transport devices and a second transport device of a further subset of transport devices are in close proximity, a first portion of the software update is performed by a master transport device. by the master transport device to the transport devices of the further subset of the transport devices; including one or more of: causing the transportation device to send a first portion of the software update to the second transportation device; and causing the second transportation device to send the second portion of the software update to the first transportation device. We can provide you with a way to

Still other example embodiments include receiving a software update at a transportation device and performing a first enabling of the software update in a first environment that includes the least amount of potential interactions. and, if the first activation is successful, performing a further activation of the software update in a further environment containing a greater amount of potential interaction than the first environment. We can provide you with a way to

Other example embodiments can provide a system including a processor and a memory, wherein the transportation device processor of a subset of the transportation devices is configured to receive a software update and determine the time period during which the software update was used. activating the software update based on one or more of a number of times the software update is used by the subset of transportation devices; and activating the software update based on the activation on the further subset of transportation devices that is larger than the subset of transportation devices. be configured to perform one or more of the following:

Other example embodiments can provide a system including a processor and a memory, wherein the processor of a master transport device is configured to control a first transport device of a subset of transport devices and a second transport device of a further subset of transport devices. sending a first portion of the software update to the transport devices of the first subset of the transport devices when the transport devices are in close proximity; and sending a second portion of the software update to the transport devices of the further subset of the transport devices. and one of: causing the first transportation device to send a first portion of the software update to the second transportation device; and causing the second transportation device to send a second portion of the software update to the first transportation device. It is configured to do the above.

Still other example embodiments can provide a system including a processor and a memory, the processor receiving a software update in a transportation device and a first process that includes the least amount of potential interaction. performing a first activation of the software update in an environment and, if the first activation is successful, updating the software update in a further environment that contains a greater amount of potential interactions than the first environment; configured to perform one or more of the following activations:

A further example embodiment provides a non-transitory computer readable medium comprising instructions, the instructions, when loaded by a processor, instructing the processor to receive a software update and the time the software update was used. activating the software update based on one or more of a time period and a number of uses of the software update by a subset of the transportation devices; Have the subset do one or more of the things you distribute.

A further example embodiment provides a non-transitory computer-readable medium comprising instructions, which, when read by a processor, cause the processor to transport a first transport device of a subset of transport devices and a further one of the transport devices. sending a first part of the software update to the transport devices of the first subset of transport devices when the second transport devices of the subset are in close proximity; and transmitting the second part of the software update to the further subset of transport devices; and causing the first transportation device to send a first portion of the software update to the second transportation device; and causing the second transportation device to send the second portion of the software update to the first transportation device. to perform one or more of the following:

Further example embodiments provide a non-transitory computer-readable medium comprising instructions, the instructions, when loaded by a processor, to the processor to receive software updates and minimize the amount of potential interaction. performing a first activation of the software update in a first environment containing a software update; and, if the first activation is successful, a further environment containing a greater amount of potential interactions than the first environment; , causing one or more of the following to be performed: further enabling the software update;

<figref num="1A">1 illustrates a transportation device network diagram according to an example embodiment.</figref><figref num="1B">1 illustrates an example network diagram including transport device nodes according to an example embodiment; FIG.</figref><figref num="1C">FIG. 6 illustrates another example network diagram including transport device nodes in accordance with an example embodiment.</figref><figref num="1D">FIG. 6 illustrates another example network diagram including transport device nodes in accordance with an example embodiment.</figref><figref num="2A">1 illustrates a blockchain architecture configuration according to an example embodiment.</figref><figref num="2B">4 illustrates another blockchain configuration according to an example embodiment.</figref><figref num="2C">4 illustrates a blockchain configuration for storing blockchain transaction data according to an example embodiment.</figref><figref num="3A">1 illustrates a flow diagram according to an example embodiment.</figref><figref num="3B">3 illustrates another flow diagram according to an example embodiment.</figref><figref num="3C">3 illustrates a further flow diagram according to an example embodiment; FIG.</figref><figref num="3D">3 illustrates a further flow diagram according to an example embodiment; FIG.</figref><figref num="3E">3 illustrates a further flow diagram according to an example embodiment; FIG.</figref><figref num="3F">3 illustrates a further flow diagram according to an example embodiment; FIG.</figref><figref num="4A">3 illustrates an example blockchain vehicle configuration for managing blockchain transactions associated with a vehicle, according to an example embodiment; FIG.</figref><figref num="4B">5 illustrates another example blockchain vehicle configuration for managing blockchain transactions between a service center and a vehicle, according to an example embodiment.</figref><figref num="4C">5 illustrates yet another example blockchain vehicle configuration for managing blockchain transactions performed between various vehicles, according to an example embodiment.</figref><figref num="5">4 illustrates an example data block according to an example embodiment.</figref><figref num="6">1 illustrates an example system supporting one or more of the example embodiments.</figref>

It will be readily appreciated that the illustrative components herein, as generally described and illustrated 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 a method, apparatus, non-transitory computer-readable medium, and system, as illustrated in the accompanying figures, limits the scope of the claimed application. are not intended to be, and are merely representative of selected embodiments.

As described throughout this specification, the illustrative features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. For example, use of the phrases "illustrative embodiments," "some embodiments," or other similar phrases, at least throughout this specification, refers to particular features described in connection with an embodiment; Refers to the fact that a structure or characteristic can be included in at least one embodiment. Therefore, throughout this specification, appearances of the phrases "example embodiment," "in some embodiments," "in other embodiments," or other similar phrases refer to the same reference to an embodiment. Rather than necessarily referring to a grouping, the features, structures or characteristics described may be combined in any suitable manner in one or more embodiments. In the figures, any connections between elements can be unidirectional and/or bidirectional, even if the depicted connection is a unidirectional or bidirectional arrow. In this application, transportation equipment refers to cars, trucks, motorcycles, scooters, bicycles, boats, recreational vehicles, airplanes, and any object that can be used to transport people and/or goods from one place to another. It can contain things.

Additionally, although the term "message" is used in the description of the embodiments, the present application is applicable to many types of network data such as packets, frames, datagrams, etc. The term "message" also includes packets, frames, datagrams, and any equivalents thereof. Furthermore, although certain types of messages and signals may be illustrated in the example embodiments, they are not limited to certain types of messages, and this application is not limited to certain types of signals.

Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and/or networks that include transportation devices (also referred to herein as vehicles), data collection at least one of a system, a data monitoring system, an enabling system, an authorization system, and a vehicle data distribution system. Vehicle status condition data received in the form of communication update messages, such as wireless data network communications and/or wired communication messages, identifies the vehicle/vehicle status condition and provides feedback regarding changes in the condition of the vehicle. can be received and processed in order to In one example, a user profile can be applied to a particular transportation device/vehicle to authorize current vehicle events, stops for service at service stations, and authorize subsequent vehicle rental services.

Within a communications infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database and includes an append-only immutable data structure (i.e., a distributed ledger) that can maintain records between parties without trust. A non-trusted party is referred to herein as a peer, node, or peer node. Each peer maintains a copy of the database record, and no single peer can modify the database record without consensus among the distributed peers. For example, peers can run consensus protocols to validate blockchain storage entities, group storage entities into blocks, and build hash chains over the blocks. This process forms a ledger by ordering storage entities for consistency, if necessary. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can include cryptocurrencies and use consensus based on various protocols, such as proof-of-work (PoW). Permissioned blockchain databases, on the other hand, are used between groups of entities that share a common goal but do not fully trust or cannot trust each other, such as businesses exchanging funds, goods, information, etc. Provide a system that allows for reliable interaction. The illustrative application can function in permissioned and/or permissionless blockchain settings.

Smart contracts are trust-based contracts that take advantage of the tamper-resistant properties of a shared or distributed ledger (i.e., a database that may be in the form of a blockchain) and an underlying agreement among member nodes called endorsements or endorsement policies. It is a highly decentralized application. Generally, blockchain entities are endorsed before being submitted to the blockchain, while non-endorsed entries are ignored. A typical endorsement policy allows smart contract executable code to identify endorsers for entries in the form of a set of peer nodes needed for endorsement. When a client sends an entry to a peer identified in an endorsement policy, the entry is executed to validate the entry. After validation, entries enter an ordering phase where a consensus protocol is used to generate an ordered sequence of endorsed entries grouped into blocks.

A node is a communicating entity in a blockchain system. A "node" is capable of performing logical functions in the sense that multiple different types of nodes can operate on the same physical server. Nodes are grouped in trust domains and associated with logical entries that control the nodes in various ways. Nodes may include different types, such as clients or submission clients that submit entry calls to endorsers (eg, peers) and broadcast entry proposals to ordering services (eg, ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, populate entries, and maintain the state and copy of a ledger of blockchain entries. Peers can also have the role of endorser, but that is not a requirement. An ordering service node or orderer is a node that operates communication services for all nodes and is also another name for the initial blockchain entry, which populates entries and typically contains control and configuration information. Implement delivery guarantees, such as broadcasts, to each of the peer nodes in the system when modifying the world state.

A ledger is an ordered, tamper-resistant record of all state transitions in a blockchain. State transitions can result from smart contract executable code invocations (i.e., entries) submitted by participating parties (eg, client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs that are entered into the ledger as one or more operands such as creates, updates, deletes, etc. The ledger includes a blockchain (also referred to as a chain), which is used to store immutable, ordered records in blocks. The ledger also includes a state database, which maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which it is a member.

A chain is a log of entries, structured as hash-linked blocks, each block containing a sequence of N entries, where N is greater than or equal to one. The block header also contains the hash of the block entry as well as the hash of the preceding block header. In this way, all entries on the ledger can be ordered and cryptographically linked to each other. Therefore, the ledger cannot be tampered with unless the hash link is destroyed. The hash of the most recently added blockchain block represents all entries on the chain that came before it, and all peer nodes are in a consistent and reliable state. make it possible to ensure Chains can be stored on peer node file systems (i.e., local attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

The current state of the immutable ledger represents the latest values for all keys contained in the chain entry log. Because the current state represents the most recent key value known to the channel, it is sometimes referred to as the world state. Smart contract executable code calls perform entries on the ledger's current state data. To make these smart contract executable code interactions efficient, the most recent values of keys can be stored in a state database. The state database may simply be an indexed view into the chain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically recovered (or regenerated, if necessary) when a peer node starts up and before entries are accepted.

Blockchain differs from traditional databases in that blockchain is not a centralized storage, but a decentralized, immutable, and secure storage where nodes must share changes in records in storage. ing. Some characteristics that are unique to blockchain and assist in making blockchain a reality include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility. There are things like gender.

Example embodiments provide a method for providing vehicle services to a particular vehicle and/or requesting a user associated with a user profile applied to the vehicle. For example, the user may be a vehicle owner or a driver of a vehicle owned by another party. A vehicle can request service at certain intervals, and the service request can require authorization before allowing the service to be received. The service center also services vehicles in nearby areas based on the vehicle's current route plan and the relative level of service requirements (e.g., immediate, severe, intermediate, non-critical, etc.). Can be provided. Vehicle demand can be monitored by one or more sensors that report sensed data to a central controller computer device in the vehicle, which in turn forwards it to a management server for investigation and action. .

The sensors can be located on one or more of the following: inside the transport device, outside the transport device, on a fixed object remote from the transport device, and on other transport devices proximate to the transport device. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service demand, vehicle gear shifting, vehicle steering, and the like. The sensor concept may also be a device such as a mobile device or the like. Sensor information is also used to identify whether the vehicle is operating safely and whether passengers are caught in unexpected vehicle conditions, such as during vehicle access periods. can. Vehicle information collected before, during, and/or after vehicle operations can be identified and stored in transactions on a shared/distributed ledger, such as via blockchain membership groups. As determined by the Authorization and Certification Association, and therefore can be reproduced in a "decentralized" manner and put into an immutable ledger. Since each stakeholder (i.e., company, institution, etc.) may also wish to limit the disclosure of private information, the blockchain and its immutability can therefore limit disclosure, and each special user vehicle profile You can manage permissions for Smart contracts can be used to provide compensation, quantify user profile scores/ratings/ratings, apply vehicle event permissions, determine when service is required, identify crash and/or degeneration events, and It can be used to identify events, identify parties to events, and provide distribution to registered entities seeking access to such vehicle event data. Also, results can be identified and the necessary information can be shared among registered companies and/or individuals based on the "consensus" approach associated with blockchain. Such an approach has not been possible with traditional centralized databases.

All autonomous driving systems are built into a whole suite of software and arrays of sensors. Machine learning, lidar projectors, radar, and ultrasonic sensors will all work together to create a living map of the world in which self-driving cars can travel. Most companies in the race to full autonomy, with a few notable exceptions, rely on the same basic technology foundation: lidar + radar + camera + ultrasound.

In other embodiments, GPS, maps, and other cameras and sensors are used in autonomous vehicles without lidar, as lidar is often considered expensive and unnecessary. . Researchers have determined that stereoscopic cameras are a low-cost alternative to more expensive lidar capabilities.

Illustrative applications include, in certain embodiments, authorizing a vehicle to service via an automated rapid authentication scheme. For example, driving to a charging station or fuel pump can be performed by the vehicle driver, and authorization to charge or receive fuel can be performed without delay if the authorization is received at the service station. The vehicle can provide a communication signal that provides the identity of a vehicle that is authorized to receive service and has a currently active profile linked to an account that can later be reconciled with compensation. Additional identifiers may be sent wirelessly from the user's device to the service center to replace or supplement the first authorization effort between the transportation device and the service center with additional authorization efforts. Other means can be used to provide further authorization.

The shared and received data can be stored in a database, which is a single database (eg, a database server) that typically maintains the data in one special location. This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database is typically accessible from multiple different points. A centralized database is easier to manage, maintain, and control because of its single location, especially for security purposes. Within a centralized database, a single storage location for all data also means that a given set of data has only one primary record, so data redundancy is minimal. .

According to an example embodiment, distribution of software updates to vehicles without using WAN technology is provided. One example embodiment allows software updates to be distributed only after testing has been performed by the first set of transport devices. Testing can be performed over a period of time or over a large number of executions of the software update code. If the software test fails, the transportation device is alerted and the transportation device software can revert to the previous software version.

In other embodiments, the master transportation equipment system, when distributing software updates to vehicles, divides the software update into at least two parts and adds the software update parts by sending the software update parts at different times and/or from different sources. security. In one example embodiment, software updates may first be sent from a master transport device. Example embodiments can provide decentralized distribution of software updates with authorization of updates via blockchain technology.

According to an example embodiment, the master transport device determines which parts of the software update are to be applied to which transport devices based on characteristics of the transport device (e.g., the security level of the transport device, the age of the transport device, The determination may be made based on the hardware in the vehicle that is capable of suitably executing the software, the condition of the vehicle, the characteristics of the user/passenger of the vehicle, the use of features in or associated with the vehicle. Updates can be provided based on the likely usage of the updates, eg, which transportation devices are better able to test/utilize software updates. In one example, vehicle 1 may obtain the first part of the update (ABC) and vehicle 2 may obtain the other part of the update (ABC') from the same master vehicle. Software updates can be split into more than two parts, for example, some vehicles receive 2 parts, some vehicles receive 3 parts, and some vehicles receive n parts. can. The master transport device may have a higher level of security than the subset of transport devices and the further subset of transport devices. Any problems with software updates can be reported to the master transport (the master transport can report it to the central server). If a problem occurs with either part or with the first and second collected parts of the update, the master transporter can be moved closer to the transporter where the problem has occurred and the problem can be determined. You can monitor that transport device to troubleshoot.

In yet another example embodiment, once a software update is received, collected, and executed, the transportation device continues to run the old software version and, in situations with the least potential problems, installs the new version. Use updated software intermittently. For example, if an update is made to a braking software update, the transportation device can use the updated software when the driving environment is at its lowest traffic (and when there are no pedestrians and/or objects). . Once the updated software is activated in this driving environment, the transportation device will be able to operate in different potentially problematic driving environments (e.g., environments with more traffic, pedestrians, and/or objects). You can use the updated software. According to example embodiments, the driver of the transportation device may not be aware of the functionality of the software update management application. The transportation device's system can test software updates in different environments incrementally and revert to a previous version of the software if necessary.

In still other embodiments, the master transport device determines which portions are assigned to which transport devices based on characteristics of the transport device (e.g., the security level of the transport device, the age of the transport device, the appropriate software configuration, etc.). The determination may be made based on the hardware in the vehicle that can be implemented, the state of the vehicle, the characteristics of the user/passenger of the vehicle, the use of features in or associated with the vehicle. Updates can be based on possible uses of the update, eg, which transportation devices can better test/utilize the software.

In further embodiments, different vehicles may collect portions of software based on time or date of submission, vehicle and/or software and/or user characteristics. For example, vehicle 1 can obtain the first part (ABC), and in the very next transmission, vehicle 2 can obtain the first part (ABC') from the same master transport device (i.e., the first part is can be different).

In further embodiments, the software update can be divided into three or more parts. Some transport devices can receive two parts, some transport devices can receive three parts, and some transport devices can receive n parts.

In a further embodiment, the master transport device comprises one or more of a subset of transport devices and a higher level of security than the further subset of transport devices, a first part of the software update, and a second part of the software update. ing.

In further embodiments, any problems with the software are reported to the master transport device (and can be reported to the central server).

In a further embodiment, if a problem occurs with any part of the update, or the first and second parts assembled, the master transport device can be in close proximity to the problematic transport device and monitor the problem. and have access to issues.

FIG. 1A illustrates a transportation device network diagram 100 in accordance with an example embodiment. According to one example embodiment, the transportation device processors 104' of a subset of transportation devices (eg, 105) may be configured to receive software updates. Software updates can be provided by a master vehicle node (eg, 102). Processor 104' can enable software updates based on a period of time that the software updates have been used by the transportation device (eg, 105). In one example, processor 104' can enable a software update based on the number of times the software update is utilized by a subset of transportation devices (eg, 105). Processor 104' can distribute the software update to a further subset of transportation devices (eg, 107) based on activation. The subset of transport devices 107 is larger than the subset of transport devices 105.

According to another example embodiment, the processor 104 of the master transportation device 102 may be configured to send a first portion of the software update to the transportation devices of the first subset of transportation devices 105. The processor 104 of the master transport device 102 may send the second portion of the software update to a further subset of transport devices 107. The processor 104 then updates the first portion of the software update to the second transportation device 107 when the first transportation device of the subset of transportation devices 105 and the second transportation device of the further subset of transportation devices 107 are in close proximity. A command can be sent to the first transport device 105 to cause it to send a command. The processor 104 can then send a command to the second transportation device to cause the first transportation device 105 to send a second portion of the software update. As such, the processors 104' and 104'' of the respective vehicles 105 and 107 can collect complete software updates.

According to a further example embodiment, the processor 104' (or 104'') receives the software update (e.g., from the master transport device 102) and performs a first activation of the software update in the first environment. The first environment may include the least amount of potential interactions (minimum traffic, no pedestrians, normal weather conditions, etc.) and may be configured such that processor 104' (or 104" ) may perform further activation of the software update in further environments if the first activation is successful. The additional environment may include a greater amount of potential interactions than the first environment (eg, more traffic, pedestrians, difficult weather conditions, etc.).

FIG. 1B illustrates a network diagram for managing software updates. Referring to FIG. 1B, network diagram 111 includes a subset of transportation device nodes 102 connected to other subsets of transportation device nodes 105 via blockchain network 106. Transport device nodes 102 and 105 can be transport devices/vehicles. Blockchain network 106 may have a ledger 108 for storing data, such as data related to software updates, including timestamps of software updates. Transporter node 102 may be connected to other subsets of transporter nodes (not shown).

Although this example details only one vehicle node 102, multiple such nodes can be connected to the blockchain 106. Without departing from the scope of the vehicle node 102 disclosed herein, the vehicle node 102 may include additional components, and some of the components described herein may be removed and/or It should be understood that it can be modified. The transportation device node 102 may include a processing unit or server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable A gate array (FPGA) and/or other hardware devices may be included. Although a single processor 104 is shown, it is understood that the transporter node 102 can include multiple processors, multiple cores, etc. without departing from the scope of the transporter node 102 system. Should.

Vehicle node 102 may also include a non-transitory computer-readable medium 112 that can store machine-readable instructions executable by processor 104. Examples of machine readable instructions are shown as 114-118 and are discussed further below. Examples of non-transitory computer-readable media 112 may include electronic, magnetic, optical, or other physical storage devices containing or storing executable instructions. For example, non-transitory computer-readable medium 112 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

Processor 104 can execute machine readable instructions 114 for receiving software updates on transportation device 104. Each of transport devices 102 and 105 can act as a network peer (ie, a node) on blockchain 106. As discussed 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 the vehicles (or nodes) 102 that can manage transactions for other participating vehicle nodes 105. Transportation device nodes 102 can provide information stored in ledger 108 to blockchain 106 .

Processor 104 can execute machine-enabled instructions 116 to enable software updates. The software update may be activated based on the time period during which the software update was used and the number of times the software update was utilized by a subset of transportation devices 102. Processor 104 can execute machine readable instructions 118 to distribute software updates to a further subset of transportation devices (eg, 105) based on activation. A further subset of transport devices 105 is larger than the subset of transport devices 102.

FIG. 1C illustrates a network diagram for management of transportation device software updates. Referring to FIG. 1C, a network diagram 121 is connected to other transportation device nodes 105 and 107 via a blockchain network 106 that has a ledger 108 for storing software update related transactions 110. It includes a transport node 102 that acts as a master transport node. Transport device nodes 102, 105, and 107 can also act as blockchain 106 peers. Although this example details only one master transporter node 102, multiple such nodes can be connected to the blockchain 106. Without departing from the scope of the master vehicle node 102 disclosed herein, the master vehicle node 102 may include additional components, and some of the components described herein may be removed. It should be understood that and/or modifications may be made. The master transport device node 102 may include a processing unit or server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field A programmable gate array (FPGA) and/or other hardware device may be included. Although a single processor 104 is shown, it is understood that the master transport node 102 can include multiple processors, multiple cores, etc. without departing from the scope of the master transport node 102 system. It should be.

Master vehicle node 102 may also include a non-transitory computer-readable medium 112' that can store machine-readable instructions executable by processor 104. Examples of machine readable instructions are shown as 113-117 and are discussed further below. Examples of non-transitory computer-readable media 112' may include electronic, magnetic, optical, or other physical storage devices containing or storing executable instructions. For example, non-transitory computer-readable medium 112' may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

Processor 104 may execute machine readable instructions 112' to send a first portion of the software update to a first subset of transportation devices 113. Blockchain 106 can be configured to use one or more smart contracts to manage transactions for multiple participating nodes (eg, 105 and 107). Master transport device 102 can provide information related to software updates to blockchain 106 and the transactions can be stored in ledger 108.

Processor 104 can execute machine readable instructions 115 to send a second portion of the software update to a further subset of transportation devices (eg, 107). The processor 104 causes the first transport device of the subset of transport devices 105 to first transmit the first portion of the software update to the first transport device when the second transport device of the further subset of transport devices 107 is in close proximity. The machine-readable instructions 117 can be executed to cause the second transportation device 107 to send the second portion of the software update to the first transportation device 105.

FIG. 1D illustrates a network diagram for management of transportation device software updates. Referring to FIG. 1D, a network diagram 130 shows a transport connected to other transport device nodes 105 via a blockchain network 106, having a ledger 108 for storing software activation data and transactions 110. Includes a device node 102 (eg, a vehicle). Vehicle nodes 102 and 105 can also act as blockchain 106 peers. Although this example details only one vehicle node 102, multiple such nodes can be connected to the blockchain 106. Without departing from the scope of the master vehicle node 102 disclosed herein, the master vehicle node 102 may include additional components, and some of the components described herein may be removed and It should be understood that/or may be modified. The transportation device node 102 may include a processing unit or server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable A gate array (FPGA) and/or other hardware devices may be included. Although a single processor 104 is shown, it should be understood that the vehicle node 102 can include multiple processors, multiple cores, etc. without departing from the scope of the vehicle node 102. It is.

Vehicle node 102 may also include a non-transitory computer-readable medium 112'' that can store machine-readable instructions executable by processor 104. Examples of machine-readable instructions are shown as 132-136 and described below. Examples of non-transitory computer-readable media 112 include electronic, magnetic, optical, or other physical storage devices containing or storing executable instructions. be able to. For example, the non-transitory computer readable medium 112'' may be random access memory (RAM), electrically erasable programmable read only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

Processor 104 can execute machine readable instructions 132 to receive software updates at transportation device 102. Blockchain 106 can be configured to use one or more smart contracts to manage transactions for multiple participating vehicle nodes 105. The transportation device 102 can provide information related to the software update to the blockchain 106 and the transaction can be stored in the ledger 108.

Processor 104 can execute machine-readable instructions 134 to perform a first activation of the software update in a first environment that includes the least amount of potential interactions. Processor 104 can execute machine readable instructions 136 to perform further activation of the software update in further environments if the first activation is successful. The further environment may include a greater amount of potential interactions than the first environment.

FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. Referring to FIG. 2A, blockchain architecture 200 may include certain blockchain elements, eg, a group of blockchain member nodes 202-206, as part of a blockchain group 210. In one example embodiment, a permissioned blockchain is not accessible to all parties, but only to members with permissioned access to the blockchain data. Blockchain nodes participate in numerous activities such as blockchain entry addition and validation process (consensus), etc. One or more blockchain nodes can endorse entries based on an endorsement policy and can provide ordering services to all blockchain nodes. A blockchain node can initiate blockchain actions (such as authentication) and seek to write to a blockchain immutable ledger stored on the blockchain, and a copy of the ledger is also can be stored on the same physical infrastructure.

Blockchain transactions 220 are stored in computer memory once the transaction is received and accepted by the consensus model dictated by the member nodes. The accepted transaction 226 is stored in the current block of the blockchain through a submission procedure that includes performing a hash of the transaction's data content in the current block and referencing the previous hash of the previous block. and then put into the blockchain. Within the blockchain, there may be one or more smart contracts 230 that specify information such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The terms and actions of the transaction agreement contained in the smart contract executable application code 232 can be defined. The code determines whether the requesting entity is registered to receive vehicle services, is entitled to receive any service features, taking into account their profile status, and/or requests and whether their actions are monitored in subsequent events. For example, sensor data monitoring can be triggered when a service event occurs and the user is in the vehicle, causing some parameter, such as the vehicle's charge level, to exceed a particular threshold for a particular period of time. /Can be identified as less than that. The result can then be a change to the current status, alerting administrative parties (e.g., vehicle owner, vehicle driver, server, etc.) so that the service can be identified and stored for reference. request that it be sent. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the status of the vehicle. The sensor data also shows where the vehicle is traveling, its average speed, maximum speed, acceleration rate, whether there were any collisions, whether the expected route was taken, where the next destination is, and whether safety measures are in place. It can also be the basis for vehicle event data 234, such as whether the vehicle has enough charge/fuel. All such information can be the basis for smart contract terms 230 and is stored on the blockchain. For example, sensor thresholds stored in a smart contract can be used as a basis for whether a detected service is needed, when and where the service should be executed.

FIG. 2B illustrates a shared ledger configuration according to an example embodiment. Referring to FIG. 2B, example blockchain logic 250 includes a blockchain application interface 252 as an API or plug-in application that links to a processing unit and an execution platform for a particular transaction. Blockchain configurations 250 can be created according to customized configurations requested by participants, and contain stored program/application code (e.g. , smart contract executable code, smart contracts, etc.) may include one or more applications linked to an application programming interface (API) for accessing and executing smart contracts. It can be deployed as an entry and installed on all blockchain nodes via addition to the distributed ledger.

Smart contract application code 254 provides the basis for the blockchain by establishing application code that, when executed, enables transaction terms and conditions. When executed, smart contract 230 causes certain accepted transactions 226 to be generated, and transactions 226 are transferred to blockchain platform 262. The platform includes a processing unit that performs security/authorization 268, transaction management 266, and storage 264 as a memory for storing transactions and smart contracts on the blockchain.

A blockchain platform receives and stores various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.) and new entries, and provides access to auditors seeking to access data entries. can include the underlying physical computer infrastructure that can be used for Blockchains can expose interfaces that provide access to virtual execution environments needed to process program code and engage physical infrastructure. Cryptographic trust services can be used to validate entries such as asset exchange entries and keep information private.

The blockchain architecture configurations of Figures 2A and 2B can process and execute programs/applications and can process and execute services provided by the blockchain platform through the interfaces exposed by the blockchain platform. As a non-limiting example, smart contracts can be created to perform reminders, updates, and/or other notifications that changes, updates, etc. have occurred. Smart contracts can be used to identify themselves, authorization and access requirements, associated rules, and ledger usage. For example, the information can include a new entry, which can be processed by one or more processing entities (eg, processors, virtual machines, etc.) included in the blockchain layer. The outcome may include a decision to reject or accept the new entry based on criteria defined in the smart contract and/or consensus of the peers. Physical infrastructure is available to retrieve any of the data or information described herein.

Within smart contract executable code, smart contracts can be created via high-level applications and programming languages and written to blocks in the blockchain. A smart contract may include executable code that is registered, stored, and/or replicated on a blockchain (eg, a distributed network of blockchain peers). Entry is the execution of smart contract code that can be executed in response to the fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger reliable modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger by executing smart contracts can be automatically replicated across a decentralized network of blockchain peers through one or more consensus protocols.

Smart contracts can write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values stored on the blockchain and use those values in the operation of the application. Smart contract code can write the outputs of various logic operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. Data written to a blockchain can be made public and/or encrypted and kept private. Temporary data used/generated by smart contracts is kept in memory by the provided execution environment and deleted once the data required for the blockchain is identified.

The smart contract executable code may include a code interpretation of the smart contract with additional features. As described herein, smart contract executable code may be program code deployed on a computing network and co-executed and validated by chain validators during a consensus process. The smart contract executable code receives the hash and retrieves from the blockchain the hash associated with the data template created by use of the previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the smart contract executable code sends the authorization key to the requested service. Smart contract executable code can be written to blockchain data that is associated with cryptographic details.

FIG. 2C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. Referring to FIG. 2C, an example configuration 270 provides a vehicle 272, a user device 274, and a server 276 that share information with a distributed ledger (ie, blockchain) 278. The server is a service provider entity that queries the vehicle service provider to share user profile rating information where a known and established user profile is attempting to rent a vehicle with an established rating profile. be able to. Server 276 can receive and process data related to vehicle service requirements. Invoke rules, thresholds, sensor information collections, etc. that can be used to invoke vehicle service events when a service event occurs, such as vehicle sensor data indicating that fuel/charging, maintenance service, etc. is required. Smart contracts can be used for this purpose. Blockchain transaction data 280 is stored for each transaction such as access events, subsequent updates to vehicle service status, event updates, etc. Transactions include the parties involved, requirements (e.g., age 18, eligible for service, valid driver's license, etc.), coverage level, distance driven during the event, access to the event, and availability of vehicle services. Registered recipients authorized to host, rights/permissions, sensor data retrieved during vehicle event operations to record details of the next service event and identify vehicle condition status , and thresholds used to determine whether the service event has been completed and whether the vehicle condition status has changed.

FIG. 3A illustrates a flow diagram 300 according to an example embodiment. Referring to FIG. 3A, an example method may be performed by transport device node 102 (see FIG. 1B). The method 300 shown in FIG. 3A can include additional acts, and some of the acts described herein can be removed and/or modified without departing from the scope of the method 300. should be understood. The description of method 300 is also made with reference to the features shown in FIG. 1B for illustrative purposes. In particular, processor 104 of vehicle node 102 may perform some or all of the operations included in method 300.

Referring to FIG. 3A, at block 302, processor 104 may receive a software update at the transportation device. At block 304, the processor 104 may enable the software update based on one or more of the time period during which the software update was used and the number of times the software update was utilized by the subset of transportation devices. At block 306, the processor 104 may distribute the software update to a further subset of transportation devices based on the activation. The further subset of transport devices may be larger than the subset of transport devices.

FIG. 3B depicts a flow diagram 320 of an example method in accordance with an example embodiment. Referring to FIG. 3B, method 320 can also include one or more of the following steps. At block 322, the processor 104 may distribute the software update to the set of all remaining transport devices, where the set of all remaining transport devices is greater than the additional set of transport devices. The subset of transport devices, the further subset of transport devices, and the set of all remaining transport devices are configured based on existing software, existing hardware, geographic location, temperature of the environment, transport make, Based on one or more of the following: vehicle model, vehicle condition, road condition, and transportation device destination.

At block 324, the processor 104 modifies one or more of the subset of transport devices, the further subset of transport devices, and the set of all remaining transport devices once a negative outcome is determined based on the validation. and reverting one or more of the subset of transportation devices, the further subset of transportation devices, and the set of all remaining transportation devices to one or more of the initial versions of the software and previous software updates. can do one or more of the following: At block 326, the processor 104 may use the software update for a first amount of time by the subset of transportation devices and for a second amount of time less than the first amount of time by the further subset of transportation devices. A subset of transportation devices may belong to a blockchain network. At block 328, the processor 104 may execute a smart contract of the blockchain network to enable the software update and distribute the software update through the plurality of transportation devices.

FIG. 3C illustrates a flow diagram 330 according to an example embodiment. Referring to FIG. 3C, the example method may be performed by master transporter node 102 (see FIG. 1C). The method 300 shown in FIG. 3C can include additional acts and some of the acts described herein can be removed and/or modified without departing from the scope of the method 330. should be understood. The description of method 330 is also made with reference to the features shown in FIG. 1C for illustrative purposes. In particular, processor 104 of master vehicle node 102 may perform some or all of the operations included in method 330.

Referring to FIG. 3C, at block 333, the processor 104 may send a first portion of the software update to the transportation devices of the first subset of transportation devices. At block 335, the processor 104 may send the second portion of the software update to the transportation devices of a further subset of transportation devices. At block 337, the processor 104 transmits the first portion of the software update to the first transport device when the first transport device of the subset of transport devices and the second transport device of the further subset of transport devices are in close proximity. to the second transportation device, and the second transportation device can cause the second portion of the software update to be sent to the first transportation device.

FIG. 3D shows a flow diagram 340 of an example method according to an example embodiment. Referring to FIG. 3D, method 340 can also include one or more of the following steps. At block 342, processor 104 may determine first and second portions of the software update prior to transmission to the subset of transportation devices and a further subset of transportation devices. At block 344, the processor 104 determines that the subset of transportation devices and the further subset of transportation devices have not received one or more of the first and second portions of the software update, When one or more of the two parts is not running, the master transport device can be routed to a geographic area.

At block 346, the processor 104 may route the first transportation device into the vicinity of the second transportation device when a period of time has elapsed since receiving the first portion of the software update; A second transport device may be routed into the vicinity of the first transport device when a period of time has elapsed since receiving the first portion. At block 348, the processor 104 may transmit the first and second portions of the software update by the transceiver at the master transport device, and the transceiver may transmit the first and second portions of the software update to the one or more of the first transport device and the second transport device. the first and second portions of the software update may be received, the first and second portions of the software update may be stored in memory in one or more of the first transportation device and the second transportation device; On two transport devices, the first part and the second part can be combined.

Note that a master transport device, a subset of transport devices, and a further subset of transport devices can be connected on a blockchain network. At block 350, processor 104 may execute a smart contract to exchange portions of software updates between transportation devices.

FIG. 3E illustrates a flow diagram 360 according to an example embodiment. Referring to FIG. 3E, the example method may be performed by the transport device node 102 (see FIG. 1D). The method 360 shown in FIG. 3E can include additional acts, and some of the acts described herein can be removed and/or modified without departing from the scope of the method 360. should be understood. The description of method 360 is also made with reference to the features shown in FIG. 1D for illustrative purposes. In particular, processor 104 of vehicle node 102 may perform some or all of the operations included in method 360.

Referring to FIG. 3E, at block 362, processor 104 may receive a software update at the transportation device. At block 364, processor 104 may perform a first activation of the software update in a first environment, where the first environment includes the least amount of potential interactions. At block 366, processor 104 may perform further activation of the software update in further circumstances if the first activation was successful. The further environment may include a greater amount of potential interactions than the first environment.

FIG. 3F shows a flow diagram 380 of an example method according to an example embodiment. Referring to FIG. 3F, method 380 can also include one or more of the following steps. At block 382, processor 104 may revert to the previous software version if one or more of the first validation and second validation fail. At block 384, processor 104 may receive further validation of software updates from other transportation devices. At block 386, processor 104 may invoke a software update based on further analysis of the environment. At block 388, the processor 104 may receive confirmations from the plurality of transportation devices for further activation of the software update. Confirmation can constitute a consensus on the blockchain to which the transport device belongs. At block 390, the processor 104 may execute the smart contract to record at least one data block reflecting the enabled software update on the blockchain ledger.

FIG. 4A illustrates an example blockchain vehicle configuration 400 for managing blockchain transactions associated with a vehicle, according to an example embodiment. Referring to FIG. 4A, a special transportation device/vehicle 425 is engaged in a transaction such as an asset transfer transaction (eg, access key exchange, vehicle service, dealer transaction, delivery/pickup, transportation service, etc.). Vehicle 425 can receive assets 410 and/or release/transfer assets 412 according to transactions defined by smart contracts. Transaction module 420 can record information such as parties, credits, service details, dates, times, locations, results, notifications, unexpected events, and the like. Those transactions in transaction module 420 may be replicated to blockchain 430 and managed by a remote server and/or remote blockchain peer, in which vehicle 425 may identify itself as a blockchain member and/or blockchain peer. can be. In other embodiments, blockchain 430 resides on vehicle 425. Assets received and/or transferred may be based on location and consensus as described herein.

FIG. 4B illustrates a blockchain between a service node (e.g., gas station, service center, body shop, rental sensor, car dealer, local service shop, delivery/pickup center, etc.) and a vehicle, according to an example embodiment. An example blockchain vehicle configuration 440 is shown for managing transactions. In this example, vehicle 425 is traveling on its own to service node 442 because it needs service and/or needs to stop at a special location. The service node 442 performs services (e.g., filling gas) or services such as oil changes, battery charging or replacement, tire changes or replacement, and any other transportation device-related services in special procedures and at special times. The vehicle 425 can be registered for a service call. The services provided 444 can be performed based on smart contracts, which in this case are downloaded from or accessed through the blockchain 430 to perform such services at special exchange rates. identified for permission to do so. The service can be recorded in the transaction log of the transaction module 420, credits 412 can be transferred to the service center 442, and the blockchain can record the transaction to represent all information regarding the recent service. In other embodiments, blockchain 430 resides on vehicle 425 and/or a service center server. In one example, a transportation device event can request refueling or other vehicle services, and a passenger can be held responsible for an increase in asset value for such services. can. Services can be provided via blockchain notifications and are used to redistribute asset value to passengers via their respective asset values. Confidence in the service center's actions can be based on asset transfer, as described herein.

FIG. 4C illustrates an example blockchain vehicle configuration 450 for managing blockchain transactions performed between various vehicles, according to an example embodiment. When a vehicle 425 is in a state where it needs to share assets with other vehicles, it communicates with other vehicles to perform various operations such as sharing access keys, transferring keys, obtaining a service call, etc. vehicle 408. For example, vehicle 408 may need a battery charge and/or have a problem with its tires, and may be in the process of picking up a package for delivery. Vehicle 408 can notify other vehicles 425 within the same network and operating on the same blockchain member service. Vehicle 425 can then receive information from vehicle 408 via wireless communication requests to perform package pickups and/or from a server (not shown). Transactions are recorded in transaction modules 452 and 420 in both vehicles. Assets are transferred from vehicle 408 to vehicle 425 and the record of the asset transfer is recorded on blockchain 430/454, assuming the blockchains are different from each other, or on the same blockchain used by all members. recorded in Trust for transferred assets can be based on asset values (eg, access keys), as described herein.

FIG. 5 illustrates a blockchain block 500 and the contents of block structures 502A-502n that can be added to a distributed ledger, according to an example embodiment. Referring to Figure 5, a client (not shown) can submit an entry to a blockchain node to effectuate an action on the blockchain. By way of example, a client may be an application acting on behalf of a requester, such as a device, person, or entity proposing an entry to a blockchain . Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and replicas of the distributed ledger. Different types of blockchains are used in a blockchain network that includes an endorsing peer that simulates and endorses the entry proposed by a client, and a commit peer that validates the endorsement, validates the entry, and puts the entry into a distributed ledger. Nodes/peers can exist. In this example, a blockchain node can perform the role of an endorser node, a committer node, or both.

The example system includes a blockchain that stores an immutable, ordered record of blocks and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger can exist for one channel, with each peer maintaining its own copy of the distributed ledger for each channel of which it is a member. An illustrative blockchain is an entry log, structured as hash-linked blocks, each block containing a sequence of N entries. The block may include various components such as those shown in FIG. A link combination of blocks can be generated by adding the hash of the previous block header in the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically linked, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of links, the latest block in the blockchain represents all entries that came before it. An illustrative blockchain can be stored on a peer file system (local or attached storage) that only supports additional blockchain workloads.

The current state of blockchains and distributed ledgers can be stored in state databases. Here, the current state data represents the latest values for all keys ever contained in the blockchain's chain entry log. Smart contract executable code calls execute entries against the current state in the state database. To make these smart contract executable code calls very efficient, the latest values of all keys are stored in a state database. The state database can include an indexed view into the blockchain's entry log, so the state database can be regenerated from the chain at any time. The state database can be automatically recovered (or generated, if necessary) when a peer starts up and before entries are accepted.

An endorsing node receives entries from clients and endorses entries based on the simulated results. Endorsing nodes hold smart contracts that simulate entry proposals. When an endorsing node endorses an entry, the endorsing node creates an entry endorsement, which is a signed response from the endorsing node to the client application indicating the simulated endorsement of the entry. How entries are endorsed relies on an endorsement policy that can be specified within the smart contract executable code. An example of an endorsement policy is: ``The majority of endorsing peers must endorse the entry.'' Different channels may have different endorsement policies. Endorsed entries are forwarded by the client application to the ordering service.

The ordering service accepts the endorsed entries, orders them in blocks, and delivers the blocks to the committing peers. For example, the ordering service may initialize a new block when a threshold of entries is reached, or a timer times out, or other conditions are met. In this example, the blockchain node is a committing peer that received data block 602A for storage on the blockchain. An ordering service can be composed of a cluster of orderers. The ordering service does not process entries, smart contracts, or maintain a distributed ledger. Rather, the ordering service specifies which endorsed entries can be accepted and in what order those entries are populated into the distributed ledger. The architecture of a blockchain network can be designed such that certain implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when they are put into the network. Unlike cryptocurrency blockchain systems (e.g. Bitcoin) where ordering occurs through solving cryptographic puzzles or mining, in this example the parties to the distributed ledger are the ones most suited to the network. You can choose which ordering mechanism to use.

Referring to FIG. 5, a block 502A (also referred to as a data block) stored in a blockchain and/or distributed ledger includes block headers 504A~504n, transaction specific data 506A~506n, and block metadata 508A~ It can contain multiple data segments, such as 508n. The various illustrated blocks and their contents, such as block 502A and their contents, are for example purposes only and are not meant to limit the scope of the example embodiments. This should be recognized. In some cases, both block header 504A and block metadata 508A may be smaller than transaction specific data 506A containing entry data, but this is not a requirement. Block 502A can store transaction information for N (eg, 100, 500, 1,000, 2,000, 3,000, etc.) entries in block data 510A-510n. Block 502A may also include a link to a previous block (eg, on the blockchain) in block header 504A. In particular, block header 504A may include a hash of a previous block header. Block header 504A may also include a unique block number, a hash of block data 510A for current block 502A, and the like. The block number for block 502A can be unique and can be assigned in an increasing/successive order starting from zero. The first block in a blockchain, also called the genesis block, contains information about the blockchain, its members, the data stored on it, etc.

Block data 510A can store entry information for each entry recorded in the block. For example, entry data may include one or more types of entry, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, smart contract executable code path (deployment tx), smart contract execution Possible code name, smart contract executable code version, inputs (smart contract executable code and functionality), client (author) identity, client signature, endorser identity, endorser signature, like public key and certificate, etc. Proposal hash, smart contract executable code event, response status, namespace, read set (list of keys and versions, etc. read by the entry), write set (list of keys and values, etc.), start key, end key, key , a Merkle tree query summary, etc. Entry data can be stored for each of the N entries.

In some embodiments, block data 510A can also store transaction specific data 506A that adds additional information to the chain linked with the block's hash in the blockchain. Accordingly, data 506A can be stored in an immutable log of blocks on a distributed ledger. Some of the benefits of storing such data 506A are reflected in the various embodiments disclosed and illustrated herein. Block metadata 508A can store multiple fields of metadata (eg, as a byte array, etc.). Metadata fields may include a signature for block creation, a reference to the most recent configuration block, entry filters that identify valid and invalid entries within the block, the most recent surviving offset of the ordering service that ordered the block, and so on. Signatures, latest building blocks, and orderer metadata can be added by the ordering service. On the other hand, a block committer (such as a blockchain node) can add valid/invalid information based on endorsement policies, read/write set validation, etc. The entry filter may include a byte array of a size equal to the number of entries in block data 510A and a validation code that identifies whether the entry was valid/invalid.

Other blocks 502B-502n in the blockchain may also have headers, files, and values. However, unlike the first block 502A, each of the headers 504A-504n in the other blocks includes the hash value of the immediately preceding block. The hash value of the immediately preceding block may be simply a hash of the header of the previous block, or it may be the hash value of the entire previous block. In order to establish an auditable and immutable chain-of-custody (also referred to as evidence hold) by including the hash value of the preceding block in each of the remaining blocks, indicated by arrow 512. As shown, we can perform tracking from the Nth block back to the genesis block (and associated original file) on a block-by-block basis.

The embodiments described above can be implemented in hardware, a computer program executed by a processor, firmware, or a combination of the above. A computer program may be included in a computer readable medium, such as a storage medium. For example, a computer program can be stored in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ( ("EEPROM"), a register, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

An example storage medium can be coupled to a processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and storage medium may reside on an application specific integrated circuit ("ASIC"). In the alternative, the processor and storage medium can reside as separate components. For example, FIG. 6 depicts an example computer system architecture 600 that may be or be integrated with any of the components described above.

FIG. 6 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein. Regardless, processing node 600 may be implemented and/or may perform any of the functions described above.

Computing node 600 includes a computer system/server 602 that is operational in numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 602 include, but are not limited to, 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 systems or devices described above.

Computer system/server 602 can be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform special tasks or implement particular abstract data types. Computer system/server 602 can be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As shown in FIG. 6, the computer system/server 602 in the cloud computing node 600 is shown in the form of a general purpose computing device. Components of computer system/server 602 include, but are not limited to, one or more processors or processing units 604, system memory 606, and a bus that couples various system components to processor 604, including system memory 606. can be included.

A bus can be any one of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses, using any of a variety of bus architectures. or a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Macro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the peripheral Contains component interconnect (PCI) bus.

Computer system/server 602 typically includes a variety of computer system readable media. Such media can be any available media that can be accessed by computer system/server 602 and includes both volatile and nonvolatile media, and removable or non-removable media. In one embodiment, system memory 606 implements the flow diagrams of other figures. 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 further include other removable/non-removable, volatile/non-volatile computer system storage media. For purposes of example only, memory 606 may be used for reading from and writing to non-removable, non-volatile magnetic media (not shown and typically referred to as a "hard drive"). Can be provided. Although not shown, magnetic disk drives for reading from and writing to non-removable, non-volatile magnetic disks (e.g., "floppy disks"), and CD-ROMs or other optical media, etc. An optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as. In such instances, one or more data medium interfaces may each be connected to the bus. As further shown and described below, memory 606 includes a set (e.g., at least one set) of program modules configured to perform the functions of various embodiments of the present application. Can include at least one program product.

A program/utility that has a set (at least one set) of program modules includes, by way of example and without limitation, an operating system, one or more application programs, other program modules, and program data in memory. Can be stored in 606. 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 generally perform the functions and/or methods of various embodiments of the present application as described herein.

As will be appreciated by those skilled in the art, aspects of the present application may be implemented as a system, method, or computer program product. Accordingly, aspects of the present application may include an entire hardware embodiment, an entire software embodiment (including firmware, resident software, microcode, etc.), or herein generally referred to as a "circuit" or "module." , or may take the form of embodiments that combine software and hardware aspects. Additionally, aspects of the present application may take the form of a computer program product embodied in one or more computer readable media containing computer readable program code.

Computer system/server 602 also includes one or more devices that allow a user to interact with computer system/server 602 via I/O adapter 612, such as a keyboard, pointing device, display, etc., and and/or with one or more external devices, such as any device (e.g., network card, modem, etc.) that enables the computer system/server 602 to communicate with one or more other computing devices. You can also communicate. Such communication can be performed via the adapter 612's I/O interface. Additionally, the computer system/server 602 may connect to one or more networks, such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via a network adapter. Can communicate with the network. As shown, adapter 612 communicates with other components of computer system/server 602 via a bus. Although not shown, it should be understood that 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, tape drives, data archival storage systems, and the like.

While at least one example embodiment of a system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description, this application is directed to the disclosed embodiments. It will be appreciated that various rearrangements, modifications, and substitutions are possible, as described and defined by the following claims without limitation. For example, the functionality of the systems in the various figures may be performed by one or more of the modules or components described herein, or may be performed in a distributed architecture, with pairs of transmitters, receivers, or both. can include. For example, all or some of the functions performed by individual modules may be performed by one or more of these modules. Additionally, the functions described herein can be performed at various times and in conjunction with various events internal to or external to the module or component. Additionally, information sent between the various modules may be sent between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and/or via multiple protocols. It can be sent by Also, messages sent or received by any of the modules can be sent or received directly and/or through one or more of the other modules.

Those skilled in the art will understand that a "system" can be defined as a personal computer, server, console, personal digital assistant (PDA), cell phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. You will realize that it can be realized. The presentation of the functions described above as being performed by a "system" is not intended to limit the scope of this application in any way, but is intended to provide one example of many embodiments. ing. Indeed, the methods, systems, and apparatus disclosed herein can be implemented in local or distributed form consistent with computing technology.

It should be noted that some of the features of the systems described herein are presented as modules to more particularly emphasize their implementation independence. For example, a module can be implemented as a customized very large scale integrated (VLSI) circuit or a hardware circuit with resident conductors, transistors, or other isolated components, such as gate arrays, logic chips, and the like. Modules can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like.

Modules can also be implemented, at least in part, in software for execution by various types of processors. An identified unit of executable code can include, for example, one or more physical or logic blocks of computer instructions that can be organized as, for example, an object, procedure, or function. Nevertheless, the identified modules need not be physically co-located for execution; they may comprise separate instructions stored in different locations, and the modules may be logically combined. , modules may be provided and the stated objectives for the modules may be achieved. Additionally, the module may be, for example, a hard disk drive, a flash device, random access memory (RAM), tape, or any other such medium used to store data, including computer readable media. Can be stored.

In fact, modules of executable code can even be distributed over several different code segments, across a single instruction, multiple instructions, and different programs and across several storage devices. Similarly, operational data may be identified and instantiated herein within modules, may be embodied in any suitable form, and may be organized within any suitable type of data structure. The operational data can be collected as a single data set or distributed over different locations, including on different storage devices, and can exist, at least in part, as simply electronic signals on a system or network.

It will be readily appreciated that the components of the present application, as generally described and illustrated herein, can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application.

One of ordinary skill in the art will readily understand that the above may be practiced with a different order of steps and/or with hardware elements in a different configuration than that disclosed. Will. Therefore, while this application has been described in terms of these preferred embodiments, certain modifications and variations will be apparent to those skilled in the art, as well as alternative configurations.

Although preferred embodiments of this application have been described, the described embodiments are for illustrative purposes only, and the scope of this application is to include equivalents and modifications thereto (e.g., protocols, hardware devices, It is to be understood that the scope of the invention (software platform, etc.) is defined solely by the accompanying claims.

<u style="Single"> The present disclosure includes the following aspects.</u><u style="Single">(1)</u><u style="Single"> A system,</u><u style="Single"> a transport device processor of a subset of the transport device;</u><u style="Single"> a memory communicatively coupled to the processor, the processor comprising:</u><u style="Single"> receiving a software update at the transportation device;</u><u style="Single"> The software update,</u><u style="Single"> the time period during which the software update was used;</u><u style="Single"> the number of times the software update is utilized by the subset of transportation devices;</u><u style="Single"> enabled based on one or more of the</u><u style="Single"> distributing the software update to a further subset of the transportation devices that is larger than the subset of transportation devices based on the activation;</u><u style="Single"> system.</u><u style="Single">(2)</u><u style="Single"> The system of claim 1, wherein the processor distributes the software update to a set of all remaining transportation devices that is larger than the further subset of transportation devices.</u><u style="Single">(3)</u><u style="Single"> One or more of the subset of transportation devices, the further subset of transportation devices, and the set of all remaining transportation devices include:</u><u style="Single"> existing software,</u><u style="Single"> existing hardware,</u><u style="Single"> geographical location,</u><u style="Single"> temperature of the environment,</u><u style="Single"> transport equipment type,</u><u style="Single"> model of transport equipment,</u><u style="Single"> transport equipment condition;</u><u style="Single"> road condition, and</u><u style="Single"> A system according to (1) above, which is based on one or more of the destinations of the transport device.</u><u style="Single">(4)</u><u style="Single"> The processor selects one or more of the subset of transportation devices, a further subset of the transportation devices, and a set of all remaining transportation devices upon determining a negative outcome based on the activation. The system described in (1) above to be changed.</u><u style="Single">(5)</u><u style="Single"> The processor selects one or more of the subset of transportation devices, a further subset of the transportation devices, and a set of all remaining transportation devices upon determining a negative outcome based on the activation. , one or more earlier versions of the software, and the system described in (1) above, reverting to a previous software update.</u><u style="Single">(6)</u><u style="Single"> The processor updates the software;</u><u style="Single"> a first amount of time by the subset of transport devices; and</u><u style="Single"> using for a second amount of time by the further subset of said transport devices;</u><u style="Single"> the first amount of time is greater than the second amount of time;</u><u style="Single"> The system described in (1) above.</u><u style="Single">(7)</u><u style="Single"> The system according to (1) above, wherein the subset of transportation devices belongs to a blockchain network.</u><u style="Single">(8)</u><u style="Single"> 7. The system of claim 7, wherein the processor executes a smart contract of the blockchain network to enable the software update and distribute the software update through the plurality of transportation devices.</u><u style="Single">(9)</u><u style="Single"> The processor performs a first validation of the software update in a first environment containing the least amount of potential interactions, and if the first validation is successful, further validation of the software update. The system according to (1) above, wherein the process is performed in a further environment containing a greater amount of potential interactions than the first environment.</u><u style="Single">(10)</u><u style="Single"> The system of (9) above, wherein the processor receives further validation of the software update from another transportation device.</u>