JP2022551560A - Manage vehicle software updates - Google Patents

Abstract

An example operation is to receive a software update on a transport device of a subset of the transport devices and to update the software 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 used by the subset of the transport devices. It may include one or more of activating the update and distributing the software update to a further subset of the transportation devices that is greater than the subset of the transportation devices based on the activation. [Selection drawing] Fig. 2A

Description

Vehicles or transports, such as automobiles, motorcycles, trucks, planes, trains, etc., typically provide transportation needs to passengers and/or goods in a variety of ways. Functionality related to transportation devices can be identified and utilized by various computing devices such as smart phones, computers, or tablets.

Software updates for vehicles are typically performed by a central server that provides software updates to each individual vehicle client computer. This typically requires a network connection to the cloud. However, overuse of the WAN to distribute software updates may be inefficient and unsafe. Additionally, a software update may not have been fully tested with a sufficiently large number of transport devices before being sent by the server. No centralized system exists that can collect information about software updates from millions of vehicles and track them securely and efficiently.

Therefore, it is desirable to have a secure propagation of vehicle software updates based on extensive testing with large numbers of vehicles. It is also desirable to have information about software updates recorded in shared storage.

One example embodiment includes receiving a software update on a transport device of a subset of the transport devices, and determining the time period during which the software update was used and the number of times the software update was used by the subset of the transport devices. activating the software update based on the activation; and propagating the software update based on the activation to a further subset of the transport devices that is greater than the subset of the transport devices. can provide

Another example embodiment provides for a first portion of a software update by a master transport device 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 proximity. to a transport device of a first subset of transport devices; forwarding, by the master transport device, a second portion of the software update to transport devices of a further subset of transport devices; one or more of causing the transport device to send a first portion of the software update to the second transport device; and causing the second transport device to send a second portion of the software update to the first transport device. can provide a way to

Yet another example embodiment includes receiving a software update on a transportation device and performing a first validation of the software update in a first environment containing the least amount of potential interactions. and performing a further activation of the software update in a further environment containing a greater amount of potential interactions than the first environment if the first activation is successful. can provide a way to

Other example embodiments can provide a system including a processor and a memory, wherein the processors of a subset of the vehicles receive the software update and the time period during which the software update has been used. activating the software update based on one or more of the number of times the software update is used by a subset of the vehicles; and activating the software update based on the activation to a further subset of the vehicles that is greater than the subset of the vehicles. configured to perform one or more of distributing;

Another example embodiment can provide a system including a processor and a memory, wherein the processor of a master transport device controls 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 transport devices and sending a second portion of the software update to the transport devices of a further subset of the transport devices when the are in proximity to each other. and causing the first transportation device to send the 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. configured to perform the above.

Yet another example embodiment can provide a system that includes a processor and a memory, the processor being configured to receive software updates on a transportation device and a first method that includes the least amount of potential interactions. Performing a first activation of a software update in an environment and, if the first activation is successful, updating the software update in a further environment containing a greater amount of potential interactions than the first environment. is configured to perform one or more of the following:

A further example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, instruct the processor to receive a software update and to notify the processor of the time the software update was in use. activating a software update based on one or more of the time period and the number of uses of the software update by a subset of the vehicles; Cause one or more of distributing to the subset to be performed.

A further example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, instruct the processor to transfer a first transportation device of the subset of transportation devices and a further transportation device of the transportation device. sending a first portion of the software update to a transport device of the first subset of transport devices when a second transport device of the subset is in proximity; and sending a second portion of the software update to a further subset of transport devices. causing the first transportation device to send the first portion of the software update to the second transportation device; and sending the second transportation device the second portion of the software update to the first transportation device. to perform one or more of

A further example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, instruct 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 in performing one or more of performing further validation of the software update.

1 illustrates a transport device network diagram in accordance with an example embodiment; FIG. 1 illustrates an example network diagram including a vehicle node in accordance with an example embodiment; FIG. FIG. 4 illustrates another example network diagram including a vehicle node in accordance with an example embodiment; FIG. 4 illustrates another example network diagram including a vehicle node in accordance with an example embodiment; 1 illustrates a blockchain architecture configuration according to an example embodiment; 4 illustrates another blockchain configuration according to an example embodiment; 1 illustrates a blockchain configuration for storing blockchain transaction data in accordance with an example embodiment; 4 illustrates a flow diagram in accordance with an example embodiment; Figure 4 illustrates another flow diagram in accordance with an example embodiment; 4 illustrates a further flow diagram in accordance with an example embodiment; 4 illustrates a further flow diagram in accordance with an example embodiment; 4 illustrates a further flow diagram in accordance with an example embodiment; 4 illustrates a further flow diagram in accordance with an example embodiment; 1 illustrates an example blockchain vehicle configuration for managing blockchain transactions associated with a vehicle, according to an example embodiment; 4 illustrates another example blockchain vehicle configuration for managing blockchain transactions between a service center and a vehicle, according to an example embodiment; 4 illustrates yet another example blockchain vehicle configuration for managing blockchain transactions conducted between different vehicles, in accordance with an example embodiment; 4 illustrates an example data block according to an example embodiment; 1 illustrates an example system that supports one or more of the example embodiments.

