Wireless energy transmission for vehicles based on route data

Abstract

The present disclosure relates to wireless energy transfer to a vehicle based on route data. Example operations include one or more of the following: determining, by the vehicle, that an energy transfer condition exists along a route; based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions, driving by the vehicle to a location on the route; aligning the vehicle's position at the location to wirelessly receive energy transfer; and receiving the energy transfer by the vehicle while the vehicle is moving.

Description

[0001] Related Applications Cross Applications

[0002] This application is related to co-pending U.S. non-provisional patent application entitled “DYNAMIC TRANSPORT ENERGY CONTROL” and U.S. provisional patent application entitled “POWER ALLOCATION TO TRANSPORTS,” which were filed on the same date and the entire contents of each of which are incorporated herein by reference. Background Art

[0003] Vehicles or conveyances (e.g., cars, motorcycles, trucks, airplanes, trains, etc.) generally provide transportation needs for passengers and / or cargo in a variety of ways. Functions related to the conveyance may be recognized and used by various computing devices (e.g., smartphones or computers on and / or off the conveyance). Summary of the invention

[0004] An example embodiment provides a method comprising one or more of the following: determining, by a vehicle, that an energy transfer condition exists along a route; based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions, traveling by the vehicle to a location on the route; aligning, by the vehicle, a position of the vehicle at the location to wirelessly receive an energy transfer; and receiving, by the vehicle, the energy transfer while the vehicle is moving.

[0005] Another example embodiment provides a vehicle comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of the following: determining, by the vehicle, that an energy transfer condition exists along a route; traveling, by the vehicle to a location on the route based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions; aligning, by the vehicle, a position of the vehicle at the location to wirelessly receive an energy transfer; and receiving, by the vehicle, the energy transfer while the vehicle is moving.

[0006] Yet another example embodiment provides a non-transitory computer-readable storage medium containing instructions that, when read by a processor, cause the processor to perform one or more of the following: determining, by a vehicle, that an energy transfer condition exists along a route; traveling, by the vehicle to a location on the route based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions; aligning, by the vehicle, the position of the vehicle at the location to wirelessly receive an energy transfer; and receiving, by the vehicle, the energy transfer while the vehicle is moving. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A An example system diagram of vehicle operation according to an example embodiment is shown.

[0008] Figures 1B to 1E An example of energy transfer between vehicles is shown according to an example embodiment.

[0009] Figure 1F Various energy transfer ports of a vehicle are shown according to example embodiments.

[0010] Figure 2A Another vehicle network diagram of vehicle operating sensors is shown according to an example embodiment.

[0011] Figure 2B Another vehicle network diagram is shown according to an example embodiment.

[0012] Figure 2C Yet another transportation network diagram is shown according to an example embodiment.

[0013] Figure 2D Yet another transportation network diagram is shown according to an example embodiment.

[0014] Figure 2E Yet another vehicle network diagram is shown in accordance with an example embodiment.

[0015] Figure 2F A diagram depicting electrification of one or more components is shown according to an example embodiment.

[0016] Figure 2G A diagram depicting the interconnections between different elements according to an example embodiment is shown.

[0017] Figure 2H Still another diagram depicting the interconnections between various elements according to an example embodiment is shown.

[0018] Fig.2I Still another diagram depicting the interconnections between different elements according to an example embodiment is shown.

[0019] Figure 3A A flow chart according to an example embodiment is shown.

[0020] Figure 3B Another flow chart according to an example embodiment is shown.

[0021] Figure 3C Yet another flow chart according to an example embodiment is shown.

[0022] Figure 4 A machine learning vehicle network diagram is shown according to an example embodiment.

[0023] Figure 5A An example vehicle configuration for managing database transactions associated with a vehicle is shown according to an example embodiment.

[0024] Figure 5B Another example vehicle configuration for managing database transactions between various vehicles is shown in accordance with an example embodiment.

[0025] Fig. 6A A blockchain architecture configuration according to an example embodiment is shown.

[0026] Figure 6B Another blockchain configuration according to an example embodiment is shown.

[0027] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown.

[0028] Fig.6D Example data blocks are shown according to example embodiments.

[0029] Figure 7 An example system is shown that supports one or more example embodiments. DETAILED DESCRIPTION

[0030] It is readily understood that the present components as generally described and illustrated in the various figures herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems as shown in the figures is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0031] Communications between a vehicle and certain entities, such as remote servers and local computing devices (such as smartphones, personal computers, computers embedded in vehicles, etc.), may be received and processed by one or more "components", which may be hardware, firmware, software, or a combination thereof. A component may be part of any of these entities or computing devices, or other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by a computing device or component associated with the vehicle and one or more components located outside or remote from the vehicle. A consensus decision or protocol is the process by which one or more nodes or peers in a network reach agreement on a value, state, result, input, output, condition, etc.

[0032] The features, structures or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the phrases "exemplary embodiments", "some embodiments" or other similar expressions used throughout this specification refer to the fact that a particular feature, structure or characteristic described in conjunction with an embodiment may be included in at least one embodiment. Therefore, the phrases "exemplary embodiments", "in some embodiments", "in other embodiments" or other similar expressions appearing throughout this specification do not necessarily all refer to the same set of embodiments, and the features, structures, characteristics described may be combined in one or more embodiments in any suitable manner. Any connection between the elements in the figure may be unidirectional and / or bidirectional communication, even if the connection shown in the figure is a unidirectional or bidirectional arrow. In the current solution, the means of transport may include one or more of a car, a truck, a pedestrian electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that can be used to transport people and / or goods from one location to another.

[0033] In addition, although the term "message" may have been used in the description of the embodiments, other types of network data (e.g., packets, frames, datagrams, etc.) may also be used. In addition, although certain types of messages and signaling may be described in the example embodiments, they are not limited to a certain type of message and signaling.

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

[0035] Within the communication infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database, including an append-only immutable data structure (i.e., a distributed ledger) that is capable of maintaining records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without consensus among the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage entries, group storage entries into blocks, and build a hash chain through blocks. As needed, the process forms a ledger by sorting the storage entries to achieve consistency. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). In contrast, a permissioned blockchain database can guarantee transactions between a group of entities that do not trust or cannot fully trust each other but have common goals, such as the business of exchanging funds, goods, information, etc. The present scheme can be used in permissioned and / or permissionless blockchain settings.

[0036] Smart contracts are trusted distributed applications that leverage the tamper-proof nature of a shared or distributed ledger (which can be in the form of a blockchain) and an underlying agreement between member nodes, known as endorsements or endorsement policies. Generally, blockchain entries are "endorsed" before being submitted to the blockchain, and unendorsed entries are ignored. A typical endorsement policy allows the smart contract 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 validate the entry. After validation, the entry enters the sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed entries grouped into blocks.

