阅读说明：本技术 运输工具电量卸载管理 (Vehicle power offloading management ) 是由 N·卢 于 2021-04-20 设计创作，主要内容包括：本公开涉及运输工具电量卸载管理。示例操作包括以下中的一个或多个：由运输工具向充电站发起提供所存储能量的第一部分的请求；由充电站确定运输工具所需的能量的实际量,其中确定是基于运输工具的第一目的地以及由充电站基于与第一目的地相关联的路线所接收的数据,其中能量的实际量不是与所存储能量的第一部分相同的量；以及由运输工具将能量的实际量存放在充电站中。(The present disclosure relates to vehicle power offload management. Example operations include one or more of: initiating, by the vehicle, a request to provide a first portion of the stored energy to a charging station; 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 storing the actual amount of energy in the charging station by the vehicle.)

1. A method, comprising:

initiating, by the vehicle, a request to provide a first portion of the stored energy to a charging station;

determining, by a 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

the actual amount of energy is stored by the vehicle in a charging station.

2. The method of claim 1, wherein the request includes a distance to a first destination, wherein the method comprises:

receiving, by a charging station, the request;

calculating, by the charging station, a distance surplus based on one or more of the weather condition, the road configuration, and the condition of the vehicle, and the current location of the vehicle;

transmitting the distance surplus to the vehicle; and

the actual amount of energy is increased by the vehicle by an amount that reflects the distance surplus.

3. The method of 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 less than the first portion of stored energy;

determining an optimal alternative route, wherein the optimal alternative route comprises an alternative route of the one or more alternative routes that has a lowest actual amount of energy compared to other alternative routes of the one or more alternative routes; and

the optimal alternate route is followed by the vehicle to the first destination.

4. The method of claim 1, comprising:

receiving, by the vehicle, a notification providing an update of the first portion;

calculating, by the vehicle, changes in the first portion at a plurality of intervals; and

providing a notification including a change to the first portion at one or more of the intervals.

5. The method of claim 1, comprising:

receiving, by the charging station from the vehicle, a notification that the vehicle requires additional travel after reaching the charging station;

calculating, by the charging station, an amount of energy for making the additional trip; and

the actual amount of energy is reduced by the amount of energy used to make the additional stroke.

6. The method of 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; and

redirecting the vehicle to a second destination.

7. The method of claim 1, comprising:

determining, by the charging station, that the first portion of the stored energy is less than the threshold;

redirecting another vehicle to take a second route that is longer than the first route, wherein the second route comprises the original route assigned to the vehicle; and

the vehicle is redirected to take a shorter route to a charging station.

8. A vehicle, comprising:

a processor; and

a memory coupled to the processor, the memory including instructions that when executed by the processor are configured to:

initiating, by the vehicle, a request to provide a first portion of the stored energy to a charging station;

determining, by the charging station, an actual amount of energy required by the vehicle, wherein the charging station determines that the actual amount of energy 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

the actual amount of energy is stored by the vehicle in a charging station.

9. The vehicle of claim 8, wherein the request includes a distance to a 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 configurations, and conditions of the vehicle, and a current location of the vehicle;

transmitting the distance surplus to the vehicle; and

the actual amount of energy is increased by an amount that reflects the distance surplus.

10. The vehicle of claim 8, wherein the vehicle is further configured to:

receiving a calculation of one or more alternative routes to the first destination, wherein the one or more alternative routes include an actual amount of energy less than the first portion of stored energy;

determining an optimal alternative route, wherein the optimal alternative route comprises an alternative route of the one or more alternative routes that has a lowest actual amount of energy compared to other alternative routes of the one or more alternative routes; and

the best alternative route is followed to the first destination.

11. The vehicle of claim 8, wherein the vehicle is further configured to:

receiving a notification providing an update of the first portion;

calculating changes to the first portion at a plurality of intervals; and

providing a notification including a change to the first portion at one or more of the intervals.

12. The vehicle of claim 8, wherein the charging station is further configured to:

receiving a notification from the vehicle that the vehicle requires additional travel after the vehicle reaches the charging station;

calculating an amount of energy for making an additional stroke; and

the actual amount of energy is reduced by the amount of energy used to make the additional stroke.

13. The vehicle of claim 8, wherein the charging station is further configured to:

calculating a second portion of stored energy for the vehicle to reach another charging station, the second portion of stored energy being less than the first portion of stored energy;

assigning another charging station to a second destination; and

redirecting the vehicle to a second destination.

14. The vehicle of claim 8, wherein the charging station is further configured to:

determining that the first portion of the stored energy is less than a threshold;

redirecting another vehicle to take a second route that is longer than the first route, wherein the second route comprises the original route assigned to the vehicle; and

the vehicle is redirected to take a shorter route to a charging station.

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

Technical Field

The present disclosure relates to vehicle power offload management.

Background

Vehicles (vehicles) or transport vehicles (transports), such as cars, motorcycles, trucks, planes, trains, etc., typically provide transport needs to passengers and/or cargo in various ways. The functions associated with the vehicle may be identified and utilized by various computing devices, such as smartphones or computers located on and/or off the vehicle.

Disclosure of Invention

One example embodiment provides a method comprising one or more of: initiating, by the vehicle, a request to provide a first portion of the stored energy to a charging station; 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 storing the actual amount of energy in the charging station by the vehicle.

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 the following: initiating, by the vehicle, a request to provide a first portion of the stored energy to a charging station; determining, by the charging station, an actual amount of energy required by the vehicle, wherein the charging station determines that the actual amount of energy 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 storing the actual amount of energy in the charging station by the vehicle.

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, by the charging station, the request; calculating, by the charging station, a distance surplus based on one or more of the weather condition, the road configuration, and the condition of the vehicle, and the current location of the vehicle; transmitting the distance surplus to the vehicle; and increasing, by the vehicle, the actual amount of energy by an amount of energy reflecting the distance surplus.

Drawings

FIG. 1 illustrates an example system for vehicle power offloading, according to an example embodiment.

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

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

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

Fig. 3 illustrates a flow diagram according to an example embodiment.

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

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

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

Fig. 6A illustrates a blockchain architecture configuration according to an example embodiment.

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

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

FIG. 6D illustrates an example data block, according to an example embodiment.

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

Detailed Description

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

The features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, use of the phrases "example embodiments," "some embodiments," or other similar language, refers to at least the following facts throughout this specification: a particular feature, structure, or characteristic described in connection with the embodiments may be included within one embodiment. Thus, appearances of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout this specification are not necessarily all referring to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the drawings, any connection between elements may allow for unidirectional and/or bidirectional communication, even though the depicted connection is a unidirectional or bidirectional arrow. In the current solution, the transportation means may include one or more of an automobile, a truck, a pedestrian-Battery Electric Vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that may be used to transport people and/or cargo from one location to another.

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

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

Within the communication infrastructure, a decentralized database is a distributed storage system comprising a plurality of nodes in communication with each other. Blockchains are examples of decentralized databases that include only added immutable data structures (i.e., distributed ledgers) that can hold records between untrusted parties. The untrusted party is referred to herein as a peer (peer), a node, or a peer node. Each peer maintains a copy of the database record and no single peer can modify the database record without agreement between the distributed peers. For example, a peer may perform a consensus protocol to verify blockchain store entries, group store entries into chunks, and build hash chains via chunks. For consistency, the process forms the ledger by ordering the stored entries as necessary. In public or license-free blockchains, anyone can participate without a specific identification. The common blockchain may involve cryptocurrency and use consensus based on various protocols such as proof of work (PoW). On the other hand, license blockchain databases provide a system that can ensure interactions such as the exchange of funds, goods, information, etc. between a group of entities that share a common goal but do not or cannot sufficiently trust each other. The present solution may play a role in licensed and/or unlicensed blockchain settings.

Smart contracts are trusted distributed applications that take advantage of the tamper-resistant nature of a shared or distributed ledger (i.e., which may be in the form of a blockchain) database and the underlying protocol between member nodes, referred to as an endorsement or endorsement policy. Typically, blockchain entries are "endorsed" before being committed to the blockchain, while entries that are not endorsed are ignored. Typical endorsement policies allow intelligent contract executable code to specify an endorser for an entry in the form of a set of peer nodes necessary for endorsement. When the client sends an entry to the peer specified in the endorsement policy, the entry is executed to validate the entry. After verification, the entries enter a sorting phase in which a consensus protocol is used to generate a sorted sequence of endorsed entries grouped into blocks.