It will be readily understood herein that the illustrative components, as generally described and illustrated in the figures, can be arranged and designed in a wide variety of different configurations. Accordingly, the following detailed description of at least one embodiment of the method, apparatus, non-transitory computer-readable medium, and system, as represented in the accompanying figures, limits the scope of the claimed application. It is not intended to be, and is 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 phrase "exemplary embodiment," "some embodiments," or other similar phrases, at least throughout this specification, refers to the particular features described in connection with the embodiments; It refers to the fact that a structure or property can be included in at least one embodiment. Thus, appearances of the phrases "exemplary embodiment," "in some embodiments," "in other embodiments," or other similar phrases may be used throughout this specification to refer to the same terminology of an embodiment. Not necessarily referring to groups, 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, whether the connections depicted are unidirectional or bidirectional arrows. As used herein, transportation equipment includes automobiles, 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. can contain objects.

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

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

Within the 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, containing an append-only immutable data structure (i.e., a distributed ledger) that can maintain records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without consensus among distributed peers. For example, peers can enable blockchain storage entities, group storage entities into blocks, and run a consensus protocol to build hash chains through the blocks. This process forms a ledger by ordering the storage entities for consistency, if necessary. Anyone can participate in a public or permissionless blockchain 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 between groups of entities that share a common goal but do not fully trust or trust each other, such as businesses that exchange funds, goods, information, etc. Provide a system that can ensure interaction. Illustrative applications can work in permissioned and/or permissionless blockchain settings.

Smart contracts are trusts that take advantage of the tamper-resistant properties of a shared or distributed ledger (which can be in the form of a blockchain) database and underlying agreements between member nodes called endorsements or endorsement policies. It is a highly distributed application. Generally, blockchain entities are endorsed before being put onto the blockchain, while unendorsed entries are ignored. A typical endorsement policy allows smart contract executable code to identify endorsers for the shape entry 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 validate the entry. After validation, the entries enter the ordering phase and 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" can perform a logical function in the sense that multiple different types of nodes can run on the same physical server. Nodes are grouped in trust domains and associated with logical entries that control the nodes in various ways. Nodes can include different types, such as clients or submission clients that submit entry calls to endorsers (eg, peers) and broadcast entry proposals to the ordering service (eg, ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, inject entries, and maintain a state and copy of a ledger of blockchain entries. A peer 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, populates an entry, and is also known as an initial blockchain entry, usually containing 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 calls (i.e., entries) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Entries can result in a set of asset key-value pairs populated in the ledger as one or more operands such as creates, updates, deletes, and so on. A ledger contains a blockchain (also called a chain), which is used to store immutable, ordered records in blocks. The ledger also contains 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 an entry log, structured as blocks linked with hashes, each block containing a sequence of N entries, where N is one or more. The block header also contains the hash of the block entry along with the hash of the preceding block header. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, the ledger cannot be tampered with unless the hash link is destroyed. The hash of a blockchain block added most recently represents all entries on the chain that came before it, and all peer nodes are in a consistent and trusted state. make it possible to ensure Chains can be stored in peer node filesystems (i.e. local granted 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-values known to the channel, it is sometimes referred to as the world state. A smart contract executable code call performs an entry into the ledger's current state data. To make these smart contract executable code interactions efficient, the latest values of the keys can be stored in a state database. The state database can be just 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 restored (or regenerated if necessary) when a peer node starts up and before entries are accepted.

Blockchains differ from traditional databases in that blockchains are not centralized storage, but rather decentralized, immutable, and secure storage where nodes must share record changes in storage. ing. Some properties that are unique to blockchains and that aid in implementing blockchains include, but are not limited to: Immutable Ledger, Smart Contracts, Security, Privacy, Decentralization, Consensus, Endorsement, Accessibility. gender, etc.

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 the owner of a vehicle, or the driver of a vehicle owned by another party. Vehicles can request service at intervals, and service demands can require authorization before allowing the service to be received. Service centers may also service vehicles in nearby areas based on the vehicle's current route plan and relative levels of service requirements (e.g., immediate, severe, moderate, non-critical, etc.). can provide. Vehicle demand can be monitored by one or more sensors that report sensed data to a central controller computer device in the vehicle so that it is forwarded to a management server for investigation and action. .

The sensors can be located one or more inside the transport device, outside the transport device, on fixed objects remote from the transport device, and on other transport devices close to the transport device. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service demand, vehicle gearshift, vehicle steering, and the like. The concept of sensor may also be a device such as a mobile device. Sensor information is also used to identify whether the vehicle is operating safely and whether passengers have been involved in unexpected vehicle conditions, such as during vehicle access periods. can. Vehicle information collected before, during, and/or after vehicle operation can be identified and stored in transactions on a shared/distributed ledger, such as through blockchain membership groups, As determined by the licensing authority, and so can be regenerated in a "decentralized" manner and injected into the immutable ledger. Each stakeholder (i.e. company, institution, etc.) may also wish to restrict the disclosure of private information, so the blockchain and its immutability can restrict disclosure, and each special user vehicle profile You can manage permissions for Smart contracts provide compensation, quantify user profile scores/ratings/ratings, apply vehicle event permissions, determine when service is needed, identify crash and/or degrade events, 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, the results can be identified and the required 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 an array of sensors. Machine learning, lidar projectors, radar, and ultrasonic sensors all work together to create a living map of the world that self-driving cars can navigate. Most companies in the race to full autonomy, with some notable exceptions, rely on the same basic technology foundation of lidar + radar + cameras + 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 functions.

