Recharging of transport vehicle batteries via virtual power plants

Abstract

Example operations include one or more of establishing a communication channel between a computing system associated with a plurality of available power sources and a vehicle including a rechargeable battery configured to power the vehicle, determining a charge power value for the rechargeable battery, generating a request identifying, in a first field, the charge power value and, in a second field, a power source of the plurality of available power sources to provide the charge power for the rechargeable battery, and transmitting the request from the vehicle to the computing system over the established communication channel.

Description

Background Technology

[0001] Vehicles or means of transport, such as cars, motorcycles, trucks, airplanes, trains, etc., typically provide transportation services for passengers and / or goods in various ways, and the functions related to the means of transport can be identified and utilized by various computing devices, such as smartphones or computers located on and / or outside the means of transport. Summary of the Invention

[0002] An example embodiment provides a transportation vehicle comprising one or more of the following: a rechargeable battery configured to power the transportation vehicle; a processor configured to determine a charging power value of the rechargeable battery and generate a request that identifies the charging power value in a first field and identifies, in a second field, a power source from a plurality of available power sources used to provide the charging power of the rechargeable battery; and an interface configured to send the request from the transportation vehicle to a computing system associated with the plurality of available power sources.

[0003] Another example embodiment provides a method comprising one or more of the following: establishing a communication channel between a computing system associated with a plurality of available power sources and a vehicle containing a rechargeable battery configured to power the vehicle; determining a charging power value for the rechargeable battery; generating a request that identifies the charging power value in a first field and identifies, in a second field, a power source among the plurality of available power sources used to provide the charging power for the rechargeable battery; and sending the request from the vehicle to the computing system via the established communication channel.

[0004] Another example embodiment provides a non-transitory computer-readable medium containing instructions that, when read by a processor, cause the processor to perform one or more of the following: establishing a communication channel between a computing system associated with a plurality of available power sources and a vehicle containing a rechargeable battery configured to power the vehicle; determining a charging power value for the rechargeable battery; generating a request that identifies the charging power value in a first field and identifies, in a second field, a power source among the plurality of available power sources used to provide the charging power for the rechargeable battery; and sending the request from the vehicle to the computing system via the established communication channel. Attached Figure Description

[0005] Figure 1A This is a network diagram illustrating a vehicle and other nodes that can request electricity via a virtual power station according to an example embodiment.

[0006] Figure 1BThis is a diagram illustrating the process by which a vehicle requests charging power from an identified power source according to an example embodiment.

[0007] Figure 1C and 1D This is a diagram illustrating a request message for requesting charging power according to an example embodiment.

[0008] Figure 1E This is a diagram illustrating a blockchain network for a virtual power plant according to an example embodiment.

[0009] Figure 1F The illustration shows that, according to an example embodiment, it may include... Figure 1E A diagram illustrating the architecture of blockchain peers in a blockchain network.

[0010] Figure 2A It is a diagram illustrating a transportation network according to an example embodiment.

[0011] Figure 2B This is a diagram illustrating another transportation network diagram according to an example embodiment.

[0012] Figure 2C This is a diagram illustrating yet another transportation network diagram according to an example embodiment.

[0013] Figure 2D This is a diagram illustrating another transportation network diagram according to an example embodiment.

[0014] Figure 2E This is a diagram illustrating yet another transportation network diagram according to an example embodiment.

[0015] Figure 2F It is a diagram depicting the charging of one or more elements according to an example embodiment.

[0016] Figure 2G It is a diagram depicting the interconnection between different elements in a transportation network according to an example embodiment.

[0017] Figure 2H This is another diagram depicting the interconnection between different elements in a transportation network according to an example embodiment.

[0018] Figure 2I This is yet another diagram depicting the interconnection between elements in a transportation network according to an example embodiment.

[0019] Figure 3 This is a diagram illustrating a method for a vehicle to request charging power according to an example embodiment.

[0020] Figure 4 This is a diagram illustrating an example of a machine learning-based transportation network according to an example embodiment.

[0021] Figure 5A This is a diagram illustrating an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

[0022] Figure 5B This is a diagram illustrating another example vehicle configuration for managing database transactions between various vehicles, according to an example embodiment.

[0023] Figure 6A This is a diagram illustrating a blockchain architecture configuration according to an example embodiment.

[0024] Figure 6B This is a diagram illustrating another blockchain configuration according to an example embodiment.

[0025] Figure 6C This is a diagram illustrating a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0026] Figure 6D This is a diagram illustrating an example data block according to an example embodiment.

[0027] Figure 7 This is a diagram illustrating an example system that supports one or more of the example embodiments.

[0028] Figure 8 This is an example diagram illustrating a system including a security processor according to an example embodiment. Detailed Implementation

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

[0030] Communication between one or more means of transport and certain entities, such as remote servers, other means of transport, and local computing devices (e.g., smartphones, personal computers, embedded computers in the means of transport, etc.) can be received and processed by one or more “components,” which can be hardware, firmware, software, or a combination thereof. These components can be any of these entities or computing devices or some other computing device. In one example, consensus decisions related to blockchain transactions can be performed by computing devices or components associated with one or more means of transport and one or more components located outside or at a remote location on the means of transport.

[0031] The functions, structures, or features described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, the use of phrases such as "example embodiment," "some embodiments," or other similar language throughout this specification refers to the fact that a particular function, structure, or feature described in connection with that embodiment may be included in at least one embodiment. Therefore, the appearance of phrases such as "example embodiment," "some embodiments," "in other embodiments," or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described functions, structures, or features can be combined in any suitable manner in one or more embodiments. In the various figures, even if the depicted connections are unidirectional or bidirectional arrows, any connection between elements may allow unidirectional and / or bidirectional communication. In the present solution, transportation vehicles may include one or more of automobiles, trucks, battery electric vehicles (BEVs) for pedestrian zones, e-Palettes, fuel cell buses, motorcycles, scooters, bicycles, boats, recreational vehicles, aircraft, and any object that can be used to transport people or goods from one location to another.

[0032] Furthermore, although the term "message" has been used in the description of the embodiments, other types of network data, such as packets, frames, datagrams, etc., may also be used. Additionally, while certain types of messages and signaling are depicted in the exemplary embodiments, they are not limited to any particular type of message and signaling.

[0033] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, vehicles, and / or networks for a vehicle configured to request charging power for a rechargeable battery from a specific power source among a plurality of available power sources.

