1. A method, comprising:

before at least one vehicle of a group of identified vehicles is connected to a charging station, the at least one vehicle is wirelessly notified via the charging station of a required amount of energy stored in the at least one vehicle.

2. The method of claim 1, comprising: providing a location of a charging station to the at least one vehicle when at least one of:

the charging station wirelessly informing the at least one vehicle of the required amount of energy; and

the at least one vehicle confirms that the required amount of energy can be provided to the charging station.

3. The method of claim 1, comprising: wirelessly notifying at least one other vehicle of the group of identified vehicles of a required amount of energy stored in the at least one other vehicle via the charging station before the at least one vehicle is connected to the charging station.

4. The method of claim 1, comprising: wirelessly informing the at least one vehicle via a charging station of a required amount of energy stored in the at least one vehicle based on the amount of energy stored in the at least one vehicle and a time of arrival of the at least one vehicle at the charging station.

5. The method of claim 1, comprising performing at least one of:

querying the at least one vehicle for an amount of energy stored in the at least one vehicle via a charging station; and

providing the amount of energy stored in the at least one vehicle to a charging station via the at least one vehicle.

6. The method of claim 1, comprising identifying, via the charging station, the set of identified vehicles based on: a distance, a speed, a direction, an amount of energy stored in each vehicle of the set of identified vehicles, an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station, and an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station and is capable of providing energy to the charging station.

7. The method of claim 1, comprising: wirelessly notifying the at least one vehicle of the set of identified vehicles of an amount of energy required by an energy-depleting vehicle and a location of the energy-depleting vehicle via a charging station, wherein the energy-depleting vehicle is not part of the set of identified vehicles.

8. A system, comprising:

a charging station configured to wirelessly notify at least one vehicle of a set of identified vehicles of a required amount of energy stored in the at least one vehicle before the at least one vehicle is connected to the charging station.

9. The system of claim 8, wherein the location of the charging station is provided to the at least one vehicle when at least one of:

the charging station wirelessly informing the at least one vehicle of the required amount of energy; and

the at least one vehicle confirms that the required amount of energy can be provided to the charging station.

10. The system of claim 8, wherein the charging station is configured to wirelessly notify at least one other vehicle in the set of identified vehicles of a desired amount of energy stored in the at least one other vehicle before the at least one vehicle is connected to the charging station.

11. The system of claim 8, wherein the charging station is configured to wirelessly notify the at least one vehicle of the required amount of energy stored in the at least one vehicle based on the amount of energy stored in the at least one vehicle and a time of arrival of the at least one vehicle at the charging station.

12. The system of claim 8, wherein the charging station is configured to perform at least one of:

querying the at least one vehicle for an amount of energy stored in the at least one vehicle via a charging station; and

providing the amount of energy stored in the at least one vehicle to a charging station via the at least one vehicle.

13. The system of claim 8, wherein the charging station is configured to identify the set of identified vehicles based on: a distance, a speed, a direction, an amount of energy stored in each vehicle of the set of identified vehicles, an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station, and an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station and is capable of providing energy to the charging station.

14. The system of claim 8, wherein the charging station is configured to: wirelessly notifying the at least one vehicle of the set of identified vehicles of an amount of energy required by an energy-depleting vehicle and a location of the energy-depleting vehicle.

15. A non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform the method of any one of claims 1-7.

Background

Currently, charging stations provide power from a power supply to an electric vehicle. Charging stations have little intelligence and communicate with the vehicle through a wired connection to obtain information strictly related to delivering power to the vehicle battery.

Thus, what is sought is a charging station that wirelessly communicates with a vehicle to perform additional and/or different roles as wireless communicators in connection with the delivery of power from the vehicle to the charging station.

Disclosure of Invention

One example embodiment provides a method comprising one or more of: before at least one vehicle of a group of identified vehicles is connected to a charging station, the at least one vehicle is wirelessly notified via the charging station of a required amount of energy stored in the at least one vehicle.

Another example embodiment provides a system comprising a charging station configured to perform one or more of the following: wirelessly notifying at least one vehicle of a set of identified vehicles of a required amount of energy stored in the at least one vehicle before the at least one vehicle is connected to a charging station.

Another example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: before at least one vehicle of a group of identified vehicles is connected to a charging station, the at least one vehicle is wirelessly notified via the charging station of a required amount of energy stored in the at least one vehicle.

Drawings

Fig. 1A illustrates a first example power return notification system overview, according to an example embodiment.

Fig. 1B illustrates a second example power return notification system overview, according to an example embodiment.

FIG. 1C illustrates an example vehicle-to-vehicle power transmission notification prior to transmission, according to an example embodiment.

FIG. 1D illustrates an example vehicle-to-vehicle power transmission notification during transmission, according to an example embodiment.

FIG. 2A illustrates a vehicle network diagram according to an example embodiment.

FIG. 2B illustrates another vehicle network diagram in accordance with an example embodiment.

Fig. 2C illustrates yet another vehicle network diagram in accordance with an example embodiment.

Fig. 3A illustrates a first flowchart in accordance with an example embodiment.

Fig. 4 illustrates a machine learning vehicle network diagram according to an example embodiment.

FIG. 5A illustrates an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

FIG. 5B illustrates another example vehicle configuration for managing database transactions conducted between various vehicles, according to an example embodiment.

Fig. 6A illustrates a blockchain architecture configuration in accordance with an example embodiment.

Fig. 6B illustrates another blockchain configuration in accordance with an example embodiment.

Fig. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment.

Fig. 6D illustrates an example data chunk, according to an example embodiment.

FIG. 7 illustrates an example system that supports one or more of the example embodiments.

Detailed Description

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

The features, structures, or characteristics as described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, use of the phrase "example embodiment," "some embodiments," or other similar language throughout at least this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in one embodiment. Thus, appearances of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the figures, any connection between elements may allow for unidirectional and/or bidirectional communication, even if the connections depicted are unidirectional or bidirectional arrows. In the present solution, the transportation means may comprise one or more of a vehicle, a car, a truck, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that may be used to transport people and/or goods from one location to another.