An illustrative application, in one embodiment, includes authorizing a vehicle for service via an automated expedited authorization scheme. For example, driving to a charging station or fuel pump can be done by the driver of the vehicle, and authorization to receive charging or fuel can be done without delay if the authorization is received at the service station. A vehicle can provide a communication signal that provides the ID 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 such that other identifiers can be sent wirelessly from the user's device to the service center to replace or supplement the first authorization effort between the transport 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), typically maintaining 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, for example. Information stored in a centralized database is typically accessible from multiple different points. A centralized database is easy to manage, maintain and control, especially for security purposes, due to its single location. Within a centralized database, a single storage location for all data also means that a given set of data has only one primary record, thus minimizing data redundancy. .

According to an example embodiment, distribution of software updates to vehicles is provided without using WAN technology. 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 can be performed over multiple executions of the software update code. If the software test fails, the transport device is alerted and the transport device software can revert to the previous software version.

In other embodiments, the master vehicle system, when distributing a software update to a vehicle, divides the software update into at least two parts and adds the software update parts by sending them at different times and/or from different sources. security. In one example embodiment, software updates may be sent from the master transport device first. 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 to give to which transport device characteristics (e.g., the security level of the transport device, the age of the transport device, the age of the transport device, hardware in the transport device that can properly execute the software, condition of the transport device, characteristics of the user/passenger of the transport device, use of features on or associated with the transport device). Updates can be provided based on possible uses of the update, eg, which transport devices can better test/utilize the software update. In one example, vehicle 1 can obtain the first part of the update (ABC) and vehicle 2 the other part of the update (ABC') from the same master vehicle. A software update can be split into more than two parts, e.g., some transporters receive two parts, some transporters receive three parts, and some transporters receive n parts. can. A master transport device may have a higher level of security than a subset of transport devices and a further subset of transport devices. Any software update problems can be reported to the master transport (which can report it to the central server). If a problem occurs with either portion, or with the collected first and second portions of the update, the master transport device can be moved closer to the problematic transport device to determine the problem. You can monitor that transport device to troubleshoot.

In yet another example embodiment, as software updates are received, collected, and implemented, the transportation device continues to run the old software version and, under the least potential problems, the newer version. Use updated software intermittently. For example, if an update is made to the braking software update, the vehicle can use the updated software in the driving environment when traffic is at its lightest (and when there are no pedestrians and/or objects). . Once the updated software is activated in this driving environment, the vehicle will be able to operate in different potentially problematic driving environments (e.g., those with more traffic, pedestrians, and/or objects). You can use the updated software. According to an example embodiment, the operator of the transportation device may be unaware of the functionality of the software update management application. The vehicle system can test software updates incrementally in different environments and revert to previous versions of the software if necessary.

In yet another embodiment, the master transport device determines which parts are given to which transport device, depending on the characteristics of the transport device (e.g., security level of the transport device, age of the transport device, software) as appropriate. hardware in the transport device that can be implemented, the state of the transport device, the characteristics of the user/passenger of the transport device, the use of features in or associated with the transport device). Updates can be based on possible uses of the update, eg, which transport devices can better test/utilize the software.

In further embodiments, different vehicles can aggregate software portions based on the time or date submitted, vehicle and/or software and/or user characteristics. For example, vehicle 1 can get the first part (ABC) and on the very next transmission vehicle 2 can get 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 split into more than two parts. Some transport devices can receive two portions, some transport devices can receive three portions, and some transport devices can receive n portions.

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

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

In a further embodiment, if a problem occurs with either part of the update, or the first and second parts aggregated, the master transport device can be brought into proximity with the problematic transport device and monitor the problem. and issues can be accessed.

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

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

According to a further example embodiment, processor 104' (or 104'') receives a software update (eg, from master transport device 102) and performs a first validation of the software update in a first environment. The first environment may contain the least amount of potential interactions (minimum traffic, no pedestrians, normal weather conditions, etc.) and the processor 104' (or 104'' ) can perform further activations of the software update in further environments if the first activation is successful. Further environments 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 management of software updates. Referring to FIG. 1B, network diagram 111 includes a subset of transport nodes 102 that are connected to other subsets of transport nodes 105 via blockchain network 106 . Vehicle nodes 102 and 105 can be vehicles/vehicles. The blockchain network 106 may have a ledger 108 for storing data such as software update related data, including software update timestamps. Transport node 102 can be connected to other subsets of transport nodes (not shown).