[0034] Various embodiments may include at least one of the following: a means of transport (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authentication system, and a vehicle data distribution system. Vehicle status data may be received in the form of communication messages (such as wireless data network communications and / or wired communication messages), processed to identify the status of the vehicle / means of transport, and provide feedback on the status and / or changes of the means of transport. In one example, a user profile may be applied to a specific means of transport / vehicle to authorize current vehicle events, service stops at service stations to authorize subsequent vehicle rental services, and to enable vehicle-to-vehicle communication.

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

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

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

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

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

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

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

[0042] Vehicles may require service at certain intervals, and service requests may require authorization before service can be granted. Service centers can provide service to vehicles in the vicinity based on the vehicle's current route plan and relative service demand level (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand can be monitored via one or more vehicle and / or road sensors or cameras, which report the sensed data to a central controller computer device located in and / or remotely to the vehicle. This data is forwarded to a management server for review and action. Sensors can be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object remotely to the vehicle, and on another vehicle nearby. Sensors can also be associated with the vehicle's speed, braking, acceleration, fuel level, service demand, gear shifting, steering, etc. The sensors described herein can also be devices such as wireless devices located in and / or near the vehicle. Similarly, sensor information can be used to identify whether the vehicle is operating safely and whether occupants have been involved in any unexpected vehicle conditions, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger as determined by a licensing body, and thus in a “decentralized” manner, such as via a blockchain membership group.

[0043] Each stakeholder (e.g., owners, users, companies, agents, etc.) may want to restrict the disclosure of private information; therefore, blockchain and its immutability can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when services are needed, identify collisions and / or downgrade events, identify safety-related issues, identify parties involved in an event, and distribute the data to registered entities seeking access to such vehicle event data. Similarly, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on consensus methods associated with the blockchain. Such methods cannot be implemented on traditional centralized databases.

[0044] The various driving systems in this solution can utilize software, sensor arrays, machine learning capabilities, LiDAR projectors, radar, ultrasonic sensors, etc., to create terrain and road maps that the vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc., can also replace LiDAR for autonomous vehicles.

[0045] The shared and received data described in this article can be stored in a database that maintains the data in a single location (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database can typically be accessed from multiple different points. Centralized databases are easy to manage, maintain, and control, especially for security purposes, because they are located in a single location. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a given dataset has only one master record. Blockchain can be used to store data and transactions related to transportation vehicles.

[0046] Electric vehicles (also known as hybrid vehicles) have become increasingly popular in recent years. As more electric vehicles are on the road, their electricity consumption is also increasing. In larger areas such as cities and towns, this consumption can lead to power shortages or outages, causing additional problems such as increased electricity costs for everyone on the grid, not just the vehicles. When an operator of an electric vehicle needs to charge its rechargeable battery, they must find a charging station and "connect" to it to draw power from the battery. However, the operator has no input / control over where this power is drawn from.

[0047] According to various embodiments, a vehicle (or other agent) can request charging power from a specific source (or multiple specific sources). Therefore, the vehicle can specifically define what type of energy is consumed by it. For example, the vehicle can specify a particular source (e.g., a solar power plant, hydroelectric power plant, wind power plant, nuclear power plant, coal-fired power plant, etc.) to draw power. Here, the vehicle can communicate with available power sources via a node (also referred to herein as a virtual power plant (VPP)). In some embodiments, the node can be integrated into the vehicle's computer, enabling the vehicle to communicate directly with different available power sources. As another example, the node can be a separate central node acting as an intermediary between the vehicle and available power sources.

[0048] According to another aspect of the example embodiment, multiple power receivers (e.g., vehicles, homes, appliances, etc.) can form a blockchain network with available power sources. Here, each power receiver and each power source can be a separate blockchain node (or sub-node) within the blockchain network. Each node can store a copy of the blockchain ledger and one or more smart contracts that manage the energy payment process between the node / power receiver and the power source. According to another aspect of the example embodiment, the VPP node can include analytics software that enables the VPP node to identify future conditions on the power grid and take mitigation measures before they occur to reduce potential downtime or power reduction.

[0049] By enabling vehicles (and other nodes, such as homes, appliances, offices, etc.) to request electricity from specific sources, the pressure on the power grid (e.g., a conventional grid driven by coal power) will be amplified or otherwise supplemented by additional clean energy. Furthermore, the clean energy source can be selected by the vehicle (or its operator), allowing for dynamically customized power extraction. In some embodiments, a vehicle can request one or more specific power sources. As another example, a vehicle can request specific attributes associated with the electricity. For instance, a vehicle can request “cleanest” electricity from a virtual power plant, and the VPP node can determine which particular power plant is cleanest, for example, based on emissions testing.

[0050] Figure 1A The illustration depicts a network 100A of vehicles and other nodes that can request power via a virtual power station, according to an example embodiment. (Refer to...) Figure 1A Network 100A may include multiple nodes (e.g., a self-organizing network of vehicles, homes, offices, appliances, etc.) that rely on rechargeable batteries to operate or otherwise require charging of rechargeable batteries. Figure 1AThe example illustrates a home node 112, a transportation node 114, and another transportation node 116; however, it should be understood that many different nodes may be included in network 100A, including homes, office buildings, transportation vehicles (e.g., vehicles, RVs, trucks, boats, etc.), and appliances (e.g., refrigerators, televisions, washing machines, etc.). In some embodiments, a transportation node (e.g., transportation node 116) may be connected to another node (e.g., home node 112, etc.) and powered from a rechargeable battery on transportation node 116. According to various embodiments, a subset of nodes (e.g., transportation vehicles) may be dynamic / mobile nodes whose geographical location changes over time. As another example, a second subset of nodes may be static nodes (e.g., homes, appliances, charging stations, etc.).

[0051] Network 100A also includes multiple power sources, including but not limited to: a solar power plant 122, a coal-fired power plant 124, a nuclear power plant 126, and a wind power plant 128. Other examples of power sources may include, but are not limited to, hydroelectric power plants, turbines, etc. In some embodiments, multiple nodes (e.g., home node 112, transportation nodes 114 and 116, etc.) may communicate directly with multiple power sources 122, 124, 126, and 128. As another example, a central node 120 may be an intermediary system (e.g., a server, database, cloud platform, etc.) that receives requests from multiple nodes and instructs power sources 122, 124, 126, and / or 128 to generate and store electricity for subsequent use by specific nodes.

[0052] In this example, the central node 120 implements a virtual power station (VPP) capable of requesting power from any of power sources 122, 124, 126, and 128, and receiving charging requests from any of nodes 112, 114, and 116. For example, any of the multiple nodes 112, 114, and 116 can request power from any of the available power sources 122, 124, 126, and 128. As an example, a node can send a request to the central node 120 identifying the amount of electricity to be consumed by the node (e.g., charging power), the type of power source used to generate that power, the charging station where the node will store / receive its charging power, etc.

[0053] In some embodiments, each vehicle (or other node) can be a separate agent that makes decisions about its own power needs and requests power from available power sources. For example, a node can request power based on what the vehicle knows (e.g., departure time, amount of charging required, energy to be restored, etc.). In this example, the node can communicate with the power source via an intermediate node (central node 120). As another example, the node can communicate directly with available power sources and establish aggregated energy storage for the node somewhere on the grid. For example, a node may be traveling to a geographical destination tomorrow and may request energy storage at the destination location.

[0054] Central node 120 can receive power requests from a predetermined geographical area and many different vehicles and nodes in and around it. Here, central node 120 is able to view the different energy demands around the geographical area and determine when additional energy will be needed due to events that put pressure on the power grid (e.g., weather-related, increased traffic, etc.). Central node 120 may include an analyzer (such as an analyzer for...) Figure 1F (To be discussed further), the analyzer can predict how much power will be needed and can request that power from available power sources.

[0055] When the means of transportation is a vehicle, the vehicle may need to purchase energy for its own rechargeable battery and one or more auxiliary systems associated with the vehicle. For example, a vehicle may supply / supply power to homes, offices, restaurants, other vehicles, etc. Therefore, the means of transportation can request additional power for itself and one or more auxiliary systems. In this example, the means of transportation can communicate with auxiliary systems (e.g., buildings, appliances, etc.) using information transmission performed via the means of transportation's computer and wireless network interface. The central node 120 may be a common bus used by multiple nodes, means of transportation, etc., to communicate with available power sources.

[0056] Figure 1B The illustration depicts a process 100B in which a vehicle requests charging power from an identified power source according to an example embodiment. (Refer to...) Figure 1B The vehicle node 116 requests charging power from the central node 120. For example, the computer of the vehicle node 116 can send a request 140 to the central node 120 via a wired or wireless interface. This request indicates the type of power desired by the vehicle node 116, the power capacity (e.g., 40-110AH), the identifier of the charging station 130, etc. Here, the vehicle computer can instruct a network interface to send the request to the central node 120. As another example, the vehicle computer can send signals via Bluetooth, a wired network connection, etc.

[0057] In this example, the power type selected by vehicle node 116 is solar energy from solar power plant 122. That is, vehicle node 116 requests charging power from central node 120 generated by solar power plant 122, retained / held somewhere in the power grid, and consumed by vehicle node 116's rechargeable battery (not shown). It should also be understood that nodes can select a combination of power sources (e.g., 50% from the power grid 124, 50% from solar power plant 128, etc.).

[0058] In this example, the charging power requested by vehicle node 116 can be reserved by central node 120. For example, central node 120 can send commands, messages, etc., instructing solar power station 122 to generate sufficient power to meet the request from vehicle node 116. Furthermore, central node 120 can identify storage locations (e.g., storage facilities, etc.) for the reserved power so that it can be consumed at the time / location requested by the power-consuming node. For example, the power-consuming node might be traveling and could reserve power for a future location and a future point in time. As an example, central node 120 can request solar power station 122 to store the generated power in a local silo until vehicle node 116 is ready to charge its battery (e.g., connect). As another example, central node 120 can instruct solar power station 122 to deliver the generated power to charging station 130 identified by the request from vehicle node 116. Here, charging station 130 could be a home station, gas / electricity station, office, building, etc., where vehicle node 116 will be located.

[0059] It should also be understood that the VPP software can be installed and operated on the computer of transportation node 116. In this example, transportation node 116 can communicate directly with any available power source and request that power be reserved for charging the rechargeable battery. It should also be understood that transportation node 116 can communicate with other nodes on the network. For example, transportation node 116 can communicate with other vehicles, homes, appliances, etc., to exchange power information, comments, requests, etc. In this example, transportation node 116 communicates with home node 112. Here, transportation node 116 is the carrier / supplier of power to one or more devices, appliances, storage units, etc., at home node 112. In this case, transportation node 116 can request sufficient power from the central node to supply itself and some power to home node 112. Here, transportation node 116 can connect to the home node and transfer power from its rechargeable battery to home node 112's storage units, batteries, etc.

[0060] Figure 1C and 1DExamples of request messages 140a and 140b for requesting charging power according to an example embodiment are illustrated. (Refer to...) Figure 1C The vehicle node generates request 140a, which includes multiple fields and values ​​141a, 142a, 143a, and 144a stored in the fields. In this example, the first field corresponds to the vehicle identifier and has a vehicle identifier value 141a. The second field stores the charging station identifier value 142a. The third field stores the charging amount / value to be consumed by the vehicle node 143a, and the fourth field stores a power type value 144a specifying which source(s) should be used to generate the charging power to be consumed by the vehicle node. In some embodiments, request 140a may be generated by a command entered by a user via the user interface of a VPP application (e.g., within the vehicle, on a mobile device, etc.). As another example, request 140a may be automatically generated by the vehicle's computer in response to predetermined conditions such as a specific time point or detection that the charging power has fallen below a predetermined threshold.

[0061] Figure 1D This includes message 140b, which has values ​​equal to those of 141a, 142a, and 143a included in request 140a. However, in Figure 1D In the example, message 140b includes identifier 144b, which does not specify a particular power source type but rather identifies the "cleanest available energy source," leaving the selection of the actual power source to the central node 120. For example, the central node 120 can determine that a wind farm is the cleanest energy source based on emissions information, etc. Here, the central node 120 can automatically select a wind farm for the transportation node based on emissions. Other examples of identifier 144b could specify the cheapest available energy source (e.g., lowest cost, etc.). As another example, identifier 144b could specify the most abundant available energy source, etc.

[0062] Figure 1E The illustration shows a blockchain network 100E for a virtual power station according to an example embodiment, and... Figure 1F The illustration shows that, according to an example embodiment, it may include... Figure 1E The architecture of blockchain peers in a blockchain network, 100F. (Refer to...) Figure 1E Nodes that consume electricity (e.g., vehicles, appliances, homes, offices, etc.) can be peers on a blockchain network. Similarly, different available power sources can also be peers on a blockchain network. Here, peers can each share and manage the blockchain ledger. For example, some or all of the peers can participate in consensus before data is stored on the blockchain ledger. Figure 1EIn this example, nodes 152b, 152c, and 152d are power-consuming nodes, while nodes 152a, 152e, 152f, and 152g are power sources that can be used to supply power to the power-consuming nodes. Each node stores a copy of the blockchain ledger 150, which can be a permissioned (private) blockchain that requires permission to join. As another example, the blockchain ledger 150 can be a publicly available public blockchain.

[0063] When a power-consuming node requests power from a power-generating node, this request can be stored as a transaction in blockchain ledger 150, specifically in blockchain 154 (e.g., Figure 1F Furthermore, when electricity is delivered to a power-consuming node, delivery details, including the amount of electricity consumed, cost, time, and the identifier of the delivery source, can also be stored on blockchain 154. Blockchain 154 can store transaction logs of requested electricity and electricity consumed by the power-consuming node. Here, each transportation node can manage the blockchain ledger 150 via vehicle-to-vehicle (V2V) communication. Meanwhile, static nodes can communicate with transportation nodes and other static nodes using peer-to-peer (P2P) communication.

[0064] Figure 1E Each blockchain peer 152a-152g shown may include Figure 1F The architecture of blockchain peer 152 is shown below. In this example, blockchain peer 152 includes smart contract 162, analyzer 164, and storage device 166 (or memory). The storage device includes blockchain ledger 150, which includes blockchain 154, a transaction log in the form of a hashed chain, and state database 156, which stores only the most recent (and latest) values ​​of different items on the blockchain. In this case, state database 156 may store only the latest values ​​of different variables, while blockchain 154 keeps track of all changes that have occurred to the variables over time. The state database may be a key-value store, where each item is represented by a unique identifier (key), and this key is paired with the current value of such an item to create a key-value pair.

[0065] When blockchain peer 152 (e.g., any of nodes 152b, 152c, and 152d) requests electricity from one of the power nodes (e.g., any of nodes 152a, 152e, 152f, and 152g), the request can be stored on blockchain 154. Before such a request is accepted, most blockchain peers may need to endorse and agree to it. Here, peers can agree on price, quantity, source, etc. This prevents unnecessary or excessive consumption of a power source. Furthermore, additional transactions identifying the source of the electricity, the amount of electricity delivered, and the nature of the electricity can be stored on the blockchain when electricity is delivered to or otherwise reserved for a power-consuming node.

[0066] In this example, smart contract 162 can coordinate payments. Here, smart contract 162 can include pricing attributes for different energy sources providing different types of energy. Additionally, users can purchase electricity via grid usage credits (e.g., green energy credits). In some embodiments, the smart contract or the consuming node can send predictive notifications to negotiate better payment terms.

[0067] Analyzer 164 can be used to predict the energy demand of individual electricity consumers and the entire power grid within a specific geographic area. In this embodiment, some peers are mobile (cars, telephones, etc.), while others are stationary (homes, offices, appliances, televisions, etc.). This allows analyzer 164 to collect data from mobile peers (e.g., traffic), and analyzer 164 can detect what type of dynamics are occurring on the power grid. For example, analyzer 164 can identify one or more traffic jams in a specific area supplied by a local power company. Traffic jams require electric vehicles to consume more battery power. Here, blockchain peer 152 can take measures to prevent power grid overload. For example, blockchain peer 152 can request one or more available power sources to generate and retain additional energy.

[0068] As another example, analyzer 164 can connect to a weather data source such as a website and identify whether the temperature is very cold or very hot. Hot and cold temperatures cause rechargeable batteries to lose power more quickly. In this example, blockchain peer 152 can take mitigation measures to request power to be generated from available power sources, so that the pressure on the power grid is not too severe.

[0069] As another example, a vehicle can supply power to a house or office. In this case, the vehicle can be used to supplement the power supplied by the power company. Analyzer 164 can identify how much power a static node in a predetermined area will consume and use this information when requesting to generate additional power for a mobile node. All decisions made by analyzer 164 can be recorded on blockchain 154.

[0070] As another example, analyzer 164 can identify when a rechargeable battery needs to be replaced. Blockchain 154 can track the energy consumed by the battery, and analyzer 164 can use this information as input to determine the exact time to replace the battery. Blockchain peer 152 can request endorsement / consensus from other peers before a battery replacement request is sent to the vehicle node. Analyzer 164 can use cost analysis or other algorithms to determine when is the most efficient time to replace the battery. Each blockchain peer can be equipped with the same algorithm, enabling peers to verify / validate analyzer 164. Analyzer 164 can be used to identify when to replace the battery or when to continue charging it.

[0071] Figure 2A A transportation network diagram 200 according to an example embodiment is illustrated. The network includes transportation node 202 containing processor 204 and transportation node 202' containing processor 204'. Transportation nodes 202, 202' communicate with another node via processor 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and elements including one or more processors, memory, and software. Although depicted as a single transportation node and processor, multiple transportation nodes and processors may exist. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by these elements.

[0072] Figure 2BAnother transportation network diagram 210 according to an example embodiment is illustrated. The network includes elements of transportation node 202 containing processor 204 and transportation node 202' containing processor 204'. Transportation nodes 202, 202' communicate with another node via processor 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and elements including one or more processors, memories, and software. Processors 204, 204' can also communicate with one or more elements 230 including sensor 212, wired device 214, wireless device 216, database 218, mobile phone 220, transportation node 222, computer 224, I / O device 226, and voice application 228. Processors 204, 204' can also communicate with one or more of the following components: processor, memory, and software.

[0073] Although described as a single transport node, processor, and element, multiple transport nodes, processors, and elements may exist. Information or communication may occur and / or originate from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204, which may initiate transport node 202 to take action, and may also provide information or additional information to processor 204', which may initiate transport node 202' to take action, and may also provide information or additional information to mobile phone 220, transport node 222, and / or computer 224. One or more applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by these elements.

[0074] In some embodiments, such as Figure 8 As shown in the example system 800, Figure 2B The computer 224 shown may include a security processor 810. Specifically, the security processor 810 can perform authorization, authentication, cryptography (e.g., encryption) on data transmissions sent between the ECU and other devices on the vehicle's CAN bus, as well as on data messages transmitted between different vehicles.

[0075] exist Figure 8In the example, the security processor 810 may include an authorization module 812, an authentication module 814, and a cryptography module 816. The security processor 810 may be implemented within the computer of the transportation vehicle and may communicate with other components of the transportation vehicle, such as the ECU / CAN network 820, wired and wireless devices 830 such as wireless network interfaces, input ports, etc. The security processor 810 can ensure the reliability of data frames (e.g., CAN frames, etc.) transmitted within the transportation vehicle (e.g., via the ECU / CAN network 820). Similarly, the security processor 810 can ensure the reliability of information transmitted between different transportation vehicles and devices attached to or connected via wires to the computer of the transportation vehicle.

[0076] For example, the authorization module 812 can store passwords, usernames, PIN codes, biometric scans, etc., for different users of the transportation vehicle. The authorization module 812 can determine whether a user (or technician) is authorized to access certain settings, such as the transportation vehicle's computer. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user wishes to change or modify the technical details of the transportation vehicle's settings via a console or GUI within the transportation vehicle or via an attached / connected device, the authorization module 812 can require the user to authenticate themselves in some way before such settings are changed. For example, the authentication module 812 can request a username, password, PIN code, biometric scan, predetermined line drawing or gesture, etc. In response, the authorization module 812 can determine whether the user has the necessary permissions (access rights, etc.) being requested.

[0077] The authentication module 814 can be used to authenticate internal communication between ECUs on a vehicle's CAN network. As an example, the authentication module 814 can provide information for verifying communication between ECUs. For example, the authentication module 814 can send a bit signature algorithm to the ECUs on the CAN network. The ECUs can use this bit signature algorithm to insert authentication bits into the CAN field of a CAN frame. All ECUs on the CAN network typically receive each CAN frame. Each time a new CAN frame is generated by one of the ECUs, the bit signature algorithm can dynamically change the position, number, etc., of the authentication bits. The authentication module 814 can also provide exemptions (security lists) and lists of ECUs that do not require the use of authentication bits. The authentication module 814 can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

[0078] The encryption module 816 can store asymmetric key pairs for use by the transportation vehicle to communicate with other external user equipment and transportation vehicles. For example, the encryption module 816 can provide a private key that the transportation vehicle will use to encrypt / decrypt communications, while the corresponding public key can be provided to other user equipment and transportation vehicles to enable them to decrypt / encrypt communications. The encryption module 816 can communicate with a remote server to receive new keys, key updates, keys for new transportation vehicles, users, etc. The encryption module 816 can also send any updates to the local private / public key pair to the remote server.

[0079] Figure 2C The illustration shows another transportation network diagram 240 according to an example embodiment. The network includes elements including a transportation node 202, which includes a processor 204 and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and element 230 (in... Figure 2B (As depicted in the text).

[0080] Reference Figure 2C The processor 204 may perform one or more of the following: in 244C establishing a communication channel between a computing system associated with multiple available power sources and a vehicle including a rechargeable battery configured to power the vehicle; in 246C estimating a power value to be used to charge the rechargeable battery over a predetermined time period; in 248C generating a request that identifies the power value in a first field and the power source among the multiple available power sources used to provide the power in a second field; and in 250C sending the request from the vehicle to the computing system via the established communication channel.

[0081] Figure 2D Figure 250 illustrates another transportation network according to an example embodiment. This network includes elements comprising a transportation node 202, which includes a processor 204 and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and element 230 (which in... Figure 2B (Depicted in the middle).

[0082] exist Figure 2DIn this process, processor 204 may perform one or more of the following: in 244D, estimating the power value to be used to charge the auxiliary system associated with the vehicle, and combining the estimated power value to be used to charge the rechargeable battery and the estimated power value to be used to charge the auxiliary system in a first field before sending the request to the computing system; in 246D, generating a request in a second field to identify one or more of the cleanest energy source and the cheapest energy source; and handing over the request to the computing system to select an available power source; in 248D, before sending the request to the computing system, storing an identifier of a charging station at which the power value from the identified power source will be delivered; and in 250D, before sending the request to the computing system, adding the identifier of one of the rechargeable batteries to the third field of the request.

[0083] Figure 2E A further transmission network diagram 260 according to an example embodiment is illustrated. (Refer to...) Figure 2E Network diagram 260 includes a transportation node 202 connected to other transportation node 202' and update server node 203 via a blockchain network 206. Transportation nodes 202 and 202' can represent transportation vehicles. The blockchain network 206 can have a ledger 208 for storing software update verification data and a verification source 207 for future use (e.g., for auditing).

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

[0085] exist Figure 2E In this process, processor 204 performs one or more of the following: in 244E, storing on the blockchain of the blockchain network the power value consumed by the rechargeable battery, the identifier of the power source, and the identifier of the vehicle; and in 246E, electrically connecting the rechargeable battery to a charging station and receiving a charge value requested from the identified power source while electrically connecting to the charging station.

[0086] The processor and / or computer-readable medium may be located wholly or partially inside or outside the transport node. Steps or functions stored in the computer-readable medium may be executed, wholly or partially, by any processor and / or element in any order. Furthermore, one or more steps or features may be added, omitted, combined, executed at a later time, etc.

[0087] Figure 2F Figure 265 illustrates the charging of one or more components. In one embodiment, vehicle 266 can provide power stored in its battery to one or more components, including one or more other vehicles 268, one or more charging stations 270, and one or more power grids 272. One or more power grids 272 are coupled to one or more charging stations 270, which in turn can be coupled to one or more vehicles 268. This configuration allows for the distribution of electricity / power received from vehicle 266. Vehicle 266 can also interact with one or more other vehicles 268, such as via vehicle-to-vehicle (V2V) technology, through cellular networks, WiFi, etc. Vehicle 266 can also interact wirelessly and / or wiredly with other vehicles 268, one or more charging stations 270, and / or one or more power grids 272. In one embodiment, vehicle 266 is routed (or routes itself) to one or more power grids 272, one or more charging stations 270, or one or more other vehicles 268 in a safe and efficient manner. As described and / or depicted herein, using one or more embodiments of this solution, the transport vehicle 266 can supply energy to one or more of the elements depicted herein in a variety of advantageous ways. Furthermore, as described and / or depicted herein, the safety and efficiency of the transport vehicle can be improved and the environment can be positively impacted.

[0088] The term "energy" can be used to refer to any form of energy received, stored, used, shared, and / or lost by one or more vehicles. During charging / use operations, this energy may be referred to in conjunction with voltage and / or current sources supplied from the entity to one or more vehicles. Energy can also be in the form of fossil fuels (e.g., for hybrid vehicles) or via alternative power sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, nuclear fusion-based energy sources, and energy generated on-the-fly during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0089] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 such that vehicle 266 has sufficient remaining charge to reach its destination. In one embodiment, a wireless connection is used to wirelessly guide the transfer of energy between vehicles 268, where all vehicles may be in motion. In one embodiment, an idle vehicle, such as vehicle 266 (which may be autonomous), is intended to provide a quantity of energy to charging station 270 and return to its original location (e.g., its original location or a different destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect surplus energy from at least one other vehicle 268 and transfer the stored surplus energy at charging station 270. In one embodiment, various factors determine the amount of energy used to transfer to charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), occupant schedules (one or more) while the vehicle is in use, potential occupant schedules (one or more) waiting for the vehicle, etc. In one embodiment, one or more vehicles 268, one or more charging stations 270, and / or one or more power grids 272 may provide energy to vehicle 266.

[0090] In one embodiment, the solutions described and depicted herein can be used to determine the load effect on a vehicle and / or system, supply energy to the vehicle and / or system based on future demand and / or priorities, and provide intelligence between the device containing the module and the vehicle, allowing the processor of the device to wirelessly communicate with the vehicle regarding the amount of energy stored in the battery on the vehicle. In one embodiment, these solutions can also be used to supply charging from the vehicle to the location based on factors such as the temperature of the location, energy cost, and the power level of the location. In one embodiment, these solutions can also be used to manage the amount of energy remaining in the vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, these solutions can also be used to instruct the vehicle to supply a certain amount of energy from the battery on the vehicle, wherein the amount of energy to be transferred is based on the distance from the vehicle to the module for receiving the energy.

[0091] In one embodiment, these solutions can also be used to employ a mobile energy storage unit that travels along a defined path to a vehicle with excess energy and stores the energy into the power grid. In one embodiment, these solutions can also be used to determine a defined priority of the vehicle's need to supply energy to the power grid, and the priority of the vehicle's current needs, such as the priority of passengers, or incoming passengers, or current cargo, or incoming cargo. In one embodiment, these solutions can also be used to determine when a vehicle decides to move to a location to discharge excess energy into the power grid while it is idle, and then return to its previous location. In one embodiment, these solutions can also be used to determine the amount of energy required for a vehicle to supply the desired energy to another vehicle via vehicle-to-vehicle energy transfer, based on one or more conditions such as weather, traffic, road conditions, vehicle conditions, and occupants and / or cargo in another vehicle, and to instruct the vehicle to route to the other vehicle and provide energy. In one embodiment, these solutions can also be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, these solutions can also be used to allow a vehicle to acquire energy based on the energy it expends to reach a meeting point with another vehicle, to provide service, and an estimated energy expenditure to return to its original location. In one embodiment, these solutions can also be used to provide the remaining distance required to a charging station, where the charging station determines the amount of energy to be acquired from the vehicle, with the remaining capacity based on the remaining distance. In one embodiment, these solutions can also be used to manage vehicles being charged simultaneously by more than one point, such as a wired charging station and another vehicle wirelessly connected. In one embodiment, these solutions can also be used to prioritize energy allocation to vehicles, giving priority to vehicles that will provide a portion of their stored energy to another entity, such as a power grid, a residence, etc. Furthermore, regarding... Figure 2F The solution described and depicted here can be utilized in this and other networks and / or systems.

[0092] Figure 2GThis diagram illustrates the interconnections between the different components 275. This solution may be stored and / or executed, wholly or partially, in and / or by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277' associated with various entities, all communicatively coupled to and communicating with network 286. Database 287 is communicatively coupled to the network and allows for the storage and retrieval of data. In one embodiment, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residential buildings 283, a power grid / charging station 284, a microphone 285, and / or another vehicle 277. Other entities and / or devices, such as one or more private users using smartphones 278, laptops 280, and / or wearable devices, may also interact with this solution. Smartphones 278, laptops 280, microphones 285, and other devices can connect to one or more of the connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', and 277'. One or more public buildings 281 may include various agents. One or more public buildings 281 may utilize computing device 281'. One or more service providers 279 may include dealerships, towing services, collision centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computing devices can be directly and / or communicatively coupled to each other, such as via wired networks, wireless networks, blockchain networks, etc. In one embodiment, microphone 285 may be used as a virtual assistant. In one embodiment, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors, or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructures 282 may utilize computing device 282'.

[0093] In one embodiment, vehicle 277 / 276 is capable of transporting people, objects, permanently or temporarily fixed installations, etc. In one embodiment, vehicle 277 can communicate with vehicle 276 via V2V communication through a computer associated with each vehicle 276' and 277', and can be referred to as a vehicle, car, vehicle, automobile, etc. Vehicle 276 / 277 can be a self-propelled wheeled vehicle, such as a car, SUV, truck, bus, van, or other engine- or battery-powered or fuel cell-powered vehicle. For example, vehicle 276 / 277 can be an electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle with a fuel cell stack, engine, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or boats, and any other form of transportation capable of transporting people. Vehicle 276 / 277 can be semi-autonomous or autonomous. For example, vehicle 276 / 277 can be self-operated and navigate without human input. Autonomous vehicles can have and use one or more sensors and / or navigation units for autonomous driving.

[0094] In one embodiment, the solutions described and depicted herein can be used to determine access to a vehicle via blockchain consensus. In another embodiment, these solutions can be used to perform profile verification before allowing occupants to use the vehicle. In yet another embodiment, these solutions can be used to instruct (visually, but in another embodiment verbally, etc.) on or from the vehicle a user's required action (which may be pre-recorded) and verify that the action is correct. In one embodiment, these solutions can also be used to provide the vehicle with the ability to determine how to fork data based on the risk level associated with the data and driving environment, distributing a portion of the forked data to the occupants during a safe driving environment with a lower risk level, and subsequently distributing the remaining portion of the forked data to the occupants after they leave the vehicle with a higher risk level. In one embodiment, these solutions can also be used to handle vehicle transfers across borders (such as country / state / etc.) via the use of blockchain and / or smart contracts, and to apply the rules of the new area to the vehicle.

[0095] In one embodiment, these solutions can also be used to allow the vehicle to continue operating outside a boundary when a consensus is reached based on the vehicle's operation and the characteristics of its occupants. In one embodiment, these solutions can also be used to analyze the vehicle's available data upload / download speed, file size, and the vehicle's speed / direction to determine the distance required to complete the data upload / download and to allocate safe zone boundaries for the data upload / download to be performed. In one embodiment, these solutions can also be used to safely perform typically dangerous maneuvers, such as when the system determines an exit is imminent and the vehicle does not appear ready to exit (e.g., in the wrong lane or traveling at a speed unfavorable for an upcoming exit), and instruct the target vehicle and other nearby vehicles to allow the target vehicle to exit safely. In one embodiment, these solutions can also be used to verify the diagnostics of one or more vehicles while both one or more vehicles and another vehicle are in motion.

[0096] In one embodiment, these solutions can also be used to detect lane usage at a location and time of day, either to notify vehicle occupants or to instruct vehicles to recommend or discourage lane changes. In one embodiment, these solutions can also be used to eliminate the need for information sent via mail, and the need for drivers / occupants to respond via mail or in person. In one embodiment, these solutions can also be used to provide services to vehicle occupants, where the services are based on subscriptions, and licenses are obtained from other vehicles linked to the occupant's profile. In one embodiment, these solutions can also be used to record changes in the status of rented objects. In one embodiment, these solutions can also be used to seek blockchain consensus from other vehicles near the damaged vehicle. In one embodiment, these solutions can also be used to receive media potentially related to the accident from the vehicle's computer from a server, such as an insurance entity server. The server accesses one or more media files to obtain damage to the vehicle and stores the damage assessment on the blockchain. In one embodiment, these solutions can also be used to obtain consensus from multiple devices at different times prior to the event related to the vehicle for determining the severity of the event.

[0097] In one embodiment, these solutions can also be used to address the problem of a lack of video evidence related to accidents involving vehicles. The current solutions detail the process by which the vehicle involved in the accident queries accident-related media from other vehicles that may have been in close proximity to the accident. In one embodiment, these solutions can also be used to record specific parts of the damaged vehicle using vehicles and other devices (e.g., pedestrians' mobile phones, streetlight cameras, etc.).

[0098] In one embodiment, these solutions can also be used to warn occupants when the vehicle is navigating toward a hazardous area and / or event, allowing the vehicle to notify occupants or a central controller of potential hazardous areas on or near the current transport route. In one embodiment, these solutions can also be used to detect when the vehicle is traveling at a high speed, at least one other vehicle assisting the vehicle in slowing down in a manner with minimal traffic impact. In one embodiment, these solutions can also be used to identify dangerous driving situations where media is captured by the vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one embodiment, these solutions can also be used to notify one or more occupants of the vehicle that the vehicle is approaching a traffic control sign on the road, and subsequently, if the vehicle crosses the sign, receive adverse driving instructions from other nearby vehicles. In one embodiment, these solutions can also be used to partially disable the vehicle by (in some embodiments) limiting speed, restricting the ability to approach another vehicle, limiting speed to a maximum, and allowing only a given number of miles allowed in each time period.

[0099] In one embodiment, these solutions can also be used to overcome the need to rely on software updates to correct problems with a vehicle when it is not being operated correctly. By observing other vehicles on the route, the server receives data from multiple other vehicles that are potentially observing unsafe or incorrect operation of the vehicle. Through analysis, these observations lead to notifications to the vehicle when the data indicates unsafe or incorrect operation. In one embodiment, these solutions can also be used to provide notification between the vehicle and potential hazardous situations involving persons outside the vehicle. In one embodiment, these solutions can also be used to send data to the server from or near an accident involving the vehicle. Based on the severity of the accident or nearby accidents, the server notifies the sender of the data. In one embodiment, these solutions can also be used to provide recommendations on operating the vehicle to the vehicle's driver or passengers based on data analysis. In one embodiment, these solutions can also be used to establish geofencing associated with physical structures and determine payment liability for the vehicle. In one embodiment, these solutions can also be used to coordinate the ability to park a vehicle at a location using both the current state of the location and the proposed future state of navigation destinations for other vehicles. In one embodiment, these solutions can also be used to coordinate the ability to automatically schedule vehicle parking at a location such as a transportation vehicle rental entity.

[0100] In one embodiment, these solutions can also be used to move a vehicle to another location based on a user's events. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user at the end of the modified event or the original event. In one embodiment, these solutions can also be used to allow verification of available locations within an area using existing vehicles within that area. Based on the verification from existing vehicles, the approximate time when a location will become available can also be determined. In one embodiment, these solutions can also be used to move a vehicle to a nearby parking space when a parking space becomes available and less than the average time of the event has elapsed since the initial parking. Furthermore, the vehicle can be moved to the final parking space at the end of the event or based on the location of the device associated with at least one occupant of the vehicle. In one embodiment, these solutions can also be used to plan parking in advance of upcoming congestion. The system interacts with the vehicle to offer services at a price below full fare and / or guides the vehicle to alternative parking locations based on vehicle priority, adding optimization to the parking situation before arrival.

[0101] In one embodiment, these solutions can also be used to sell partial ownership of pricing and availability in transportation or ride-sharing applications. In one embodiment, these solutions can also be used to provide accurate and timely dealer sales activity reports, far exceeding currently available reports. In one embodiment, these solutions can also be used to allow dealers to request assets via blockchain. By using blockchain, consensus can be reached before any asset is moved. Furthermore, the process is automated, and payments can be initiated via blockchain. In one embodiment, these solutions can also be used to arrange agreements reached and actions performed (such as diagnostics) by multiple entities (such as service centers) where consensus has been reached. In one embodiment, these solutions can also be used to associate digital keys with multiple users. The first user can be the operator of the transportation vehicle, and the second user can be the responsible party for the transportation vehicle. These keys are authorized by a server, where proximity of the keys is verified based on the location of the service provider. In one embodiment, these solutions can also be used to determine the services required for the transportation vehicle's destination. One or more service locations capable of providing the required services can be found, both within the area of ​​the route to the destination and with the availability to perform the service. The transportation vehicle's navigation is updated based on the determined service locations. A smart contract containing the compensation value for the service is identified, and the blockchain transaction is stored in the distributed ledger of that transaction.

[0102] In one embodiment, these solutions can also be used to link a service provider's vehicles with the occupant profiles of the vehicles to identify services and goods that the occupants might be interested in. These services and goods are determined from the occupants' history and / or preferences. In another embodiment, the vehicle then receives a quote from the service provider for its vehicles, along with services / goods to satisfy the vehicle. In one embodiment, these solutions can also be used to detect vehicles within a range and send service quotes (such as repair quotes, product quotes, etc.) to those vehicles. An agreement is reached between the system and the vehicles, and the system selects a service provider to deliver the agreement. In one embodiment, these solutions can also be used to assign one or more vehicles as road managers, where the road managers assist in traffic control. The road managers can generate road indicators (such as lights, displays, sounds) to assist in traffic flow. In one embodiment, these solutions can also be used to alert drivers of vehicles via devices, where the device could be a traffic light or located near an intersection. The alert is sent when an event occurs, such as when a traffic light turns green and a vehicle ahead in the vehicle list has not moved.

[0103] Figure 2HThis is another block diagram illustrating the interconnection between different components in one example 290. A vehicle 276 is shown and includes ECUs 295, 296 and a head unit (also referred to as an infotainment system) 297. An electrical control unit (ECU) is an embedded system in an automated electronic device that controls one or more of the electrical systems or subsystems in the vehicle. An ECU may include, but is not limited to, the management of the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's Controller Area Network (CAN) bus 294. The ECU may also communicate with the vehicle's computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as the vehicle computer) 298 may communicate with external components such as a server 293 via a network 292 (such as the Internet). ECUs 295, 296, and head unit 297 may each contain their own security policies. The security policies define the permitted processes that can be executed in the appropriate context. In one embodiment, the security policy may be provided in part or in whole in the vehicle computer 298.

[0104] Each of ECUs 295, 296, and head unit 297 may include a custom safety function element 299 that defines authorized processes and the contexts that permit these processes to run. Determining valid context-based authorization, if a process can be executed, allows the ECU to maintain safe operation and prevent unauthorized access from components such as the vehicle's controller area network (CAN bus). When the ECU encounters an unauthorized process, it can block that process from operating. The automated ECU can use various contexts to determine whether a process is operating within its permitted scope, such as proximity contexts (e.g., nearby objects), distance to an approaching object, speed, and trajectory relative to other moving objects; operational contexts (e.g., indications of whether the vehicle is moving or stationary); the vehicle's current speed; transmission status; user-related contexts (e.g., devices connected to the vehicle via wireless protocols); use of the infotainment system; cruise control; parking assistance; driver assistance; location-based contexts; and / or other contexts.

[0105] In one embodiment, the solutions described and depicted herein can also be used to partially render a vehicle inoperable by (in some embodiments) limiting speed, restricting the ability to approach another vehicle, limiting speed to a maximum, and allowing only a given mileage per time period. In one embodiment, these solutions can also be used with blockchain to facilitate the exchange of vehicle ownership, where data is sent to a server from a device associated with or near an accident involving the vehicle. The server notifies the sender of the data based on the severity of the accident or nearby accidents. In one embodiment, these solutions can also be used to help vehicles avoid accidents, such as by querying a server of other vehicles near the accident when the vehicle is involved in one. The server seeks data from other vehicles, allowing the server to gain insight into the nature of the accident from multiple perspectives. In one embodiment, these solutions can also be used to determine if sounds emanating from the vehicle are abnormal and send data related to these sounds, along with possible source locations, to a server, where the server can determine possible causes and avoid potentially dangerous situations. In one embodiment, these solutions can also be used to establish location boundaries via the system when the vehicle is involved in an accident. This boundary is based on the decibel level associated with the accident. Multimedia content from devices within the boundary is obtained to assist in further understanding the accident scenario. In one embodiment, these solutions can also be used to link a vehicle to an accident, subsequently capturing media obtained by a device near the accident location. The captured media is saved as a media segment. This media segment is sent to another computing device to build an audio profile of the accident. This audio profile will help to understand more details surrounding the accident.

[0106] In one embodiment, these solutions can also be used to utilize sensors to record audio, video, motion, etc., to record areas where potential events have occurred, such as if a vehicle comes into contact with or may come into contact with another vehicle (while moving or parked). The system captures data from sensors that may be located on one or more vehicles and / or fixed or moving objects. In one embodiment, these solutions can also be used to identify new conditions of the vehicle by using sensor data during a transportation event and comparing that condition with a transportation condition profile, enabling the safe and reliable capture of critical data from vehicles about to be involved in a harmful incident to determine if the vehicle has been damaged.

[0107] In one embodiment, these solutions can also be used to warn occupants of a vehicle when one or more sensors have determined that the vehicle is approaching or traveling along a one-way street in the wrong way. The vehicle has sensors / cameras / maps that interact with the system of the current solution. The system knows the geographic location of the one-way street. For example, the system can audibly notify occupants, "Approaching a one-way street." In one embodiment, these solutions can also be used to allow vehicles to be compensated, allowing autonomous vehicle owners to monetize the data collected and stored by their vehicle's sensors, creating incentives for vehicle owners to share their data and providing entities with additional data to improve future vehicle performance, provide services to vehicle owners, etc.

[0108] In one embodiment, these solutions can also be used to add or remove vehicle characteristics based on the vehicle's actions over a period of time. In another embodiment, these solutions can also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicles is used to determine the condition of the vehicles. Partial ownership of the vehicles is determined based on the condition and provides new responsibilities for the vehicles. In one embodiment, these solutions can also be used to provide data to a replacement / modification component, wherein the data attempts to subvert the authorized functions of the replacement / modification component, and in response to the non-subversive nature of the authorized functions, the component authorizes the use of the authorized functions of the replacement / modification component.

[0109] In one embodiment, these solutions can also be used to provide individuals with the ability to ensure that a passenger is on the vehicle and that the passenger reaches a specific destination. Furthermore, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authorized to interact with the passenger. Additionally, boarding, alighting, and location are indicated. All of the above is stored immutably on a blockchain. In one embodiment, these solutions can also be used to determine driver characteristics through analysis of driving style and other elements to take action when the driver is not driving normally, such as the driver's previous driving habits under specific conditions, such as during the day, at night, in the rain, or in the snow. Furthermore, vehicle attributes are also taken into account. Attributes include weather, whether headlights are on, whether navigation is being used, whether a HUD is being used, the volume of media being played, etc. In one embodiment, these solutions can also be used to notify passengers on board the vehicle of dangerous situations when items within the vehicle indicate that passengers may not be aware of the danger.

[0110] In one embodiment, these solutions can also be used to mount calibration equipment on a vehicle-mounted vehicle, where various sensors on the vehicle can automatically self-adjust based on a comparison of what the calibration device should detect with what it actually detects. In one embodiment, these solutions can also be used to request consensus from multiple service centers using blockchain when a vehicle requiring service sends fault information that allows for remote diagnostics, where consensus is requested from other service centers regarding the severity threshold of the data. Once consensus is received, the service centers can send the fault-safe level to the blockchain for storage. In one embodiment, these solutions can also be used to determine discrepancies between sensor data from outside the vehicle and sensor data from within the vehicle itself. The vehicle requests software from a server to correct the problem. In one embodiment, these solutions can also be used to allow message transmission from vehicles in or near the vehicle or in the area when an event occurs (e.g., a collision).

[0111] Reference Figure 2I The diagram illustrates an operating environment 290A for a connected vehicle according to some embodiments. As depicted, the vehicle 276 includes a Controller Area Network (CAN) bus 291A connecting components 292A-299A of the vehicle. Other components may be connected to the CAN bus and are not depicted here. The components connected to the CAN bus depicted include a sensor set 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0112] Processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar array of processors that performs calculations and provides electronic display signals to display unit 299A. Processor 296A processes data signals and may include various computing architectures, including Complex Instruction Set Computer (CISC) architecture, Reduced Instruction Set Computer (RISC) architecture, or architectures that implement instruction set combinations. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not depicted) communicatively coupled to each other may be used with this solution.

[0113] Memory 297A is a non-transitory memory storing instructions or data that can be accessed and executed by processor 296A. These instructions and / or data may include code for performing the techniques described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory device. In some embodiments, memory 297A may also include non-volatile memory or similar permanent storage devices and media, which may include hard disk drives, floppy disk drives, CD-ROM devices, DVD-ROM devices, DVD-RAM devices, DVD-RW devices, flash memory devices, or some other high-capacity storage devices for permanently storing information. A portion of memory 297A may be reserved for use as a buffer or virtual random access device (virtual RAM). Without departing from the current solution, vehicle 276 may include one or more memories 297A.

[0114] The memory 297A of the vehicle 276 may store one or more of the following data types: navigation route data 295A and autonomous characteristic data 294A. In some embodiments, the memory 297A stores data necessary for providing functionality to the navigation application 295A.

[0115] Navigation system 295A can describe at least one navigation route including a start point and an end point. In some embodiments, navigation system 295A of vehicle 276 receives a request from a user for a navigation route, wherein the request includes a start point and an end point. Navigation system 295A can query real-time data server 293 (via network 292), such as a server providing driving directions, to obtain navigation route data corresponding to the navigation route including the start point and end point. Real-time data server 293 transmits the navigation route data to vehicle 276 via wireless network 292, and communication system 298A stores the navigation data 295A in memory 297A of vehicle 276.

[0116] ECU 293A controls the operation of various systems in vehicle 276, including ADAS system 294A. In response to instructions received from navigation system 295A, ECU 293A can deactivate any unsafe and / or unselected autonomous functions during a journey controlled by ADAS system 294A. In this way, navigation system 295A can control whether ADAS system 294A is activated or enabled so that it can be activated for a given navigation route.

[0117] Sensor set 292A may include any sensor that generates sensor data in vehicle 276. For example, sensor set 292A may include short-range and long-range sensors. In some embodiments, sensor set 292A of vehicle 276 may include one or more of the following vehicle sensors: camera, lidar sensor, ultrasonic sensor, automotive engine sensor, radar sensor, laser altimeter, manifold absolute pressure sensor, infrared detector, motion detector, thermostat, sound detector, carbon monoxide sensor, carbon dioxide sensor, oxygen sensor, mass airflow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air-fuel ratio meter, blind spot meter, roadside sensor, defect detector, Hall effect sensor, parking sensor, radar gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission fluid temperature sensor, turbine speed sensor (TSS), variable reluctance sensor, vehicle speed sensor (VSS), water sensor, wheel speed sensor, GPS sensor, mapping function, and any other type of automotive sensor. Navigation system 295A may store sensor data in memory 297A.

[0118] Communication unit 298A sends data to and receives data from network 292 or sends and receives data to and from another communication channel. In some embodiments, communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make the vehicle 276 a DSRC-equipped device.

[0119] The vehicle 276 can interact with other vehicles 277 via V2V technology. In one embodiment, V2V communication includes sensing radar information corresponding to the relative distance to external objects, receiving GPS information of the vehicle, setting an area based on the sensed radar information as the area where other vehicles 277 are located, calculating the probability that the GPS information of the target vehicle will be located in the set area, and identifying the vehicle and / or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

[0120] In one embodiment, the solutions described and depicted herein can also be used to manage emergency scenarios and vehicle characteristics when a vehicle is determined to be entering an area without network access. In one embodiment, these solutions can also be used to manage and provide characteristics (such as audio, video, navigation, etc.) within a vehicle without network connectivity. In one embodiment, these solutions can also be used to determine when the profile of a person approaching the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0121] In one embodiment, these solutions can also be used to analyze the availability of occupants in various vehicles available for voice communication, based on the remaining time in the vehicle and the context of the communication to be performed. In one embodiment, these solutions can also be used to determine two levels of road obstacle threat and receive gestures that indicate the obstacle has not escalated above a threshold, allowing the vehicle to proceed along the road. In one embodiment, these solutions can also be used to remove sensitive data from the vehicle if it is damaged to the point that it is unusable.

[0122] In one embodiment, these solutions can also be used to verify that customer data to be removed has indeed been deleted from all required locations within an enterprise demonstrating GDPR compliance. In one embodiment, these solutions can also be used to provide consideration from one vehicle to another in exchange for data related to safety, important notifications, etc., to enhance the autonomy of low-level autonomous vehicles. In one embodiment, these solutions can also be used to provide a vehicle with the ability to receive data based on a first biometric associated with an occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuation of the first biometric. The vehicle provides the decrypted data to the occupant when only the occupant can receive it, and removes sensitive portions of the decrypted data when providing sensitive portions, and removes non-sensitive portions after a period associated with the biometric. In one embodiment, these solutions can also be used to provide a vehicle with the ability to verify an individual based on the weight and grip force applied to the vehicle's steering wheel. In one embodiment, these solutions can also be used to provide features for existing but not currently activated vehicles that present occupant characteristics to autonomous vehicles reflecting occupant characteristics.

[0123] In one embodiment, these solutions can also be used to allow modifications to the vehicle, specifically the interior and exterior of the vehicle in one embodiment, to reflect and assist at least one occupant. In another embodiment, the re-creation of an occupant's work and / or home environment is disclosed. If the system determines that a user is in "work mode" or "home mode," then while the user is in the vehicle, the system can attempt to "recreate" the user's work / home environment. All data related to the interior and exterior of the vehicle and the various occupants utilizing the vehicle is stored on a blockchain and executed via smart contracts. In one embodiment, these solutions can also be used to detect occupant gestures to assist communication with nearby vehicles, which can then be manipulated accordingly. In one embodiment, these solutions can also be used to provide the vehicle with the ability to detect anticipated gestures using a gesture definition database. In one embodiment, these solutions can also be used to provide the vehicle with the ability to take various actions based on the user's gait and gestures. In one embodiment, these solutions can also be used to ensure that the driver of the vehicle currently engaged in various operations (e.g., driving while talking and using navigation) has not exceeded an unsafe number of operations before being permitted to make gestures.

[0124] In one embodiment, these solutions can also be used to assign a state to each occupant in the vehicle and verify occupant gestures based on the occupant's state. In one embodiment, these solutions can also be used to collect details of collision-related sounds (location, direction, ascent or descent, origin of the device, device-related data such as type, manufacturer, owner, number of simultaneous sounds, and time of sound emission, etc.) and provide them to the system, where analysis of the data assists in determining details of the collision. In one embodiment, these solutions can also be used to provide a determination of unsafe operation of the vehicle. The vehicle includes multiple components that interoperate to control the vehicle, and each component is associated with a separate component key. An encryption key is sent to the vehicle to reduce vehicle functionality. In response to receiving the encryption key, the vehicle disables one or more of the component keys. Disabling one or more component keys results in one or more of the following: limiting the vehicle's movement to a given speed, limiting the vehicle's proximity to another vehicle to a certain distance, and limiting the vehicle's travel to a threshold distance.

[0125] In one embodiment, these solutions can also be used to facilitate the transfer of a seat from one particular vehicle (which is about to become available) to another particular vehicle (which is seeking to occupy a seat), with the blockchain used for authentication and coordination. In another embodiment, these solutions can also be used to determine partial ownership of a vehicle. In cases such as multiple owners of a single vehicle, the use of the vehicle (which may change over time) is used by the system to update partial ownership. This application will include other embodiments, including minimum ownership of a vehicle, where minimum ownership is not based on the use of the vehicle, but rather on its availability, the identification of the vehicle's driver, and other factors.

[0126] In one embodiment, these solutions can also be used to authorize a user within a vehicle to share his / her subscription with a closed group of people, such as family members or friends. For example, a user might want to share a membership, and if so, the associated transaction is stored on a blockchain or a traditional database. When subscription materials are requested by a user who is not the primary subscriber, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has already shared a profile. In one embodiment, these solutions can also be used to allow persons to use one or more supplemental vehicles to reach their intended destination. Functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining which type of alternative vehicle to use) are used to determine the supplemental vehicle. In one embodiment, these solutions can also be used to allow occupants in an accident to use alternative vehicles to continue to their initial destination.