Further, although the term "message" may have been used in the description of the embodiments, the present application may be applied to many types of network data, such as packets, frames, datagrams, and the like. The term "message" also includes packets, frames, datagrams and any equivalent thereof. Further, while certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to a certain type of message, and the application is not limited to a certain type of signaling.

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

Within the communication infrastructure, a decentralized database is a distributed storage system comprising a plurality of nodes in communication with each other. Blockchains are examples of decentralized databases that include an attached-only immutable data structure (i.e., a distributed ledger) that can maintain records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record and any single peer cannot modify the database record without reaching consensus among the distributed peers. For example, peers may perform a consensus protocol to verify blockchain storage entries, group storage entries into chunks, and build hash chains via these chunks. For consistency, the process forms a ledger by ordering store entries as needed. In a public or license-free blockchain, any party can participate without a specific identity. The common blockchain may involve cryptocurrency and use consensus based on various protocols, such as proof of work (PoW). On the other hand, licensed blockchain databases provide a system that can protect interactions between a group of entities (such as businesses that exchange funds, goods, information, etc.) that share a common goal but do not fully trust or cannot fully trust each other. The present application may operate in a licensed and/or unlicensed blockchain setting.

Smart contracts are trusted distributed applications that utilize the tamper-resistant properties of a shared or distributed ledger (i.e., possibly in the form of a blockchain) database and underlying protocols between member nodes called endorsement or endorsement policies. In general, blockchain entries are "endorsed" prior to submission to the blockchain, while entries that are not endorsed are ignored. Typical endorsement policies allow intelligent contract executables to specify an endorser for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified in the endorsement policy, the entry is enforced to validate the entry. After validation, the entry enters an ordering stage in which a consensus protocol is used to generate an ordered sequence of endorsement entries grouped into blocks.

A node is a communication entity of the blockchain system. A "node" may perform a logical function in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. The nodes may comprise different types, such as client or submitting client nodes that submit an entry call to an endorser (e.g., a peer) and broadcast an entry suggestion to a ranking service (e.g., a ranking node). Another type of node is a peer node that can receive client-submitted entries, submit entries, and maintain a state and copy of the blockchain purpose ledger. The peer may also have the role of an endorser, but this is not essential. A sequencing service node or sequencer is a node that runs communication services for all nodes and that implements delivery guarantees such as broadcasts to each peer node in the system when submitting entries and modifying the world state of the blockchain (which is another name for the original blockchain purpose, the original blockchain entry typically contains control and setup information).

The ledger is an ordered, tamper-resistant record of all state transitions of the blockchain. State transitions may be caused by intelligent contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, sequencing nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being submitted to a ledger as one or more operands, such as create, update, delete, and the like. The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel it is a member of.

A chain is a log of entries constructed as a hash of linked chunks, and each chunk contains a sequence of N entries, where N is equal to or greater than 1. The chunk header includes a hash of the chunk entry, as well as a hash of the previous chunk header. In this manner, all entries on the ledger can be sorted and linked together by a password. Thus, it is not possible to tamper with the ledger data without destroying the hash link. The hash of the most recently added blockchain chunk represents each entry on the chain that comes before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chains may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.) to efficiently support the only additional nature of the blockchain workload.

The current state of the immutable ledger represents the most recent values of all keys contained in the chain entry log. Because the current state represents the latest key value known to the channel, it is sometimes referred to as the world state. The smart contract executable code calls an execution entry for the current state data of the ledger. For efficient interaction of these smart contract executables, the latest values of the keys may be stored in a state database. The state database may simply be an indexed view of the entry log for the chain, so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) upon startup of the peer node and before the entry is accepted.

Blockchains differ from traditional databases in that blockchains are not centrally stored, but are decentralized, immutable, and secure storage, where nodes must share changes to records in the storage. Some attributes that are inherent in a blockchain and that facilitate the blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

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

The sensors may be located on one or more of the following: an interior of the vehicle, an exterior of the vehicle, on a fixed object separate from the vehicle, and on another vehicle proximate to the vehicle. The sensors may also be associated with the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the fuel level, service requirements, gear changes of the vehicle, steering of the vehicle, etc. The concept of a sensor may also be a device, such as a mobile device. Also, the sensor information may be used to identify whether the vehicle is operating safely and whether the occupant user is engaged in any unexpected vehicle condition, such as during vehicle entry. Vehicle information collected before, during, and/or after vehicle operation can be identified and stored in transactions on a shared/distributed ledger, which can be generated and submitted to an immutable ledger as determined by a permission granting community, and thus in a "decentralized" fashion, such as via a blockchain membership group. Each stakeholder (i.e., company, agency, etc.) may wish to limit disclosure of private information, so blockchains and their invariance may limit disclosure and administrative permissions for each particular user's vehicle profile. Smart contracts may be used to provide compensation, quantify user profile scores/ratings/reviews, apply vehicle event permissions, determine when services are needed, identify conflicts and/or degradation events, identify security-related issues, identify parties to an event, and provide distribution to registered entities seeking access to such vehicle event data. Likewise, the results may be identified and necessary information may be shared between registered companies and/or individuals based on a "consensus" method associated with the blockchain. Such an approach cannot be implemented on a traditional centralized database.

In an embodiment of the present solution, the charging station assumes an additional role and/or a different role as a wireless communicator with the vehicle. The disclosed charging station communicates the power requirements of the system(s) with which it communicates (or the requirements of the charging station(s) themselves), receives energy from the vehicle for delivery to a local power grid or location (location), and knows the location, direction of travel, and status of various electric vehicles.

Another embodiment of the current solution wirelessly notifies the vehicle to provide a portion of the energy amount prior to coupling of the vehicle and the charging station, and provides intelligence between the charging station and the vehicle, allowing the processor of the charging station to wirelessly communicate with the vehicle regarding the amount of energy stored in the one or more batteries on the vehicle. The processor and/or other devices (such as transceivers, transmitters, receivers, sensors, etc.) of the charging station are configured to communicate with one or more processors and/or other devices (such as transceivers, transmitters, receivers, sensors, etc.) of the vehicle to determine the current battery charge level and provide a portion of the charge level to the charging station. In one example, the coupling of the vehicle and the charging station may be through a direct electrical connection, inductive coupling, or the like.