Although this example describes only one transport node 102 in detail, multiple such nodes can be connected to the blockchain 106 . Without departing from the scope of the transport node 102 disclosed herein, the transport node 102 may include additional components, and some of the components described herein may be omitted and/or It should be understood that modifications can be made. The vehicle node 102 may have a processing unit or server computer, etc., and may have a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), field programmable. It may include gate arrays (FPGAs), and/or other hardware devices. Although a single processor 104 is shown, it is understood that the vehicle node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the vehicle node 102 system. should.

Vehicle node 102 may also include non-transitory computer-readable media 112 that may 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 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 type of storage device.

Processor 104 can execute machine-readable instructions 114 for receiving software updates at transportation device 104 . Each of transport devices 102 and 105 can act as a network peer (ie, node) on blockchain 106 . As discussed above, blockchain ledger 108 can store software update related transactions. A blockchain 106 network can be configured to use one or more smart contracts located on a transport device (or node) 102 that can manage transactions to other participating transport device nodes 105 . Vehicle nodes 102 can provide information to blockchain 106 that is stored in ledger 108 .

Processor 104 can execute machine executable instructions 116 to activate the software update. Software updates can be activated based on the period of time the software update has been used and the number of times the software update has been used by a subset of the transportation devices 102 . Processor 104 can execute machine readable instructions 118 for distributing the software update 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 vehicle software updates. Referring to FIG. 1C, network diagram 121 is connected to other transport device nodes 105 and 107 via blockchain network 106 having ledger 108 for storing software update related transactions 110 . It includes a transport node 102 that acts as a master transport node. Vehicle nodes 102, 105, and 107 can also act as blockchain 106 peers. Although this example details only one master transport node 102 , multiple such nodes can be connected to the blockchain 106 . The master transport node 102 may include additional components and some of the components described herein may be omitted without departing from the scope of the master transport node 102 disclosed herein. and/or modified. The master vehicle node 102 may have a processing unit or server computer or the like, 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 It may include programmable gate arrays (FPGAs), and/or other hardware devices. Although a single processor 104 is shown, it is understood that the master transport node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the master transport node 102 system. It should be.

Master transport node 102 may also include non-transitory computer-readable media 112 ′ that may 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), hard disk, optical disk, or other type of storage device.

Processor 104 can execute machine readable instructions 112 ′ for sending a first portion of a software update to a first subset of vehicles 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 transaction can be stored in ledger 108 .

Processor 104 can execute machine readable instructions 115 for sending a second portion of the software update to a further subset of the transportation devices (eg, 107). The processor 104 first sends the first portion of the software update to the first transport device when the first transport device of the subset of transport devices 105 and the second transport device of the further subset of the transport devices 107 are in proximity. Machine readable instructions 117 can be executed to cause second transportation device 107 to send the second portion of the software update to first transportation device 105 .

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

The vehicle node 102 may also include a non-transitory computer-readable medium 112'' that may store machine-readable instructions executable by the processor 104. Examples of machine-readable instructions are shown as 132-136 and are described below. Examples of non-transitory computer-readable media 112″ include electronic, magnetic, optical, or other physical storage devices that contain or store 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), hard disk, optical disk, or other type of storage device.

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

Processor 104 can execute machine readable instructions 134 for performing a first validation of a software update in a first environment containing the least amount of potential interactions. Processor 104 can execute machine readable instructions 136 to perform further validation of the software update in further environments if the first validation is successful. Further environments may contain 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, a blockchain architecture 200 can include certain blockchain elements, eg, groups of blockchain member nodes 202 - 206 , as part of blockchain groups 210 . In one example embodiment, an authorized blockchain is not accessible to all parties, but only to members with authorized access to blockchain data. Blockchain nodes participate in numerous activities such as blockchain entry addition and validation processes (consensus). One or more of the blockchain nodes can endorse entries based on the endorsement policy and provide ordering services to all blockchain nodes. Blockchain nodes can initiate blockchain behavior (such as authentication) and attempt to write to the blockchain immutable ledger stored on the blockchain, and a copy of the ledger can also be used by the underlying can be stored in any physical infrastructure.

A blockchain transaction 220 is stored in the computer's memory once the transaction has been received and accepted by the consensus model dictated by the member nodes. Accepted transactions 226 are stored in the current block of the blockchain through an injection procedure that involves performing a hash of the transaction's data content in the current block and referencing the previous hash of the previous block. will be put into the blockchain. Within the blockchain, there can be one or more smart contracts 230, which can be used to set things such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The terms and actions of transaction agreements contained in smart contract executable application code 232 can be defined. The code determines whether the requesting entity is registered to receive vehicular services, which service features it is entitled to receive, and/or requests, taking into account their profile status. and whether to monitor their behavior in subsequent events. For example, when a service event occurs and the user is in the vehicle, sensor data monitoring can be triggered and certain parameters, such as the vehicle's charge level, exceed a particular threshold for a particular period of time. / can be identified as less than 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 to 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. Sensor data can also tell you where you are driving, average speed, top speed, acceleration rate, whether there have been any collisions, whether the expected route has been taken, where is your next destination, are safety measures in place, It can also be the basis for vehicle event data 234, such as whether the vehicle has sufficient charge/fuel. All such information can underlie smart contract terms 230 and is stored on the blockchain. For example, sensor thresholds stored in smart contracts can be used as the basis for whether a detected service is needed, when and where the service should be performed.