[0127] In one embodiment, the solution can also be used to propagate software / firmware uploads to a first subset of the vehicles. This first subset of vehicles tests the update, and upon successful testing, propagates the update to another set of vehicles. In one embodiment, the solution can also be used to propagate software / firmware updates from a master vehicle to the vehicles, where the update propagates from a first subset via the vehicle network, followed by larger subsets, etc. A portion of the update may be sent first, followed by the remainder from the same or another vehicle. In one embodiment, these solutions can also be used to provide updates to the vehicle's computer to the vehicles and the devices of the vehicle's operators / occupants. The update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicle and(one or more) devices. Users do not need to do anything; they simply approach the vehicle, and the functionality occurs automatically. A notification indicating the completion of the software update is sent to(one or more) devices. In one embodiment, these solutions can also be used to verify that an OTA software update is performed by a qualified technician and by one or more vehicle components regarding the generation of a state relating to: the initiator of the verification code, the program used to wirelessly receive the software update, the information contained in the software update, and the verification result.

[0128] In one embodiment, these solutions can also be used to provide the ability for a second component to parse software updates located in a first component. Subsequently, a first portion of critical updates and a second portion of non-critical updates are verified. The verified first portion is assigned to a process within the transportation vehicle, which runs the verified first portion for a period of time. In response to positive results based on that period, other processes run the verified first portion after that period. In one embodiment, these solutions can also be used to provide passengers with a choice of services based on passenger profiles and shared profiles shared with those passenger profiles. In one embodiment, these solutions can also be used to store user profile data in a blockchain and intelligently present offers and recommendations to users based on automatically collected purchase history and preferences derived from user profiles on the blockchain.

