Transport power unloading management

Abstract

The present disclosure relates to vehicle power unloading management. Example operations include one or more of the following: initiating a request by the vehicle to a charging station to provide a first portion of stored energy; determining, by the charging station, an actual amount of energy required by the vehicle, wherein the determination is based on a first destination of the vehicle and data received by the charging station based on a route associated with the first destination, wherein the actual amount of energy is not the same amount as the first portion of stored energy; and depositing, by the vehicle, the actual amount of energy in the charging station.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is related to co-pending U.S. non-provisional patent application entitled “VEHICLE TO VEHICLE WIRELESS ENERGY TRANSFER” and co-pending U.S. non-provisional patent application entitled “LOAD EFFECTS ON TRANSPORT ENERGY,” both filed on April 21, 2020 and each of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to transport power unloading management. Background Art

[0004] Vehicles or transports, such as cars, motorcycles, trucks, airplanes, trains, etc., generally provide transportation needs for passengers and / or cargo in various ways. Functions associated with the transport may be recognized and utilized by various computing devices, such as smartphones or computers located on and / or outside the transport. Summary of the invention

[0005] An example embodiment provides a method comprising one or more of: initiating, by a vehicle, a request to a charging station to provide a first portion of stored energy; determining, by the charging station, an actual amount of energy required by the vehicle, wherein the determination is based on a first destination of the vehicle and data received by the charging station based on a route associated with the first destination, wherein the actual amount of energy is not the same amount as the first portion of the stored energy; and depositing, by the vehicle, the actual amount of energy in the charging station.

[0006] Another example embodiment provides a vehicle comprising a processor and a memory coupled to the processor, the memory comprising instructions that, when executed by the processor, are configured to perform one or more of: initiating, by the vehicle, a request to a charging station to provide a first portion of stored energy; determining, by the charging station, an actual amount of energy required by the vehicle, wherein the charging station determines the actual amount of energy based on a first destination of the vehicle and data received by the charging station based on a route associated with the first destination, wherein the actual amount of energy is not the same amount as the first portion of the stored energy; and storing, by the vehicle, the actual amount of energy in the charging station.

[0007] Yet 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: receiving a request by a charging station; calculating, by the charging station, a range surplus based on one or more of weather conditions, road conditions, road construction, and conditions of a transport and a current location of the transport; sending the range surplus to the transport; and increasing, by the transport, an actual amount of energy by an amount of energy reflecting the range surplus. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 An example system for vehicle power shedding according to an example embodiment is illustrated.

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

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

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

[0012] Figure 3 A flow chart according to an example embodiment is illustrated.

[0013] Figure 4 A machine learning transportation network diagram is illustrated according to an example embodiment.

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

[0015] Figure 5B Another example vehicle configuration for managing database transactions between various vehicles is illustrated according to an example embodiment.

[0016] Fig. 6A A blockchain architecture configuration according to an example embodiment is illustrated.

[0017] Figure 6B Another blockchain configuration according to an example embodiment is illustrated.

[0018] Figure 6C Illustrated is a blockchain configuration for storing blockchain transaction data according to an example embodiment.

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

[0020] Figure 7An example system is illustrated that supports one or more of the example embodiments. DETAILED DESCRIPTION

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

[0022] The features, structures or characteristics described throughout this specification may be combined in one or more embodiments in any suitable manner. For example, the use of the phrase "exemplary embodiment", "some embodiments" or other similar language refers at least throughout this specification to the fact that a specific feature, structure or characteristic described in conjunction with an embodiment may be included in an embodiment. Therefore, the appearance of the phrase "exemplary embodiment", "in some embodiments", "in other embodiments" or other similar language throughout this specification does not necessarily all refer to the same set of embodiments, and the described features, structures or characteristics may be combined in one or more embodiments in any suitable manner. In the accompanying drawings, even if the depicted connection is a unidirectional or bidirectional arrow, any connection between elements may allow unidirectional and / or bidirectional communication. In the current solution, the means of transport may include one or more of a car, a truck, a pedestrian zone battery electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a ship, a recreational vehicle, an airplane and any object that can be used to transport people and / or goods from one location to another.

[0023] In addition, although the term "message" may have been used in the description of the embodiments, the present application can be applied to various types of network data, such as packets, frames, datagrams, etc. The term "message" also includes packets, frames, datagrams, and any equivalents thereof. In addition, although specific types of messages and signaling may be depicted in exemplary embodiments, they are not limited to specific types of messages, and the present application is not limited to specific types of signaling.

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

[0025] Within the communication infrastructure, a decentralized database is a distributed storage system including multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an immutable data structure (i.e., distributed ledger) that can maintain records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage entries, group storage entries into blocks, and build a hash chain via blocks. For consistency, the process forms an account book by sorting storage entries when necessary. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). On the other hand, a permissioned blockchain database provides a system that can ensure interactions between a group of entities such as businesses that exchange funds, goods, information, etc., which share a common goal but do not or cannot fully trust each other. The present solution can work in permissioned and / or permissionless blockchain settings.