FIG. 2B illustrates a shared ledger configuration according to an example embodiment. Referring to FIG. 2B, an example blockchain logic 250 includes a processing unit and a blockchain application interface 252 as an API or plug-in application that links to an execution platform for a particular transaction. Blockchain configuration 250 is a stored program/application code (e.g., , smart contract executable code, smart contracts, etc.) that are linked to application programming interfaces (APIs) for executing. It can be deployed as an entry and installed on all blockchain nodes via appending to the distributed ledger.

Smart contract application code 254 provides the rationale for the blockchain by establishing the application code that, when executed, makes the terms and conditions of the transaction valid. Smart contract 230 , when executed, causes an accepted transaction 226 to be generated, and transaction 226 is transferred to blockchain platform 262 . The platform includes security/authorization 268, a computing unit that performs transaction management 266, and storage 264 as memory that stores 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 wishing to access data entries. It can include the underlying physical computer infrastructure that can be used to 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 configuration of Figures 2A and 2B can process and execute programs/applications and 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 implement reminders, updates, and/or other notifications that changes, updates, etc. are made. The smart contract can itself be used to identify the rules associated with authorization and access requirements, and the usage of the ledger. For example, the information can include new entries, which can be processed by one or more processing entities (eg, processors, virtual machines, etc.) included in the blockchain layer. Results may include decisions to reject or accept new entries based on criteria defined in the smart contract and/or consensus of peers. A physical infrastructure can be utilized to retrieve any of the data or information described herein.

Within the smart contract executable code, smart contracts can be created through high-level applications and programming languages and written to blocks in the blockchain. A smart contract can include executable code that is registered, stored, and/or replicated on a blockchain (eg, a distributed network of blockchain peers). An entry is an execution of smart contract code, which can be executed in response to a condition associated with the smart contract being met. Execution of smart contracts can induce reliable modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger from the execution of 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 form of key-value pairs. Additionally, the 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 output 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 the blockchain can be made public and/or encrypted and kept private. Temporary data used/generated by the smart contract is held in memory by the supplied execution environment and deleted once the required data is identified for the blockchain.