In an embodiment of the present solution, the charging station acts as a vehicle energy director and a bidirectional energy transfer/transmission device, wherein the energy demand is fulfilled both from grid to terminal and from terminal to grid. The destination may be a vehicle, a residence, another charging station, etc. This bidirectionality of energy flow is performed by current solutions that have extended intelligence into the vehicles around them. The extended intelligence of the charging station may include vehicle status information received from the vehicle via wireless communication, such as the current charging status of the vehicle, its location, direction of travel, destination, other stops, its current usage, and the like. The charging station may determine the amount of additional energy that would be required for the vehicle to complete its route, which information may also be wirelessly transmitted by the vehicle to the charging station as vehicle status information. The charging station may additionally store prior vehicle state information from prior interactions with the vehicle and form a historical travel pattern for the vehicle based on the prior interactions.

The charging stations may communicate with each other to provide information related to the direction of transit travel, the state of charge, transit time to the charging station(s), and the like. In such current solutions, in one embodiment, charging stations may communicate with each other and with the transit vehicle to track their energy demand and excess energy storage capacity. This information is used to select a particular vehicle(s) based on the current energy storage of the vehicle(s) and the time to charging station. In other embodiments, an estimated time that will be taken by the vehicle to discharge at the charging station may also be determined and used to select the particular vehicle(s) and manage ingress and egress of the vehicle(s) at the charging station to provide additional power to the grid (fig. 1A, 142). The estimated time it takes for the vehicle to discharge at the charging station may be based on the state of charge of the vehicle, the type of energy storage, the type of galvanic connection, etc. The communication between the charging stations may be one of wireless, wired, network, internet, etc.

In one example embodiment, a charging station wirelessly informs a vehicle in a group of vehicles that it knows, travels towards it, and has excess energy to provide a required amount of energy that the vehicle has and can be allocated to the charging station.

In one embodiment, a charging station may communicate wirelessly with a group of electric vehicles in its vicinity and may know the group of electric vehicles in its vicinity, its direction of travel, and the state of charge of its respective transit vehicle batteries. In one embodiment, the vehicle storage unit may be comprised of a capacitor, a super capacitor, or the like. In one embodiment, a vehicle in wireless communication with a charging station transmits status information related to the vehicle to the charging station including one or more of: its current status, location, travel route, load, energy consumption per mile, etc. The charging station collects the status information to form a status matrix of the vehicle with which the charging station communicates. The state matrix may be used as a basis for decisions made by the charging station regarding a group of vehicles traveling towards the charging station. The state matrix may be utilized to select potential candidates to transfer some of their energy to the charging station. The state matrix may be stored at the charging station, in the cloud, or on a server communicatively coupled to the charging station. The status information associated with the vehicle may be stored locally in the vehicle, in the cloud, or on a server communicatively coupled to the vehicle.

In one embodiment, the charging station maintains a state matrix. In this embodiment, the state matrix is an information matrix for a vehicle approaching the charging station. In other embodiments, the state matrix is maintained when the vehicle is within wireless communication range of the charging station or when the vehicle is within distance of the charging station. This information matrix of the vehicle communicating with the charging station can be used for decisions related to energy transfer, and a history of the information matrix of the vehicle can be saved for subsequent history analysis. The information maintained by the state matrix may include one or more of a state of charge, a direction of travel, end point(s), a current location, a barrier at the location, a travel route, a load, a start point, an end point, an instantaneous travel speed, an average travel speed, a top speed, an acceleration rate, a current energy usage rate per distance (such as miles or kilometers), an amount of charge to provide, an amount of time to spend at a charging station, current and/or future road conditions, current and/or future weather conditions, an estimated distance to a charging station, an estimated distance to a subsequent end point, and the like. The charging station (via one or more processors, sensors, and/or memory that may store state matrices and/or information on the charging station or accessible by the charging station) may use this information to make decisions for one or more of the vehicles in wireless communication with the charging station. The state matrix may also include historical travel patterns, and may be based on previously stored vehicle state reports from previous interactions, the likelihood of a vehicle traveling directly to an endpoint and/or docking along a particular date, and so forth.

In one example embodiment where the state matrix has a minimum number of components, the matrix may include an identifier for each vehicle with which it is in communication, their location relative to the charging station, whether the vehicle is traveling toward the charging station, the state of charge of the vehicle, and one or more endpoints of the vehicle. With this information in the matrix, it is possible to determine which vehicle travelling towards the charging station will have the most excess energy after taking into account the energy required to travel from the charging station to the destination. The vehicle with the largest excess energy may be selected to transmit a portion of its excess energy back to the charging station and from there optionally to the grid or site. As previously discussed, other data may be collected and the vehicle used to provide the energy may be selected in different ways.

The charging station may select a potential candidate based on those vehicles having the greatest energy reserve, the vehicle having the greatest energy reserve to estimated energy usage, the vehicle closest to its destination, the vehicle proximate to the charging station and near its destination, the vehicle that will have the shortest queuing time based on the current speed and energy download/discharge time of the vehicle, and so forth. The destination may be a vehicle, a residence, another charging station, etc.

The charging station will not starve the vehicle and be unable to complete its journey because the charging station will have access to the historical driving patterns of the vehicle either via the currently planned route of the vehicle obtained from the vehicle via wireless transmission, or via data stored in the vehicle, data stored in the charging station about the vehicle, data stored in the cloud, server, etc. For example, the historical travel pattern may be based on previously stored vehicle status reports from previous interactions, the charging station may determine the likelihood of the vehicle traveling directly to a certain location or waypoint on a particular date, and so on. This information may form part of a state matrix that the charging station may use to determine which vehicle(s) will form the group.