[0129] Figure 3 The illustration depicts a method for a vehicle to request charging according to an example embodiment. (Refer to...) Figure 3 In step 302, the method may include establishing a communication channel between a computing system associated with multiple available power sources and a vehicle including a rechargeable battery configured to power the vehicle. For example, the communication channel may be established via an interface of the vehicle, such as a wireless interface or a port (e.g., via a cable plugged into a network). Here, the computing system may be a remote server or the like capable of connecting to the vehicle via the Internet.

[0130] In 304, the method may include estimating the power value that will be used to charge the rechargeable battery over a predetermined period of time. For example, a vehicle may estimate its power requirements over a future period (e.g., next week) based on its historical usage patterns, user input, etc. The power may also be referred to as the amount of charge provided from a power source to the vehicle's rechargeable battery.

[0131] In step 306, the method may include generating a request that identifies a power value in a first field and a power source among a plurality of available power sources for providing the charging amount in a second field. In step 308, the method may include sending the request from the vehicle to a computing system via an established communication channel. The request may be generated by the vehicle and may identify the type of electricity to be supplied / delivered to a charging station associated with the vehicle. For example, the request may specify one or more power sources from a wind power plant, a solar power plant, a coal power plant, a hydropower plant, a nuclear power plant, etc. In some embodiments, the request may identify multiple power sources to be extracted (e.g., 50% solar and 50% from the power grid, etc.).