The smart contract executable code can 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 executed and validated together by chain validators during the consensus process. The smart contract executable code receives the hash and retrieves from the blockchain the hash associated with the data template created using the previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the smart contract executable code sends the authorization key to the requested service. Smart contract executable code can be written to blockchain data 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 asks the vehicle service provider to share user profile rating information if the known and established user profile is attempting to rent a vehicle with the established rating profile. be able to. Server 276 may receive and process data related to vehicle service requirements. When a service event occurs, such as vehicle sensor data indicating that fuel/charging, maintenance service, etc. is required, invoke rules, thresholds, sensor information aggregates, etc. that can be used to invoke vehicle service events. You can use smart contracts for this. Blockchain transaction data 280 is saved for each transaction, such as access events, subsequent updates to vehicle service status, event updates, and the like. Transactions may include parties, requirements (e.g., age 18, eligible for service, valid driver's license, etc.), coverage level, distance traveled during the event, access to the event, and vehicle service. Registered recipients allowed to host, rights/permissions, sensor data captured during vehicle event operations to record details of upcoming service events and to identify vehicle health status , and thresholds used to determine whether the service event has been completed and whether the vehicle's 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 a transport node 102 (see FIG. 1B). 3A may include additional acts, and some of the acts described herein may be removed and/or modified without departing from the scope of method 300. should be understood. The description of method 300 is also made with reference to 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 the processor 104 may receive a software update at the transportation device. At block 304, the processor 104 can activate the software update based on one or more of the period of time the software update has been used and the number of times the software update has been used by the subset of transportation devices. At block 306, the processor 104 can distribute the software update to a further subset of vehicles based on the activation. A further subset of transport devices may be larger than the subset of transport devices.

FIG. 3B illustrates a flow diagram 320 of an example method according to 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 all remaining sets of transport devices, where all remaining sets of transport devices are greater than the additional set of transport devices. Subsets of transport devices, further subsets of transport devices, and all remaining sets of transport devices are defined by existing software, existing hardware, geographic location, environmental temperature, transport make, Based on one or more of vehicle model, vehicle condition, road conditions, and vehicle destination.

At block 324, the processor 104 modifies one or more of the subset of transport devices, the further subset of transport devices, and all remaining sets of transport devices if a negative result is determined based on the validation. and reverting one or more of the subset of vehicles, further subsets of vehicles, and all remaining sets of vehicles to one or more of the initial versions of the software and prior software updates; can perform one or more of At block 326, the processor 104 may use the software update for a first amount of time by a subset of vehicles and a second amount of time by a further subset of vehicles that is less than the first amount of time. A subset of transport devices can belong to a blockchain network. At block 328, the processor 104 can execute a blockchain network smart contract to activate the software update and distribute the software update across multiple transportation devices.

FIG. 3C illustrates a flow diagram 330 according to an example embodiment. Referring to FIG. 3C, an example method may be performed by master transport node 102 (see FIG. 1C). 3C may include additional acts, and some of the acts described herein may be removed and/or modified without departing from the scope of 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 transport 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 transport devices of the first subset of transport devices. At block 335, the processor 104 may send the second portion of the software update to a further subset of the transportation devices. At block 337, the processor 104 instructs the first transport device of the subset of transport devices and the second transport device of the further subset of transport devices to perform the first portion of the software update when the first transport device and the second transport device of the further subset of transport devices are in proximity. is sent to the second transportation device, and the second transportation device can be caused to send the second portion of the software update to the first transportation device.

FIG. 3D illustrates 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, the processor 104 can determine the first and second portions of the software update prior to transmission to the subset of transport devices and the further subset of transport devices. At block 344, 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 and the first and second portions of the software update. When not running one or more of the two parts, the master transport can be routed to a geographic area.

At block 346, the processor 104 may route the first transportation device in proximity to the second transportation device when a period of time has elapsed since receiving the first portion of the software update, and the first portion of the software update. A second transport device may be routed to the vicinity of the first transport device when a period of time has elapsed since the portion was received. At block 348, the processor 104 can transmit the first portion and the second portion of the software update via a transceiver at the master vehicle, and the transceiver transmits the first portion of the software update at one or more of the first vehicle and the second vehicle. The first portion and the second portion can be received, a memory in one or more of the first transportation device and the second transportation device can store the first portion and the second portion of the software update; The first part and the second part can be combined on two transport devices.

Note that a master transport device, a subset of transport devices, and further subsets of transport devices can be connected on the blockchain network. At block 350, processor 104 may execute smart contracts 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, an example method may be performed by transport node 102 (see FIG. 1D). The method 360 shown in FIG. 3E may include additional acts, and some of the acts described herein may 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 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 the processor 104 may receive a software update at the transportation device. At block 364, processor 104 may perform a first validation of the software update in a first environment, where the first environment contains the least amount of potential interactions. At block 366, the processor 104 may perform further validation of the software update in additional environments if the first validation was successful. Further environments may contain a greater amount of potential interactions than the first environment.

FIG. 3F illustrates 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 and second validations fail. At block 384, the processor 104 may receive further activations 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 confirmation from the plurality of transportation devices of further activation of the software update. Confirmation can constitute a consensus on the blockchain that the transport device belongs to. At block 390, the processor 104 can execute a smart contract to record at least one data block reflecting the activated 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 particular transportation device/vehicle 425 engages in transactions such as asset transfer transactions (eg, access key exchange, vehicle services, dealer transactions, delivery/pickup, transportation services, etc.). Vehicles 425 can receive assets 410 and/or release/transfer assets 412 according to transactions defined by smart contracts. The 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 can be replicated to blockchain 430 and managed by remote servers and/or remote blockchain peers, in which vehicle 425 identifies 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 can be based on location and consensus as described herein.

FIG. 4B illustrates a blockchain between service nodes (e.g., gas stations, service centers, body shops, rental sensors, car dealers, local service shops, delivery/pickup centers, etc.) and vehicles, 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 particular location. The service node 442 may perform services (e.g., fill gas) or services such as oil change, battery charge or replacement, tire change or replacement, and any other transportation related services in a special procedure and at a specific time. Vehicle 425 can be registered for service calls in . Provided services 444 can be performed based on smart contracts, where smart contracts are downloaded from or accessed through blockchain 430 to perform such services at a particular exchange rate. identified for permission to do. The service can be recorded in the transaction log of the transaction module 420, the credit 412 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 service center servers. In one example, a vehicle event can call for refueling or other vehicle service, and the passenger can be held accountable for increased asset value for such service. can. Services can be provided via blockchain notifications and used to redistribute property value to passengers via their respective property values. Confidence in service center behavior can be based on asset transfers as described herein.

FIG. 4C illustrates an example blockchain vehicle configuration 450 for managing blockchain transactions conducted between different vehicles, according to an example embodiment. When the vehicle 425 is in a state where it needs to share assets with other vehicles, the vehicle 425 may contact other vehicles to perform various actions such as sharing access keys, transferring keys, getting service calls, etc. of vehicles 408 . For example, vehicle 408 may need a battery charge and/or have tire problems and may be in the process of picking up a package for delivery. A vehicle 408 can notify other vehicles 425 in the same network that operate on the same blockchain member service. Vehicle 425 can then receive information from vehicle 408 and/or from a server (not shown) via wireless communication requests to effectuate package pickup. Transactions are recorded in the transaction modules 452 and 420 of both vehicles. Assets are transferred from vehicle 408 to vehicle 425 and records of asset transfers are recorded on blockchain 430/454, assuming the blockchains are different from each other, or on the same blockchain used by all members. recorded in Trustworthiness for transferred assets can be based on asset value (eg, access keys) as described herein.

FIG. 5 illustrates a blockchain block 500 that can be added to a distributed ledger and the contents of block structures 502A-502n, according to an example embodiment. Referring to FIG. 5, clients (not shown) can submit entries to blockchain nodes to implement actions on the blockchain. By way of example, a client may be an application acting on behalf of a requestor, such as a device, person, or entity that proposes an entry into the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. There are different types of blockchains in the blockchain network, including endorsing peers that simulate and endorse entries proposed by clients, and commit peers that validate endorsements, validate entries, and inject entries into the distributed ledger. There can be nodes/peers. In this example, a blockchain node can perform the role of an endorser node, a committer node, or both.

An illustrative system includes a blockchain that stores an immutable, ordered record in blocks and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger can exist for one channel, and each peer maintains 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 blocks linked with hashes, each block containing a sequence of N entries. A block can include various components as shown in FIG. A link union of blocks can be generated by adding a 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 blockchain data unless the hash link is broken. Furthermore, due to the links, the latest block in the blockchain represents all the entries that came before it. Illustrative blockchains can be stored in peer file systems (local or attached storage) that support append-only blockchain workloads.

The current state of the blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest values for all keys that were ever contained in the blockchain's chain entry log. A smart contract executable code call executes an entry to 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 the state database. Since the state database can contain an indexed view into the blockchain's entry log, it can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated if necessary) when the peer starts up and before entries are accepted.