[0026] Smart contracts are trusted distributed applications that take advantage of the tamper-proof nature of a shared or distributed ledger (i.e., which can be in the form of a blockchain) database and an underlying protocol between member nodes, referred to as endorsement or endorsement policy. Typically, blockchain entries are "endorsed" before being submitted to the blockchain, while unendorsed entries are ignored. A typical endorsement policy allows the smart contract executable code to specify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified in the endorsement policy, the entry is executed to verify the entry. After verification, the entry enters the sorting phase, in which a consensus protocol is used to produce a sorted sequence of endorsed entries grouped into blocks.

[0027] A node is a communication entity of a blockchain system. A "node" can perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submission client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to a sorting service (e.g., sorting nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit entries, and maintain the state and copy of the ledger of blockchain entries. Peers can also play the role of endorsers, although it is not a requirement. An ordering service node or orderer is a node that runs communication services for all nodes and implements delivery guarantees such as broadcasting to each peer node in the system when submitting entries and modifying the world state of the blockchain. The delivery guarantee is another name for the initial blockchain entry that normally includes control and setup information.

[0028] The ledger is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can be caused by smart contract executable code calls (i.e., entries) submitted by participating parties (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). Entries can result in a collection of asset key-value pairs submitted to the ledger as one or more operands such as create, update, delete, etc. 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. Each channel typically has a ledger. Each peer node maintains a copy of the ledger for each channel of which the peer node is a member.

[0029] A chain is a log of entries structured as hash-linked blocks, and each block contains 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 and 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 links. The hash of the most recently added blockchain block represents every entry that came before it on the chain, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage device, cloud, etc.), effectively supporting the add-only nature of blockchain workloads.

[0030] The current state of the immutable ledger represents the latest values ​​for all keys included in the chain entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Smart contract executable code calls execute entries against the current state data of the ledger. In order to make these smart contract executable code interactions efficient, the latest values ​​of the keys can be stored in a state database. The state database can be just an indexed view into the chain entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) after the peer node is started and before the entry is accepted.

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