[0132] In some embodiments, the method further includes estimating a power value to be used to charge an auxiliary system associated with the vehicle, and combining the estimated power value to be used to charge a rechargeable battery and the estimated power value to be used to charge the auxiliary system in a first field before sending a request to a computing system. In some embodiments, the computing system may be a central node connected to multiple available power sources, and the generation may include generating a request that identifies one or more of the cleanest and cheapest energy sources in a second field, and submitting it to the central node for selection of available power sources.

[0133] In some embodiments, the method further includes storing an identifier of a charging station in a third field of the request, at which the power value is delivered from an identified power source, before sending the request to the computing system. In some embodiments, the vehicle may include a plurality of rechargeable batteries. In this example, the method may also include adding an identifier of a rechargeable battery among the plurality of rechargeable batteries to the third field of the request before sending the request to the computing system.

[0134] In some embodiments, the vehicle may include a mobile (dynamic) blockchain node within a blockchain network, which includes multiple mobile blockchain nodes and multiple static blockchain nodes. In this example, the method may also include storing on the blockchain of the blockchain network the power consumed by the rechargeable battery, an identifier of the power source, and an identifier of the vehicle. In some embodiments, the method may further include electrically connecting the rechargeable battery to a charging station and receiving a requested charge value from the identified power source upon electrical connection to the charging station.