[0037] A node is a communication entity of a blockchain system. Multiple nodes of different types can run on the same physical server, and in this sense, a "node" can perform a logical function. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as clients or submitting client nodes that submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to ordering services (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 copy 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, which perform delivery guarantees, such as broadcasting to every peer node in the system when submitting entries and modifying the world state of the blockchain. The world state can constitute the initial blockchain entry, which typically includes control and setup information.

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

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

[0040] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain's entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Smart contract executable code calls execute entries against the current state data of the ledger. In order to make these smart contract executable code interactions efficient, the latest values ​​of the keys can be stored in a state database. The state database can be just an indexed view 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 if needed) when a peer node starts up and before an entry is accepted.

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

[0042] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. A vehicle may need service at intervals, and may need to authorize the service demand before being allowed to receive service. In addition, a service center may provide services to vehicles in a nearby area based on the relative level of the vehicle's current route planning and service requirements (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand may be monitored by one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer device in and / or away from the vehicle. The data is forwarded to a management server for review and action. The sensor may be located in one or more of the following: the interior of a vehicle, the exterior of a vehicle, a fixed object away from the vehicle, and another vehicle near the vehicle. The sensor may also be associated with the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the amount of fuel, the service demand, the shifting of the vehicle, the steering of the vehicle, etc. As described herein, the sensor may also be a device, such as a wireless device in and / or near the vehicle. Additionally, sensor information may be used to identify whether the vehicle is operating safely and whether passengers are in any unexpected vehicle states, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be generated and submitted to an immutable ledger determined by a permissioned consortium and thus in a "decentralized" manner, such as through a blockchain member group.

[0043] Each party involved (i.e., owner, user, company, institution, etc.) may wish to limit exposure of private information, so 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 service is required, identify collision and / or degradation events, identify safety issue events, identify parties involved in the event, and provide distribution to registered entities that apply for access to such vehicle event data. In addition, the results can be identified and the necessary information can be shared between registered companies and / or individuals based on a consensus method associated with the blockchain. This approach cannot be implemented on a traditional centralized database.

[0044] Various driving systems of this solution can use software, sensor arrays, and machine learning capabilities, light detection and ranging (LIDAR) projectors, radars, ultrasonic sensors, etc. to create terrain maps and road maps for vehicles to use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles instead of LIDAR.

[0045] In certain embodiments, the present solution includes authorizing a vehicle for service through an automated and rapid authentication scheme. For example, travel to a charging station or gas pump may be performed by a vehicle operator or an autonomous vehicle, and in the event that the service station and / or charging station receives authorization, authorization to receive electricity or gas may be performed without delay. The vehicle may provide a communication signal with a vehicle identifier having a current activity profile linked to an account authorized to receive service, which may be subsequently corrected through compensation. Additional measures may be used to achieve further authentication, such as wirelessly sending another identifier from the user's device to the service center, thereby replacing or supplementing the initial authorization effort between the vehicle and the service center with an additional authorization effort.

[0046] The shared and received data can be stored in a database, which holds data in a single database (e.g., a database server) and is typically located in one specific location. This location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a central database can typically be accessed from multiple different points. Centralized databases are easy to manage, maintain, and control, and their single location is particularly conducive to data security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data means there is only one master record for a given data set. Blockchain can be used to store data and transactions related to vehicles.

[0047] Figure 1A An example system diagram 100 of vehicle operation according to an example embodiment is shown. Figure 1A, the vehicles may include one or more providing vehicles 110 and one or more receiving vehicles 120. In this example, there may be one providing vehicle and one receiving vehicle, but there may be multiple depending on the situation. For example, over a period of time, a receiving vehicle 120 may have multiple energy providing vehicles 110 providing energy in a single energy sharing session or multiple sessions. The server 130 may be a communication entity operating on a network that provides services to the vehicles 110 / 120 to participate in energy sharing events. All vehicles may have their own on-board computing devices, such as embedded computing devices, mobile devices within the vehicle, etc. In addition, each vehicle may have its own communication service, such as any wireless service using any wireless protocol.

[0048] Events conducted between vehicles may include vehicle-to-vehicle (V2V) power sharing or other energy sharing, which is conducted by aligning vehicles close to each other in any one or more of parking situations, moving at a fixed location at a specific speed, and / or moving from one location to another relative to each other in a parking area or on the road. The ability to identify whether a potential charging event can occur at any specific time can be based on certain energy transfer conditions, such as how much power or energy one vehicle has available to provide to another vehicle, how long it will take for the vehicles to meet on the road to initiate the transfer, the expected destination of the vehicle, and the status of the vehicle (e.g., busy, not busy, willing to share, unwilling to share, etc.). Traffic conditions may include the volume of traffic on the road, the time of day, and specific expected events (accidents, weather, rush hour, etc.). Certain traffic conditions are more conducive to completing energy transfer events. In one example, frequent stop-and-go may or may not be a favorable event because the distance between vehicles may or may not be consistent, which depends particularly on the type of vehicle providing / receiving energy, which may be another condition to consider when planning an event.

[0049] In an example embodiment, when a potential recipient of energy, such as a receiving vehicle 120, has received information (112) about when and where an energy transfer event may occur based on energy transfer conditions and / or traffic conditions, the receiving vehicle 120 may accept / set up an energy transfer event. The event may be recorded via the server 130 and shared with participating vehicles 110 / 120 that are set to participate in such an event. In another embodiment, the receiving vehicle 120 may communicate directly with the providing vehicle 110 and / or the server 130 to establish the energy transfer. The process may also include determining by the receiving vehicle 120 (via the computing platform) and due to the existence of energy transfer conditions along the current route, based on energy transfer conditions exceeding an energy transfer value and based on one or more traffic conditions, to drive the vehicle to a location on the route (114). The energy transfer value may be weighted by a function with a set of conditions to determine whether the event is above a threshold value for the transfer value. For example, whether two vehicles are close to each other, a set distance apart (e.g., 10 miles), traveling in the same direction, and can catch up with each other without pulling over (e.g., one vehicle slows down, the other increases speed, etc.). The combined weighted score may need to be equal to or higher than the energy transfer value in order for the event to proceed. The process may also include aligning the position of the vehicle at the intended transfer location by the vehicle to wirelessly receive the energy transfer (116). The driving and aligning operations may include moving the receiving vehicle 120 / providing vehicle 110 along a specific route at a specific time and at a specific speed so that the receiving vehicle 120 / providing vehicle 110 can align their positions on a specific lane of a multi-lane road so that wireless energy (i.e., power) flows from one location (or port) to another location. Because the road may include various obstacles (e.g., moving traffic of other vehicles, construction, traffic, changing weather conditions, etc.), the receiving vehicle 120 may change position (122) during the energy transfer event and receive additional energy (124) at a different location on the vehicle than the first location. The final results (126) of the energy transfer event may be shared with the server 130 to confirm the various parties, profiles, energy transfer amounts, locations, time amounts, values ​​received and / or exchanged, etc. The location may include both receiving and delivering capabilities via a bilateral (provide / receive) charging interface.

[0050] Energy transfer events, such as power sharing, can be performed while the vehicle is stationary or in motion. Before the event can be set up and executed, the server 130 and / or the vehicle 110 / 120 can perform, before participating in the energy transfer event: determining one or more traffic conditions along the route, determining the vehicle location and one or more additional vehicle locations, and whether one or more traffic conditions and vehicle locations will satisfy the energy transfer conditions. In one example, the energy transfer conditions may include a specific amount of charge required within a certain distance on the route of the receiving vehicle and within a certain amount of time. These conditions may be requirements for providing vehicles as candidates for identification. When one or more of these conditions can be met with a certain accuracy (i.e., 5% or less), the event can be considered acceptable. The energy demand level can be an estimated amount of charge that may be exchanged based on the various conditions identified.

[0051] Once an event is triggered due to an event criterion being above the energy requirement level of the energy transfer condition, the vehicles may have an alignment plan (provided from the server 130 to the vehicles 110 / 120) as to how the transfer will proceed, such as identifying the current and future positions of one or more vehicles in motion, and changing one or more positions of the vehicles to be within a certain distance of each other to receive and provide energy between the vehicles. An energy transfer event may include a receiving vehicle 120 receiving a portion of energy from a providing vehicle 110. Then, after a period of time, the position of one or both of the vehicles may change, and the energy may be provided at a different location through a different port on one or both vehicles (see Figures 1B to 1F ) to provide additional energy. A variety of different energy sharing configurations can be used in a single energy sharing event.

[0052] Figures 1B to 1E Different examples of energy sharing while on the road according to example embodiments are shown. Figure 1B , the vehicle 110 / 120 is at a first distance D1, which may be too far to conduct an energy transfer event. The distance required for the energy sharing event may need to be less than D1 in the example, which may be about 15 feet for this example. To obtain wireless charging, the distance may need to be 10 feet or less.

[0053] exist Figure 1C In the embodiment, the providing vehicle 110 can provide charging from the front of the providing vehicle 110 to the rear of the receiving vehicle 120. The two vehicles can be in a position where they can remain relatively fixed to each other while moving along the road. Figure 1DThe example of FIG. 1 shows that the receiving vehicle 120 receives charge from the rear of the vehicle body through a port located at the rear, and the providing vehicle 110 provides charge from its front to the rear of the vehicle 120 through a port located at the front. As can be seen, as traffic patterns change, the positions of the vehicles relative to each other may change. Thus, the charging ports used in a charging event session may be switched between each other, however, the total charge amount may be based on the time when one or more ports on the providing vehicle 110 engage with one or more ports on the receiving vehicle 120. Figure 1E In another example, a corner port at the front of providing vehicle 110 may provide charging to a corner port at the rear of receiving vehicle 120 .

[0054] Figure 1F A vehicle is shown having various charging ports around the vehicle body according to an example embodiment. Figure 1F , example 150 shows how the receiving vehicle 120 can have various energy sharing / receiving ports 152-162 and potentially more ports distributed around the entire body of the vehicle. Any port can be connected to one or more batteries or other energy sources that can receive and store energy or share and release energy. In this example, at a first time T1, ports 152 and / or 154 can be used when providing vehicles 110 close to those parts of the vehicle. At a later time T2, when providing vehicles 110 in front of receiving vehicles 120, ports in the front area of ​​the vehicle 120, such as 156, 158, and 162, can be used. Then, at a later time T3, assuming that the vehicle changes position again, the rear port 152 can be used for a third energy sharing event. Various port positions provide a way to accumulate multiple energy transfers when the vehicle moves along the road or when only one position of the vehicle is the best position at a particular time.

[0055] In one example, vehicles 110 / 120 are in proximity to each other. Ports on the vehicles are provided, such as ports located, for example, at the lower portion of each door, to allow energy transfer. In one embodiment, a request for energy transfer is initiated by one vehicle (in other embodiments, the request may be initiated by server 130). A wireless connection is established between the two vehicles 110 / 120 to determine whether the requested amount of energy can be transferred. Transferring an amount of energy between ports includes transferring a portion of the amount of energy at any time and transferring a portion of the amount of energy until the energy transfer request is satisfied.

[0056] Charging the battery of one vehicle to the battery of another vehicle uses at least one energy transfer process. Implementations of wireless energy transfer include at least two different types: inductive, which uses magnetic field coupling between conductive coils to transfer energy, and capacitive, which uses electric field coupling between conductive plates to transfer energy. Capacitive transfer systems reduce the need for electromagnetic field shielding and can operate at high frequencies, making them potentially smaller and cheaper. One or more of these types and / or other technologies that allow wireless energy transfer can be used with the present solution.

[0057] In one embodiment, by controlling the input voltage of a single inverter (not shown) and its relative phase shift, energy can be maintained at a uniform level and wirelessly transferred between various ports on the vehicle 110 / 120 and a charging station containing the necessary equipment. A high-frequency inverter can be used to compensate for coupling changes when operating at a fixed frequency. The load of the inverter can appear to provide voltage-free compensation with almost no current switching. Voltage gain and compensation networks can be used to provide voltage and / or current gain. When the coupling reactance changes from its nominal value, the inverter provides the required additional compensation. A high-frequency rectifier (not shown) can be used to provide variable compensation at a fixed frequency while maintaining high efficiency.

[0058] When a pair of vehicles, or even three or more vehicles, participate in a road-moving energy transfer event, a control entity may be necessary to maintain control of the vehicles for road safety and traffic measures. For example, if two or more vehicles are performing energy transfer while moving along a road, one of the vehicles or another network entity (e.g., a server) may be responsible for (by controlling one or more onboard processors on the other vehicles) the acceleration, braking, speed, etc. of all vehicles. In addition, if a vehicle is ahead of the other vehicles with respect to the leading vehicle in front, the vehicle may provide braking and speed control for both vehicles while the transfer is in progress. Once the transfer stops, the vehicles may again maintain their own control and be independent of each other.

[0059] In an example embodiment, the energy exchange may include receiving a portion of the energy transfer at a first location on the vehicle body during a first time period and receiving another portion of the energy transfer at a second location on the vehicle body during a second time period to complete the energy transfer. The accumulation of charging positions may equal the complete energy transfer. The process may include determining an estimated amount of time based on one or more traffic conditions, the vehicle and one or more additional vehicles, and how the vehicles are best aligned while in motion during the energy transfer, and determining that an energy transfer condition exists based on the estimated amount of time and whether sufficient power can be exchanged.

[0060] When the energy transfer occurs, the vehicle may receive verification of the energy transfer from at least one component (as described and / or depicted herein), wherein the verification may include a blockchain consensus between a peer group consisting of the vehicle (or one or more devices in the vehicle) and the at least one component, and the process may also include executing a smart contract by the vehicle to record the verification and the at least one component on a blockchain based on the blockchain consensus.

[0061] In an example embodiment, a vehicle is able to determine the best time and location to perform wireless energy transfer with another vehicle. The time and location may be based on current or future traffic on a route, current or future road conditions on a route, and / or current or future weather conditions on a route, which may be a route for receiving or providing vehicles. In an embodiment, a vehicle 120 that needs energy notifies a server 130 and one or more of vehicles 110 that can provide energy. The notification sent by the vehicle 120 includes one or more of the current location of the vehicle, the amount of energy remaining in the vehicle, the future location where the energy of the vehicle will be exhausted, and the time when the vehicle will have no energy. If the location and availability of the vehicle 120 are known, the notification may be sent directly by the vehicle 120 to the vehicle 110. The notification may also be sent by the vehicle 120 to the server 130 to request energy through other vehicles. The server 130 determines whether the vehicle 110 (or other vehicles) can meet the vehicle 120 before the vehicle 120 will run out of energy. If so, server 130 notifies vehicle 120 and vehicle 110 of the meeting point, where vehicle 110 can wirelessly provide energy to vehicle 120 while both vehicles move along the route and / or temporarily stop (e.g., red light, traffic jam, rest area, etc.).

[0062] The rendezvous point may be based on traffic condition data. For example, one or more network elements, such as vehicle 110, vehicle 120, and server 130, may determine likely traffic conditions at the rendezvous point based on recent or historical traffic information. When traffic conditions are optimal, for example, if the vehicle will be moving at a slow speed and / or stopping frequently, the location may be set for wireless energy transfer, which will be more efficient because the vehicle may be optimally aligned for a longer period of time for energy transfer.

[0063] In another embodiment, whether a slow speed is possible can depend on the length of time and / or distance that the vehicle can be optimally positioned based on the traffic ahead. For example, if the vehicles are side by side, the traffic in the two lanes ahead should allow the minimum distance for optimal energy transfer. This can be further confirmed by determining the amount of time required to transfer enough power and ensure that there is enough road ahead, which can be determined by one or more network elements. For example, if the vehicle is in a back-to-front or front-to-back configuration on the road, the traffic in the single lane ahead should allow the minimum distance for optimal energy transfer. In one example, one vehicle and another vehicle remain in place based on instructions from a server, and the server can control the vehicle during the shared event. In one embodiment, the vehicle and another vehicle continuously send messages to each other to ensure accurate alignment. Therefore, the vehicles may be side by side, then from front to back, then disconnected due to the inability to perform optimal energy transfer, then side by side, disconnected, reconnected at different locations, or even connected to different vehicles that provide better energy transfer, so that the event becomes an event for three or more vehicles.

[0064] In one embodiment, the notification sent from the vehicle 120 may include the amount of energy required. If such an amount can be provided, the distance and / or time required to do so and the number and / or location of the vehicles that will perform wireless energy transmission can all be determined before the event. If such an amount cannot be provided, the amount of energy that can be provided can be determined. In a further embodiment, the notification from the vehicle may include the destination of the vehicle and / or the amount of time available to receive energy before the vehicle has to start full speed. The vehicle is provided (directly or through a server) to receive this notification and determine whether it can travel to the vehicle before the vehicle reaches its destination and / or within the available time and provide energy. Unlike vehicles that need to stop and use charging stations, road energy transmission events allow vehicles to continue to operate along the route while wirelessly receiving energy. In one embodiment, the ability to receive energy and to move the send / receive module through a motorized control feature can provide automatic / dynamically calibrated control to receive the best / most efficient energy transmission for moving vehicles. The module moves to achieve optimal connection and energy transmission.

[0065] In one embodiment, a mobile device associated with a vehicle is used as a controller so that the placement of the device helps guide the energy transfer sensor to a location where the transmission is strongest. Indications provided by the vehicle and / or other vehicles that wireless charging is occurring can provide a control feature that uses feedback information to maintain optimal speed, position, and / or alignment between vehicles. In addition, while identifying dynamic traffic condition information, a decision can be made as to whether it is prudent to exit and begin charging off the road for at least a period of time, and possibly resume charging on the road once a majority of the charge has been exchanged due to improved traffic conditions. The amount of time charging is maintained on the road, whether charging is performed off the road, and whether charging is performed at an off-road charging station, etc. can all be considered in the planned energy transfer event.

[0066] In one example, a trip may have a total time function where a set number of minutes is added to the trip for a particular course of action and then modified each time traffic conditions change. Other factors included when exiting a road include stop lights, exiting the vehicle, starting and stopping the vehicle, etc. In a further example, the vehicle may be traveling along a route where rain or a storm is about to occur, visibility is poor, and / or daylight is fading, so the use of wipers or headlights is required. In such examples, additional energy may be required that was not initially considered and is obtained from various sources. This increased required energy may also be factored into the function necessary to obtain the accurate usage and amount of energy required for the trip.

[0067] Figure 2A A vehicle network diagram 200 according to an example embodiment is shown. The network includes elements, and the elements include a vehicle node 202 with a processor 204 and a vehicle node 202' with a processor 204'. The vehicle nodes 202 and 202' communicate with each other through the processors 204 and 204' and other elements (not shown), and the other elements include transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of communication. The vehicle nodes 202 and 202' can communicate directly through private and / or public networks (not shown) or through other vehicle nodes and elements containing one or more of the processors, memories, and software. Although a single vehicle node and processor are shown, multiple vehicle nodes and processors may also exist. One or more of the applications, characteristics, steps, schemes, etc. described and / or depicted herein may be used and / or provided by these elements.

[0068] Figure 2BAnother vehicle network diagram 210 according to an example embodiment is shown. The network includes elements, including a vehicle node 202 with a processor 204 and a vehicle node 202' with a processor 204'. The vehicle nodes 202 and 202' communicate with each other through the processors 204 and 204' and other elements (not shown), and the other elements include transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of communication. The vehicle nodes 202 and 202' can communicate directly through private and / or public networks (not shown) or through other vehicle nodes and elements containing one or more of the processors, memories, and software. The processors 204 and 204' can further communicate with one or more elements 230, including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicle nodes 222, computers 224, I / O devices 226, and voice applications 228. Processors 204 and 204' may further be in communication with elements including one or more of a processor, memory, and software.

[0069] Although shown as a single vehicle node, processor and element, multiple vehicle nodes, processors and elements may also be present. Information may be sent and received or communicated with any one of the processors 204, 204' and the element 230. For example, the mobile phone 220 may provide information to the processor 204, the processor 204 may start the vehicle node 202 to take action, and may further provide the information or additional information to the processor 204', the processor 204' may start the vehicle node 202' to take action, and may further provide the information or additional information to the mobile phone 220, the vehicle node 222 and / or the computer 224. One or more of the applications, features, steps, schemes, etc. described and / or depicted herein may be used and / or provided by these elements.

[0070] Figure 2C 240 according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer readable medium 242C and the element 230 (e.g., Figure 2B ).

[0071] Processor 204 performs one or more of the following: determining that an energy transfer condition exists along the route (244C), traveling to a location on the route based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions (246C), aligning the position of the vehicle at the location to wirelessly receive the energy transfer (248C), and receiving the energy transfer while the vehicle is moving (250C).

[0072] Figure 2D 250 according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a non-transitory computer readable medium 242D. The processor 204 is communicatively coupled to the computer readable medium 242D and the element 230 (e.g., Figure 2B ).

[0073] The processor 204 performs one or more of the following: determining one or more traffic conditions along the route, determining a vehicle location and one or more additional vehicle locations, and determining that one or more traffic conditions and vehicle locations will satisfy an energy transfer condition (244D); identifying the location of one or more additional vehicles while in motion and changing the location of the vehicle to be within a distance of the one or more additional vehicles (246D); receiving a portion of the energy transfer at a first location of the vehicle body within a first time period, and receiving another portion of the energy transfer at a second location of the vehicle body within a second time period to complete the energy transfer (248D); and determining an estimated amount of time based on the one or more traffic conditions during which the vehicle and the one or more additional vehicles will be optimally aligned while in motion during the energy transfer, and determining that an energy transfer condition exists based on the estimated amount of time (250D).

[0074] Figure 2E Still another transportation network diagram 260 is shown according to an example embodiment. Figure 2E , the network diagram 260 includes a vehicle node 202 connected to other vehicle nodes 202' and an update server node 203 through a blockchain network 206. The vehicle nodes 202 and 202' may represent vehicles / vehicles. The blockchain network 206 may have a ledger 208 for storing software update verification data and verification sources for future use (e.g., for auditing).

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

[0076] The processor 204 performs one or more of the following operations: receiving verification of the energy transfer from the at least one component, the verification comprising a blockchain consensus between a peer group consisting of the vehicle and the at least one component (244E); and executing a smart contract to record the energy transfer event and the at least one component on the blockchain based on the blockchain consensus (246E).

[0077] The processor and / or computer readable medium may be located in whole or in part inside or outside the vehicle node. The steps or features stored in the computer readable medium may be executed in whole or in part by any processor and / or element in any order. In addition, one or more steps or features may be added, omitted, combined, or performed at a later time.

[0078] Figure 2F A diagram 265 depicting the electrification of one or more elements is shown. In one embodiment, a vehicle 266 can provide energy stored in its battery to one or more elements, including other vehicles 268, charging stations 270, and a power grid 272. The power grid 272 is connected to one or more charging stations 270, which can be connected to one or more vehicles 268. This configuration allows the distribution of power / energy received from the vehicle 266. The vehicle 266 can also interact with other vehicles 268, such as through vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. The vehicle 266 can also interact with other vehicles 268, charging stations 270, and / or power grids 272 in a wireless and / or wired manner. In one embodiment, the vehicle 266 is routed (or routed itself) to the power grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. In one or more embodiments employing the present solution, the vehicle 266 can provide energy to one or more of the elements depicted herein in a variety of advantageous ways described and / or depicted herein. Further, transportation safety and efficiency may be improved, and the environment may be positively impacted as described and / or depicted herein.

[0079] The term "energy" may be used to refer to any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may refer to a voltage source and / or current supply provided from an entity to a vehicle for charging during a charging / using operation. Energy may also be in the form of fossil fuels (e.g., for hybrid vehicles) or through other alternative energy sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion energy, and energy dynamically generated during energy sharing and / or using operations to increase or decrease one or more vehicle energy levels at a given time.

[0080] In one embodiment, the charging station 270 manages the amount of energy transferred from the vehicle 266 so that there is enough power left in the vehicle 266 to reach the destination. In one embodiment, the amount of energy transferred between the vehicles 268 is guided wirelessly using a wireless connection, wherein these vehicles can all be in operation. In one embodiment, an idle vehicle, such as the vehicle 266 (which can be autonomous) is guided to provide a certain amount of energy to the charging station 270 and return to the initial location (such as its initial location or a different destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 268 and transfer the stored excess energy at the charging station 270. In one embodiment, factors determine the amount of energy that can be transferred to the charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (weight, etc.), passenger use schedule, expected passenger schedule waiting for the vehicle, etc. In one embodiment, the vehicle 268, the charging station 270 and / or the power grid 272 can provide energy to the vehicle 266.

[0081] In one embodiment, the solution described and depicted herein may be used to determine the load impact on a vehicle and / or system, provide energy to the vehicle and / or system based on future needs and / or priorities, and provide intelligence between the device containing the module and the vehicle, allowing the processor in the device to wirelessly communicate with the vehicle regarding the amount of energy stored in the battery on the vehicle. In one embodiment, the solution may also be used to provide charging from the vehicle to a location based on factors such as the temperature of the location, the cost of energy, and the energy level at the location. In one embodiment, the solution may 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, the solution may also be used to notify the vehicle to provide a certain amount of energy from the battery on the vehicle, wherein the amount of energy to be transferred is based on the distance between the vehicle and the module to receive the energy.

[0082] In one embodiment, the solution can also be used to use a mobile energy storage unit that uses a determined path to travel to a vehicle that has excess energy and deposits the stored energy into the grid. In one embodiment, the solution can also be used to determine the priority of the vehicle's need to provide energy to the grid, as well as the priority of the vehicle's current needs, such as the priority of passengers, incoming passengers, current cargo, or incoming cargo. In one embodiment, the solution can also be used to determine that when the vehicle is idle, the vehicle decides to travel to a certain location to release excess energy to the grid and then return to the previous location. In one embodiment, the solution can also be used to determine the energy required by the vehicle based on one or more conditions (such as weather, traffic, road conditions, car conditions, and / or passengers and / or cargo in other vehicles) to provide the required energy for another vehicle through vehicle-to-vehicle energy transfer, and instruct the vehicle to route to another vehicle and provide energy. In one embodiment, the solution can also be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, the solution may also be used to retrieve energy from a vehicle based on an estimated amount of energy consumed by the vehicle to reach a rendezvous point with another vehicle, provide service, and return to an original location. In one embodiment, the solution may also be used to provide a remaining distance required to reach a charging station, which determines the amount of energy to be taken from the vehicle, wherein the amount of energy remaining is based on the remaining distance. In one embodiment, the solution may also be used to manage vehicles that are charging at multiple points simultaneously, such as a charging station connected by a wire and another vehicle connected by a wireless connection. In one embodiment, the solution may also be used to assign energy application priorities to vehicles, wherein priority is given to those vehicles that will provide a portion of their stored energy to another entity (e.g., a power grid, a residence, etc.). Further, with respect to Figure 2F The described and depicted solutions may be used here and in other networks and / or systems.

[0083] Figure 2GA diagram of interconnection 275 between different elements is shown. The present solution may be stored and / or executed in whole or in part on one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287' and 277' associated with various entities, wherein the various entities are all communicatively coupled to and communicate with a network 286. A database 287 is communicatively coupled to the network and allows data storage and retrieval. 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 residences 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 a smart phone 278, a laptop 280 and / or a wearable device, may also interoperate with the present solution. Smartphone 278, laptop 280, microphone 285, and other devices may be connected to one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various institutions. One or more public buildings 281 may use computing device 281'. One or more service providers 279 may include dealers, towing services, collision centers, or other repair shops. One or more service providers 279 may use computing device 279'. Such various computer devices may be directly and / or communicatively coupled to each other, for example, via a wired network, a wireless network, a blockchain network, etc. In one embodiment, microphone 285 may serve as a virtual assistant. In one embodiment, one or more traffic infrastructure 282 may include one or more traffic lights, one or more sensors (including one or more cameras, vehicle speed sensors, or traffic sensors), and / or other traffic infrastructure. One or more traffic infrastructure 282 may use computing device 282'.

[0084] In one embodiment, the vehicle 277 / 276 can transport people, objects, permanent or temporarily fixed devices, etc. In one embodiment, the vehicle 277 can communicate with the vehicle 276 through the computer 276' and 277' associated with each vehicle through V2V communication, and can be referred to as a vehicle, a car, a vehicle, a car, etc. The vehicle 276 / 277 can be a self-driving wheeled vehicle, such as a car, a sports utility vehicle, a truck, a bus, a van, or other motor or battery-driven or hybrid vehicle. For example, the vehicle 276 / 277 can be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle with a fuel cell stack, a motor and / or a generator. Other examples of vehicles include bicycles, scooters, trains, airplanes or ships, and any other form of transportation that can be used for transportation. The vehicle 276 / 277 can be semi-automatic or fully automatic. For example, the vehicle 276 / 277 can be automatically manipulated and navigated without manual operation. An autonomous vehicle may have and use one or more sensors and / or navigation units to enable autonomous driving.

[0085] In one embodiment, the solution described and depicted herein can be used to determine access to a vehicle through a consensus of a blockchain. In one embodiment, the solution can also be used to perform profile verification before allowing a passenger to use a vehicle. In one embodiment, the solution can also be used to allow the vehicle to indicate (visually, in another embodiment, in a language, etc.) the actions that the user needs to perform (which can be pre-recorded) on or from the vehicle and verify the correctness of the actions. In one embodiment, the solution can also be used to provide the vehicle with the ability to determine how to branch the data based on the risk level associated with the data and the driving environment, and distribute the portion of the branch data with a lower risk level to the passenger in a safe driving environment, and later distribute the remaining portion of the branch data with a higher risk level to the passenger after the passenger leaves the vehicle. In one embodiment, the solution can also be used to handle vehicle transfers across borders (such as countries / states / etc.) using blockchains and / or smart contracts, and apply the rules of the new area to the vehicle.

[0086] In one embodiment, the solution can also be used to allow the vehicle to continue to travel outside the boundary when the vehicle reaches a consensus based on the characteristics of the vehicle's operation and the vehicle's passengers. In one embodiment, the solution can also be used to analyze the available data upload / download speed of the vehicle, the size of the file, and the driving speed / direction of the vehicle to determine the distance required to complete the data upload / download and allocate the safe area boundary for performing the data upload / download. In one embodiment, the solution can also be used to perform usually dangerous operations in a safe manner, such as when the system determines that the exit location is approaching and when the vehicle does not seem to be ready to leave the exit (for example, in the wrong lane or when it is driving at a speed that is not conducive to leaving the exit), instruct the subject vehicle and other nearby vehicles so that the subject vehicle can safely leave the exit. In one embodiment, the solution can also be used to use one or more vehicles to verify the judgment of another vehicle, wherein the one or more vehicles and the other vehicle are all in motion.

[0087] In one embodiment, the solution can also be used to detect lane usage at a certain location at a certain time to notify the passengers of the vehicle or guide the vehicle to recommend or not recommend changing lanes. In one embodiment, the solution can also be used to remove the need to send information by email and the need to remove the driver / passenger to respond by email or pay in person. In one embodiment, the solution can also be used to provide services to passengers of the vehicle, wherein the services are provided on a subscription basis and wherein permissions are obtained from other vehicles connected to the passenger profile. In one embodiment, the solution can also be used to record changes in the status of the rental object. In one embodiment, the solution can also be used to seek blockchain consensus from other vehicles close to the damaged vehicle. In one embodiment, the solution can also be used to receive media from a server such as an insurance entity server, from a vehicle computer, which may be related to an accident. The server accesses one or more media files to access the damage of the vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also be used to obtain consensus from multiple devices at different times before an event related to the vehicle to determine the severity of the event.

[0088] In one embodiment, the solution can also be used to solve the problem of insufficient video evidence of vehicle-related accidents. The current solution details that the vehicle involved in the accident queries other vehicles that may be close to the accident for media related to the accident. In one embodiment, the solution can also be used to use vehicles and other devices (such as pedestrians' mobile phones, street light cameras, etc.) to record specific parts of damaged vehicles.

[0089] In one embodiment, the solution can also be used to warn passengers when the vehicle is approaching a dangerous area and / or event, allowing the vehicle to notify passengers or a central controller of potential dangerous areas on or near the current route of travel. In one embodiment, the solution can also be used to detect when the vehicle is traveling at a high speed, and at least another vehicle is used to help the vehicle slow down in a way that minimizes the impact on traffic. In one embodiment, the solution can also be used to identify dangerous driving situations, where media information is captured by the vehicle in the dangerous driving situation. A geo-fence is established based on the distance to the dangerous driving situation, and additional media information is captured by at least one other vehicle within the established geo-fence. In one embodiment, the solution can also be used to send a notification to one or more passengers of the vehicle that the vehicle is approaching a traffic control sign on the road, and if the vehicle crosses this sign, it receives instructions for bad driving from other nearby vehicles. In one embodiment, the solution can also be used to make the vehicle partially inoperable by limiting the speed, limiting the ability to approach another vehicle, limiting the maximum speed, and setting a given number of miles allowed per time period (in some embodiments).

[0090] In one embodiment, the solution can also be used to overcome the need to rely on software updates to correct vehicle problems when the vehicle is not operating correctly. By observing other vehicles on the route, the server receives data from potentially multiple other vehicles and observes unsafe or incorrect operation of the vehicle. Through analysis, these observations can generate notifications to the vehicle when the data indicates that there is unsafe or incorrect operation. In one embodiment, the solution can also be used to provide notifications between vehicles and potentially dangerous situations involving people outside the vehicle. In one embodiment, the solution can also be used to send data to the server through a device associated with the vehicle or the accident or a device close to the accident. Based on the severity of the accident or impending accident, the server notifies the sender of the data. In one embodiment, the solution can also be used to provide suggestions for operating the vehicle to the driver or passenger of the vehicle based on data analysis. In one embodiment, the solution can also be used to establish a geographical fence associated with a physical structure and determine the payment responsibility of the vehicle. In one embodiment, the solution can also be used to coordinate the ability to drop off a vehicle at a location based on the current state of a location and the future state of suggestions for navigating a destination using other vehicles. In one embodiment, the solution may also be used to coordinate capabilities to automatically schedule vehicle returns at locations such as vehicle rental entities.

[0091] In one embodiment, the solution can also be used to move a vehicle to another location based on a user event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user at the end of the original event or the modified event. In one embodiment, the solution can also be used to allow the available locations in the area to be verified by existing vehicles in the area. The approximate time when the location can be vacated can also be determined based on the verification of existing vehicles. In one embodiment, the solution can also be used to move the vehicle to the parking space when there is a nearby parking space available, and the time elapsed after the parking starts is less than the average time of the event. In addition, the vehicle is moved to the final parking space when the event is completed or based on the location of the device associated with at least one passenger of the vehicle. In one embodiment, the solution can also be used to plan parking before congestion arrives. The system interacts with the vehicle to provide some services at a price lower than the full price and / or guide the vehicle to an alternative parking space based on the priority of the vehicle, thereby improving the optimization of parking conditions before arrival.

[0092] In one embodiment, the solution can also be used to sell fractional ownership in a vehicle or determine pricing and availability in a ride-sharing application. In one embodiment, the solution can also be used to provide accurate and timely reporting of dealer sales activity at a scale far beyond what is currently available. In one embodiment, the solution can also be used to allow dealers to request assets through the blockchain. By using the blockchain, consensus is reached before any assets are transferred. In addition, the process is automated and payments can be initiated through the blockchain. In one embodiment, the solution can also be used to arrange agreements with multiple entities (such as service centers) where consensus is obtained and actions (such as diagnostics) are performed. In one embodiment, the solution can also be used to associate digital keys with multiple users. The first user can be the operator of the vehicle and the second user is the responsible party of the vehicle. These keys are authorized by a server where the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be used to determine the services required by the vehicle at the destination. One or more service points are located that are capable of providing the required services, the service points are both located in the area on the route to the destination and have availability to perform the services. The navigation of the vehicle is updated with the determined service points. A smart contract containing the compensation value for the service is identified and the blockchain transaction is stored in the distributed ledger of the transaction.

[0093] In one embodiment, the solution can also be used to connect a service provider vehicle with the profile of the vehicle's passengers to determine the services and goods that may be of interest to the passengers in the vehicle. These services and goods are determined by the passenger's history and / or preferences. The vehicle then receives a quote from the service provider vehicle, and in another embodiment, satisfies the vehicle to provide the service / goods. In one embodiment, the solution can also be used to detect vehicles within range and send service quotes (such as maintenance quotes, product quotes, etc.) to the vehicle. An agreement is reached between the system and the vehicle, and the system selects a service provider to provide the agreement. In one embodiment, the solution can also be used to assign one or more vehicles as road managers, where the road manager assists in traffic control. The road manager can generate road indication signals (such as lights, displays, sounds) to help divert traffic. In one embodiment, the solution can also be used to issue an alert to the driver of the vehicle through a device, where the device can be a traffic light or near an intersection. The alert is issued when an event occurs, such as when the light turns green and the vehicle in front of a column of vehicles does not move.

[0094] Figure 2H 290 is another block diagram showing the interconnections between the different elements in the example 290. A vehicle 276 is shown and includes ECUs 295, 296 and a head unit (also known as an infotainment system) 297. An electrical control unit (ECU) is an automotive electronic embedded system that controls one or more electrical systems or subsystems in a vehicle. An ECU may include, but is not limited to, managing the vehicle's engine, braking system, transmission system, door locks, instrument panel, 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 can also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (e.g., a vehicle computer) 298 can communicate with external elements, such as communicating with a server 293 via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 can contain its own security policy. The security policy defines the permission process that can be executed in the appropriate context. In one embodiment, the security policy can be provided in part or in whole in the vehicle computer 298.

[0095] ECU295, 296 and head unit 297 can each include a custom security function element 299 for defining authorized processes and contexts in which such processes are allowed to run. Context-based authorization determines the validity of a process when it can be executed, keeps the ECU running securely, and prevents unauthorized access to components such as the controller area network (CAN bus) of the vehicle. When an ECU encounters an unauthorized process, the ECU can prevent the process from running. The automotive ECU can use different contexts to determine whether a process is running within its allowed range, such as proximity contexts (such as nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects), operational contexts (such as an indication of whether the vehicle is moving or parked, the current speed of the vehicle, and the transmission status), user-related contexts (such as devices connected to the vehicle via wireless protocols, use of infotainment, cruise control, parking assistance, driving assistance), location-based contexts, and / or other contexts.

[0096] In one embodiment, the solution described and depicted herein can be used to render a vehicle partially inoperable by limiting speed, limiting the ability to approach another vehicle, limiting the maximum speed, and setting a given number of miles allowed per time period (in some embodiments). In one embodiment, the solution can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent to a server via a device associated with the vehicle or an accident or a device close to the accident. Based on the severity of the accident or the proximity of the accident, the server notifies the sender of the data. In one embodiment, the solution can also be used to help the vehicle avoid accidents, such as when the vehicle is involved in an accident, the server queries other vehicles close to the accident. The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one embodiment, the solution can also be used to determine whether the sound emitted by the vehicle is atypical and transmit data related to the sound and the possible source location to the server, where the server can determine the possible cause and avoid potentially dangerous situations. In one embodiment, the solution can also be used to establish a location boundary through the system when the vehicle is involved in an accident. The boundary is determined based on the decibels associated with the accident. Multimedia content of devices within the boundary is obtained to help further understand the accident scene. In one embodiment, the solution can also be used to associate a vehicle with an accident, and then capture media obtained by a device near the accident location. The captured media is saved as a media fragment. The media fragment is sent to another computing device, which creates an audio profile of the accident. This audio profile helps to understand more details about the accident.

[0097] In one embodiment, the solution can also be used to utilize sensors to record audio, video, motion, etc. to record the area where a potential event has occurred, such as if a vehicle (while moving or parked) contacts or may contact another vehicle, the system captures data from sensors that may be located on one or more of the vehicle and / or fixed or moving objects. In one embodiment, the solution can also be used to determine that the vehicle has been compromised by using sensor data to identify a new condition of the vehicle during an event, comparing that condition to the vehicle condition profile, thereby safely and reliably capturing critical data from a vehicle that is about to enter an adverse event.

[0098] In one embodiment, the solution can also be used to warn passengers of a vehicle when the vehicle determines through one or more sensors that it is approaching or traveling along a one-way road in the wrong way. The vehicle has sensors / cameras / maps that interact with the system in the current solution. The system knows the geographic location of the one-way road. For example, the system can notify passengers with sound that "you are approaching a one-way road." In one embodiment, the solution can also be used to allow vehicles to be paid, allowing autonomous vehicle owners to earn money with data collected and stored by their vehicle sensors, encouraging vehicle owners to share their data and provide additional data to entities, through which the performance of future vehicles can be improved, services can be provided to vehicle owners, and so on.

[0099] In one embodiment, the solution may also be used to increase or decrease vehicle features based on the vehicle's actions over a period of time. In one embodiment, the solution may also be used to assign partial ownership of a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine the condition of the vehicle. Partial ownership of the vehicle is determined based on the condition and provides new vehicle responsibilities. In one embodiment, the solution may also be used to provide data to a replacement / upgrade component, wherein the data attempts to destroy an authorized function of the replacement / upgrade component, and in response to the indestructibility of the authorized function, the component allows the use of the authorized function of the replacement / upgrade component.

[0100] In one embodiment, the solution can also be used to provide individuals with the ability to ensure that a passenger is in a vehicle and that the passenger arrives at a specific destination. Further, the system ensures that an authorized driver (if it is a non-autonomous vehicle) and / or other passengers interact with the passenger. In addition, boarding, disembarking, and location are annotated. All of the above is stored on the blockchain in an immutable manner. In one embodiment, the solution can also be used to determine the characteristics of the driver through analysis of driving style and other elements to take action if the driver does not drive in a normal manner, such as the driver's previous driving style under specific conditions, such as daytime, night, rain, snow, etc. Further, the attributes of the vehicle are also taken into account. Attributes include weather, whether the headlights are on, whether navigation is being used, whether the HUD is being used, the volume of media being played, etc. In one embodiment, the solution can also be used to notify passengers in the vehicle of dangerous conditions when objects in the vehicle indicate that the occupants may not be aware of the dangerous situation.

[0101] In one embodiment, the solution can also be used to install a calibration device on a rig fixed to the vehicle, where various sensors on the vehicle can automatically adjust themselves based on the comparison of what the calibration device should detect and the actual detection results. In one embodiment, the solution can also be used to request consensus from multiple service centers using blockchain when a vehicle in need of service sends fault information that allows remote diagnostic functions, where other service centers need to reach a consensus on the severity threshold of the data. Once the consensus is received, the service center can send the fail-safe level to the blockchain for storage. In one embodiment, the solution can also be used to determine the difference between sensor data outside the vehicle and the sensor data of the vehicle itself. The vehicle requests software from the server to correct the problem. In one embodiment, when an event occurs (such as a collision), the solution can also be used to allow vehicles nearby or in the area to pass messages.

[0102] refer to Fig.2I , an operating environment 290A of a connected vehicle according to some embodiments is shown. As shown, a vehicle 276 includes a controller area network (CAN) bus 291A connecting elements 292A-299A in the vehicle. Other elements may be connected to the CAN bus, which is not shown here. The elements shown connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous driving feature or an 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.

[0103] The processor 296A includes an arithmetic logic unit, a microprocessor, a general purpose controller, and / or a similar processor array for performing calculations and providing electronic display signals to the display unit 299A. The processor 296A processes data signals and may include various computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture that implements a combination of instruction sets. The vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) that are communicatively coupled to each other may be used together in the present solution.

[0104] Memory 297A is a non-transient memory that stores instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include codes for executing the technology described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory, or some other memory device. In some embodiments, memory 297A may also include a non-volatile memory or similar permanent storage device and medium, and may include a hard drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other large-capacity storage device for permanent storage of information. A portion of memory 297A may be reserved for use as a buffer or a virtual random access memory (virtual RAM). Vehicle 276 may include one or more memories 297A without departing from the current solution.

[0105] The memory 297A of the vehicle 276 may store one or more of the following types of data: navigation route data 295A and autonomous driving feature data 294A. In some embodiments, the memory 297A stores data that may be required for the navigation application 295A to provide functionality.

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

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

[0108] The sensor group 292A may include any sensor in the vehicle 276 for generating sensor data. For example, the sensor group 292A may include a short-range sensor and a long-range sensor. In some embodiments, the sensor group 292A of the vehicle 276 may include one or more of the following vehicle sensors: a camera, a LIDAR sensor, an ultrasonic sensor, a car engine sensor, a radar sensor, a laser altimeter, an intake pressure sensor, an infrared detector, a motion detector, a thermostat, an acoustic detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, an air mass flow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timer, an air-fuel ratio meter, a blind spot meter, a curb detector, a defect detector, a Hall effect sensor, a parking sensor, a radar gun, a speedometer, a speed sensor, a tire-pressure monitoring sensor, a torque sensor, a transmission oil temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a water sensor, a wheel speed sensor, a GPS sensor, a mapping function, and any other type of car sensor. The navigation system 295A may store the sensor data in the memory 297A.

[0109] Communication unit 298A sends or receives data to or from network 292 or 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 vehicle 276 a DSRC-equipped device.

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

[0111] In one embodiment, the solution described and depicted herein may be used to manage emergency situations and vehicle features when it is determined that the vehicle enters an area without network access. In one embodiment, the solution may also be used to manage and provide features (e.g., audio, video, navigation, etc.) in the vehicle without a network connection. In one embodiment, the solution may also be used to determine when a profile of a person in proximity to the vehicle matches a profile attribute of a profile of at least one passenger in the vehicle. A notification is sent from the vehicle to establish communication.

[0112] In one embodiment, the solution may also be used to analyze the presence of passengers in each vehicle that may be used for voice communication based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one embodiment, the solution may also be used to determine two risk levels of a road being blocked, and receive a gesture that may indicate a warning that the blockage has not risen above a threshold so that the vehicle can continue along the road. In one embodiment, the solution may also be used to delete sensitive data from a vehicle when the vehicle has been damaged and cannot be used.

[0113] In one embodiment, the solution can also be used to verify that the customer data to be deleted has indeed been deleted from all necessary locations within the enterprise, demonstrating GDPR compliance. In one embodiment, the solution can also be used to consider exchanging data related to safety, important notifications, etc. with another vehicle to enhance the autonomous driving capabilities of lower-level autonomous vehicles. In one embodiment, the solution can also be used to provide the vehicle with the ability to receive data based on a first biometric associated with a passenger. The vehicle then decrypts the encrypted data based on the verification of a second biometric, where the second biometric is a continuation of the first biometric. The vehicle provides the decrypted data to the passenger when only the passenger can receive the decrypted data, deletes the sensitive portion of the decrypted data when the sensitive portion is provided, and deletes the non-sensitive portion after a time period associated with the biometric. In one embodiment, the solution can also be used to provide the vehicle with the ability to verify a person based on weight and grip on the steering wheel of the vehicle. In one embodiment, the solution can also be used to provide the car with features that exist but are not currently enabled to be presented to the car passengers, which reflect the characteristics of the passenger.

[0114] In one embodiment, the solution may also be used to allow modification of a vehicle, particularly the interior of the vehicle, but also the exterior of the vehicle, to reflect or assist at least one passenger in one embodiment. In another embodiment, reproducing the work and / or home environment of a passenger is disclosed. If the system determines that the user is in "work mode" or "home mode", the system may attempt to "reproduce" the user's work / home environment while the user is in the vehicle. All data related to the interior and exterior of the vehicle and the various passengers using the vehicle are stored on the blockchain and executed by smart contracts. In one embodiment, the solution may also be used to detect passenger gestures to help communicate with nearby vehicles, where the vehicle may operate accordingly. In one embodiment, the solution may also be used to provide vehicles with the ability to detect expected gestures using a gesture definition data store. In one embodiment, the solution may also be used to provide vehicles with the ability to take various actions based on the gait and gestures of passengers. In one embodiment, the solution may also be used to ensure that the driver of a vehicle currently engaged in various operations (e.g., voice navigation while driving, etc.) has not exceeded the number of unsafe operations before being allowed to operate gestures.

[0115] In one embodiment, the solution can also be used to assign a status to each passenger in the vehicle and verify the gesture of the passenger based on the passenger's status. In one embodiment, the solution can also be used to collect sound details related to the collision (at what position, in what direction, raised or lowered, from what device, data related to the device, such as type, manufacturer, owner, and the number of sounds emitted at the same time, the time when the sound was emitted, etc.), and provide it to the system, where data analysis helps to determine the details about the collision. In one embodiment, the solution can also be used to determine that the vehicle operation is unsafe. The vehicle includes multiple components that control the vehicle through interoperation, and each component is associated with a separate component key. The encryption key is sent to the vehicle to reduce the vehicle function. In response to receiving the encryption key, the vehicle disables one or more component keys. Disabling one or more component keys results in one or more of the following operations: limiting the vehicle to move at no more than a given speed, limiting the distance between the vehicle and another vehicle to no less than a certain distance, and limiting the vehicle to travel no more than a threshold distance.

[0116] In one embodiment, the solution can also be used to provide instructions from a specific vehicle (that will vacate a spot) to another specific vehicle (that wants to take the spot), with blockchain used to perform authentication and coordination. In one embodiment, the solution can also be used to determine partial responsibility for vehicles. For example, in the case of multiple people owning a single vehicle, the use of the vehicle (which may change over time) is used by the system to update partial ownership. Other embodiments will be included in the application, including minimum ownership of vehicles based not on the use of the vehicle, but based on the following: availability of the vehicle, determination of the driver of the vehicle, and others.

[0117] In one embodiment, the solution can also be used to allow users within the vehicle to share their subscription services with small groups such as family or friends. For example, a user may want to share membership, and if so, the associated transaction will be stored in the blockchain or traditional database. When a user who is not a primary subscriber requests subscription materials, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared a profile. In one embodiment, the solution can also be used to allow people to use auxiliary vehicles to reach a predetermined destination. Auxiliary vehicles are determined using a functional relationship value (e.g., a value representing various parameters and their importance in determining what type of vehicle to use). In one embodiment, these solutions can also be used to allow passengers who have been in an accident to continue to their original destination using other vehicles.

[0118] In one embodiment, the solution can also be used to propagate software / firmware uploads to vehicles of a first subgroup. This first group of vehicles tests the update, and when the test is successful, propagates the update to another group of vehicles. In one embodiment, the solution can also be used to propagate software / firmware updates from the main vehicle to the vehicle, where the update propagates through the network of vehicles from the first subgroup, followed by a larger subgroup, and so on. A portion of the update can be sent first, and then the rest can be sent from the same vehicle or another vehicle. In one embodiment, the solution can also be used to provide updates to the vehicle computer to the devices of the vehicle and the vehicle operator / passenger. The update may be authorized by all drivers and / or all passengers. Provide software updates to vehicles and devices. The user does not need to do anything, as long as he approaches the vehicle, the function will be completed automatically. Send a notification to the device indicating that the software update has been completed. In one embodiment, the solution can also be used to verify that the OTA software update is performed by a qualified technician, and one or more vehicle components generate status related to the following: the initiator of the verification code, the program for wirelessly receiving the software update, the information contained in the software update, and the verification result.

[0119] In one embodiment, the solution can also be used to provide the ability to parse software updates located in the first component through the second component. Then verify the critical update content of the first part and the non-critical update content of the second part, assign the verified first part to a process in the vehicle, which runs the verified first part for a period of time, responds to a positive result based on the time period, and runs the verified first part again with other processes after a period of time. In one embodiment, the solution can also be used to provide passengers with service selection, where the service is based on the passenger profile of the vehicle and the profile shared with the passenger profile. In one embodiment, the solution can also be used to store user profile data in the blockchain and intelligently display offers and recommendations to users based on the user's automatically collected purchase history and preferences obtained from the user profile on the blockchain.

[0120] Figure 3A A flowchart 300 is shown according to an example embodiment. Figure 3A , the processor may perform one or more of the following: determining that an energy transfer condition exists along a route (302); based on the energy transfer condition exceeding an energy transfer value and based on one or more traffic conditions, traveling to a location on the route (304); aligning a position of a vehicle at the location to wirelessly receive an energy transfer (306); and receiving the energy transfer while the vehicle is moving (308).

[0121] Figure 3B A flowchart 320 is shown according to an example embodiment. Figure 3B , the processor may perform one or more of the following: determining one or more traffic conditions along the route, determining a vehicle location and one or more additional vehicle locations, and determining that one or more traffic conditions and vehicle locations will satisfy an energy transfer condition (322); identifying the location of one or more additional vehicles while in motion, and changing the location of the vehicle to be within a distance of the one or more additional vehicles (324); receiving a portion of the energy transfer at a first location of the vehicle body within a first time period, and receiving another portion of the energy transfer at a second location of the vehicle body within a second time period to complete the energy transfer (326); determining an estimated amount of time based on the one or more traffic conditions, wherein the vehicle and the one or more additional vehicles will be optimally aligned while in motion during the energy transfer, and determining that an energy transfer condition exists based on the estimated amount of time (328).

[0122] Figure 3C Still another flow chart 340 is shown according to an example embodiment. Figure 3C, the processor may perform one or more of the following operations: receiving verification of the energy transfer from at least one component, wherein the verification includes a blockchain consensus between a peer group consisting of the vehicle and the at least one component (342); and executing a smart contract to record the energy transfer event and the at least one component on a blockchain based on the blockchain consensus (344).

[0123] Figure 4 A machine learning vehicle network diagram 400 is shown according to an example embodiment. The network 400 includes a vehicle node 402 that interfaces with a machine learning subsystem 406. The vehicle node includes one or more sensors 404.

[0124] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by the machine learning training system 410 that generates predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 is in the vehicle node 402. In other embodiments, the machine learning subsystem 406 is outside the vehicle node 402.

[0125] The vehicle node 402 sends data from one or more sensors 404 to a machine learning subsystem 406. The machine learning subsystem 406 provides the one or more sensor 404 data to a learning model 408, which returns one or more predictions. The machine learning subsystem 406 sends one or more instructions to the vehicle node 402 based on the predictions from the learning model 408.

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

[0127] Figure 5A An example vehicle configuration 500 for managing database transactions associated with a vehicle is shown according to an example embodiment. Figure 5A, when a particular vehicle / vehicle 525 engages in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle may receive assets 510 and / or write off / transfer assets 512 in accordance with the transaction. A vehicle processor 526 is in the vehicle 525, and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The transaction module 520 may record information such as assets, parties, points, service descriptions, dates, times, locations, results, notifications, incidents, etc. Those transactions in the transaction module 520 may be replicated in the database 530. The database 530 may be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on or off the vehicle, or directly accessible and / or accessible over a network, or accessible by the vehicle.

[0128] Figure 5B An example vehicle configuration 550 for managing database transactions between vehicles according to an example embodiment is shown. When a vehicle enters a state where a service needs to be shared with another vehicle, a vehicle 525 can engage with another vehicle 508 to perform various actions, such as sharing, transferring, obtaining a service call, etc. For example, vehicle 508 may need to charge the battery and / or may have a tire problem, and may be on the way to pick up a package for delivery. The vehicle processor 528 is in the vehicle 508, and there is communication between the vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 can notify another vehicle 525 that is in its network and running on its blockchain member service. The vehicle processor 526 is in the vehicle 525, and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The vehicle 525 can then request to receive information through wireless communication to perform a package pickup from the vehicle 508 and / or a server (not shown). The transaction is recorded in the transaction modules 552 and 520 of the two vehicles respectively. The points are transferred from vehicle 508 to vehicle 525, and a record of the transfer service is recorded in database 530 / 554 if the blockchains are different from each other, otherwise recorded in the same blockchain common to all members. Database 554 can be one of a SQL database, RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and can be on the vehicle, can be off the vehicle, can be directly accessible and / or can be accessed through a network.

[0129] Fig. 6A A blockchain architecture configuration 600 is shown according to an example embodiment. Fig. 6A, the blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, a permissioned blockchain is not accessible to all parties, but only to those members who are allowed to access blockchain data. Blockchain nodes participate in multiple activities, such as blockchain entry addition and verification processes (consensus). One or more blockchain nodes can endorse entries based on endorsement policies and can provide ordering services for all blockchain nodes. Blockchain nodes can initiate blockchain actions (such as authentication) and seek to write to the blockchain immutable ledger stored in the blockchain, and its ledger copy can also be stored on the underlying physical infrastructure.

[0130] Blockchain transactions 620 are stored in the computer's memory as transactions received and reviewed by the consensus model specified by the member nodes. Reviewed transactions 626 are stored in the current block of the blockchain and submitted to the blockchain through a submission procedure, which includes performing a hash operation on the data content of the transaction in the current block and making a previous hash reference to the previous block. Within the blockchain, there may be one or more smart contracts 630 that define the terms of the transaction agreement and actions contained in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, what service functions they are entitled to / need to obtain based on the profile of the requesting entity, and whether to monitor their behavior in subsequent events. For example, when a service event occurs and a user is riding in a vehicle, sensor data monitoring can be triggered, and a parameter (such as the vehicle charge level) can be identified as being above / below a specific threshold during a specific time period, so that the result may be a change in the current state, which requires sending an alert to the management party (i.e., the vehicle owner, vehicle operator, server, etc.) to identify and store the service for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle status. Sensor data may also be the basis for vehicle event data 634, such as where to travel, average speed, maximum speed, acceleration, whether there was a collision, whether the intended route was taken, where the next destination is, whether safety measures are in place, whether the vehicle has enough power / fuel, etc. All of this information can be used as the basis for smart contract 630 clauses and stored in the blockchain. For example, sensor thresholds stored in a smart contract can be used as the basis for determining whether a detected service is necessary, when and where to perform the service.

[0131] Figure 6B A shared ledger configuration according to an example embodiment is shown. Figure 6B, the blockchain logic example 640 includes a blockchain application program interface 642 as an API or plug-in application that is linked to a computing device and execution platform for a specific transaction. The blockchain configuration 640 may include one or more applications that are linked to an 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 based on the customized configuration sought by the participants, can maintain its own state, control its own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes by attaching to the distributed ledger.

[0132] Smart contract application code 644 provides the basis for blockchain transactions by establishing application code that, when executed, validates the terms and conditions of the transaction. When smart contracts 630 are executed, certain approved transactions 626 are generated and then forwarded to the blockchain platform 652. The platform includes security / authorization 658, a computing device 656 that performs transaction management, and a storage portion 654 that acts as a memory for storing transactions and smart contracts in the blockchain.

[0133] The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that can be used to receive and store new entries and be accessed by auditors seeking access to data entries. The blockchain may expose interfaces that provide access to the virtual execution environment necessary to process program code and use the physical infrastructure. Cryptographic trust services may be used to verify entries (e.g., asset exchange entries) and keep the information private.

[0134] Fig. 6A and 6B The blockchain architecture configuration can process and execute program / application code through one or more interfaces exposed by the blockchain platform and the services it provides. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications that are subject to modification or update, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and ledger usage. For example, the information may include a new entry, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results may include rejection or approval of the new entry based on the criteria defined in the smart contract and / or the consensus decision of the peers. The physical infrastructure can be used to retrieve any data or information described herein.

[0135] In smart contract executable code, smart contracts can be created by high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated with a blockchain (e.g., a distributed network of blockchain peers). An entry is an execution of the smart contract code, which can be executed in response to the satisfaction of a condition associated with the smart contract. The execution of a smart contract can trigger a trusted modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

[0136] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and maintained as private information. Temporary data used / generated by smart contracts is saved in memory by the provided execution environment and deleted once the data required by the blockchain is identified.

[0137] The smart contract executable code may include a code interpretation of the smart contract with additional features. As described herein, the smart contract executable code may be a program code deployed on a computing network that is executed and verified together by a chain validator during a consensus process. The smart contract executable code receives a hash and retrieves a hash value associated with a data template created using a previously stored feature extractor from the blockchain. If the hash value of the hashed identifier matches the hash value created from the stored identifier template data, the smart contract executable code sends an authorization key to the requested service. The smart contract executable code may write data associated with encryption details into the blockchain.

[0138] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown. Figure 6C, an example configuration 660 provides for a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server may, on behalf of a service provider entity, query a vehicle service provider to share user profile rating information in the event that an established known user profile attempts to rent a vehicle with an existing rating profile. The server 666 may be receiving and processing data related to service requirements for the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for refueling / charging, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, sensor information collection, etc., which may be used to invoke a vehicle service event. Blockchain transaction data 670 is saved for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. Transactions may include the parties involved, requirements (e.g., age 18 or older, qualified candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients allowed access to the event and managed vehicle services, rights / permissions, sensor data retrieved during vehicle event operations to record details of the next service event and identify vehicle status, and thresholds used to determine whether the service event is completed and whether the vehicle status has changed.

[0139] Fig.6D A blockchain block 680 that may be added to a distributed ledger is shown, along with the contents of block structures 682A through 682n, according to an example embodiment. Fig.6D , clients (not shown) can submit entries to blockchain nodes to perform activities on the blockchain. For example, a client can be an application that proposes entries to a blockchain on behalf of a requester (e.g., a device, person, or entity). Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of a blockchain network and a copy of the distributed ledger. There may be different types of blockchain nodes / peers in a blockchain network, including endorsing peers that simulate and endorse entries proposed by clients, and committing peers that verify endorsements, validate entries, and commit entries to the distributed ledger. In this example, a blockchain node can act as an endorsing node, a committing node, or both.

[0140] The live system consists of 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. There may be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel it belongs to. The live blockchain is a log of entries, structured as hash-linked blocks, each containing a sequence of N entries. Blocks can include various components, such as Fig.6DThe components shown in . The link of the block can be generated by adding the hash of the previous block header in the block header of the current block. In this way, all entries on the blockchain can be arranged in sequence and cryptographically linked together, preventing tampering of the blockchain data without breaking the hash link. In addition, due to the linked structure, the latest block in the blockchain represents every entry that came before it. The live blockchain can be stored on a peer-to-peer file system (local or attached storage device), which supports append-only blockchain workloads.

[0141] The current state of the blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest values ​​of all keys contained in the blockchain's chain entry log. Smart contract executable code calls execute entries against the current state in the state database. In order to make these smart contract executable code interactions extremely efficient, the latest values ​​of all keys are stored in the state database. The state database may include an indexed view into the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored at peer startup (or generated when needed) before accepting an entry.

[0142] An endorsing peer receives an entry from a client and endorses the entry based on the simulation results. An endorsing peer holds a smart contract, which simulates an entry proposal. When an endorsing peer endorses an entry, the endorsing peer creates an entry endorsement, which is a signed response from the endorsing peer to the client application indicating the endorsement of the simulated entry. The method of endorsing an entry depends on the endorsement policy specified in the smart contract executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry". Different channels can have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0143] The sorting service accepts endorsed entries, sorts them into blocks, and transmits those blocks to committing peers. For example, the sorting service can start a new block when an entry threshold is reached, a timer times out, or other conditions. In this example, the blockchain node is a committing peer that has received data block 682A to be stored on the blockchain. The sorting service may consist of a cluster of sorting nodes. The sorting service does not handle entries, smart contracts, or maintain a shared ledger. Instead, the sorting 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 the specific implementation of "sorting" (such as Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0144] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems where ordering is achieved by solving cryptographic puzzles, in this example, each participant in the distributed ledger can choose the ordering mechanism that best suits the network.

[0145] refer to Fig.6D , a block 682A (also referred to as a data block) stored on a 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 block 682A and its contents, are for example purposes only and are not meant to limit the scope of the example embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A storing the entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within the block data 690A to 690n. Block 682A may also include a link to a previous block (e.g., on a blockchain) within the block header 684A. In particular, the block header 684A may include a hash value of a previous block header. The block header 684A may also include a unique block number, a hash value of the block data 690A of the current block 682A, etc. The block number of the block 682A may be unique and assigned in an increasing / sequential order starting from zero. The first block in the blockchain may be called a genesis block, including information related to the blockchain, blockchain members, and data stored therein, etc.

[0146] Block data 690A may store entry information for each entry recorded in the block. For example, the entry data may include one or more of the following: entry type, version, timestamp, channel ID of the distributed ledger, entry ID, epoch, payload visibility, smart contract executable code path (deployment transaction tx), smart contract executable code name, smart contract executable code version, input (smart contract executable code and function), client (creator) identity such as public key and certificate, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (key and version list read by the entry, etc.), write set (key and value list, etc.), start key, end key, key list, Merkle tree query summary, etc. Entry data may be stored for each of the N entries.

[0147] In some embodiments, the block data 690A may also store transaction-specific data 686A, which adds additional information to the chain of hash links of blocks in the blockchain. Thus, the data 686A may be stored in an immutable log of the block on the distributed ledger. Some benefits of storing such data 686A are embodied in various embodiments disclosed and described herein. The block metadata 688A may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature when the block was created, a reference to the last configured block, an entry filter that identifies valid and invalid entries within the block, the last offset of the sorting service that sorts the block, etc. The signature, the last configured block, and the sorting node metadata may be added by the sorting service. At the same time, the submitter of the block (e.g., a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The entry filter may include a byte array of size equal to the number of entries in the block data 610A and a verification code that identifies whether the entry is valid / invalid.

[0148] The other blocks 682B to 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the block headers 684A to 684n in the other blocks includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may be only the hash of the previous block header, or it may be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, it is possible to trace back from the Nth block to the genesis block (and the associated original file) block by block, as shown by arrow 692, to establish an auditable and immutable chain of custody.

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

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

[0151] Figure 7 It is not intended to suggest any limitation as to the scope of use or functionality of the described embodiments of the application. Regardless, computing node 700 is capable of implementing and / or performing any of the functions set forth above.

[0152] In computing node 700 there is a computer system / server 702, which can operate with numerous other general or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or notebook devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, and the like.

[0153] Computer system / server 702 may be described in the general context of computer system executable instructions (e.g., program modules) executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media including memory storage devices.

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

[0155] Bus refers to any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0156] The computer system / server 702 typically includes various computer system readable media. Such media can be any available media accessible to the computer system / server 702, and it includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 706 implements the flowcharts of other figures. The 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. The computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the memory 706 may be used to read from and write to a non-removable, non-volatile magnetic medium (not shown, commonly referred to as a "hard drive"). Although not shown, a disk drive for reading and writing a removable non-volatile disk (such as a "floppy disk"), and an optical drive for reading or writing a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In this case, each may be connected to the bus via one or more data media interfaces. As further depicted and described below, the memory 706 may include at least one program product having a set (eg, at least one) of program modules for executing the functions of various embodiments of the present application.

[0157] As an example and not limitation, a program / utility having a set (at least one) of program modules, as well as an operating system, one or more application programs, other program modules, and program data may be stored in memory 706. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a networking environment. The program modules generally perform the functions and / or methods of the various embodiments of the present application as described herein.

[0158] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as systems, methods, or computer program products. Accordingly, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, which may all be generally referred to herein as "circuits," "modules," or "systems." In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0159] The computer system / server 702 may also communicate with one or more external devices through an I / O device 712 (e.g., an I / O adapter), which may include a keyboard, a pointing device, a display, a voice recognition module, etc., one or more devices that enable 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 card, a modem, etc.). Communication may be achieved through the I / O interface of the device 712. Moreover, the computer system / server 702 may communicate with one or more networks through a network adapter, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet). As shown, the device 712 communicates with other components of the computer system / server 702 through a bus. It should be understood that, although not shown, other hardware and / or software components may be used 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.