[0032] Example embodiments provide a means for providing vehicle services to a particular vehicle and / or requesting a user associated with a user profile applied to the vehicle. For example, the user may be the owner of the vehicle or the operator of a vehicle owned by another party. Vehicles may require service at specific intervals, and service requests may require authorization before receiving service is permitted. Additionally, a service center may provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service demand (e.g., immediate, severe, moderate, minor, 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 in turn is forwarded to a management server for inspection and action.

[0033] The sensor may be located inside the vehicle, outside the vehicle, on a fixed object away from the vehicle, and on one or more of another vehicle close to the vehicle. The sensor may also be associated with the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the fuel level, the service demand, the gear shifting of the vehicle, the steering of the vehicle, etc. The concept of a sensor may also be a device such as a mobile device. In addition, sensor information may be used to identify whether the vehicle is operating safely and whether the occupant user is involved in any unexpected vehicle conditions (such as during a vehicle access period). Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in a transaction on a shared / distributed ledger, which may be generated and submitted to an immutable ledger determined by a licensing alliance and therefore in a "decentralized" manner, such as via a blockchain member group.

[0034] Each interested party (e.g., company, agency, etc.) may wish to limit exposure of private information, and thus the blockchain and its immutability can limit exposure and manage permissions for each specific user vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify collision and / or degradation events, identify safety issue events, identify event participants and provide distribution to registered entities seeking access to such vehicle event data. In addition, results can be identified and necessary information can be shared between registered companies and / or individuals based on a "consensus" method associated with the blockchain. This approach cannot be implemented on a traditional centralized database.

[0035] Autonomous driving systems can utilize software, sensor arrays, and machine learning capabilities, lidar projectors, radars, ultrasonic sensors, etc. to create maps of terrain and roads that vehicles can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles instead of lidar.

[0036] In certain embodiments, the solution includes authorizing service for a vehicle via an automatic and rapid authentication scheme. For example, driving up to a charging station or fuel pump can be performed by the vehicle operator, and if the service station receives authorization to receive the charge or fuel, the authorization can be performed without any delay. The vehicle can provide a communication signal that provides an identification of a vehicle with a currently active profile linked to an account that can be authorized to receive service, which can then be corrected by compensation. Additional measures can be used to provide further authentication, such as another identifier can be wirelessly sent from the user's device to the service center to replace or supplement the first authorization work between the vehicle and the service center with an additional authorization work.

[0037] The shared and received data can be stored in a database that keeps the data in a single database (e.g., a database server) and usually in a specific location. The location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. The information stored on a centralized database is usually accessible from multiple different points. A centralized database is easy to manage, maintain, and control because of its single location, especially for security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data also means that a given data set has only one master record.

[0038] Figure 1An example system 100 for transport power unloading according to an example embodiment is illustrated. The transport or vehicle 104 may be an electric vehicle (EV) that includes stored energy 108 in a battery or other form of energy storage device. In one embodiment, the transport or vehicle 104 receives electrical energy at a charging station 112. In another embodiment, the transport or vehicle 104 may receive electrical energy from a solar panel or other device associated with the transport or vehicle 104. In yet another embodiment, the transport or vehicle 104 may receive electrical energy from either or both of the charging station 112 and / or the solar panel or other device associated with the transport or vehicle 104. The stored energy 108 may gradually be depleted as the transport or vehicle 104 travels around, which limits the driving range of the transport or vehicle 104. Therefore, when the stored energy 108 is at the maximum capacity of the battery, the driving range is maximized.

[0039] Sometimes, the vehicle 104 or the driver or owner of the vehicle 104 may be motivated to transfer some unused portions of the stored energy 108 back to the charging station 112. The charging station 112 may be physically located in, near, or at many possible locations near their residence. In some embodiments, the vehicle 104, the owner, or the driver may receive some kind of credit as a reward for transferring back a portion of the stored energy 108. Thus, the vehicle 104 or the owner / driver may be motivated to find opportunities to transfer back unused energy. For example, the vehicle 104 may commute to a work location a certain distance from the residence each weekday and may receive a full load of stored energy 108 at night. When returning from the work location later in the day, the driver may know that they do not need to make any additional stops or trips on the way home or on the way to the charging station 112. Thus, they may recognize that there is an opportunity to transfer back the first portion of the stored energy. The vehicle 104 may then transmit a request 116 to the charging station 112 for providing the first portion of the stored energy. In one embodiment, after determining the actual amount of energy, charging station 112 may provide notification 120 of the actual amount of energy to vehicle 104 .

[0040] After receiving the request 116, the charging station 112 may then determine the actual amount of energy required by the transport 104. The determination may be based on the first destination of the transport 104 and the data received by the charging station 112 based on the route associated with the first destination. The actual amount of energy may not be the same amount of energy as the first portion of the stored energy. In one embodiment, the actual amount of energy may include less energy than the first portion of the stored energy. For example, the charging station 112 may determine that other factors that may reduce the actual amount of energy should be considered. In another embodiment, the actual amount of energy may include more energy than the first portion of the stored energy. For example, the charging station 112 may determine that the first portion of the stored energy is too conservatively determined. In yet another embodiment, the actual amount of energy may include the same amount of energy as the first portion of the stored energy.

[0041] Once the vehicle 104 arrives at the charging station 112, the vehicle 104 may deposit the actual amount of energy 124 to the charging station 112. In most embodiments, this requires a direct connection between the vehicle 104 and the charging station 112. At this point, the vehicle 104 may either need some form of recharging stored energy 108 to continue traveling, have an amount of remaining stored energy 108 to reach another charging station 112, or have an amount of remaining stored energy 108 to complete one or more trips to an alternate destination.

[0042] In one embodiment, the request 116 may include the distance to the first destination. The charging station 112, in response to the request 116, may calculate a distance surplus based on any of weather conditions, road conditions, road configuration, or conditions of the vehicle 104 and the current location of the vehicle 104. For example, a better weather report or a mainly downhill road between the current location of the vehicle 104 and the charging station 112 may result in a distance surplus. The charging station 112 may then send the distance surplus to the vehicle 104, perhaps in the form of a notification 120 of the actual amount of energy. Upon receiving the distance surplus, the vehicle 104 may increase the actual amount of energy by an amount of energy corresponding to the distance surplus, and thereby store the increased amount of energy 124.

[0043] In another embodiment, the charging station 112 may calculate one or more alternative routes to the first destination. One or more of the alternative routes may include an actual amount of energy that is less than the first portion of the stored energy. The vehicle 104 may determine the best route among the one or more alternative routes and follow the best route to the first destination. In another embodiment, the vehicle 104 may transmit the one or more alternative routes to the charging station 112, and the charging station 112 may determine the best route from the one or more alternative routes. The charging station 112 may then transmit the best route to the vehicle 104, and the vehicle 104 follows the best route to the first destination.

[0044] In another embodiment, the vehicle 104 may receive a notification providing an update of the first portion 116 of stored energy. At various intervals, the vehicle 104 may calculate changes in the first portion of stored energy. The interval may be a time interval, for example, every minute. The interval may also be an interval of distance, for example, every mile. The interval may also be irregular in nature, such as whenever another vehicle traveling in the opposite direction on the same road passes the vehicle 104 in the opposite direction. In another embodiment, the interval may be road-related. For example, the vehicle 104 may be approaching an intersection or an exit ramp (such as along a highway) with another road from the current road. By recalculating the first portion of stored energy at intervals, the vehicle 104 has the opportunity to provide a more accurate and up-to-date first portion 116 notification to the charging station 112. In one embodiment, the vehicle may provide a first portion 116 update at each interval. In another embodiment, the vehicle 104 may provide a first portion 116 update only when the first portion 116 update is different from the previous first portion 116 transmitted to the charging station 112. Advantageously, this may result in fewer transmissions 116 , 120 and calculations by charging station 112 . In response to receiving first portion 116 updates at intervals, charging station 112 may recalculate the actual amount of stored energy, which is provided back to vehicle 104 as notification 120 .

[0045] In another embodiment, charging station 112 may receive a notification from vehicle 104 that vehicle 104 needs to make an additional trip after arriving at charging station 112. Charging station 112 then calculates the amount of energy used by vehicle 104 to make the additional trip, and in response, reduces the actual amount of energy by the amount of energy used to make the additional trip. Notification 120 of the reduced actual amount of energy may then be provided to vehicle 104.

[0046] In another embodiment, the charging station 112 may calculate a second portion of the stored energy that is less than the first portion 116 of the stored energy in order to advance the vehicle 104 from the current location to the location of another charging station that may be closer to the current location of the vehicle 104. The charging station 112 may assign the other charging station to the second destination and redirect the vehicle 104 to proceed to the second destination.

[0047] In another embodiment, the charging station 112 may determine that the first portion 116 of the stored energy is less than a threshold. For example, the threshold may represent a minimum increment of the stored energy to be transferred in order to be cost-effective or efficient in some way. Therefore, the first portion 116 of the stored energy may not initially meet the threshold. In response, the charging station 112 may redirect another transport along a second route that is longer than the first route, wherein the second route may include the original route assigned to the transport 104. In this context, the transport 104 and the other transport may be part of a package delivery service, wherein both transports may be associated with the charging station 112. By redirecting the other transport along the original route assigned to the transport 104, the package delivery requirements may still be met while allowing the transport 104 to consume less stored energy 108. The charging station 112 may then redirect the transport 104 to take a shorter route to the charging station 112. In a preferred embodiment, the shorter route may cause one or both of the first portion 116 of stored energy or the actual amount of energy to exceed a threshold, thereby making redirection efficient or cost-effective.

[0048] In another embodiment, the charging station 112 or charging system (CS) can inform the vehicle 104 that although the vehicle 104 may request the remaining driving distance capacity (in the form of stored energy 108) in the vehicle 104 after providing energy, the charging station 112 may leave the requested driving distance + / - the distance surplus. The CS may know the destination of the vehicle 104. Alternatively, the CS may infer the destination through the ID# or vehicle identification number (VIN), knowledge of the normal route of the vehicle 104, interaction with the driver's calendar application, etc. For example, the vehicle 104 may be returning to the original location due to the time of day, the normal route, etc. The vehicle 104 may request to leave a certain distance, but the CS may inform the driver that the driver actually needs a longer distance due to an accident on the highway on the way back. Machine learning and / or feedback loops can be used from the vehicle 104 on the road to the destination that may be the charging station 112.

[0049] In another embodiment, the driver may input the remaining distance and the system (CS) may infer something. For example, the CS may understand where the driver is going and needs 9.6 miles of charge instead of 8 miles (due to conditions such as accidents, hills, traffic, weather, location of other vehicles, etc.). As an example, the system may override what the vehicle 104 originally requested and may leave the vehicle 104 with 9.6 miles instead of the requested 8 miles.

[0050] In another example, a feedback loop may be utilized between the CS and the vehicle 104. The CS may have informed the previous vehicle that it required X miles to reach the destination or charging station 112. However, based on real-time data, the vehicle 104 may actually require X+2 miles. Thus, the current vehicle 104 may have a range that is adjusted based on the previous vehicle's request and actual usage. Real-time determinations may be made based on the previous vehicle's actual usage.

[0051] Figure 2A The transport network diagram 200 according to an example embodiment is illustrated.The network includes an element comprising a transport node 202 and a transport node 202', and the transport node 202 includes a processor 204, and the transport node 202' includes a processor 204'. The transport nodes 202, 202' communicate with each other via processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors and other elements that can provide communication. The communication between the transport nodes 202, 202' can occur directly, via private and / or public networks (not shown) or via other transport nodes and including one or more elements in processors, memory and software. Although depicted as a single transport node and processor, multiple transport nodes and processors can exist. One or more of the application, feature, step, solution etc. described and / or depicted herein can be utilized and / or provided by this element.

[0052] Figure 2BAnother vehicle network diagram 210 according to example embodiment is illustrated.This network comprises the element that comprises vehicle node 202 and vehicle node 202', and vehicle node 202 comprises processor 204, and vehicle node 202' comprises processor 204'.Vehicle node 202,202' communicates with each other via processor 204,204' and comprises transceiver, transmitter, receiver, storage device, sensor and other other elements (not shown) that can provide the element of communication.Communication between vehicle node 202,202' can directly, via private and / or public network (not shown) or via other vehicle nodes and comprise one or more elements in processor, memory and software and occur.Processor 204,204' can also communicate with one or more elements 230, and element 230 comprises sensor 212, wired device 214, wireless device 216, database 218, mobile phone 220, vehicle node 222, computer 224, I / O device 226 and voice application 228. The processors 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

[0053] Although depicted as a single transport node, processor and element, multiple transport nodes, processors and elements may exist. Information or communication may occur to any one of processor 204, 204' and element 230 and / or occur from any one of processor 204, 204' and element 230. For example, mobile phone 220 may provide information that may start transport node 202 to take action to processor 204, may also provide information or additional information that may start transport node 202' to processor 204', may also provide information or additional information to mobile phone 220, transport node 222 and / or computer 224. One or more of the application, feature, step, solution, etc. described and / or depicted herein may be utilized and / or provided by this element.

[0054] Figure 2C 240 according to an example embodiment. The network includes elements including a transport node 202, which includes a processor 204 and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer readable medium 242C and the element 230 (which is depicted in FIG. Figure 2B middle).

[0055] The processor 204 performs one or more of the following steps. In box 244C, the vehicle 104 initiates a request to the charging station 112 to provide the first portion 116 of the stored energy. The charging station 112 provides the stored energy 108 to the vehicle or vehicle 104 and may also receive a portion of the stored energy 108 from the vehicle 104. In box 246C, the vehicle 104 receives a notification 120 of the actual amount of energy from the charging station 112. In one embodiment, the charging station 112 calculates the actual amount of energy based on the first destination of the vehicle 104 and based on data received by the charging station 112 based on the route associated with the first destination. The actual amount of energy is not the same amount as the first portion of the stored energy. In box 248C, the vehicle 104 deposits the actual amount of energy 124 in the charging station 112. At this point, the excess stored energy 108 can be returned to the power grid.

[0056] The processor and / or computer readable medium may reside in whole or in part inside or outside of the transport node. The steps or features stored in the computer readable medium may be executed in whole or in part by any of the processors and / or elements in any order. In addition, one or more steps or features may be added, omitted, combined, performed at a subsequent time, etc.

[0057] Figure 3 A flowchart 300 is illustrated according to an example embodiment. Figure 3 , at box 302, the vehicle 104 initiates a request to the charging station 112 to provide a first portion 116 of stored energy. The charging station 112 provides the stored energy 108 to the vehicle or vehicle 104 and may also receive a portion of the stored energy 108 from the vehicle 104. At box 304, the charging station 112 determines an actual amount of energy. In one embodiment, the charging station 112 calculates the actual amount of energy based on a first destination of the vehicle 104 and based on data received by the charging station 112 based on a route associated with the first destination. The actual amount of energy is not the same amount as the first portion of the stored energy. At box 306, the vehicle 104 deposits the actual amount 124 of energy in the charging station 112. At this point, the excess stored energy 108 can be returned to the power grid.

[0058] Figure 4 A machine learning vehicle network diagram 400 is illustrated 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.

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

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

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

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

[0063] Figure 5BAn example vehicle configuration 550 for managing database transactions between various vehicles according to an example embodiment is illustrated. When a vehicle 525 reaches a state where it is necessary to share a service with another vehicle, the vehicle 525 can engage with another vehicle 508 to perform various actions such as sharing, transferring, obtaining a service call, etc. For example, the vehicle 508 may be scheduled for battery charging and / or may have a tire problem and may be on the way to pick up a package to be delivered. The transport processor 528 resides in the vehicle 508, and there is communication between the transport processor 528, the database 554, the transport processor 528, and the transaction module 552. The vehicle 508 can notify another vehicle 525 that is in its network and operates on its blockchain member service. The transport processor 526 resides in the vehicle 525, and there is communication between the transport processor 526, the database 530, the transport processor 526, and the transaction module 520. The vehicle 525 can then receive information from the vehicle 508 and / or a server (not shown) via a wireless communication request for performing a package pickup. The transaction is recorded in the transaction modules 552 and 520 of both vehicles. Points are transferred from vehicle 508 to vehicle 525, and the record of the transferred service is recorded in database 530 / 554 (assuming that the blockchains are different from each other) or in the same blockchain used by all members. Database 554 can be one of a SQL database, RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and can be on the vehicle, can be off the vehicle, can be directly accessible and / or can be accessible through a network.

[0064] Fig. 6A A blockchain architecture configuration 600 is illustrated according to an example embodiment. Fig. 6A , the blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, not all parties have access to a permissioned blockchain, but only those members with permissioned access to the blockchain data. Blockchain nodes participate in multiple activities, such as blockchain entry addition and verification processes (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 nodes 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.

[0065] When the transaction is received and approved by the consensus model specified by the member nodes, the blockchain transaction 620 is stored in the memory of the computer. The approved transaction 626 is stored in the current block of the blockchain and is submitted to the blockchain via a submission process that includes executing a hash of the data content of the transaction in the current block and referencing the previous hash of the previous block. Within the blockchain, there may be one or more smart contracts 630 that define the terms of the transaction agreement and actions such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc. included in the smart contract executable application code 632. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, what service features they are authorized / required to receive given their profile status, and whether to monitor their actions in subsequent events. For example, when a service event occurs and the user is riding in a vehicle, sensor data monitoring can be triggered, and specific parameters such as the vehicle power level can be identified as being above / below a specific threshold for a specific period of time, and the result can then be a change in the current state, which requires an alert to be sent to a management party (i.e., the vehicle owner, vehicle operator, server, etc.), so the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle state. The sensor data can also be the basis for vehicle event data 634 (such as (one or more) locations to be traveled, average speed, maximum speed, acceleration rate, whether there are any collisions, whether the expected route is taken, where the next destination is, whether safety measures are in place, whether the vehicle has enough power / fuel, etc.). All such information can be the basis for smart contract terms 630, which are then stored in the blockchain. For example, sensor thresholds stored in a smart contract can be used as the basis for whether a detected service is necessary and when and where the service should be performed.

[0066] Figure 6B FIG. 1 illustrates a shared ledger configuration according to an example embodiment. Figure 6B , blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application linked to a computing device and execution platform for specific transactions. Blockchain configuration 640 may include one or more applications that are linked to an application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contract, etc.), which may be created according to the customized configuration sought by the participating parties and may maintain its own state, control its own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via addition to the distributed ledger.

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

[0068] 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 who are attempting to access data entries. The blockchain may expose an interface that provides access to the virtual execution environment necessary for processing program code to engage with the physical infrastructure. Cryptographic trust services may be used to verify entries such as asset exchange entries and keep the information private.

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

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

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

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

[0073] Figure 6C FIG. 1 illustrates a blockchain configuration for storing blockchain transaction data according to an example embodiment. Figure 6C , an example configuration 660 enables a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that asks a vehicle service provider to share user profile rating information when a known and established user profile is attempting to rent a vehicle with an established rating profile. The server 666 may receive and process data related to service requirements for the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel / power, maintenance service, etc., a smart contract may be used to invoke rules, thresholds, sensor information collection, etc. that may be used to invoke a vehicle service event. Blockchain transaction data 670 is saved for each transaction, such as an access event, a subsequent update of the service status of the vehicle, an event update, etc. A transaction may include the parties, requirements (e.g., 18 years of age or older, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients permitted to access the event and host vehicle service, permissions / permissions, sensor data retrieved during vehicle event operations to record details of the next service event and identify the condition status of the vehicle, and thresholds for determining whether the service event is completed and whether the condition status of the vehicle has changed.

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

[0075] 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 can be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel it belongs to. The blockchain is a log of entries, structured as a sequence of hash-linked blocks where each block contains N entries. Blocks may include entries such as Fig.6D The blockchain can be stored on a peer file system (local or attached storage) that supports only add-on blockchain workloads.

[0076] 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 ever included in the chain entry log of the blockchain. Smart contract executable code calls execute entries against the current state in the state database. In order to make these smart contract executable code interactions extremely efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view in the entry log of the blockchain, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated when needed) after the peer node is started and before the entry is accepted.

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

[0078] The sorting service accepts endorsed entries, sorts them into blocks, and delivers blocks to commit peers. For example, the sorting service can start a new block when a threshold of entries has been reached, a timer has expired, or another condition has occurred. In this example, a blockchain node is a committing peer that has received a data block 682A for storage on the blockchain. The sorting service can consist of a cluster of sorters. The sorting service does not handle entries, smart contracts, or maintain shared ledgers. Specifically, the sorting service can accept endorsed entries and specify the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that a specific implementation of "sorting" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0079] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is performed by solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that best suits the network.

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

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