[0135] Figure 4 A machine learning transportation network diagram 400 is illustrated according to an example embodiment. Network diagram 400 includes transportation nodes 402 that interface with a machine learning subsystem 406. Each transportation node includes one or more sensors 404.

[0136] Machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by machine learning training system 410 that generates predictions by finding patterns in one or more training datasets. In some embodiments, machine learning subsystem 406 is located within transportation node 402. In other embodiments, machine learning subsystem 406 is located outside transportation node 402.

[0137] Transportation node 402 sends data from one or more sensors 404 to machine learning subsystem 406. Machine learning subsystem 406 provides the data from one or more sensors 404 to learning model 408, which returns one or more predictions. Based on the predictions from learning model 408, machine learning subsystem 406 sends one or more instructions to transportation node 402.

[0138] In another embodiment, the transportation node 402 may send data from one or more sensors 404 to the machine learning training system 410. In yet another embodiment, the machine learning subsystem 406 may send the sensor data 404 to the machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may utilize the machine learning network 400 as described herein.

[0139] Figure 5AThe illustration depicts an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Referring to 5A, when a particular vehicle / transporter 525 participates in a transaction (e.g., vehicle service, dealership transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or release / transfer assets 512 according to one or more transactions. A vehicle processor 526 is located within the vehicle 525, and communication exists between the vehicle processor 526, the database 530, and the transaction module 520. The transaction module 520 can record information such as assets, parties, points, service descriptions, dates, times, locations, results, notifications, incidents, etc. These transactions in the transaction module 520 can be copied to the database 530. The database 530 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and can be on the vehicle, outside the vehicle, directly and / or via a network, or accessible by the vehicle.

[0140] Figure 5B The illustration depicts an example vehicle configuration 550 for managing database transactions between vehicles according to an example embodiment. When vehicle 525 reaches a state requiring service sharing with another vehicle 508, the vehicle can combine with the other vehicle to perform various actions such as sharing, transferring, obtaining service calls, etc. For example, vehicle 508 may have a battery charging failure and / or a tire problem, and may be en route to pick up a package for delivery. A transport processor 528 is located in vehicle 508, and communication exists between transport processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle operating in its network and its blockchain membership service. A transport processor 526 is located in vehicle 525, and communication exists between transport processor 526, database 530, transport processor 526, and transaction module 520. Vehicle 525 can subsequently request information from vehicle 508 and / or from a server (not shown) via wireless communication to perform package pickup. Transactions are registered in transaction modules 552 and 520 of both vehicles. Assuming the blockchains are distinct from each other, or registered to the same blockchain used by all members, points are transferred from vehicle 508 to vehicle 525, and the record of the transferred service is registered in databases 530 / 554. Database 554 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be on the vehicle, off the vehicle, or directly and / or via a network.

[0141] Figure 6AThe illustration shows a blockchain architecture configuration 600 according to an example embodiment. (Refer to...) Figure 6A The blockchain architecture 600 may include certain blockchain elements, such as a group of blockchain member nodes 602-606 as part of blockchain group 610. In one example embodiment, the permissioned blockchain is not accessible to all parties; only those members authorized to access the blockchain data can access it. Blockchain nodes participate in many activities, such as the blockchain entry addition and verification process (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide subscription services to all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and seek to write to the blockchain's immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0142] When blockchain transaction 620 is received and approved by the consensus model instructed by member nodes, the transaction is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and submitted to the blockchain via a submission procedure, including a hash of the data content of the transaction executed in the current block and referencing a previous hash from a previous block. Within the blockchain, one or more smart contracts 630 may exist, whose definitions include items of transaction protocols and actions in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity has registered to receive vehicle services, what service characteristics they are entitled to / need to receive based on their profile status, and whether their actions should be monitored in subsequent events. For example, when a service event occurs and a user is riding in the vehicle, sensor data monitoring can be triggered. Within a specific time period, a parameter such as the vehicle's charging level can be identified as being above / below a specific threshold. This result can then be a change in the current state, requiring an alert to be sent to management (i.e., the vehicle owner, vehicle operator, server, etc.) so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the sensor data type used to collect information about the vehicle's state. Sensor data can also form the basis of vehicle event data 634, such as (one or more) the location to be traveled, average speed, maximum speed, acceleration, whether there has been any collision, whether the expected route has been followed, what the next destination is, whether safety measures are appropriate, whether the vehicle has sufficient battery / fuel, etc. All such information can form the basis of smart contract item 630, which is then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether the detected service is necessary and when and where the service should be performed.

[0143] Figure 6B The illustration depicts a shared ledger configuration according to an example embodiment. Referring to 6B, blockchain logic example 640 includes a blockchain application programming interface 642 as an API or plug-in application linked to a computing device and execution platform for a specific transaction. Blockchain configuration 640 may include one or more applications linked to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which can be created according to custom configurations sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as entries and installed on all blockchain nodes via attachment to the distributed ledger.

[0144] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, upon execution, activates transaction items and states. Smart contract 630, upon execution, causes certain approved transactions 626 to be generated, which are then forwarded to the blockchain platform 652. This platform includes security / authentication 658, computing devices for executing transaction management 656, and a storage component 654 that serves as a repository for storing transactions and smart contracts on the blockchain.

[0145] A blockchain platform can include various layers of blockchain data, services (such as cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain can expose interfaces to provide access to the processing code and the virtual execution environment necessary for participation in the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and maintain the privacy of information.

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

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

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

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

[0150] Figure 6C The illustration shows a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Refer to...) Figure 6CExample configuration 660 specifies that vehicle 662, user equipment 664, and server 666 share information with a distributed ledger (i.e., blockchain) 668. The server can represent a service provider entity that, in the event that a known and established user profile is attempting to rent a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 666 can be receiving and processing data related to vehicle service requests. As service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., that can be used to invoke vehicle service events. Blockchain transaction data 670 is saved for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. The transaction may include the parties involved, requirements (e.g., 18 years of age, qualified candidates, valid driver's license, etc.), salary level, distance traveled during the activity, authorized access events and registered recipients of the managed vehicle service, rights / licenses, sensor data retrieved during vehicle event operations to register the next service event and identify the vehicle's condition status, and thresholds used to determine whether the service event has been completed and whether the vehicle's condition has changed.

[0151] Figure 6D The illustration shows a blockchain block 680 that can be added to a distributed ledger according to an example embodiment, and the contents of the block structure 682a to 682n. (Refer to...) Figure 6D A client (not shown) can submit entries to a blockchain node to initiate an activity on the blockchain. As an example, the client could be an application acting on behalf of a requester, such as a device, person, or entity that proposes an entry to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers can exist in a blockchain network, including endorsement peers that mimic and endorse entries proposed by clients, and submission peers that verify endorsements, validate entries, and submit entries to the distributed ledger. In this example, a blockchain node can act as an endorsement node, a delegator node, or both.

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

[0153] The current state of the blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest value of all keys included in the blockchain's chain entry log. Smart contract executable code calls execute entries based on the current state in the state database. To make these smart contract executable code interactions highly efficient, the latest value of all keys is stored in the state database. The state database can contain an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) before an entry is accepted, upon peer startup.

[0154] An endorsing node receives an entry from a client and endorses it based on the simulation results. The endorsing node holds the smart contract that simulated the 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 instructing the client application to endorse the simulated entry. The method of endorsing an entry depends on the endorsement policy, which can be specified within the smart contract's executable code. An example of an endorsement policy is "a majority of peers making endorsements must endorse the entry." Different channels can have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0155] The ordering service accepts endorsed entries, arranges them into a block, and delivers the block to the committing peers. For example, the ordering service can initiate a new block when a threshold for entries is reached, a timer expires, or other conditions occur. In this example, the blockchain node is the committing peer that has received data block 682A for storage on the blockchain. The ordering service can consist of groups of orders. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, the ordering service can accept endorsed entries and specify the order in which these entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that concrete implementations of "ordering" (such as Solo, Kafka, BFT, etc.) are pluggable components.

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

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

[0158] Block data 690A can store entry information for each entry recorded within a block. For example, entry data may include one or more of the following: entry type, version, timestamp, channel ID of the distributed ledger, entry ID, epoch, load visibility, smart contract executable code path (deployment TX), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code events, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkle tree query digest, etc. Entry data can be stored for each of N entries.

[0159] In some embodiments, block data 690A may also store transaction-specific data 686A, which adds additional information to the hashed chain of blocks in the blockchain. Therefore, data 686A can be stored in an immutable block log on a distributed ledger. Some advantages of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. Block metadata 688A may store multiple fields of metadata (e.g., as byte arrays, etc.). Metadata fields may include a signature on block creation, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, the last offset of the ordering service for the block, etc. The signature, the last configured block, and the orderer metadata can be added via the ordering service. Simultaneously, the block submitter (such as a blockchain node) can add validity / invalidity information, such as verification of read / write sets, based on an endorsement policy. Entry filters may include byte arrays of size equal to the number of entries in block data 610A and verification codes identifying whether an entry is valid / invalid.

[0160] The other blocks 682B through 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each header 684a through 684n in the other blocks includes the hash value immediately preceding the previous block. The hash value immediately preceding the previous block can be simply the hash of the header of the previous block, or it can be the hash value of the entire previous block. As indicated by arrow 692, by including the hash value of the previous block in each of the remaining blocks, a traceback from the Nth block back to the Genesis block (and the associated original file) can be performed on a block-to-block basis to establish an auditable and immutable chain of custody.

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

[0162] An exemplary storage medium can be coupled to a processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can exist as discrete components. For example, Figure 7An example computer system architecture 700 is illustrated, which may represent or be integrated into any of the above components.

[0163] Figure 7 This is not intended to suggest any limitation on the scope of use or functionality of the embodiments of the applications described herein. In any case, compute node 700 is capable of implementing and / or performing any of the functions listed above.

[0164] Computing node 700 contains a computer system / server 702 that operates alongside many 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 702 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, microcomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

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

[0166] like Figure 7 As shown, the computer system / server 702 in the cloud computing node 700 is illustrated as a general-purpose computing device. Components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, system memory 706, and buses that couple various system components, including system memory 706, to processor 704.

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

[0168] Computer system / server 702 typically includes a variety of computer system readable media. Such media can be any available media accessible through computer system / server 702, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements a flowchart of another diagram. System memory 706 may include computer system readable media in the form of volatile memory such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, memory 706 may provide read and write capabilities to non-removable, non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, magnetic optical disc drives for reading and writing from removable, non-volatile magnetic optical discs (such as "floppy disks") and optical disc drives for reading or writing from removable, non-volatile optical discs such as CD-ROMs, DVD-ROMs, or other optical media may be provided. In such an instance, each can be connected to the bus via one or more data media interfaces. As will be further depicted and described below, memory 706 may include a program product consisting of at least one set of program modules (e.g., at least one) having functionality configured to execute applications in various embodiments.

[0169] A program / utility having a collection (at least one) of program modules, along with an operating system, one or more application programs, other program modules, and program data, may be stored in memory 706, by way of example and not limitation. 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 network environment. Program modules typically perform functions and / or methods of various embodiments of the application programs described herein.

[0170] As will be understood by those skilled in the art, various aspects of this application may be embodied as a system, method, or computer program product. Therefore, various aspects of this application may take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all generally referred to herein as a “circuit,” “module,” or “system.” Furthermore, various aspects of this application may take the form of a computer program product embedded in one or more computer-readable media, on which computer-readable program code is embodied.

[0171] The computer system / server 702 can also communicate with one or more external devices via I / O device 712 (such as an I / O adapter). This device may include a keyboard, pointing device, display, voice recognition module, etc., enabling one or more devices to allow a user to interact with the computer system / server 702, and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). Such communication can occur via the I / O interface of device 712. Again, the computer system / server 702 can communicate with 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. As depicted, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0172] While exemplary embodiments of the systems, methods, and at least one of the non-transitory computer-readable media have been illustrated in the accompanying drawings and described in the foregoing detailed description, it is to be understood that this application is not limited to the disclosed embodiments, but is capable of various rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the functionality of the systems in the various figures can be performed by one or more of the modules or components described herein or in the distributed architecture, and may include transmitters, receivers, or pairs of both. For example, all or part of the functionality performed by a single module can be performed by one or more of these modules. Furthermore, the functionality described herein can be performed at different times and in relation to various events, either internal or external to the module or component. Additionally, information sent between the modules can be sent between the modules via at least one of the following: data network, Internet, voice network, Internet Protocol network, wireless device, wired device, and / or via multiple protocols. Similarly, messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0173] Those skilled in the art will understand that "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting 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 embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

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