[0160] Although the example embodiments of at least one of the systems, methods, and non-transient computer-readable media have been shown in the drawings and described in detail above, it should be understood that the present application is not limited to the various embodiments disclosed, but is capable of various rearrangements, modifications, and substitutions as described and defined in the appended claims. For example, the functions of the systems of the various drawings may be performed by one or more modules or components described herein, or may be performed in a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by a single module may be performed by one or more of these modules. Further, the functions described herein may be performed at different times and in relation to various events inside or outside the modules or components. In addition, the information sent between the modules may be transmitted between the modules by at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or by a variety of protocols. Moreover, the messages sent or received by any module may be sent or received directly and / or sent or received by one or more other modules.

[0161] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a smart phone, 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 the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0162] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically highlight their implementation independence. For example, a module can be implemented as a hardware circuit that includes a custom very large scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor, or other discrete components. A module can also be implemented as a programmable hardware device, such as a field programmable gate array, a programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0163] Modules may also be implemented at least in part in software for execution by various types of processors. An identified executable code unit may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be assembled into an object, a procedure, or a function. However, the executable files of the identified modules need not be physically placed together, but may include different instructions stored in different locations; when logically connected together, these instructions comprise the module and achieve the stated purpose of the module. In addition, the module may be stored on a computer-readable medium, which may, for example, be a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

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