The vehicle wirelessly communicates with the charging station and provides its state of charge, direction of travel, endpoint(s), location, amount of charge to be provided, amount of time spent at the charging station, and one or more of an estimated distance to the charging station, an estimated distance to a subsequent endpoint, and the like. The vehicle can independently determine how much energy it can shed.

In one embodiment, in the event that the first vehicle is unable or unwilling to transfer energy to the charging station, the charging station wirelessly communicates its energy requirements to the vehicle and the backup vehicle. The system may also schedule communication and energy transmission such that the time that the transmitting vehicle queues at the charging station is minimized. Efficient vehicle energy upload throughput can be achieved by scheduling vehicles for energy transmission based on their wirelessly transmitted status information based on the distance from the vehicle to the charging station and the instantaneous speed of the vehicle traveling toward the charging station, while having minimal queuing time for the charging station and the vehicle. Queuing time may also be reduced by determining the travel time of a previous vehicle at about the same distance from the charging station, and scheduling the vehicle to arrive when the previous vehicle is to complete its energy transfer. In some embodiments, the travel time may be a function of time of day, distance, traffic density, traffic throughput barriers, and the like.

FIG. 1A illustrates an example power return notification system overview 100. In one example, the charging station (fig. 1A, 114) is configured to wirelessly notify at least one vehicle (fig. 1A, 110) of the identified set of vehicles (fig. 1A, 110, and 112) of a required amount of energy stored in the at least one vehicle (fig. 1A, 110) before the at least one vehicle is connected to the charging station (fig. 1A, 114). The charging station may provide feedback to the vehicle via communication (fig. 1A, 116).

FIG. 1B illustrates an example power return notification system overview 120. In another example, the charging station (114, fig. 1B) is configured to receive energy from a vehicle storage unit (134, 136, fig. 1B). The processor may wirelessly notify at least one vehicle (fig. 1B, 110) of a desired indication of an amount of energy stored in the at least one vehicle (fig. 1B, 110) before at least one vehicle (fig. 1B, 110) of the group of identified vehicles (fig. 1B, 110, 112) is connected to the charging station (fig. 1B, 114). The charging station may provide feedback to the vehicle via communication (116, fig. 1B).

In yet another example embodiment, the charging station (fig. 1B, 114) may wirelessly notify another vehicle (fig. 1B, 112) in the group of identified vehicles (fig. 1B, 110, and 112) of a desired amount of energy stored in the other vehicle (fig. 1B, 112). The charging station (114, fig. 1B) may also direct another vehicle (112, fig. 1B) to provide a portion of the energy amount to the charging station (114, fig. 1B) before at least one vehicle (112, fig. 1B) is connected to the charging station (114, fig. 1B).

Another example embodiment may include a charging station (fig. 1C, 114) and a processor that determines an amount of energy stored in at least one storage unit (fig. 1B, 134, 136) of a vehicle (fig. 1C, 110). The processor may determine an amount of energy reserved for performing a set of vehicle tasks, determine an amount of energy available based on the amount of stored energy and the reserved energy, and a discharge limit of at least one storage unit (134, 136, fig. 1B). The processor may provide an indication of an amount of available energy of at least one storage unit (134, 136, fig. 1B) of the vehicle, and based on the indication, provide a notification that a portion of the available energy is to be provided to a charging station (134, 136, fig. 1B) prior to coupling. The vehicle (fig. 1B, 110) communicates wirelessly (fig. 1B, 116) with the charging station (fig. 1B, 114) and transmits via the transceiver (fig. 1B, 124, 126) the charging state of the storage unit (fig. 1B, 134) of the vehicle and the position of the vehicle obtained via the spatial position sensor (fig. 1B, 128, 132).

In other embodiments, the system may provide the location of the charging station to the at least one vehicle when at least one of the following occurs: the charging station wirelessly notifies the at least one vehicle of the required amount of energy, and the at least one vehicle confirms that the required amount of energy can be provided to the charging station. The charging station may wirelessly inform another vehicle of the group of identified vehicles of a required amount of energy stored in the other vehicle before at least one vehicle is connected to the charging station. The charging station may wirelessly notify the vehicle of the required amount of energy stored in the vehicle based on the amount of energy stored in the vehicle and the time of arrival of the vehicle at the charging station.

The charging station can query the at least one vehicle for the energy quantity stored in the at least one vehicle via the charging station and provide the energy quantity stored in the at least one vehicle to the charging station via the at least one vehicle. The charging station may also identify the group of identified vehicles based on: a distance, a speed, a direction, an amount of energy stored in each vehicle of the set of identified vehicles, an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station, and an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station and can provide energy to the charging station.

FIG. 1C illustrates an example vehicle-to-vehicle power transmission notification prior to transmission 150. The charging station (fig. 1C, 114) may have information about the energy status of each vehicle in its vicinity and may inform one energy rich vehicle (fig. 1C, 110) of another vehicle (fig. 1C, 112) in the vicinity of the energy rich vehicle that is exhausted and that has insufficient energy to reach its destination. FIG. 1D illustrates another example vehicle-to-vehicle power transmission notification prior to transmission 160. In one embodiment, the charging system may schedule, but not directly participate in, roadside transmissions of energy from an energy-rich vehicle (fig. 1D, 110) to an energy-depleted vehicle (fig. 1D, 112), wherein the energy-depleted vehicle is not part of the set of identified vehicles. Roadside transmissions may be made via charging cables connecting energy-rich vehicles with energy-depleted vehicles. In this case, neither the energy-rich vehicle nor the energy-depleted vehicle would be connected to the charging station, but would be directed by the charging station to perform an action such that both vehicles would be able to complete their journey without affecting the grid (fig. 1A, 142). In an example embodiment, the coupling of the energy-rich vehicle and the energy-depleted vehicle may be by way of a direct electrical connection, inductive coupling, or the like.

Fig. 2A illustrates a vehicle network diagram 200 according to an example embodiment. The network includes elements, including: a vehicle node 202 comprising a processor 204; and a vehicle node 202 'including a processor 204'. The vehicle nodes 202, 202 'communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between the vehicle nodes 202, 202' may occur directly via private and/or public networks (not shown) or directly via other vehicle nodes and elements including one or more of processors, memory, and software. Although depicted as a single vehicle node and processor, there may be multiple vehicle nodes and processors. One or more of the applications, features, steps, solutions, etc. described and/or depicted herein can be utilized and/or provided by the present elements.