[0175] Modules can also be at least partially implemented in software for execution by various types of processors. For example, an identified executable code unit may comprise a physical or logical block of one or more computer instructions, organized, for example, as an object, process, or function. However, the executable files of the identified module do not need to be physically together, but may comprise different instructions stored in different locations that, when logically connected, constitute the module and achieve its specified purpose. Furthermore, modules can be stored on computer-readable media, such as hard disk drives, flash memory devices, random access memory (RAM), magnetic tape, or any other such media used for storing data.

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

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

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

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

Claims

1. A means of transportation, wherein the means of transportation includes a movable node within a decentralized database, the means of transportation comprising: A rechargeable battery configured to power the vehicle; Processor, the processor being configured to: The energy requirements of the power grid associated with the vehicle are determined via software applications; The charging power value of the rechargeable battery is determined, and the type of energy from which the vehicle extracts electricity is determined based on the determined energy demand of the power grid. A request message is generated, and the charging power value is stored in a first field within the request message, and the type of energy from which the vehicle extracts the charging power is stored in a second field of the request message; The request message is stored on a decentralized database, where other decentralized database peers endorse and agree to the request message to avoid unnecessary or excessive consumption of a power source. as well as An interface configured to send the request message from the vehicle to a computing system associated with the charging station.

2. The vehicle of claim 1, wherein the processor is further configured to determine an additional charging power value to be used for charging an auxiliary system associated with the vehicle, and to combine the charging power value to be used for charging the rechargeable battery and the additional charging power value to be used for charging the auxiliary system in a first field before sending the request message to the computing system.