[0165] It is easy to understand that the components of the present application as generally described and illustrated in the drawings herein 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 only represents selected embodiments of the present application.

[0166] Those skilled in the art will readily appreciate that the above content may be practiced with steps in different orders and / or with hardware elements having configurations different from those disclosed. Therefore, although the present application has been described based on these preferred embodiments, some modifications, variations, and alternative configurations are apparent to those skilled in the art.

[0167] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and the scope of the present application should be defined by the appended claims, taking into account all equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method, include: determining an estimated amount of time that the vehicle and a plurality of additional vehicles will be optimally aligned while moving along a route to perform energy transfer from the plurality of vehicles to the vehicle based on current or future traffic volume on the route; causing the vehicle to travel on the route at a particular speed for an estimated amount of time; receiving, for a first time period in the estimated amount of time, a first portion of the energy transfer from a first vehicle of a plurality of vehicles while the vehicle is in motion; receiving a control command from one of the plurality of vehicles to control a position and a speed of the vehicle while the vehicle is receiving the first portion of the energy transfer; changing a position of the vehicle along the road based on the control command after receiving the first portion of the energy transfer and before receiving the second portion of the energy transfer; and A second portion of the energy transfer is received from a second vehicle of the plurality of vehicles for a second period of the estimated amount of time.