[0082] In some embodiments, block data 690A may also store transaction specific data 686A that adds additional information to the hash link chain of the block in the blockchain. Therefore, data 686A may be stored in an immutable log of the block on the distributed ledger. Some benefits of storing such data 686A are reflected in various embodiments disclosed and described herein. Block metadata 688A may store multiple fields of metadata (e.g., as byte arrays, etc.). The metadata field may include a signature created by the block, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, the last offset maintained by the sorting service for sorting the block, etc. The signature, the last configured block, and the 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, etc. The entry filter may include a byte array of size equal to the number of entries in the block data 610A and a verification code identifying whether the entry is valid / invalid.

[0083] The other blocks 682B to 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the headers 684A to 684n in the other blocks includes a hash value of the previous block. The hash value of the previous block can be just 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, tracking from the Nth block back 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.

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

[0085] An exemplary storage medium may be coupled to a processor such that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be integral with the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium may reside as separate components. For example, Figure 7An example computer system architecture 700 is illustrated, which may represent or be integrated in any of the above-described components, among others.

[0086] Figure 7 It is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the application described herein.In any event, computing node 700 is capable of being implemented and / or performing any of the functionality set forth above.

[0087] In computing node 700, there is a computer system / server 702, which can operate with numerous other general or special 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, fat 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 including any of the above systems or devices, etc.

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