Fig. 2B illustrates another vehicle network diagram 210 according to an example embodiment. The network includes elements, including: a vehicle node 202 comprising a processor 204; and a vehicle node 202 'including a processor 204'. The vehicle nodes 202, 202 'communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between the vehicle nodes 202, 202' may occur directly via private and/or public networks (not shown) or directly via other vehicle nodes and elements including one or more of processors, memory, and software. The processors 204, 204' may also 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. The processor 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

Although depicted as a single vehicle node, processor, and element, there may be multiple vehicle nodes, processors, and elements. Information or communications may occur at and/or from any of the processors 204, 204' and the element 230. For example, mobile phone 220 may provide information to processor 204, processor 204 may initiate vehicle node 202 to take action, may further provide the information or additional information to processor 204', the processor 204' may initiate vehicle node 202' to take action, may further provide the information or additional information to mobile phone 220, vehicle node 222, and/or computer 224. One or more of the applications, features, steps, solutions, etc. described and/or depicted herein can be utilized and/or provided by the present elements.

Fig. 2C illustrates yet another vehicle network diagram 240, according to an example embodiment. The network includes elements including a vehicle node 202, the vehicle node 202 including a processor 204 and a non-transitory computer readable medium 242C. Processor 204 is communicatively coupled to non-transitory computer readable medium 242C and element 230 (which is depicted in fig. 2B).

The processor 204 wirelessly notifies 244C at least one vehicle in the identified set of vehicles of the amount of energy required to be stored in the at least one vehicle via the charging station before the at least one vehicle is connected to the charging station.

In other embodiments, the processor may provide the location of the charging station to the at least one vehicle when at least one of the following occurs: the charging station wirelessly notifies the at least one vehicle of the required amount of energy, and the at least one vehicle confirms that the required amount of energy can be provided to the charging station. The processor may wirelessly notify at least one other vehicle of the group of identified vehicles of the required amount of energy stored in the at least one other vehicle via the charging station before the at least one other vehicle is connected to the charging station. The processor may also wirelessly notify the at least one vehicle of a desired amount of energy stored in the at least one vehicle via the charging station based on the amount of energy stored in the at least one vehicle and a time of arrival of the at least one vehicle at the charging station. The processor may also query at least one vehicle for the amount of energy stored in the at least one vehicle via a charging station, and provide the amount of energy stored in the at least one vehicle to the charging station via the at least one vehicle. The processor may also identify, via the charging station, the group of identified vehicles based on: a distance, a speed, a direction, an amount of energy stored in each vehicle of the set of identified vehicles, an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station, and an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station and is capable of providing energy to the charging station.

In another example, a non-transitory computer-readable medium includes instructions that, when read by a processor, cause the processor to perform providing, to at least one vehicle of a set of identified vehicles, a wireless notification indicative of a desired amount of energy stored in the at least one vehicle before the at least one vehicle is connected to a charging station, and providing, to at least another vehicle of the set of identified vehicles, a wireless notification indicative of a desired amount of energy stored in the at least another vehicle before the at least one vehicle is connected to a charging station.

The processor and/or computer readable medium may be wholly or partially internal or external to the vehicle node. The steps or features stored in the computer-readable medium may be executed in whole or in part by any one of the processors and/or elements, in any order. Further, one or more steps or features may be added, omitted, combined, performed at a later time, and so forth.

Fig. 3A illustrates a flow diagram 300 according to an example embodiment. Referring to fig. 3A, a process includes wirelessly notifying 302, via a charging station, at least one vehicle of a set of identified vehicles of a desired amount of energy stored in the at least one vehicle before the at least one vehicle is connected to the charging station.

In other embodiments, the method may provide the location of the charging station to the at least one vehicle when at least one of the following occurs: the charging station wirelessly informs the at least one vehicle of the required amount of energy, and the at least one vehicle confirms that the required amount of energy can be provided to the charging station. The method may also wirelessly notify at least one other vehicle of the group of identified vehicles of a required amount of energy stored in the at least one other vehicle via the charging station before the at least one vehicle is connected to the charging station, and may wirelessly notify the at least one vehicle of the required amount of energy stored in the at least one vehicle via the charging station based on the amount of energy stored in the at least one vehicle and a time of arrival of the at least one vehicle at the charging station. The processor may also query the at least one vehicle for the amount of energy stored in the at least one vehicle via the charging station and provide the amount of energy stored in the at least one vehicle to the charging station via the at least one vehicle. The processor may also identify, via the charging station, the group of identified vehicles based on: a distance, a speed, a direction, an amount of energy stored in each vehicle of the set of identified vehicles, an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station, and an estimated amount of energy stored in each vehicle of the set of identified vehicles when each vehicle of the set of identified vehicles arrives at a charging station and is capable of providing energy to the charging station.

In another example, a method comprises: prior to at least one vehicle of a set of identified vehicles being connected to a charging station, wirelessly notifying the at least one vehicle via a processor of an indication of a desired amount of energy stored in the at least one vehicle. The method may further comprise: prior to the at least one vehicle being connected to the charging station, wirelessly notifying, via the processor, at least another vehicle of the set of identified vehicles of an indication of a required amount of energy stored in the at least another vehicle to provide a portion of the amount of energy to the charging station.

Fig. 4 illustrates a machine learning vehicle network diagram 400, 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.

The machine learning subsystem 406 contains a learning model 408, the learning model 408 being a mathematical artifact (artifact) created by a 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 located in the vehicle node 402. In other embodiments, the machine learning subsystem 406 is located external to the vehicle node 402.

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

In 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 sensor 404 data to the machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc., described and/or depicted herein may utilize a machine learning network 400 as described herein.

