Demand-based energy sharing

Abstract

Example operations include one or more of determining, by the charging station, a first amount of energy required to fully charge the vehicle, determining, by the charging station, a second amount of energy that the vehicle will provide back to the charging station at a later time, and charging, by the charging station, the vehicle to a charge level equal to a difference between the first amount of energy and the second amount of energy.

Description

[0001] Cross-reference to related applications

[0002] This application relates to a co-pending U.S. non-provisional patent application entitled “PRIORITY-BASED ENERGY TRANSFER”, both of which were filed on the same day and are incorporated herein by reference in their entirety. Background Technology

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

[0004] One example embodiment provides a method comprising one or more of the following: determining, by a charging station, a first amount of energy required to fully charge a vehicle; determining, by the charging station, a second amount of energy that the vehicle will provide back to the charging station at a later time; and charging, by the charging station, the vehicle to a charging level equal to the difference between the first and second amounts of energy.

[0005] Another example embodiment provides a system including a processor and a memory, wherein the processor is configured to perform one or more of the following: determining a first amount of energy required to fully charge a vehicle; determining a second amount of energy that the vehicle will provide back to a charging station at a later time; and charging the vehicle to a charging level equal to the difference between the first and second amounts of energy.

[0006] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: determine a first amount of energy required to fully charge a vehicle; determine a second amount of energy that the vehicle will provide back to a charging station at a later time; and charge the vehicle to a charging level equal to the difference between the first and second amounts of energy. Attached Figure Description

[0007] Figure 1 The diagram illustrates a transportation network according to an example embodiment.

[0008] Figure 2A The illustration shows yet another transportation network diagram according to an example embodiment.

[0009] Figure 2B Another transportation network diagram according to an example embodiment is illustrated.

[0010] Figure 2CThe illustration shows a blockchain-included architecture configuration according to an example embodiment.

[0011] Figure 3A A flowchart according to an example embodiment is illustrated.

[0012] Figure 3B Another flowchart according to an example embodiment is illustrated.

[0013] Figure 4 The diagram illustrates a machine learning transportation network according to an example embodiment.

[0014] Figure 5A The illustration shows an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

[0015] Figure 5B The illustration shows another example vehicle configuration for managing database transactions between various vehicles, according to an example embodiment.

[0016] Figure 6A The diagram illustrates a blockchain architecture configuration according to an example embodiment.

[0017] Figure 6B The illustration shows another blockchain configuration according to an example embodiment.

[0018] Figure 6C The illustration shows a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0019] Figure 6D An example data block according to an example embodiment is illustrated.

[0020] Figure 7 An example system supporting one or more of the example embodiments is illustrated. Detailed Implementation

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

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

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