An endorsing node receives entries from clients and endorses the entries based on simulated results. An endorsing node holds a smart contract that simulates an entry proposal. When an endorsing node endorses an entry, it creates an entry endorsement, which is a signed response from the endorsing node to the client application indicating endorsement of the simulated entry. How an entry is 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 can 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 commit peers. For example, the ordering service may initialize a new block when a threshold of entries is reached, or when a timer times out, or other conditions are met. In this example, the blockchain node is the commit peer that received the data block 602A for storage on the blockchain. An ordering service can consist of a cluster of orderers. The ordering service does not process entries, smart contracts, nor maintain a distributed ledger. Instead, the ordering service can accept endorsed entries and specify in what order they will be injected into the distributed ledger. The architecture of the blockchain network can be designed so that specific implementations of "ordering" (eg 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 pushed into the network. Unlike in cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles and mining, in this example the participants in the distributed ledger are the most suitable for the network. You can choose which ordering mechanism to use.

Referring to FIG. 5, blocks 502A (also referred to as data blocks) stored on a blockchain and/or distributed ledger include block headers 504A-504n, transaction specific data 506A-506n, and block metadata 508A-508A-506N. 508n, etc.). 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. it 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 can include a hash of previous block headers. Block header 504A may also include a unique block number, a hash of block data 510A for current block 502A, and the like. Block numbers for block 502A can be unique and assigned in increasing/consecutive order starting at zero. The first block in the blockchain can also be referred to as the genesis block and contains information about the blockchain, its members, the data stored in it, and so on.

The block data 510A can store entry information of each entry recorded in the block. For example, entry data may include one or more types of entries, 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, input (smart contract executable code and functions), client (creator) 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 entries), Write Set (list of keys, values, etc.), Start Key, End Key, Key , a Merkle tree query summary, and the like. 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 to the hash of the block in the blockchain. Thus, data 506A can be stored in an immutable log of blocks on the 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 can include a signature for block creation, a reference to the latest configuration block, an entry filter that identifies valid and invalid entries in the block, the last-lived offset of the ordering service that ordered the block, and so on. Signatures, last building blocks, and orderer metadata can be added by the ordering service. On the other hand, block committers (such as blockchain nodes) can add valid/invalid information based on endorsement policy, read/write set validation, etc. The entry filter may include a byte array of 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 contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the previous block's header, or it may be the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, the hash value indicated by arrow 512 is established to establish an auditable and immutable chain-of-custody (also referred to as security). As noted, tracking back from the Nth block to the genesis block (and associated original file) can be performed on a block-by-block basis.

The above embodiments can be implemented in hardware, a computer program executed by a processor, firmware, or a combination of the above. A computer program can be included in a computer readable medium such as a storage medium. For example, a computer program may 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 (“EPROM”), ("EEPROM"), registers, hard disk, removable disk, compact disk read only memory ("CD-ROM"), or any other form of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium can be integral to 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 separate components. For example, FIG. 6 illustrates 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, the processing node 600 can be implemented and/or can perform any of the functions described above.

Within computing node 600 is computer system/server 602, which operates 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, 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, Mini Computer Systems, Mainframe Computer Systems , and distributed cloud computing environments containing any of the above systems or devices.

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 can include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system/server 602 may 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, computer system/server 602 in cloud computing node 600 is shown in the form of a general purpose computing unit. Components of computer system/server 602 include one or more processors or processing units 604 , system memory 606 , and a bus coupling various system components to processor 604 , including but not limited to system memory 606 . can contain.