Fig. 5A illustrates an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Referring to fig. 5A, when a particular vehicle/vehicle 525 conducts a transaction (e.g., vehicle service, dealer transaction, delivery/pick-up, transportation service, etc.), the vehicle may receive asset 510 and/or discharge/transfer asset 512 according to the transaction(s). The vehicle processor 526 is located in the vehicle 525 and communication exists 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, credits, service descriptions, dates, times, locations, results, notifications, incidents, and the like. Those transactions in the transaction module 520 may be copied 530 into the database. The database 530 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and may be on-board the vehicle, may be off-board the vehicle, may be accessed directly and/or over a network, or may be accessed by the vehicle.

Fig. 5B illustrates an example vehicle configuration 550 for managing database transactions conducted between various vehicles, according to an example embodiment. When the vehicle 525 reaches a state requiring sharing of services with another vehicle, the vehicle 525 may engage with another vehicle 508 to perform various actions, such as to share, transfer, obtain a service call, and so forth. For example, the vehicle 508 may be due to battery charging and/or tires may be problematic and may be en route to pick up packages for delivery. The vehicle processor 528 is located in the vehicle 508 and there is communication between the vehicle processor 528, the database 554, the vehicle processor 528, and the transaction module 552. The vehicle 508 can notify another vehicle 525 operating in its network and on its blockchain member services. The vehicle processor 526 is located in the vehicle 525 and communication exists between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The vehicle 525 may then receive information via a wireless communication request from the vehicle 508 and/or from a server (not shown) to perform package extraction. The transactions are recorded in the transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525 and a record of the transferred services is recorded in database 530/554 (assuming the blockchains are different from each other) or in the same blockchain used by all members. The database 554 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and may be on-board the vehicle, may be off-board the vehicle, may be accessed directly and/or over a network.

Fig. 6A illustrates a blockchain architecture configuration 600 in accordance with an example embodiment. Referring to fig. 6A, a blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602 and 606 that are part of a blockchain set 610. In one example embodiment, the permitted blockchain is not accessible to all parties, but only to those members having permission to access the blockchain data. The blockchain nexus participates in many activities such as blockchain entry addition and verification processing (consensus). One or more of the blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain link points may initiate blockchain actions (such as authentication) and attempt to write to a blockchain immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

When blockchain transaction 620 is received and approved by the consensus model specified by the member node, the transaction is stored in the memory of the computer. Approved transaction 626 is stored in the current chunk of the blockchain and submitted to the blockchain via a submission process that includes performing a hash of the data content of the transaction in the current chunk and referencing a previous hash of the previous chunk. Within the blockchain, there may be one or more intelligent contracts 630 that define terms of the transaction agreements and actions included in the intelligent contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, and the like. The code may be configured to identify whether requesting entities are registered to receive vehicle services, which service features they are entitled/required to receive given their profile status, and whether to monitor their actions in subsequent events. For example, when a service event occurs and a user is riding in a vehicle, sensor data monitoring may be triggered and a certain parameter (e.g., vehicle charge level) may be identified as above/below a certain threshold for a certain period of time, and then the result may be a change to a current state that requires an alert to be sent to a management party (e.g., vehicle owner, vehicle operator, server, etc.) so that the service may be identified and stored for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle state. The sensor data may also be based on vehicle event data 634, such as location(s) to be driven, average speed, highest speed, acceleration rate, whether there are any collisions, whether an expected route is taken, where the next endpoint is, whether safety measures are in place, whether the vehicle has sufficient charge/fuel, etc. All of this information may be used as a basis for the intelligent contract terms 630 and then stored in the blockchain. For example, sensor thresholds stored in the smart contracts may be used as a basis for detecting whether and when and where services are necessary to be performed.

Fig. 6B illustrates a shared ledger configuration, according to an example embodiment. Referring to fig. 6B, the blockchain logic example 640 includes a blockchain application interface 642 as an application programming interface or plug-in application that is linked to the computing device and execution platform for a particular transaction. Blockchain configuration 640 may include one or more applications linked to Application Programming Interfaces (APIs) to access and execute stored program/application code (e.g., intelligent contract executable code, intelligent contracts, etc.) that may be created according to custom configurations sought by participants and may maintain their own state, control their own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via an attach to distributed ledger.

The smart contract application code 644 provides the basis for blockchain transactions by establishing application code that, when executed, causes the transaction terms and conditions to become active. The smart contracts 630, when executed, cause certain approved transactions 626 to be generated, which are then forwarded to the blockchain platform 652. The platform includes security/authorization 658, the computing device that performs transaction management 656, and a storage portion 654 that is memory that stores transactions and intelligent contracts in a blockchain.

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 may be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain may expose an interface that provides access to the handler code and the virtual execution environment needed to interface the physical infrastructure. A cryptographic trust service may be used to verify items such as asset exchange items and keep information secret.

The blockchain architecture arrangement of fig. 6A and 6B can process and execute program/application code via one or more interfaces exposed and services provided by the blockchain platform. By way of non-limiting example, smart contracts may be created to perform reminders, updates, and/or other notifications that undergo changes, updates, and the like. The smart contracts themselves may be used to identify rules associated with authorization and access requirements and the use of ledgers. For example, the information may include a new entry that may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results may include deciding to reject or approve the new entry based on criteria defined in the intelligent contract and/or consensus of peers. The physical infrastructure may be utilized to retrieve any of the data or information described herein.

Within the intelligent contract executable code, intelligent contracts may be created via high-level applications and programming languages and then written to blocks in a blockchain. The intelligent contracts may include executable code that is registered, stored, and/or replicated with a blockchain (e.g., a distributed network of blockchain peers). The entry is an execution of intelligent contract code, which may be executed in response to a condition associated with the intelligent contract being satisfied. Execution of the intelligent contract may trigger trusted modification(s) of the status of the digital blockchain ledger. The modification(s) to the blockchain ledger caused by the execution of the intelligent contract may be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

The intelligent contracts may write data to the blockchain in a key-value pair format. In addition, the intelligent contract code may read the values stored in the blockchain and use them in application operations. The intelligent contract code may write the output of various logical operations into a blockchain. The code may be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain may be public and/or may be encrypted and maintained private. Temporary data used/generated by the smart contract is maintained in memory by the provisioning execution environment and then deleted once the data needed for the blockchain is identified.