[0089] like Figure 7 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. The components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor 704.

[0090] The bus represents one or more of any of a variety of 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 an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0091] Computer system / server 702 generally includes a variety of computer system readable media. Such media can be any available media accessible to computer system / server 702, and it includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements the flow charts of other figures. System memory 706 can 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 can also include other removable / non-removable, volatile / non-volatile computer system storage media. For example only, memory 706 can be provided for reading and writing non-removable non-volatile magnetic media (not shown and commonly referred to as "hard drive"). Although not shown, a disk drive for reading and writing a removable non-volatile disk (e.g., "floppy disk") and an optical disk drive for reading and writing a removable non-volatile optical disk (such as CD-ROM, DVD-ROM or other optical media) can be provided. In this case, each can be connected to the bus through one or more data media interfaces. As will be further depicted and described below, memory 706 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of various embodiments of the present application.

[0092] By way of example and not limitation, a program / utility having a set (at least one) of program modules may be stored in memory 706, as may 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. The program modules generally perform the functions and / or methods of various embodiments of the present application as described herein.

[0093] As will be appreciated by those skilled in the art, various aspects of the present application may be implemented as a system, method or computer program product. Therefore, various aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or a combination of software and hardware embodiments, which may generally all be referred to as "circuit", "module" or "system" in this article. In addition, various aspects of the present application may take the form of a computer program product implemented in one or more computer-readable media, with a computer-readable program code implemented on the computer-readable medium.

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