A node is a communication entity of the blockchain system. A "node" may perform a logical function in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. The nodes may comprise different types, such as client or submission client nodes that submit an entry call to an endorser (e.g., peer) and broadcast an entry proposal to a ranking service (e.g., ranking node). Another type of node is a peer node that can receive an entry submitted by a client, submit the entry and maintain a state and copy of the blockchain destination ledger. Peers may also function as endorsers, although this is not a requirement. A ranking service node or ranker is a node that runs communication services for all nodes and implements a delivery guarantee, such as a broadcast to each peer node in the system when submitting an entry and modifying the world state of a blockchain, the delivery guarantee being another name for the original blockchain purpose that normally includes control and setup information.

The ledger is an ordered, tamper-resistant record of all state transitions of the blockchain. The state transition may be caused by an intelligent contract executable code call (i.e., entry) submitted by a participant (e.g., client node, sequencing node, endorser node, peer node, etc.). An entry may result in a collection of asset key-value pairs (asset _ value _ pair) that are submitted to the ledger as one or more operands (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. There is typically one book per channel. Each peer node maintains a copy of the accounting for each channel of which it is a member.

A chain is a log of entries structured as hash-linked chunks, and each chunk contains a sequence of N entries, where N is equal to or greater than 1. The chunk header includes a hash of the entry of the chunk and a hash of the header of the previous chunk. In this way, all entries on the ledger can be ordered and cryptographically linked together. Thus, it is not possible to tamper with the ledger data without destroying the hash link. The hash of the most recently added blockchain chunk represents every entry on the chain that comes before it, making it possible to ensure that all peers are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the additive-only nature of the blockchain workload.

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

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

Example embodiments provide a way to provide vehicle services to a particular vehicle and/or request a user associated with a user profile applied to the vehicle. For example, the user may be an owner of the vehicle or an operator of a vehicle owned by another party. The vehicle may require service at certain intervals, and the service requirements may require authorization before permitting receipt of the service. Additionally, the service center may provide services to vehicles in the vicinity based on the vehicle's current route plan and the relative levels of service demand (e.g., immediate, severe, medium, minimal, etc.). Vehicle demand may be monitored via one or more sensors that report sensed data to a central controller computer device in the vehicle, which in turn is forwarded to a management server for inspection and action.

The sensor may be located one or more of inside the vehicle, outside the vehicle, on a stationary object remote from the vehicle, and on another vehicle proximate to the vehicle. The sensors may also be associated with the speed of the vehicle, the brakes of the vehicle, the acceleration of the vehicle, the fuel level, service requirements, gear shifting of the vehicle, steering of the vehicle, etc. The concept of a sensor may also be a device such as a mobile device. Additionally, the sensor information may be used to identify whether the vehicle is operating safely and whether the occupant user is engaged in any unexpected vehicle condition (such as during a vehicle access period). Vehicle information collected before, during, and/or after vehicle operation can be identified and stored in transactions on the shared/distributed ledger, which can be generated and submitted to an immutable ledger determined by the licensing authority affiliation and thus in a "decentralized" manner, such as via a blockchain member group.

Each interested party (e.g., company, agent, etc.) may wish to limit exposure of private information, and thus the blockchain and its inflexibility may limit exposure and administrative permissions for each particular user vehicle profile. Smart contracts may be used to provide compensation, quantify user profile scores/ratings/reviews, apply vehicle event permissions, determine when services are needed, identify collision and/or degradation events, identify security issue events, identify event participants, and provide distribution to registered entities seeking access to such vehicle event data. Additionally, results may be identified and necessary information may be shared between registered companies and/or individuals based on a "consensus" method associated with the blockchain. This approach cannot be implemented on a traditional centralized database.

Autonomous driving systems may utilize software, sensor arrays, and machine learning functions, lidar projectors, radar, ultrasonic sensors, etc. to create maps of terrain and roads that a vehicle may use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. may also be used in autonomous vehicles instead of lidar.

In certain embodiments, the present solution includes authorizing services for vehicles via an automatic and fast authentication scheme. For example, driving up to a charging station or fuel pump may be performed by the vehicle operator, and if the service station receives authorization to receive the amount of electricity or fuel, the authorization may be performed without any delay. The vehicle may provide a communication signal that provides an identification of the vehicle with a currently active (active) profile linked to an account that may be authorized to accept services that may be subsequently corrected by compensation. Additional measures may be used to provide further authentication, such as another identifier may be wirelessly transmitted from the user's device to the service center to replace or supplement the first authorization job between the vehicle and the service center with additional authorization jobs.

The shared and received data may be stored in a database that maintains the data in a single database (e.g., a database server) and typically at a particular 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 the centralized database is typically accessible from a number of different points. A centralized database is easy to manage, maintain and control because of its single location, especially for security purposes. Within 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 primary record.

Fig. 1 illustrates an example system 100 for vehicle power offloading, according to an example embodiment. The vehicle 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 vehicle or vehicle 104 receives electrical energy at a charging station 112. In another embodiment, the vehicle or vehicle 104 may receive electrical energy from a solar panel or other device associated with the vehicle or vehicle 104. In yet another embodiment, the vehicle or vehicle 104 may receive electrical energy from either or both of the charging station 112 and/or a solar panel or other device associated with the vehicle or vehicle 104. The stored energy 108 may be gradually depleted as the vehicle or vehicle 104 travels around, which limits the driving range of the vehicle or vehicle 104. Thus, the driving range is maximized when the stored energy 108 is at the maximum capacity of the battery.

At times, the vehicle 104 or the driver or owner of the vehicle 104 may be motivated to transfer some of the unused portion of the stored energy 108 back to the charging station 112. The charging station 112 may be physically located in its residence, located near the residence, or at potentially many locations near the residence. In some embodiments, the vehicle 104, owner, or driver may receive some credit (credit) as a reward for transferring back to a portion of the stored energy 108. Thus, the vehicle 104 or owner/driver may be motivated to seek opportunities to transfer back to unused energy. For example, the vehicle 104 may commute to a work site located a distance away from the residence on each weekday and may receive a full charge of stored energy 108 at night. When returning from the work site at a later time of the day, the driver may know that they do not need to make any additional stops or trips either on the way home or on the way to the charging station 112. Thus, they may recognize the opportunity to transfer back to the first portion of 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, the charging station 112 may provide a notification 120 of the actual amount of energy to the vehicle 104.

After receiving the request 116, the charging station 112 may next determine the actual amount of energy required by the vehicle 104. The determination may be based on the first destination of the vehicle 104 and data received by the charging station 112 based on a route associated with the first destination. The actual amount of energy may not be the same amount of energy as the first portion of stored energy. In one embodiment, the actual amount of energy may comprise less energy than the first portion of 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 comprise more energy than the first portion of stored energy. For example, the charging station 112 may determine that the first portion of the stored energy is determined too conservatively. In yet another embodiment, the actual amount of energy may comprise the same amount of energy as the first portion of stored energy.

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 require some form of recharging the stored energy 108 to continue traveling, have a certain amount of stored energy 108 remaining to reach another charging station 112, or have a certain amount of stored energy 108 remaining to complete one or more trips to an alternate destination.

In one embodiment, the request 116 may include a distance to the first destination. The charging station 112, in response to the request 116, may calculate a distance surplus (supplus) based on any of the weather conditions, road configuration, or conditions of the vehicle 104, and the current location of the vehicle 104. For example, a degraded weather report or a primarily 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 corresponding to the distance surplus, and thereby deposit the increased amount of energy 124.

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

In another embodiment, the vehicle 104 may receive a notification that provides an update to the first portion 116 of the stored energy. At various intervals, the vehicle 104 may calculate a change in the first portion of the stored energy. The interval may be a time interval, for example, every minute. The interval may also be a distance interval, for example, every mile. The spacing 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 exit ramp with another road from the current road (such as along an expressway). By recalculating the first portion of the stored energy at intervals, the vehicle 104 has an 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 first portion 116 updates at each interval. In another embodiment, the vehicle 104 may only provide the first portion 116 update 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 the charging station 112. In response to receiving the first portion 116 update at the interval, the charging station 112 may recalculate the actual amount of stored energy, which is provided back to the transport 104 as a notification 120.

In another embodiment, the charging station 112 may receive a notification from the vehicle 104 that the vehicle 104 requires additional travel after reaching the charging station 112. The charging station 112 then calculates an amount of energy for the 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. A notification 120 of the actual amount of reduced energy may then be provided to the vehicle 104.

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

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 stored energy to be transferred in order to be cost-effective or effective in some way. Thus, the first portion 116 of the stored energy may not initially satisfy the threshold. In response, the charging station 112 may redirect another vehicle to travel along a second route that is longer than the first route, where the second route may include the original route assigned to the vehicle 104. In this context, the vehicle 104 and other vehicles may be part of a package delivery service, where both vehicles may be associated with a charging station 112. By redirecting other vehicles along the original route assigned to the vehicle 104, package dispatch requirements may still be met while allowing the vehicle 104 to consume less of the stored energy 108. The charging station 112 may then redirect the vehicle 104 to take a shorter route to the charging station 112. In a preferred embodiment, the shorter route may result in one or both of the first portion 116 of stored energy or the actual amount of energy exceeding a threshold, making the redirection effective or cost-effective.

In another embodiment, the charging station 112 or Charging System (CS) may inform the vehicle 104 that the charging station 112 may leave a +/-distance surplus for the requested driving distance, although the vehicle 104 may request the driving distance capacity remaining in the vehicle 104 (in the form of the stored energy 108) after providing the energy. The CS may know the destination of the vehicle 104. Alternatively, the CS may infer the destination by ID # or Vehicle Identification Number (VIN), knowing the normal route of the vehicle 104, interaction with the driver's calendar application, and the like. For example, the vehicle 104 may be returning to the original location due to time of day, normal route, etc. The vehicle 104 may request a certain distance to be left, 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 may be used from the vehicle 104 on the road to the destination, which may be a charging station 112.

In another embodiment, the driver may enter the remaining distance and the system (CS) may infer something. For example, the CS may know where the driver is going and needs 9.6 miles of power instead of 8 miles of power (due to conditions such as accidents, hills, traffic, weather, location of other vehicles, etc.). As an example, the system may override the content originally requested by the vehicle 104 and may leave the vehicle 104 9.6 miles instead of the requested 8 miles.

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 needs X miles to reach the destination or charging station 112. However, from real-time data, the vehicle 104 may actually require X +2 miles. Thus, the current vehicle 104 may have a distance that is adjusted based on the request and actual use of the previous vehicle. The real-time determination may be made based on actual usage of previous vehicles.

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

Fig. 2B illustrates another vehicle network diagram 210 according to an example embodiment. The network includes elements including a vehicle node 202 and a vehicle node 202 ', the vehicle node 202 including a processor 204, the vehicle node 202 ' including a processor 204 '. The vehicle nodes 202, 202 'communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between the vehicle nodes 202, 202' may occur directly, via private and/or public networks (not shown), or via other vehicle nodes and elements including one or more of processors, memory, and software. The processors 204, 204' may also communicate with one or more elements 230, the elements 230 including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicle nodes 222, computers 224, I/O devices 226, and voice applications 228. The processor 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

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

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

The processor 204 performs one or more of the following steps. In block 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 block 246C, the vehicle 104 receives the 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 a route associated with the first destination. The actual amount of energy is not the same amount as the first portion of stored energy. In block 248C, the vehicle 104 stores the actual amount of energy 124 in the charging station 112. At this point, excess stored energy 108 may be returned to the power grid.

The processor and/or computer readable medium may reside, completely or partially, within or outside of the vehicle 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. Additionally, one or more steps or features may be added, omitted, combined, performed at a later time, and so forth.

Fig. 3 illustrates a flow diagram 300 according to an example embodiment. Referring to fig. 3, at block 302, 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. At block 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 the 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 stored energy. At block 306, the vehicle 104 stores the actual amount of energy 124 in the charging station 112. At this point, excess stored energy 108 may be returned to the power grid.

Fig. 4 illustrates a machine learning vehicle network diagram 400, according to an example embodiment. The network 400 includes a vehicle node 402 that interfaces with a machine learning subsystem 406. The vehicle node includes one or more sensors 404.

Machine learning subsystem 406 contains learning model 408, learning model 408 being a mathematical product created by machine learning training system 410, machine learning training system 410 generating predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 resides in the vehicle node 402. In other embodiments, the machine learning subsystem 406 resides outside of the vehicle node 402.

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

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

Fig. 5A illustrates an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Referring to fig. 5A, when a particular vehicle/vehicle 525 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 according to the transaction(s). The vehicle processor 526 resides in the vehicle 525 and communication exists between the vehicle processor 526, the database 530, the vehicle processor 526 and the transaction module 520. The transaction module 520 may record information such as assets, parties, points, service descriptions, dates, times, locations, results, notifications, incidents, and the like. Those transactions in the transaction module 520 may be copied into the database 530. Database 530 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed book, and may be on-board the transport, may be off-board the transport, may be directly accessible and/or accessible over a network, or may be accessible to the transport.

Fig. 5B illustrates an example vehicle configuration 550 for managing database transactions conducted between various vehicles, according to an example embodiment. When the vehicle 525 reaches a state requiring sharing of services with another vehicle, the vehicle 525 may engage with another vehicle 508 to perform various actions such as sharing, transferring, obtaining a service call, and the like. For example, the vehicle 508 may be scheduled for battery charging and/or may be tire-questionable and may be in the route to pick up the package to be delivered. The vehicle processor 528 resides in the vehicle 508 and communication exists between the vehicle processor 528, the database 554, the vehicle processor 528, and the transaction module 552. The vehicle 508 can notify another vehicle 525 operating in its network and on its blockchain member services. The vehicle processor 526 resides in the vehicle 525 and communication exists between the vehicle processor 526, the database 530, the vehicle processor 526 and the transaction module 520. The vehicle 525 may then receive information from the vehicle 508 and/or a server (not shown) via a wireless communication request for performing package pickup. The transactions are recorded in the transaction modules 552 and 520 of both vehicles. Points are transferred from vehicle 508 to vehicle 525 and a record of the transferred service is recorded in database 530/554 (assuming the blockchains are different from each other) or in the same blockchain used by all members. The database 554 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed book, and may be on-board the vehicle, may be off-board the vehicle, may be directly accessible, and/or accessible over a network.

Fig. 6A illustrates a blockchain architecture configuration 600, according to an example embodiment. Referring to fig. 6A, a blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 that are part of a blockchain set 610. In one example embodiment, not all parties can access the licensed blockchain, and only those members that have licensed access to the blockchain data can access the licensed blockchain. The blockchain nexus participates in a number of 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. The blockchain link point may initiate a blockchain action (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.

Blockchain transaction 620 is stored in the memory of the computer when the transaction is received and approved by the consensus model specified by the member node. Approved transaction 626 is stored in the current chunk of the blockchain and submitted to the blockchain via a submission process that includes performing a hash of the data content of the transaction in the current chunk and referencing a previous hash of the previous chunk. Within the blockchain, there may be one or more intelligent contracts 630, the intelligent contracts 630 defining terms of transaction agreements and actions included in the intelligent contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, and the like. The code may be configured to identify whether the requesting entity is registered to receive vehicle services, which 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 a user is riding in a vehicle, sensor data monitoring may be triggered and a particular parameter such as vehicle charge level may be identified as above/below a particular threshold for a particular period of time, and the result may then be a change in current state that requires an alert to be sent to a management party (i.e., vehicle owner, vehicle operator, server, etc.), so that the service may be identified and stored for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle state. The sensor data may also be the basis for vehicle event data 634, such as location(s) to be traveled, average speed, top speed, acceleration rate, whether there are any collisions, whether an expected route is being taken, where the next destination is, whether safety measures are in place, whether the vehicle has sufficient charge/fuel, etc. All such information may be the basis for the intelligent contract terms 630, with the intelligent contract terms 630 then being stored in the blockchain. For example, sensor thresholds stored in the smart contract may be used as a basis for whether a detected service is necessary and when and where the service should be performed.

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

The smart contract application code 644 provides the basis for blockchain transactions by establishing application code that, when executed, causes transaction terms and conditions to become active. Smart contracts 630, when executed, cause certain approved transactions 626 to be generated, which approved transactions 626 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 as memory that stores transactions and intelligent contracts in a blockchain.

The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure that may be used to receive and store new entries and provide access to an auditor (editor) that is attempting to access the data entries. The blockchain may expose an interface that provides access to the virtual execution environment necessary for the handler code to participate in the physical infrastructure. Cryptographic trust services may be used to verify items such as asset exchange items and keep information private.

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

Within the intelligent contract executable code, an intelligent contract may be created via a high-level application and programming language and then written to a block in a block chain. The 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 the execution of intelligent contract code that may be executed in response to satisfying a condition associated with an intelligent contract. Execution of the intelligent contract may trigger trusted modification(s) of the state of the digital blockchain ledger. The modification(s) to the blockchain ledger resulting from execution of the intelligent contract may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

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

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

Fig. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. Referring to fig. 6C, 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., a blockchain) 668. The server may represent a service provider entity that queries the vehicle service provider to share user profile rating information if a known and established user profile is attempting to rent a vehicle having an established rating profile. The server 666 can receive and process data related to the service requirements of the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel/electricity, maintenance services, etc., a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., that may be used to invoke the vehicle service event. Blockchain transaction data 670 is maintained for each transaction, such as an access event, subsequent updates to the service state of the vehicle, event updates, and the like. The transaction may include parties, requirements (e.g., year of age 18, candidates meeting service conditions, valid driver licenses, etc.), compensation levels, distances traveled during the event, registered recipients permitted to access the event and host vehicle services, permissions/permissions, sensor data retrieved during vehicle event operations to record details of a next service event and identify a condition state of the vehicle, and thresholds for determining whether the service event is complete and whether the condition state of the vehicle has changed.

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

The system includes a blockchain that stores immutable ordered records in blocks and a state database (current world state) that maintains the current state of the blockchain. There may be one distributed accounting per channel, and each peer keeps its own copy of the distributed accounting for each channel to which it belongs. The present blockchain is a log of entries constructed as hash-linked blocks where each block contains a sequence of N entries. The blocks may include various components such as those shown in fig. 6D. The linking of the blocks may be generated by adding a hash of the header of the previous block in the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Furthermore, because of the linking, the newest chunk in the chunk chain represents each entry that comes before it. The present blockchain may be stored on a peer file system (local or attached storage) that supports only added blockchain workloads.

The current state of the blockchain and the distributed ledger may be stored in a state database. Here, the current state data represents the latest values of all keys once included in the chain entry log of the block chain. The smart contract executable code calls an execution entry for 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 a state database. The state database may include the indexed view in a log of entries in the blockchain so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated when needed) after the peer node boots, before the entry is accepted.