The intelligent contract executable code may include a code interpretation of the intelligent contract, as well as additional features. As described herein, smart contract executable code may be program code deployed on a computing network where it is executed and validated together by a chain validator during consensus processing. The intelligent contract executable code receives the hashes and retrieves the hashes from the blockchain associated with the data template created by using the previously stored feature extractor. The intelligent contract executable code sends the authorization key to the requested service if the hash of the hashed identifier matches a hash created from the stored identifier template data. The smart contract executable code may write data associated with the cryptographic details to the blockchain.

Fig. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. Referring to fig. 6C, the example configuration 660 utilizes a distributed ledger (i.e., blockchain) 668 to provide shared information for the vehicle 662, the user device 664, and the server 666. The server may represent a service provider entity that queries a vehicle service provider to share user profile rating information in the event that a known and established user profile is attempting to lease a vehicle having an established rating profile. Server 666 may be receiving and processing data related to vehicle service requirements. As service events occur, such as vehicle sensor data indicating a need for fuel/charging, maintenance services, etc., rules, thresholds, sensor information collection, etc., may be invoked using smart contracts, which may be used to invoke vehicle service events. Blockchain transaction data 670 is maintained for each transaction, such as access events, subsequent updates to vehicle service status, event updates, and the like. The transaction may include parties, requirements (e.g., age of 18 years, candidates eligible for service, valid driver's licenses, etc.), compensation levels, distances traveled during the event, registered recipients allowed to enter the event and host vehicle service, permissions/permits, sensor data retrieved during vehicle event operations to record detailed information for the next service event and identify the condition state of the vehicle, and thresholds for determining whether the service event has been completed and whether the condition state of the vehicle has changed.

Fig. 6D illustrates a blockchain block 680 that may be added to a distributed ledger, and the contents of the blockstructures 682A-682 n, according to an example embodiment. Referring to fig. 6D, a client (not shown) may submit an entry to a blockchain node to enact an activity on the blockchain. As an example, a client may be an application that acts on behalf of a requestor (such as a device, person, or entity) to present an entry for a blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain a copy of the state of the blockchain network and the distributed ledger. There may be different types of blockchain nodes/peers in a blockchain network, including endorsement peers that simulate and endorse client-proposed entries and submission peers that verify endorsements, validate entries, and submit entries to the distributed ledger. In this example, the tile chain node may perform the role of an endorser node, a submitter node, or both.

The system includes a blockchain that stores immutable ordered records in blocks, and a state database (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 that it is a member of. The present blockchain is a log of entries structured as hash-linked chunks, where each chunk contains a sequence of N entries. A tile may include various components, such as those shown in fig. 6D. The linking of tiles may be generated by adding a hash of the header of the previous tile in the tile header of the current tile. In this way, all entries on the blockchain are sorted and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Furthermore, because of the presence of the link, the newest block in the block chain represents each entry that has come before it. The local blockchain may be stored on a peer-to-peer file system (local or attached storage) that supports only additional blockchain workloads.

The current state of the blockchain and the distributed ledger can be stored in a state database. Here, the current state data represents the latest values of all keys once contained in the chain entry log of the block chain. The smart contract executable code invokes an execution entry for the current state in the state database. In order to make these intelligent contract executable code interactions very efficient, the latest values of all keys are stored in the state database. The state database may include an indexed view into the log of entries of the blockchain so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated when needed) after peer startup before accepting the entry.

The endorsement node receives an entry from the client and endorses the entry based on the simulation results. The endorsement node holds intelligent contracts that model the proposal for the entries. When an endorsement node endorses an entry, the endorsement node creates an entry endorsement, which is a signed response from the endorsement node to the client application indicating an endorsement for the simulated entry. The method of endorsement entry depends on the endorsement policy that may be specified in the intelligent contract executable code. An example of an endorsement policy is "most endorsement peers must endorse the entry". Different channels may have different endorsement policies. The client application forwards the entry for the endorsement to the ranking service.

The ordering service accepts entries of endorsements, orders them into blocks, and delivers these blocks to the submitting peers. For example, the ordering service may initiate a new tile when a threshold for an entry has been reached, a timer has expired, or other conditions. In this example, the blockchain node is a commit peer that has received data chunk 682A for storage on the blockchain. The ranking service may be comprised of a cluster of rankers. The ranking service does not process the input, the smart contract, or maintain the shared ledger. Rather, the ranking service can accept entries for endorsements and specify an order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

Entries are written to the distributed ledger in a consistent order. The order of the entries is established to ensure that updates to the state database are valid as they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., bitcoins, etc.) where ordering is done by solving cryptographic challenges or mining, in this example, the parties to the distributed ledger can select the ordering mechanism that best fits the network.

Referring to fig. 6D, a tile 682A (also referred to as a data tile) stored on a blockchain and/or distributed ledger may include multiple data segments, such as tile headers 684A through 684n, transaction-specific data 686A through 686n, and tile metadata 688A through 688 n. It should be appreciated that the various blocks and their contents, such as block 682A and its contents, are depicted for exemplary purposes only and are not meant to limit the scope of the exemplary embodiments. In some cases, both the tile header 684A and tile metadata 688A may be smaller than the transaction-specific data 686A that stores the entry data; but this is not essential. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A-690N. Chunk 682A may also include a link to a previous chunk (e.g., on a chunk chain) within the chunk header 684A. In particular, chunk header 684A may include a hash of the header of the previous chunk. The tile apparatus 684A may also include a unique tile number, a hash of tile data 690A for the current tile 682A, etc. The tile numbers for tile 682A may be unique and assigned in increments/order starting from zero. The first tile in a chain of tiles may be referred to as a founder tile, which includes information about the chain of tiles, their members, data stored therein, and the like.