[0095] Although illustrated in the drawings and described in the foregoing detailed description, at least one exemplary embodiment of the system, method and non-transient computer-readable medium, it will be understood that the present application is not limited to the disclosed embodiments, but can be rearranged, modified and replaced as described and defined in the appended claims. For example, the capabilities of the systems of the various drawings can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include a transmitter, a receiver or a pair of the two. For example, all or part of the functions performed by each module can be performed by one or more of these modules. In addition, the functions described herein can be performed inside or outside the module or component, at various times and about various events. Moreover, the information sent between the various modules can be sent between the modules via at least one of the following: data network, Internet, voice network, Internet protocol network, wireless device, wired device and / or via multiple protocols. In addition, the message sent or received by any one of the modules can be sent or received directly and / or via one or more of the other modules.

[0096] Those skilled in the art will appreciate that a "system" may be implemented as a personal computer, server, console, personal digital assistant (PDA), cell phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0097] 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 a programmable hardware device such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0098] Modules may also be implemented at least in part with software to be performed by various types of processors. The unit of the executable code identified may for example include one or more physical or logical blocks of computer instructions that may for example be organized as an object, process or function. However, the executable file of the module identified need not be physically located together, but may include different instructions stored in different locations that include the module and realize the purpose of the module when these instructions are logically combined. In addition, modules may be stored on a computer-readable medium, which may be a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape or any other such medium for storing data.