A bus may 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 Industry Standard Architecture (ISA) buses, Macro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and peripheral A component interconnect (PCI) bus is included.

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, removable and non-removable media. In one embodiment, system memory 606 implements the flow diagrams of other figures. The system memory 606 can 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. For purposes of example only, memory 606 can be used to read from and write to non-removable, non-volatile magnetic media (not shown and typically referred to as a "hard drive"). can provide. Although not shown, a magnetic disk drive for reading from and writing to non-removable, non-volatile magnetic disks (e.g., "floppy disks"), CD-ROMs, or other optical media, etc. An optical disc drive can be provided for reading from or writing to removable, non-volatile optical discs, such as. In such an example, one or more data media interfaces may each connect to the bus. As further shown and described below, memory 606 has a set (eg, at least one set) of program modules configured to perform the functions of various embodiments of the present application. It can contain at least one program product.

A program/utility having a set (at least one set) of program modules may be, by way of example and without limitation, an operating system, one or more application programs, other program modules, and program data. 606. An operating system, one or more application programs, other program modules, and program data, or some combination thereof, each may comprise an implementation of a networking environment. The 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 can be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may refer to an overall hardware embodiment, an overall software embodiment (including firmware, resident software, microcode, etc.), or collectively as a "circuit" or "module" herein. , or may be referred to as a "system", which may take the form of an embodiment combining software and hardware aspects. Furthermore, 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 users to interact with computer system/server 602 via I/O adapters 612, such as keyboards, pointing devices, displays, etc.; /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 may be performed via the I/O interface of adapter 612 . Additionally, the computer system/server 602 may be connected to one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (eg, 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 may 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, and data archival storage systems.

While at least one example embodiment of a system, method, and non-transitory computer-readable medium has been illustrated in the accompanying drawings and described in the foregoing detailed description, the present application relates to the disclosed embodiments. It will be understood that various rearrangements, modifications and substitutions are possible as described and defined by the following claims, without limitation. For example, the functions of the systems in various figures can be performed by one or more of the modules or components described herein, or can be performed in a distributed architecture, with pairs of transmitters, receivers, or both. can include For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Further, the functions described herein may execute at various times and in connection with various events internal or external to the module or component. Additionally, information sent between the various modules may be routed between modules over at least one of data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and/or over multiple protocols. can be sent by Also, messages sent or received by any of the modules may 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" may be 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 recognize that it can be implemented. Representation of the above functions 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 implementations. ing. Indeed, the methods, systems, and apparatus disclosed herein can be implemented in localized or distributed forms consistent with computing technology.

It should be noted that some of the features of the systems described herein have been represented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising customized very large scale integrated (VLSI) circuits or gate arrays, resident conductors such as logic chips, transistors or other discrete components, or the like. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units or the like.

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

In fact, a module of executable code may be distributed in a single instruction, multiple instructions, and even on several different code segments, among different programs and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and 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, simply as electronic signals on a system or network.

It will be readily appreciated that the components herein, as generally described and illustrated in the figures, can be arranged and designed in a wide variety of different configurations. As such, 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.

Those of ordinary skill in the art will readily appreciate that the above can be practiced in a different order of steps and/or with hardware elements in different configurations than those disclosed. Will. Thus, although the present application has been described with reference to these preferred embodiments, certain modifications and variations, and alternative constructions will be apparent to those skilled in the art.

Although preferred embodiments of the present application have been described, the described embodiments are for illustrative purposes only and the scope of the present application covers equivalents and modifications thereto (e.g., protocols, hardware devices, software platform, etc.) is to be defined only by the appended claims.

Claims (10)

a system,
a transport device processor of a subset of transport devices;
a memory communicatively coupled to the processor, the processor comprising:
receiving a software update on the transport device;
the software update,
a period of time during which the software update was used; and
a number of uses of the software update by a subset of the transportation devices; and
enabled based on one or more of
distributing the software update based on the activation to a further subset of the transport devices that is larger than the subset of the transport devices;
system. 2. The system of claim 1, wherein the processor distributes the software update to all remaining sets of vehicles greater than the further subset of the vehicles. one or more of said subset of transport devices, said further subset of transport devices, and all remaining sets of transport devices,
existing software,
existing hardware,
geographical location,
environmental temperature,
transport equipment mold,
model of transport equipment,
the condition of the transport equipment,
3. The system of claim 1, based on one or more of: road conditions; and destination of the vehicle. The processor determines, based on the validation, one or more of the subset of transport devices, a further subset of the transport devices, and all remaining sets of transport devices if a negative result is determined. 3. The system of claim 1, wherein the system is modified. The processor determines, based on the validation, one or more of the subset of transport devices, a further subset of the transport devices, and all remaining sets of transport devices if a negative result is determined. , one or more of an initial version of software, and a previous software update. The processor updates the software by:
a first amount of time by a subset of said transport devices; and
for a second amount of time with a further subset of said transport devices;
the first amount of time is greater than the second amount of time;
The system of claim 1. 2. The system of claim 1, wherein said subset of transport devices belong to a blockchain network. 7. The system of claim 6, wherein the processor executes a smart contract of the blockchain network to validate the software update and distribute the software update across the plurality of transportation devices. The processor performs a first validation of the software update in a first environment containing the least amount of potential interactions, and further validates the software update if the first validation is successful. 2. The system of claim 1, wherein the transformation is performed in a further environment containing a greater amount of potential interactions than the first environment. 10. The system of claim 9, wherein the processor receives further activation of the software update from another transportation device.

Images