The endorsement node receives the entry from the client and endorses the entry based on the simulation result. The endorsement node holds an intelligent contract that simulates the proposal of the entry. When an endorsement node endorses an entry, the endorsement node creates an entry endorsement, the entry endorsement being a signed response from the endorsement node to the client application that indicates the endorsement that simulated the entry. The method of endorsement of an entry depends on an endorsement policy that may be specified within the intelligent contract executable code. An example of an endorsement policy is "most endorsement peers must endorse an entry". Different channels may have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

The sorting service accepts endorsed entries, sorts them into tiles, and delivers the tiles to the submitting peers. For example, the ordering service may initiate a new chunk when a threshold of entries has been reached, a timer has expired, or another condition. In this example, a chunk chain link point is a commit peer that has received a data chunk 682A for storage on the chunk chain. The ranking service may consist of a cluster of rankers. The ranking service does not process items, smart contracts, or maintain shared accounts. Specifically, the ranking service may accept endorsed entries and specify the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

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

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

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

In some embodiments, chunk data 690A may also store transaction specific data 686A that adds additional information to the hashed link chain of chunks in the chunk chain. Thus, data 686A may be stored in an immutable log of the blocks on the distributed journal. Some of the benefits of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. Chunk metadata 688A may store a plurality of fields of metadata (e.g., as an array of bytes, etc.). The metadata fields may include a signature of the chunk creation, a reference to the last configured chunk, an entry filter identifying valid and invalid entries within the chunk, a last offset maintained by the ordering service for the chunk ordering, and the like. Signatures, last configuration tiles, and sorter metadata may be added by a sorting service. Meanwhile, the submitter of the block (such as a blockchain node) may add validity/invalidity information based on an endorsement policy, validation of read/write sets, and the like. The entry filter may include an array of bytes equal in size to the number of entries in block data 610A and a validation code that identifies whether the entry is valid/invalid.

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

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 embodied on a computer readable medium such as a storage medium. For example, the computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

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

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

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

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

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

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

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

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 well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networked environment. The program modules generally perform the functions and/or methods of the various embodiments of the present application as described herein.

As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied in the computer-readable media.

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

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

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

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

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

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

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

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

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