[0099] In fact, the module of executable code can be a single instruction or multiple instructions, and can even be distributed on multiple different code segments, distributed between different programs and distributed across multiple memory devices. Similarly, operating data can be identified and illustrated in this article within the module, and can be implemented in any suitable form and can be organized in the data structure of any suitable type. Operating data can be collected as a single data set, or can be distributed in different locations, including distribution on different storage devices, and can be at least partially present in a system or network only as an electronic signal.

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

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

[0102] Although preferred embodiments of the present application have been described, it is to be understood that the described embodiments are merely illustrative and that the scope of the present application will be limited only by the appended claims when considered together with their full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method for unloading power of a transportation vehicle, comprising: Initiating a request by the vehicle to the charging station to provide a first portion of the stored energy; determining, by the charging station, an actual amount of energy that the vehicle can store in the charging station, wherein the determination is based on a first destination of the vehicle and data received by the charging station based on a route associated with the first destination, wherein the actual amount of energy is not the same amount as the first portion of the stored energy; as well as When the vehicle arrives at the charging station, the vehicle deposits the actual amount of energy in the charging station; Wherein, the method further comprises: calculating, by the transport, a change in the first portion at a plurality of intervals; and providing a notification including a change of the first portion to the charging station at one or more of the intervals; Wherein, the method further comprises: determining, by the charging station, that the first portion of the stored energy is less than a threshold value, wherein the threshold value represents a minimum increment of the stored energy to be transferred; redirecting another transport to take a second route that is longer than the first route, wherein the second route includes the original route assigned to the transport; and The vehicle is redirected to take a shorter route to a charging station, wherein the shorter route causes one or both of the first portion of stored energy or the actual amount of energy to exceed the threshold.