The tile data 690A may store entry information of each entry recorded within a tile. For example, entry data may include one or more of a type of entry, a version, a timestamp, a channel ID of a distributed ledger, an entry ID, a time period (epoch), payload visibility, a smart contract executable code path (deployment tx), a smart contract executable code name, a smart contract executable code version, inputs (smart contract executable code and functions), a client (creator) identification (such as public keys and certificates), a signature of a client, an identity of an endorser, an endorser signature, a proposal hash, a smart contract executable code event, a response state, a namespace, a read set (a list of versions and keys read by an entry, etc.), a write set (a list of values and keys, etc.), a start key, an end key, a key list, a Merkel tree query digest, etc. Entry data may be stored for each of the N entries.

In some embodiments, the tile data 690A may also store transaction-specific data 686A, which adds additional information to the hash-linked chain of tiles in the tile chain. Thus, data 686A can be stored in an immutable log of the tile on the distributed ledger. Some of the benefits of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. Chunk metadata 688A may store a plurality of fields of metadata (e.g., as an array of bytes, etc.). The metadata fields may include a signature at tile creation, a reference to the last configured tile, an entry filter identifying valid and invalid entries within a tile, a last offset of the ordering service persistence to order tiles, and the like. The signature, last configuration chunk, and sorter metadata may be added by the sorting service. At the same time, the submitter of the block (such as a blockchain node) may add validity/invalidity information based on endorsement policies, verification of read/write sets, and the like. The entry filter may include an array of bytes equal in size to the number of entries in block data 610A and a validation code that identifies whether the entries are valid/invalid.

The other blocks 682B through 682n in the block chain also have headers, files, and values. However, unlike the first chunk 682A, each of the headers 684A-684 n in the other chunks includes the hash value of the immediately preceding chunk. The hash value of the immediately preceding chunk may be just the hash of the header of the preceding chunk, or may be the hash value of the entire preceding chunk. By including the hash value of the previous block in each of the remaining blocks, tracking from the nth block to the founder block (and associated original file) may be performed on a block-by-block basis, as indicated by arrow 692, to establish a chain of custody-of-custody that is auditable and immutable.

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

An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components. For example, FIG. 7 illustrates an example computer system architecture 700 that may represent or be integrated within any of the components described above, and/or the like.

FIG. 7 is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the application described herein. In any event, the computing node 700 is capable of being implemented and/or performing any of the functionality described herein.

In computing node 700, there is a computer system/server 702 that is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 702 include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the above systems or devices, and the like.

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

As shown in fig. 7, a computer system/server 702 in a cloud computing node 700 is shown in the form of a general purpose computing device. Components of 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 processors 704.

The bus represents one or more of any 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.

Computer system/server 702 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system/server 702 and includes both volatile and nonvolatile media, removable and non-removable media. In one embodiment, system memory 706 implements the flow diagrams of the 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. Computer system/server 702 may also include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, memory 706 may be provided for reading from and writing to non-removable, nonvolatile magnetic media (not shown and commonly referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, nonvolatile disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk such as a CD-ROM, DVD-ROM, or other optical media may be provided. In these cases, each drive may be connected to the bus by one or more data media interfaces. As will be further depicted and described below, memory 706 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of the various embodiments of the application.

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

As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to as a "circuit," module "or" system. Herein, 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.

Computer system/server 702 may also communicate via I/O device 712 (such as an I/O adapter) with one or more external devices (which may include a keyboard, pointing device, display, voice recognition module, etc.), one or more devices that enable a user to interact with computer system/server 702, and/or any device (e.g., network card, modem, etc.) that enables computer system/server 702 to communicate with one or more other computing devices. Such communication may occur via the I/O interface of device 712. Still yet, computer system/server 702 can communicate with one or more networks, such as a Local Area Network (LAN), a general Wide Area Network (WAN), and/or a public network (e.g., the internet) via a network adapter. As shown, device 712 communicates with the other components of computer system/server 702 via a bus. It should be appreciated that although not shown in the figures, other hardware and/or software components may be used in conjunction with computer system/server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external arrays of disk drives, RAID systems, tape drives, and data archival storage systems, etc.

Although exemplary embodiments of at least one of the systems, methods and non-transitory computer readable media have been illustrated in the accompanying drawings and described in the foregoing detailed description, it should be understood that the application is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functions performed by the various modules may be performed by one or more of the modules. In addition, the functions described herein may be performed at different times and in relation to various events internal or external to the module or component. Also, information transmitted between the respective modules may be transmitted between the modules via at least one of: data networks, the internet, voice networks, internet protocol networks, wireless devices, wired devices, and/or via multiple protocols. Also, messages sent or received by any module may be sent or received directly and/or via one or more other modules.

Those skilled in the art will recognize that a "system" may be implemented as a personal computer, a server, a console, a Personal Digital Assistant (PDA), a cellular telephone, a tablet computing device, a smart phone, or any other suitable computing device or combination of devices. The presentation of the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather is intended to provide one example of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in a localized and distributed form consistent with computing technology.

It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

Modules may also be implemented, at least in part, in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module. Additionally, the modules may be stored on a computer readable medium, which may be, for example, a hard disk drive, a flash memory device, a Random Access Memory (RAM), a magnetic tape, or any other such medium for storing data.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

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

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

While the preferred embodiments of the present application have been described, it is to be understood that the described embodiments are illustrative only, and that the scope of the present application is to be limited only by the appended claims when considered in terms of having a full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Cross Reference to Related Applications

Cross-reference the following commonly assigned U.S. patent applications, filed concurrently herewith: attorney docket number IP-A-4220, entitled "DISTANCE-BASED ENERGY TRANSFER FROM A TRANSPORT"; attorney docket No.: IP-A-4281 entitled "MOBILE TRANSPORT FOR EXTRACTING AND DEPOSITING ENERGY"; attorney docket No.: IP-A-4282, entitled "EXECUTING AN ENERGY TRANSFER DIRECTIVE FOR AN IDLE TRANSPORT"; and attorney docket number IP- ｃA-4458 entitled "TRANSPORT-BASED ENERGY ALLOCATION", wherein each application is incorporated by reference herein for all purposes.