2. The method according to claim 1, include: Identifying the positions of multiple vehicles in motion; as well as The position of the vehicle is changed to be within a range of one of the plurality of vehicles.

3. The method according to claim 1, include: receiving a first portion of the energy transfer at a first location on the vehicle body during a first time period; as well as A second portion of the energy transfer is received at a second location on the vehicle body during a second time period to complete the energy transfer.

4. The method of claim 1 , comprising receiving, by the vehicle, verification of the energy transfer from at least one component, wherein the verification comprises a blockchain consensus among a peer group consisting of the vehicle and the at least one component.

5. The method of claim 4, comprising executing a smart contract by the vehicle to record the verification on a blockchain based on the blockchain consensus.

6. A means of transportation, include: A processor, the processor being configured to: determining an estimated amount of time that the vehicle and a plurality of additional vehicles will be optimally aligned while moving along a route to perform energy transfer from the plurality of vehicles to the vehicle based on current or future traffic volume on the route; causing the vehicle to travel on the route at a particular speed for an estimated amount of time; receiving, for a first time period in the estimated amount of time, a first portion of the energy transfer from a first vehicle of a plurality of vehicles while the vehicle is in motion; receiving a control command from one of the plurality of vehicles to control a position and a speed of the vehicle while the vehicle is receiving the first portion of the energy transfer; changing a position of the vehicle along the road based on the control command after receiving the first portion of the energy transfer and before receiving the second portion of the energy transfer; and A second portion of the energy transfer is received from a second vehicle of the plurality of vehicles for a second period of the estimated amount of time.

7. The vehicle of claim 6, wherein the processor is further configured to: identifying the positions of multiple vehicles in motion; and The position of the vehicle is changed to be within the range of the plurality of vehicles.

8. The vehicle of claim 6, wherein the processor is further configured to: receiving a portion of the energy transfer at a first location on the vehicle body during a first time period; and During a second time period, another portion of the energy transfer is received at a second location on the vehicle body to complete the energy transfer.

9. The vehicle of claim 6, wherein the processor is further configured to: Verification of the energy transfer is received from at least one component, wherein the verification comprises a blockchain consensus among a peer group consisting of the vehicle and the at least one component.

10. The vehicle of claim 9, wherein the processor is further configured to: A smart contract is executed by the vehicle to record the verification on a blockchain based on the blockchain consensus.

11. A non-transitory computer-readable storage medium configured to store instructions that, when executed, cause a processor to perform the operations of the method according to any one of claims 1 to 5.

Images