2. The method of claim 1 , wherein the request includes a distance to a first destination, wherein the method comprises: receiving, by the charging station, the request; calculating, by the charging station, a range surplus based on one or more of weather conditions, road conditions, road configuration, and conditions of the vehicle and a current location of the vehicle; Send the distance surplus to the transport; as well as The actual amount of energy used by the means of transport is increased by the amount of energy reflecting the distance surplus.

3. The method according to claim 1, comprising: calculating, by the charging station, one or more alternative routes to the first destination, wherein the one or more alternative routes include an actual amount of energy that is less than the first portion of the stored energy; determining a best alternative route, wherein the best alternative route comprises an alternative route of the one or more alternative routes having a lowest actual amount of energy compared to other alternative routes of the one or more alternative routes; as well as The transportation vehicle follows the best alternative route to the first destination.

4. The method according to claim 1, comprising: A notification is received by the transport providing an update of the first portion.

5. The method according to claim 1, comprising: receiving, by the charging station, a notification from the transportation vehicle that the transportation vehicle needs to make an additional trip after arriving at the charging station; The amount of energy used to carry out the additional journey is calculated by the charging station; as well as The actual amount of energy is reduced by the amount of energy used to perform the additional stroke.

6. The method according to claim 1, comprising: calculating, by the charging station, a second portion of the stored energy for the vehicle to reach another charging station, the second portion of the stored energy being less than the first portion of the stored energy; assigning another charging station to a second destination; as well as Redirect the transport to the second destination.

7. A means of transport, comprising: processor; as well as A memory coupled to the processor, the memory comprising instructions that when executed by the processor are configured to: Initiating a request by the vehicle to the charging station to provide a first portion of the stored energy; determining, by the charging station, an actual amount of energy that the vehicle can store in the charging station, wherein the charging station determines the actual amount of energy based on a first destination of the vehicle and data received by the charging station based on a route associated with the first destination, wherein the actual amount of energy is not the same amount as the first portion of the stored energy; and When the vehicle arrives at the charging station, the vehicle deposits the actual amount of energy in the charging station. The transport is also configured as: calculating a change in the first portion at a plurality of intervals; and providing a notification including a change of the first portion to the charging station at one or more of the intervals; The charging station is also configured as: determining that the first portion of the stored energy is less than a threshold value, wherein the threshold value represents a minimum increment of the stored energy to be transferred; redirecting another transport to take a second route that is longer than the first route, wherein the second route includes the original route assigned to the transport; as well as The vehicle is redirected to take a shorter route to a charging station, wherein the shorter route causes one or both of the first portion of stored energy or the actual amount of energy to exceed the threshold.

8. The vehicle of claim 7, wherein the request includes a distance to the first destination, wherein the charging station is further configured to: receiving the request; calculating a distance surplus based on one or more of weather conditions, road conditions, road configuration, and conditions of the transport and a current position of the transport; Send the distance surplus to the transport; as well as The actual amount of energy is increased by an amount reflecting the distance surplus energy.

9. The vehicle of claim 7, wherein the vehicle is further configured to: receiving a calculation of one or more alternative routes to a first destination, wherein the one or more alternative routes include an actual amount of energy that is less than a first portion of the stored energy; determining a best alternative route, wherein the best alternative route comprises an alternative route of the one or more alternative routes having a lowest actual amount of energy compared to other alternative routes of the one or more alternative routes; as well as Follow the best alternative route to your first destination.

10. The vehicle of claim 7, wherein the vehicle is further configured to: Receive notifications when updates to Part 1 are available.

11. The vehicle of claim 7, wherein the charging station is further configured to: receiving a notification from the transport that the transport needs to make an additional trip after the transport arrives at the charging station; calculating an amount of energy to perform the additional trip; and The actual amount of energy is reduced by the amount of energy used to perform the additional stroke.

12. The vehicle of claim 7, wherein the charging station is further configured to: calculating a second portion of the stored energy for the vehicle to reach another charging station, the second portion of the stored energy being less than the first portion of the stored energy; assigning another charging station to the second destination; and Redirect the transport to the second destination.

13. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform the method according to any one of claims 1-6.

Images