3. The vehicle of claim 1, wherein the computing system includes a central node connected to a plurality of available power sources connected to the charging station, and the processor is configured to request one or more of the cleanest energy source and the cheapest energy source in a second field, and to submit the selection of available power sources to the computing system.

4. The means of transport as claimed in claim 1, wherein the processor is further configured to store in a third field of the request message an identifier of the charging station to which the charging power value from the identified power source will be delivered before sending the request message to the computing system.

5. The means of transport of claim 1, wherein the means of transport comprises a plurality of rechargeable batteries, and the processor is further configured to add an identifier of one of the plurality of rechargeable batteries to a third field of the request message before sending the request message to the computing system.

6. The means of transport as claimed in claim 1, wherein the means of transport includes a mobile blockchain node within a blockchain network, the blockchain network including a plurality of mobile blockchain nodes and a plurality of static blockchain nodes, and the processor is further configured to store on the blockchain of the blockchain network a power value consumed by the rechargeable battery, an identifier of the power source, and an identifier of the means of transport.

7. The vehicle of claim 1, wherein the rechargeable battery is configured to be electrically connected to the charging station and to receive a requested value of charging power while being electrically connected to the charging station.

8. A method performed by a means of transport, comprising: A communication channel is established between a computing system associated with multiple available power sources and the vehicle containing a rechargeable battery configured to power the vehicle, wherein the vehicle includes a mobile node within a decentralized database. The energy requirements of the power grid associated with the vehicle are determined via software applications; The charging power value of the rechargeable battery is determined, and the type of energy from which the vehicle extracts electricity is determined based on the determined energy demand of the power grid. A request message is generated, and the charging power value is stored in a first field within the request message, and the type of energy from which the vehicle extracts the charging power is stored in a second field of the request message; The request message is stored on a decentralized database, where other decentralized database peers endorse and agree to the request message to avoid unnecessary or excessive consumption of a power source. as well as The request message is sent from the vehicle to the computing system via the established communication channel.

9. The method of claim 8, wherein the method further comprises determining an additional charging power value to be used for charging an auxiliary system associated with the vehicle, and combining the charging power value to be used for charging the rechargeable battery and the additional charging power value to be used for charging the auxiliary system in a first field before sending the request message to the computing system.

10. The method of claim 8, wherein the computing system includes a central node connected to a plurality of available power sources at the charging station, and the generation includes generating a request to identify one or more of the cleanest energy source and the cheapest energy source in a second field, and submitting it to the computing system to select an available power source.

11. The method of claim 8, wherein the method further comprises, before sending the request message to the computing system, storing in a third field of the request message an identifier of the charging station where the charging power value from the identified power source will be delivered.

12. The method of claim 8, wherein the means of transport comprises a plurality of rechargeable batteries, and the method further comprises adding an identifier of one of the plurality of rechargeable batteries to a third field of the request message before sending the request message to the computing system.

13. The method of claim 8, wherein the means of transport includes a mobile blockchain node within a blockchain network, the blockchain network including a plurality of mobile blockchain nodes and a plurality of static blockchain nodes, and the method further includes storing on the blockchain of the blockchain network a power value consumed by the rechargeable battery, an identifier of the power source, and an identifier of the means of transport.

14. The method of claim 8, wherein the method further comprises electrically connecting the rechargeable battery to a charging station and receiving a requested value of charging power while electrically connecting to the charging station.

15. A non-transitory computer-readable medium containing instructions that, when read by a processor, cause the processor to perform a method, the method comprising: A communication channel is established between a computing system associated with multiple available power sources and a vehicle containing a rechargeable battery configured to power the vehicle, wherein the vehicle includes a mobile node within a decentralized database. The energy requirements of the power grid associated with the vehicle are determined via software applications; The charging power value of the rechargeable battery is determined, and the type of energy from which the vehicle extracts electricity is determined based on the determined energy demand of the power grid. A request message is generated, and the charging power value is stored in a first field within the request message, and the type of energy from which the vehicle extracts the charging power is stored in a second field of the request message; The request message is stored on a decentralized database, where other decentralized database peers endorse and agree to the request message to avoid unnecessary or excessive consumption of a power source. as well as The request message is sent from the vehicle to the computing system via the established communication channel.

16. The non-transitory computer-readable medium of claim 15, wherein the method further comprises determining an additional charging power value to be used for charging an auxiliary system associated with a vehicle, and combining the charging power value to be used for charging the rechargeable battery and the additional charging power value to be used for charging the auxiliary system in a first field before sending the request message to the computing system.

17. The non-transitory computer-readable medium of claim 15, wherein the generation includes identifying one or more energy sources among the cleanest energy source and the cheapest energy source and storing the identifiers of the one or more energy sources among the cleanest energy source and the cheapest energy source in the second field, and submitting the power supply to the computing system for selection of available power.

18. The non-transitory computer-readable medium of claim 15, wherein the method further comprises, before sending the request message to the computing system, storing in a third field of the request message an identifier of the charging station where the charging power value from the identified power source will be delivered.

19. The non-transitory computer-readable medium of claim 15, wherein the means of transport comprises a plurality of rechargeable batteries, and the method further comprises adding an identifier of one of the plurality of rechargeable batteries to a third field of the request message before sending the request message to the computing system.

20. The non-transitory computer-readable medium of claim 15, wherein the means of transport includes a movable blockchain node within a blockchain network, the blockchain network including a plurality of movable blockchain nodes and a plurality of static blockchain nodes, and the method further includes storing on the blockchain of the blockchain network a power value consumed by the rechargeable battery, an identifier of the power source, and an identifier of the means of transport.

Images