[0024] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of the following: a means of transport (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status 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 / means status and provide feedback on the condition and / or changes of the means of transport. In one example, a user profile can be applied to a specific means of transport / vehicle to authorize current vehicle events, service stops at service stations, authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

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

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

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

[0028] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be caused by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, 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 that maintains the current state of the blockchain. Each channel typically has its own ledger. Each peer node maintains a copy of the ledger for each channel for which it is a member.

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

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

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

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

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

[0034] The various driving systems in this solution can utilize software, sensor arrays, machine learning capabilities, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, etc., to create terrain and road maps that the vehicle can use for navigation and other destinations. In some embodiments, GPS, maps, cameras, sensors, etc., can also be used in place of LIDAR in autonomous vehicles.

[0035] In some embodiments, this solution includes authorizing the vehicle to provide service via an automated and rapid authentication scheme. For example, driving to a charging station or fuel pump can be performed by a vehicle operator or autonomous vehicle, and authorization to receive charge or fuel can be performed without any delay once the service station and / or charging station receives authorization. The vehicle can provide a communication signal that identifies the vehicle with a current activity profile linked to an authorized account for receiving service, which can then be corrected through compensation. Other measures can be used to provide further authentication, such as another identifier that can be wirelessly transmitted from the user's device to the service center to replace or supplement the initial authorization work between the vehicle and the service center through additional authorization work.

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

[0037] According to an example embodiment, a solution for demand-based energy sharing between transportation vehicles and charging stations is provided. Providing surplus energy via vehicle-to-grid (V2G) is useful, especially during periods of high energy demand. Electric or hybrid transportation vehicles can be used as temporary mobile energy storage devices. The example embodiment allows control over the amount of energy obtained from the electric or hybrid transportation vehicle and the determination of a second amount of energy the vehicle will request over a period of time. The transportation vehicle can independently determine, based on instructions from a server, to provide energy back to the grid via charging stations. This decision (or instruction) can be based on current temperature, a day of the year, time of day, predicted weather changes, the current energy use of objects (such as transportation vehicles, residences, businesses, etc.), and overall energy use (geographical location, city, etc.). The decision can also be made based on machine learning data provided by an AI system that models energy consumption scenarios (described further below).

[0038] In one embodiment, a vehicle providing energy to a charging station is equivalent to a vehicle that saves energy by not obtaining such energy from the charging station. The charging station may provide energy to the vehicle, but may not provide the amount of energy that, based on historical data or machine learning data, is believed to be returned to the charging station by the vehicle in the near future.

[0039] For example, a vehicle user wants to charge their vehicle to 100% from a charging station. The charging station "knows" that the usage will only be 50%, and that the vehicle will typically return to the charging station at some point in the future with 25% remaining. The charging station knows this information based on previous usage records, which may be available on and / or from data storage devices located outside the vehicle. Furthermore, the charging station can receive the vehicle's destination(s) and route(s) for a given time period (hour, day, week, etc.). This information can be received from the vehicle, a server communicatively coupled to the vehicle and the charging station, another vehicle, or a device such as a cellular phone. Based on this information, the charging station can determine the amount of energy the vehicle will need and provide an equivalent or near-equivalent amount. The charging station can also consider weather, road conditions, traffic conditions, the vehicle's condition, etc., while determining the required energy. By providing the necessary amount of energy, the charging station, in another way, preserves the additional energy it would have provided to the vehicle if it were charged to 100%. This eliminates the need for the vehicle to return to the charging station and provide excess energy back to the grid. The savings associated with the vehicle not needing to return to a charging station to provide any excess energy can be calculated.

[0040] Referring to the example in this article, even if a user wants to charge the vehicle to 100%, the charging station can stop energy transfer at 75% because the charging station determines that energy usage will be at 50% and the remaining energy to be charged will be 25%. Not taking 25% of the energy from the charging station is a more efficient way to provide V2G energy transfer than temporarily providing the vehicle with 100% energy and then having it return to recharge, such as 25% (50% in this example). The amount of energy saved periodically during the round trip to and from the charging station is calculated as the total energy savings, which can include the amount saved (25%) plus the amount that would have been spent but is now saved because the vehicle is not making the round trip (e.g., 2.5%). The amount of energy savings can be calculated by the charging station (or by the vehicle) based on the type of vehicle, the distance to the charging station, the number of segments associated with the vehicle, and the number of passengers per day. In one example, the vehicle (or its user) may receive consideration for the energy transfer (e.g., monetary credits or energy credits).

[0041] In one embodiment, one or more vehicles can be communicatively coupled to a server and a charging station via a blockchain network. The vehicles, server, and charging station can act as blockchain peers. Energy requests can be broadcast to several vehicle peers within the charging station's reach. The charging station can identify vehicles that have supplied energy to it based on transactions recorded on the blockchain ledger.

[0042] In one embodiment, the vehicle maintains all records on local storage or a local copy of a blockchain ledger. Alternatively, records can be created on a central server. Records may include the vehicle's energy transfer history along with previously recorded energy savings. The vehicle may also record its current energy level and an estimated energy level during passenger and / or cargo transport. Based on this data, an energy request can be sent to the vehicle. Conversely, a vehicle recording local short-haul journeys may have a significant amount of surplus energy. Once the vehicle completes the transport of cargo and / or passengers, it records the current energy level and the availability of the remaining energy can be reassessed. In one example, the estimated amount of available energy can be calculated by the vehicle's processor and made available to a server or charging station. In another example, the server can access the vehicle's local storage and can determine the estimated energy level based on the current energy level, the vehicle's current location, the vehicle's destination, etc.

[0043] The amount of energy to be transferred to and from a vehicle can be determined by a server or computer, which may be located on or outside the vehicle. Parameters such as time of day / night, energy transfer time, the value of the transferred energy, the type of final recipient of the energy from the power grid, and direct energy transfer from a charging station to another vehicle can be considered. The charging station (or server) can determine which vehicles are available within reach (including distance and / or time). The charging station / server can also estimate the efficiency of obtaining energy from the vehicle based on its current distance from the requesting charging station and the vehicle's energy consumption. For example, if the server detects several vehicles within range of the requesting charging station, the charging station / server can identify vehicles with surplus energy via communication between the charging station / server and the vehicles. The server can calculate the additional energy consumption required for each vehicle to reach the requesting charging station. Then, one or more vehicles with the lowest additional energy consumption can be guided to the charging station for the most efficient transfer of surplus energy.

[0044] According to an example embodiment, a method for managing surplus energy between vehicles and charging stations is implemented. As discussed herein, vehicles may not be indiscriminately routed to charging stations and may not be simply charged to 100%. Instead, if a vehicle has surplus energy, has a history of providing energy back to the charging station (or a consensus to provide energy), or requires a minimum amount of additional energy to reach the charging station, then the system guides one or more vehicles to the charging station to provide surplus energy to the grid. This allows charging stations and vehicles to weigh the expected and one or more additional energy amounts to achieve more efficient and robust energy savings.

[0045] In one embodiment, one or more vehicles can connect to a charging station via a blockchain network. The vehicles and charging stations can act as blockchain peers. Energy requests can be broadcast to several vehicles within reach of the charging station. The vehicles and charging station nodes can reach a consensus on which vehicle will provide energy or charge less than 100% of its capacity. Once a charging station peer receives consensus from at least one vehicle, that vehicle can be directed to the charging station, while the other vehicles are directed away. Energy transfer transactions can be recorded on the blockchain to track the amount of energy available. In one embodiment, each blockchain peer (i.e., the charging station and the vehicle) maintains a local copy of its own blockchain ledger. Thus, the vehicle peer can execute smart contracts to record each energy transfer (or charging) transaction on its local ledger. For example, a vehicle can record the pickup and delivery location and time, as well as the energy level at pickup and destination. The energy level at the destination can be estimated based on the known energy consumption of a model of the vehicle. Once delivery is complete, the vehicle can record its current location and energy level on its local ledger, with a timestamp. The availability of remaining energy in a vehicle can be updated upon delivery completion. This allows the server or charging station peer to possess all information about vehicles with remaining energy. Therefore, a charging station can generate an energy transfer request for a vehicle based on its current location, energy level, and the additional energy required to travel to the requested charging station. The remaining energy level, timestamped location, vehicle type, and energy consumption can be retrieved by the charging station peer from the blockchain ledger. The vehicle's current energy level should be sufficient to share the remaining energy or charge a smaller amount. For example, a certain type of vehicle can travel locally for 3 days with 50% energy. If the vehicle's current energy level is 75%, it can safely transfer up to 25% of its energy to the requested charging station. Furthermore, if the vehicle requires energy, it might only charge to 50% instead of fully charging, based on local driving needs. Then, if the charging station peer selects a vehicle, a consensus is reached on the energy transfer based on the vehicle's available energy relative to the amount of energy requested by the charging station. Once a vehicle transfers energy to a charging station (or receives a smaller amount of energy from a charging station), the energy transfer transaction is recorded on the blockchain for further consideration (such as monetary credit or energy credit).

[0046] As discussed in this article, transportation vehicles can reach a consensus on which vehicle will provide energy (or receive less than 100% charge). Once the charging station peers receive consensus from at least one transportation vehicle, that vehicle can be directed to the charging station for energy transfer (or partial charging). Energy transfer transactions can be recorded on the blockchain to track the amount of energy available. Savings can be recorded for each transportation vehicle for future reference. Each energy transfer transaction can be recorded on the blockchain for future auditing and record keeping for each transportation vehicle.

[0047] Figure 1 A transportation network diagram according to an example embodiment is illustrated. (Reference) Figure 1 Network diagram 100 includes electric (or hybrid) vehicles 104 and 105 connected to charging station (or charging station node) 112 via a network (not shown). Charging station 112 can receive energy requests 134 / 135 from one or more of vehicles 104 and 105. Similarly, charging station 112 can detect electric (or hybrid) vehicles 104 and 105 operating within a certain range and can send energy requests 134 / 135 to these vehicles. Vehicles 104 and 105 can provide their current charging data to charging station 112. If charging station 112 determines that the current charging data of a vehicle is sufficient, then charging station 112 can instruct the vehicle to go to the charging station to provide energy. If charging station 112 determines that the current charging data of a vehicle is low, and also determines, for example, that a recharge of 25% remaining for the vehicle is available, then charging station 112 can instruct the vehicle to maneuver to charging station 112 and receive the remaining power.

[0048] In one embodiment, if vehicles 104 and 105 have similar energy levels, one of the vehicles can provide confirmation / consensus 132 to charging station 112 based on an agreement (i.e., consensus) 138 between vehicles within reach. In one example, charging station 112 can record that a particular vehicle has provided a certain amount of energy to charging station 112 for future auditing and / or for returning a similar amount of energy to that vehicle at a later point in time (based on payment credit, energy credit, etc.).

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

[0050] Figure 2B Another transportation network diagram 210 according to an example embodiment is illustrated. The network includes components including a transportation node 202 having a processor 204 and a transportation node 202' having a processor 204'. Transportation nodes 202, 202' can communicate with each other via processors 204, 204' and other components (not shown), including transceivers, transmitters, receivers, storage devices, sensors, and other components capable of providing communication. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and components including one or more of processors, memory, and software. Processors 204, 204' can also communicate with one or more components 230 including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, transportation nodes 222, computers 224, I / O devices 226, and voice applications 228. Processors 204, 204' can also communicate with one or more of the following components: processor, memory, and software.

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

[0052] Figure 2C The illustration depicts a transportation network diagram for priority-based energy transfer from a vehicle to a charging station, according to an example embodiment. (Reference) Figure 2C Network diagram 240 includes a transportation node 202 connected to other transportation node 202' and charging station node 203 via a blockchain network 206. Charging station node 203 can connect to transportation nodes 202 and 202', which can represent transportation vehicles. Blockchain network 206 may have a ledger 208 for storing data related to energy transfer (i.e., donor transportation ID, energy amount, remaining amount, savings, transfer date and time, etc.).

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

[0054] Charging station node 203 may also include a non-transitory computer-readable medium 201 on which machine-readable instructions executable by processor 204 may be stored. Examples of machine-readable instructions are shown in steps 211-215 and are discussed further herein. Examples of non-transitory computer-readable medium 201 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, non-transitory computer-readable medium 201 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices. The processor and / or computer-readable medium may reside wholly or partially on and / or outside the transportation node. Steps or features stored in the computer-readable medium may be executed wholly or partially by any processor and / or element in any order.

[0055] Processor 204 can execute machine-readable instructions 211 to determine a first amount of energy required to fully charge the vehicles (e.g., 202 / 202'). Each of vehicles 202 and 202' can serve as a network node on blockchain network 206. Blockchain network 206 can be configured to use one or more smart contracts located on the vehicles (i.e., nodes) that can manage transactions involving participating nodes (e.g., 202 and 202'). Processor 204 can execute machine-readable instructions 213 to determine a second amount of energy that vehicles 202 / 202' will provide back to charging station 212 at a later time. Processor 204 can execute machine-readable instructions 215 to charge vehicles 202 / 202' to a charging level equal to the difference between the first and second energy amounts. Furthermore, one or more steps or features can be added, omitted, combined, executed at a later time, etc.

[0056] Figure 3A A flowchart 300 illustrating a method according to an example embodiment is shown. (Reference) Figure 3A The example method can be executed by charging station node 203 (see [link]). Figure 2C It should be understood that... Figure 3A The method 300 described herein may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of this application. For illustrative purposes, reference is also made to... Figure 2C The features described herein are used to describe method 300. In particular, the processor 204 of SC node 203 can perform some or all of the operations included in method 300.

[0057] refer to Figure 3AProcessor 204 may perform one or more of the following steps. At block 302, processor 204 may determine a first amount of energy required to fully charge the vehicle. At block 304, processor 204 may determine a second amount of energy that the vehicle will provide back to the charging station at a later time. At block 306, processor 204 may charge the vehicle to a charging level equal to the difference between the first and second energy amounts.

[0058] Figure 3B A flowchart 320 illustrating an example method according to an example embodiment is shown. (Reference) Figure 3B Method 320 may further include one or more of the following steps. At block 322, processor 204 may at a later time charge the vehicle to a charging level equal to the difference between the second energy quantity and a third energy quantity calculated based on a proportional share of the second energy quantity and the first energy quantity. Thus, if the vehicle always yields 25% of the requested energy quantity (or total energy quantity), then the third energy quantity can be calculated as 25% of the second energy quantity.

[0059] At box 324, processor 204 can calculate the energy saved based on the estimated round-trip journey of the vehicle to the charging station when the vehicle returns to provide the second energy. At box 326, processor 204 can provide the saved energy, along with the charging level, to the vehicle. The saved energy can be used as an incentive to relinquish the second energy. At box 328, processor 204 can determine the second energy based on machine learning data calculated from historical data of energy returned by the vehicle. The machine learning data can be generated by an AI model that predicts energy use and demand based on factors such as temperature, time of day, and time of year. At box 330, processor 204 can receive confirmation of the transfer of the second energy from the vehicle. Note that the confirmation can be a blockchain consensus between peers represented by the vehicle and the charging station. At box 332, processor 204 can execute a smart contract to record the transaction related to the energy transfer on the blockchain based on the blockchain consensus.

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

[0061] 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 datasets. In some embodiments, the machine learning subsystem 406 is located within the transportation node 402. In other embodiments, the machine learning subsystem 406 is located outside the transportation node 402.

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

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

[0064] Figure 5A The illustration depicts an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Reference Figure 5A When a specific means of transport / vehicle 525 engages in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or discharge / transfer assets 512 according to (one or more) the transaction. A means of transport processor 526 is located within vehicle 525, and communication exists between means of transport processor 526, database 530, and transaction module 520. Transaction module 520 can record information such as assets, parties, credit, service description, date, time, location, results, notifications, and unexpected events. Transactions in transaction module 520 can be copied to database 530. Database 530 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be accessed on the means of transport, outside the means of transport, directly and / or via a network, or accessible by the means of transport.

[0065] Figure 5BThe illustration depicts an example vehicle configuration 550 for managing database transactions between various vehicles, according to an example embodiment. When vehicle 525 reaches a state requiring service sharing with another vehicle, vehicle 525 can engage with another vehicle 508 to perform various actions, such as sharing, transferring, or receiving service calls. For example, vehicle 508 might be experiencing battery charging and / or tire problems and may be en route to retrieve a package for delivery. A vehicle processor 528 is located within vehicle 508, and communication exists between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle 525 operating within its network and on its blockchain member service. A vehicle processor 526 is located within vehicle 525, and communication exists between vehicle processor 526, database 530, and transaction module 520. Vehicle 525 can then wirelessly request information from vehicle 508 and / or from a server (not shown) to perform package retrieval. Transactions are recorded in transaction modules 552 and 520 of the two vehicles. Credit is transferred from vehicle 508 to vehicle 525, and the record of the transferred service is recorded in databases 530 / 554 (assuming the blockchains are different from each other), or in the same blockchain used by all members. Database 554 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be accessed on the vehicle, outside the vehicle, directly, and / or via a network.

[0066] Figure 6A The illustration shows a blockchain architecture configuration 600 according to an example embodiment. (Reference) Figure 6A The blockchain architecture 600 may include certain blockchain elements, such as a group of blockchain member nodes 602-606 as part of blockchain group 610. In one example embodiment, the permissioned blockchain is not accessible to all parties, but only to those members with permission to access the blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processing (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and attempt to write to the immutable blockchain ledger stored in the blockchain, copies of which may also be stored on the underlying physical infrastructure.

[0067] When blockchain transaction 620 is received and approved by the consensus model defined by the member nodes, the transaction is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and submitted to the blockchain via a submission process that includes hashing the data content of the transaction in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 630 may exist, whose definitions include terms of transaction protocols and actions in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. This code can be configured to identify whether requesting entities are registered to receive vehicle services, which service characteristics they are entitled to / required to receive given their profile status, and whether their actions are monitored in subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring can be triggered, and a parameter (such as the vehicle's charge level) can be identified as being above / below a specific threshold for a specific time period. The result might then be a change to the current state, which requires sending an alert to management (e.g., vehicle owner, vehicle operator, server, etc.) to identify and store the service for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's status. Sensor data can also form the basis of vehicle event data 634, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, whether there has been any collision, whether the expected route has been taken, the next destination, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All this information can serve as the basis for smart contract terms 630, which are then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary and when and where the service should be performed.

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

[0069] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, upon execution, makes the transaction terms and conditions effective. Smart contract 630, upon execution, causes the generation of certain approved transactions 626, which are then forwarded to the blockchain platform 652. This platform includes security / authorization 658, computing devices for executing transaction management 656, and a storage component 654 that serves as a storage device for storing transactions and smart contracts within the blockchain.

[0070] A blockchain platform can include blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and various layers of the underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain can expose interfaces that provide access to the processing code and the virtual execution environment required to interface with the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and keep information private.

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

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

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

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

[0075] Figure 6C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Reference) Figure 6C Example configuration 660 provides information sharing with a distributed ledger (i.e., blockchain) 668 for vehicle 662, user equipment 664, and server 666. The server may represent a service provider entity that, in the event that a known and established user profile is attempting to lease a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 666 may be receiving and processing data related to vehicle service requests. As service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., age of 18, qualified candidates, valid driver's license, etc.), compensation level, distance traveled during the event, recipient of registration to access the event and preside over vehicle service, permissions / permissions, sensor data retrieved during the vehicle event, details of recording the next service event and actions to identify the vehicle's condition status, and thresholds for determining whether the service event has been completed and whether the vehicle's condition status has changed.

[0076] Figure 6D The illustration shows a blockchain block 680 that can be added to a distributed ledger according to an example embodiment, and the contents of block structures 682A to 682n. (Reference) Figure 6D A client (not shown) can submit entries to a blockchain node to establish an activity on the blockchain. As an example, the client could be an application acting on behalf of a requester (such as a device, individual, or entity) to submit entries to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers may exist in a blockchain network, including endorsing peers that simulate and endorse entries submitted by clients, and submitting peers that verify endorsements, validate entries, and submit them to the distributed ledger. In this example, a blockchain node could act as an endorser node, a submitter node, or both.

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

[0078] The current state of a blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest value of all keys ever contained in the blockchain's entry log. Smart contract executables invoke execution entries against the current state in the state database. To make these smart contract executable interactions highly efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after a peer initiates operations but before accepting entries (or generated when needed).

[0079] Endorsing nodes receive entries from clients and endorse them based on the mock results. Each endorsing node holds a smart contract containing the mock entry proposal. When an endorsing node endorses an entry, one or more endorsing nodes create an entry endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the mock entry. The method of endorsing entries depends on the endorsement policy, which can be specified within the smart contract's executable code. An example of an endorsement policy is "most endorsing peers must endorse the entry." Different channels can have different endorsement policies. The client application forwards the endorsed entries to a sorting service.

[0080] The ordering service accepts endorsed entries, orders them into blocks, and delivers these blocks to submitting peers. For example, the ordering service can initiate a new block when a threshold for entries is reached, a timer times out, or other conditions occur. In this example, the blockchain node is the submitting peer, and it has received block 682A of data to be stored on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, it accepts endorsed entries and specifies the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

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

[0082] refer to Figure 6DBlock 682A (also known as a data block) stored on the blockchain and / or distributed ledger may include multiple data segments, such as block headers 684A to 684n, transaction-specific data 686A to 686n, and block metadata 688A to 688n. It should be understood that the various blocks and their contents depicted, such as block 682A and its contents, are for illustrative purposes only and are not intended to limit the scope of the exemplary embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A, which stores 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 block data 690A to 690n. Block 682A may also include links to previous blocks (e.g., on the blockchain) within its block header 684A. Specifically, block header 684A may include hashes of the headers of previous blocks. Block header 684A may also include a unique block number, a hash of block data 690A of the current block 682A, etc. The block number of block 682A can be unique and is assigned incrementally / sequentially starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

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

[0084] In some embodiments, block data 690A may also store transaction-specific data 686A, which adds additional information to the blockchain of hash-linked blocks in the blockchain. Thus, data 686A can be stored in the immutable log of blocks on a distributed ledger. Some benefits of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. Block metadata 688A may store multiple fields of metadata (e.g., as byte arrays, etc.). Metadata fields may include a signature at the time of block creation, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, the last offset persisted by a sorting service that sorts the blocks, etc. The signature, the last configured block, and the sorter metadata may be added by the sorting service. Simultaneously, the block submitter (such as 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 block data 610A and a verification code identifying whether an entry is valid / invalid.

[0085] Other blocks 682B through 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, the headers of each of the other blocks 684A through 684n include the hash value of the preceding block. The hash value of the preceding block can be simply the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, a trace from the Nth block to the genesis block (and the associated original file) can be performed block by block, as indicated by arrow 692, to establish an auditable and immutable chain-of-custody.

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

[0087] Example storage media can be coupled to a processor, allowing the processor to read information from and write information to the storage media. Alternatively, the storage media can be integrated with the processor. The processor and storage media can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage media can reside as discrete components. For example, Figure 7 The illustration shows an example computer system architecture 700, which can be represented or integrated into any of the components, etc.

[0088] Figure 7 This is not intended to imply any limitation on the scope or functionality of the embodiments of this application described herein. In any case, the compute node 700 is capable of implementing and / or performing any of the functions set forth herein.

[0089] Within compute node 700, there is a computer system / server 702 that can operate with many other general-purpose 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, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of these systems or devices.

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

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

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

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

[0094] A program / utility having a set (at least one) of program modules may be stored in memory 706. By way of example and not limitation, such program modules include 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 networking environment. Program modules typically perform functions and / or methods as described in the various embodiments of this application herein.

[0095] As those skilled in the art will recognize, aspects of this application can be implemented as systems, methods, or computer program products. Therefore, aspects of this application can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which can generally be referred to as "circuit," "module," or "system." Furthermore, aspects of this application can take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0096] The computer system / server 702 can 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 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, modem, etc.). Such communication can occur via the I / O interface of device 712. Again, the computer system / server 702 can communicate with one or more networks (such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet)) via a network adapter. As shown, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown in the figure, other hardware and / or software components can be used in conjunction with the computer system / server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, belt drives, and data archiving storage systems.

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

[0098] Those skilled in the art will recognize that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the functionality as being performed by the "system" is not intended to limit the scope of this application in any way, but is intended to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

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

[0100] Modules can also be implemented at least partially in software so that they can be executed by various types of processors. The identified units of executable code can, for example, comprise one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together, but can include different instructions stored in different locations that, when logically connected, encompass the module and implement the module's stated purpose. Additionally, modules can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

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

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

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

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

Claims

1. A method for energy sharing, comprising: determining, by a charging station, a first amount of energy required to fully charge a vehicle; determining, by the charging station, a second amount of energy that the vehicle will provide back to the charging station at a future point in time according to prior usage records; and charging, by the charging station, the vehicle to a charge level equal to a difference between the first amount of energy and the second amount of energy.

2. The method of claim 1, further comprising charging the vehicle at the future point in time to a charge level equal to a difference between the second amount of energy and a third amount of energy, the third amount of energy calculated based on a proportional share of the second amount of energy and the first amount of energy.

3. The method of claim 1, further comprising calculating an amount of energy saved based on an estimated round trip of the vehicle to the charging station when the vehicle returns to provide back the second amount of energy.

4. The method of claim 3, further comprising providing the amount of energy saved to the vehicle along with the charge level, wherein the amount of energy saved serves as an incentive for giving up the second amount of energy.

5. The method of claim 1, further comprising determining the second amount of energy based on machine learning data, the machine learning data calculated based on historical data of energy returned by the vehicle.

6. The method of claim 1, further comprising receiving a confirmation of the transfer of the second amount of energy from the vehicle, wherein the confirmation comprises a blockchain consensus between peers represented by the vehicle and the charging station.

7. The method of claim 6, further comprising executing a smart contract to record a transaction related to the transfer of energy on a blockchain based on the blockchain consensus.

8. A system for energy sharing, comprising: a processor of a charging station; a memory having stored thereon machine readable instructions that, when executed by the processor, cause the processor to: determine a first amount of energy required to fully charge a vehicle; determine a second amount of energy that the vehicle will provide back to the charging station at a future point in time according to prior usage records; and charge the vehicle to a charge level equal to a difference between the first amount of energy and the second amount of energy.

9. The system of claim 8, wherein the instructions further cause the processor to charge the vehicle at the future point in time to a charge level equal to a difference between the second amount of energy and a third amount of energy, the third amount of energy calculated based on a proportional share of the second amount of energy and the first amount of energy.

10. The system of claim 8, wherein the instructions further cause the processor to calculate an amount of energy saved based on an estimated round trip of the vehicle to the charging station when the vehicle returns to provide back the second amount of energy.

11. The system of claim 10, wherein the instructions further cause the processor to provide the amount of energy saved to the vehicle along with the charge level, wherein the amount of energy saved serves as an incentive for giving up the second amount of energy. ​ ​ 12. The system of claim 8, wherein the instructions further cause the processor to determine a second amount of energy based on machine learning data, the machine learning data calculated based on historical data of energy returned by the vehicle.

13. The system of claim 8, wherein the instructions further cause the processor to receive a confirmation of the transfer of the second amount of energy from the vehicle, wherein the confirmation comprises a blockchain consensus between peers represented by the vehicle and the charging station.

14. The system of claim 13, wherein the instructions further cause the processor to execute a smart contract to record a transaction related to the energy transfer on a blockchain based on the blockchain consensus.

15. A non-transitory computer-readable medium comprising instructions that, when read by a processor of a charging station, cause the processor to perform: determining a first amount of energy needed to fully charge a vehicle; determining a second amount of energy that the vehicle will provide back to the charging station at a future point in time according to a previous usage record; and charging the vehicle to a charge level equal to a difference between the first amount of energy and the second amount of energy.

16. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when read by the processor, cause the processor to charge the vehicle to a charge level equal to a difference between the second amount of energy and a third amount of energy calculated based on a proportional share of the second amount of energy and the first amount of energy at the future point in time.

17. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when read by the processor, cause the processor to calculate an amount of energy saved based on a projected round trip of the vehicle to the charging station when the vehicle returns to provide back the second amount of energy.

18. The non-transitory computer-readable medium of claim 17, further comprising instructions that, when read by the processor, cause the processor to provide the amount of energy saved along with the charge level to the vehicle, wherein the amount of energy saved serves as an incentive for giving up the second amount of energy.

19. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when read by the processor, cause the processor to receive a confirmation of the transfer of the second amount of energy from the vehicle, wherein the confirmation comprises a blockchain consensus between peers represented by the vehicle and the charging station.

20. The non-transitory computer-readable medium of claim 19, further comprising instructions that, when read by the processor, cause the processor to execute a smart contract to record a transaction related to the energy transfer on a blockchain based on the blockchain consensus.

Images