Decentralized power exchange

Abstract

To provide decentralized power exchange.SOLUTION: An example operation includes one or more of: determining an inability for an entity to provide electricity over a threshold to an area; determining available energy greater than the threshold from a group of electric vehicles from locations currently receiving energy in the area and a group of energy storage units in the area; and providing the determined available energy to locations not currently receiving energy from the entity.SELECTED DRAWING: Figure 1A

Description

Background Art

[0001] Generally, vehicles or means of transportation, such as passenger cars, motorcycles, trucks, airplanes, trains, provide transportation needs for passengers and / or goods in various ways. Functions related to the means of transportation can be identified and utilized by various computing devices, such as smartphones or computers, located on or away from the means of transportation.

Summary of the Invention

[0002] An exemplary embodiment provides a method including one or more of determining that an entity cannot provide electricity exceeding a threshold for an area, determining available energy exceeding the threshold from a group of electric vehicles in the area currently receiving energy and a group of energy storage units in the area, and providing the determined available energy from the entity to locations not currently receiving energy.

[0003] Another exemplary embodiment provides a system including a memory communicatively connected to a processor, the processor performing one or more of determining that an entity cannot provide electricity exceeding a threshold for an area, determining available energy exceeding the threshold from a group of electric vehicles in the area currently receiving energy and a group of energy storage units in the area, and providing the determined available energy from the entity to locations not currently receiving energy.

[0004] A further exemplary embodiment provides a computer-readable storage medium comprising instructions, the instructions which, when read by a processor, cause the processor to perform one or more of the following actions: determine that an entity is unable to supply electricity to an area in excess of a threshold; determine that there is available energy in excess of a threshold from a group of electric vehicles and a group of energy storage units in the area that are currently receiving energy from locations within the area; and provide the determined available energy to locations that are not currently receiving energy from the entity. [Brief explanation of the drawing]

[0005] [Figure 1A] This figure shows an exemplary system for providing a distributed power exchange according to an exemplary embodiment. [Figure 1B] This figure shows a further exemplary system for providing a distributed power exchange according to an exemplary embodiment. [Figure 1C] This figure shows a further exemplary system for providing a distributed power exchange according to an exemplary embodiment. [Figure 2A] This figure shows a transportation network diagram according to an exemplary embodiment. [Figure 2B] This figure shows another transportation network diagram according to an exemplary embodiment. [Figure 2C] This figure shows yet another transportation network diagram according to an exemplary embodiment. [Figure 2D] This figure shows a further transportation network diagram according to an exemplary embodiment. [Figure 2E] This figure shows a diagram of an additional transportation network according to an exemplary embodiment. [Figure 2F] This figure shows a diagram illustrating the power supply of one or more elements according to an exemplary embodiment. [Figure 2G] This figure shows a diagram illustrating the interconnection between different elements according to an exemplary embodiment. [Figure 2H]This figure shows a further diagram illustrating the interconnections between different elements according to an exemplary embodiment. [Figure 2I] This figure shows additional diagrams illustrating the interconnections between elements according to an exemplary embodiment. [Figure 2J] This figure shows additional diagrams illustrating a keyless entry system according to an exemplary embodiment. [Figure 2K] This figure shows additional diagrams illustrating a CAN within a transport means according to an exemplary embodiment. [Figure 2L] This figure shows an additional diagram illustrating an end-to-end communication channel according to an exemplary embodiment. [Figure 2M] This figure shows additional diagrams illustrating an example of a transportation means that performs secure V2V communication using security certificates, according to an exemplary embodiment. [Figure 2N] This figure shows additional diagrams illustrating an example of a transport means that interacts with a security processor and a wireless device, according to an exemplary embodiment. [Figure 3A] This figure shows a flowchart according to an exemplary embodiment. [Figure 3B] This figure shows another flowchart according to an exemplary embodiment. [Figure 3C] This figure shows yet another flowchart according to an exemplary embodiment. [Figure 4] This figure shows a network diagram of a machine learning transport means according to an exemplary embodiment. [Figure 5A] This figure shows an exemplary vehicle configuration for managing database transactions associated with a vehicle, according to an exemplary embodiment. [Figure 5B] This figure shows another exemplary vehicle configuration for managing database transactions that occur between various vehicles, according to an exemplary embodiment. [Figure 6A] This figure shows a blockchain architecture configuration according to an exemplary embodiment. [Figure 6B] This figure shows another blockchain configuration according to an exemplary embodiment. [Figure 6C] This figure shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment. [Figure 6D] This figure shows an exemplary data block according to an exemplary embodiment. [Figure 7] This figure shows an exemplary system supporting one or more of the exemplary embodiments. [Modes for carrying out the invention]

[0006] It will be readily apparent that the components described herein and shown in the figures can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, computer-readable storage medium, and system, as shown in the accompanying figures, is not intended to limit the scope of the claimed application, but merely represents a selected embodiment. The multiple embodiments described herein are not intended to limit the scope of the solution. The computer-readable storage medium may be a non-temporary computer-readable medium or a non-temporary computer-readable storage medium.

[0007] Communication between a means of transport and certain entities such as remote servers, other means of transport, and local computing devices (e.g., smartphones, personal computers, computers embedded in the means of transport) may be transmitted and / or received and processed by one or more “components” which may be hardware, firmware, software, or a combination thereof. These components may be part of these entities or computing devices, or certain other computing devices. For example, consensus decisions relating to blockchain transactions may be made by one or more computing devices or components associated with the means of transport (which may be any elements described and / or depicted herein), as well as by one or more components located outside or away from the means of transport.

[0008] The functions, structures, or characteristics described in this specification can be combined in any suitable manner in one or more embodiments. For example, the use of phrases such as "exemplary embodiments", "some embodiments", or other similar terms throughout this specification indicates that the specific functions, structures, or characteristics described in relation to the embodiments can be included in at least one example. Therefore, even if phrases such as "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar terms appear throughout this specification, they do not necessarily all refer to the same group of embodiments, and the described functions, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the figures, any connection between elements can enable one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. In this solution, a vehicle or means of transportation can include one or more of a passenger car, truck, walking area battery electric vehicle (BEV), e-Palette, fuel cell bus, motorcycle, scooter, bicycle, boat, recreational vehicle, airplane, and any object that can be used to transport people and / or goods from one place to another.

[0009] In addition, although the term "message" may be used in the description of embodiments, other types of network data such as packets, frames, datagrams, etc. can also be used. Furthermore, specific types of messages and signal transmissions can be depicted in the preferred embodiments, but they are not limited to specific types of messages and signal transmissions.

[0010] Exemplary embodiments provide methods, systems, components, non-transient computer-readable media, devices, and / or networks that provide at least one of a means of transport (also referred to herein as a vehicle or passenger car), a data collection system, a data monitoring system, a verification system, an authentication system, and a vehicle data distribution system. Vehicle status data received in the form of communication messages, such as wireless data network communications and / or wired communication messages, may be processed to identify the status of a vehicle / means of transport and to provide feedback on the status and / or changes of the means of transport. In one example, a user profile may be applied to a particular means of transport / vehicle to approve current vehicle events, service outages at service stations, subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

[0011] In a communication infrastructure, a distributed database is a distributed storage system that includes multiple nodes that communicate with each other. A blockchain is an example of a distributed database and includes an append-only and immutable data structure (i.e., a distributed ledger) that can maintain records among untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no peer can modify the database records unless a consensus is reached among the distributed peers. For example, a peer can execute a consensus protocol to verify blockchain storage entries, group the storage entries into blocks, and construct a hash chain through the blocks. Through this process, the ledger is formed by ordering the storage entries as necessary for consistency. In a public or permissionless blockchain, anyone can participate without having specific identification information. A public blockchain can be involved in cryptocurrencies and can use consensus based on various protocols such as proof-of-work (PoW). Conversely, a permissioned blockchain database can secure transactions among a group of entities that share a common goal but do not fully trust or cannot trust each other, such as businesses that exchange funds, goods, information, and the like. This solution can function in permissioned and / or permissionless blockchain settings.

[0012] Smart contracts are trusted decentralized applications that leverage the tamper-resistant properties of a shared or distributed ledger (which may take the form of a blockchain) and the underlying consensus among member nodes, known as endorsements or endorsement policies. Generally, blockchain entries are "approved" before being committed to the blockchain, while unapproved entries are ignored. A typical endorsement policy allows the smart contract executable code to designate endorsers for entries in the form of a set of peer nodes required for endorsement. When a client submits an entry to a peer designated in an endorsement policy, the entry is executed to validate it. After validation, the entry enters an ordering phase in which the consensus protocol generates an ordered sequence of approved entries grouped into blocks.

[0013] A node is a communication entity in a blockchain system. A "node" can perform logical functions, meaning that multiple nodes of different types can operate on the same physical server. Nodes are grouped within a trust domain and associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which receives client submission entries, commits entries, and maintains the state and copies of the blockchain entry ledger. Peers can also act as endorsers. An ordering service node, or orderer, is a node that performs communication services to all nodes and ensures delivery, such as broadcasting to each peer node in the system, when committing entries and modifying the blockchain's world state. The world state can constitute the initial blockchain entries, which typically include control and configuration information.

[0014] The ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can occur as a result of invocations (i.e., entries) of smart contract executable code submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Entries can result in a set of key-value pairs of assets committed to the ledger as one or more operands, such as create, update, delete, and homogeneous. The ledger contains the blockchain (also called the chain), which stores immutably ordered records within blocks. The ledger also contains a state database that maintains the current state of the blockchain. Typically, there is one ledger per channel. Each peer node maintains a copy of the ledger for each channel it is a member of.

[0015] A chain is an entry log constructed as hash link blocks, each block containing a sequence of N entries, where N is greater than or equal to 1. The block header contains the hash of the block's entries and the hash of the header of the previous block. In this way, all entries in the ledger can be ordered and cryptographically joined. Therefore, it is impossible to tamper with ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all entries on the chain that occurred before it, thereby ensuring that all peer nodes are in a consistent and trusted state. Chains can be stored on peer node file systems (i.e., local, attached storage, cloud, etc.) to efficiently support the append-only nature of the blockchain's workload.

[0016] The current state of the immutable ledger represents the most recent values ​​for all keys contained in the chain's entry log. Because the current state represents the most recent known key values ​​in the channel, it is sometimes referred to as the world state. Smart contract executable code calls perform entries against the current state data of the ledger. To streamline these smart contract executable code interactions, the most recent key values ​​may be stored in a state database. The state database can simply be an indexed view of the chain's entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) when a peer node starts up and before entries are accepted.

[0017] Blockchain differs from traditional databases in that it is a decentralized, immutable, and secure storage rather than a centralized storage, and nodes must share changes to the records within the storage. Some of the properties inherent in blockchain and that help make it a reality include, but are not limited to, immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and similar.

[0018] Exemplary embodiments provide services for a particular vehicle and / or user profiles applicable to that vehicle. For example, a user could be the owner of the vehicle or the operator of a vehicle owned by another party. A vehicle may require service at specific intervals, and a service request may require approval before allowing service. A service center may also provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of the service requirement (e.g., urgent, critical, moderate, minor). Vehicle requests may be monitored via one or more vehicle and / or road sensors or cameras that report detected data to a central controller computer device inside and / or away from the vehicle. This data is transferred to a management server for review and action. Sensors may be located inside the vehicle, outside the vehicle, on a stationary object away from the vehicle, and on another vehicle close to the vehicle. Sensors may also be associated with the vehicle's speed, braking, acceleration, fuel level, service requests, gear shifts, steering, and similar information. Sensors as described herein may also be devices such as wireless devices located within and / or near the means of transport. Sensor information may also be used to identify whether the vehicle is operating safely and whether the occupants have engaged in any unexpected vehicle conditions, such as during vehicle access and / or use. Vehicle information collected before, during, and / or after the operation of the vehicle may be identified and stored in transactions on a shared / distributed ledger, which may be generated and committed to an immutable ledger determined in a “distributed” manner by a permissioning consortium, and thus by a blockchain member group, etc.

[0019] Each interested party (i.e., owner, user, company, agent, etc.) may want to limit the exposure of private information; therefore, blockchain and its immutability can be used to manage permissions for each specific 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 deterioration events, identify events of safety concern, identify the parties involved in an event, and distribute such vehicle event data to registered entities seeking access. Furthermore, results can be identified, and necessary information can be shared among registered companies and / or individuals based on a consensus mechanism associated with the blockchain. Traditional centralized databases could not achieve such a method.

[0020] To create topographic and road maps that can be used by means of transport for navigation and other purposes, various driving systems of this solution may utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (Lidar) projectors, radar, ultrasonic sensors, etc. In some embodiments, GPS, maps, cameras, sensors, and similar devices may also be used in autonomous vehicles instead of Lidar.

[0021] In certain embodiments, the solution includes authorizing a vehicle for service via an automated, rapid authentication scheme. For example, driving to a charging station or fuel pump may be performed by the vehicle operator or autonomous transport, and authorization to receive charging or fuel may occur without any delay once authorization is received by the service and / or charging station. The vehicle may provide a communication signal providing vehicle identification information, which has a currently active profile linked to an account authorized to accept service, which may be later corrected by compensation. Additional measures may be used to provide further authentication, for example, another identifier may be transmitted wirelessly from the user's device to the service center to replace or add to a first authorization operation between the transport and the service center with an additional authorization operation.

[0022] Shared and received data can be stored in a database, which generally maintains data in a specific location within a single database (e.g., a database server). This location is often a central computer, such as a desktop's central processing unit (CPU), a server's CPU, or a mainframe computer. Information stored in a centralized database is typically accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, and their centralized location makes them particularly secure. Within a centralized database, having all data in a single storage location also means that a given dataset has only one primary record, thus minimizing data redundancy. Blockchain can be used to store data and transactions related to means of transport.

[0023] Any of the operations described herein may be performed by one or more processors having or not having memory (e.g., microprocessors, sensors, electronic control units (ECUs), head units, and the like) that may be located onboard and / or offboard of the transport (e.g., servers, computers, mobile / wireless devices, etc.). One or more processors may communicate with other onboard or offboard memory and / or other processors in other transport to utilize data transmitted by and / or transmitted to the transport. One or more processors and other processors may transmit data, receive data, and utilize this data to perform one or more of the operations described or depicted herein.

[0024] Figure 1A shows an exemplary system 103 for providing distributed power exchange. This application may run entirely or partially on one or more of the following: any vehicle described herein, a computer / server in a cloud / network, and any other processors in the system that communicate wirelessly with the vehicle, such as a mobile device. In the example of Figure 1A, system 100 runs partially on a cloud / network 101 and includes a processor 102, which executes instructions 106 stored in memory 104 to determine if an entity is unable to supply electricity to an area above a threshold, and to determine the available energy above the threshold from a group of electric vehicles and a group of energy storage units in the area that are currently receiving energy in the area, and to provide the determined available energy to locations that are not currently receiving energy from the entity.

[0025] Referring to Figure 1A, locations 110, 130, and 150 are located within Area 109. Locations may include any type of dwelling or structure (e.g., houses, office spaces, hotels, charging stations, etc.). In the example in Figure 1A, locations 110, 130, and 150 are houses, but the solution also envisions other embodiments that include additional locations or other combinations of different types of locations within an area. The vehicles depicted in Figure 1A may refer to any electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Such vehicles may store electricity in rechargeable battery packs that are used to propel the vehicle, in some embodiments to provide and return electricity to one location (e.g., vehicle-to-home (V2H) technology, vehicle-to-building (V2B) technology, vehicle-to-grid (V2G) technology, etc.), or to provide electricity to another vehicle (e.g., peer-to-peer car charging, etc.).

[0026] In the example in Figure 1A, location 110 includes vehicle 120, location 130 includes vehicle 140, and location 150 includes vehicle 160, but the solution also envisions other embodiments that include multiple vehicles in other types of locations, such as charging stations. Vehicles 120, 140, and 160 each include processors 122, 142, and 162, which may be referred to as electronic control modules ("ECMs"). Processors 122, 142, and 162 may include network technology that enables data exchange between one or more processors in the vehicles and one or more processors associated with the solution via the Internet or other communication networks (e.g., Bluetooth® network, 5G wireless network, Wi-Fi, etc.). Vehicles 120, 140, and 160 each include memory 124, 144, and 164, respectively, which may store instructions related to this solution and other data specific to vehicles 120, 140, and 160 (e.g., usage data, travel data, battery data, etc.). In addition, vehicles 120, 140, and 160 each include battery 126, 146, and 166, respectively, which may include rechargeable battery packs (e.g., lithium-ion battery cells, etc.) for storing energy to propel each vehicle or to transfer energy to another vehicle or location. Vehicles 120, 140, and 160 also include connection devices 129, 149, and 169, respectively, which may enable connections between vehicles (e.g., a power cord between connection device 129 of vehicle 120 and connection device 149 of vehicle 140) or between vehicles and locations (e.g., a power cord between connection device 149 of vehicle 140 and connection device 119 or location 110). Furthermore, vehicles 120, 140, and 160 each include sensors 128, 148, and 168, which may include GPS sensors, battery capacity sensors, camera sensors, and other sensors (e.g., radar, ultrasound, LIDAR, etc.).

[0027] Referring to Figure 1A, locations 110, 130, and 150 also include power integration systems 111, 131, and 151, respectively. Furthermore, power integration systems 111, 131, and 151 may each include processors 112, 132, and 152. In some embodiments, processors 112, 132, and 152 may enable the distribution of electricity from the power grid to any devices that can operate at each location (e.g., HVAC systems, electrical appliances, etc.). In other embodiments, processors 112, 132, and 152 may enable the distribution of electricity from non-power sources (e.g., cars, solar panels, energy storage devices, etc.) to any devices that can operate at each location, isolated from the power grid. In addition, processors 112, 132, and 152 may communicate both real-time energy demand and historical energy patterns for each location (stored in memories 114, 134, and 154, respectively) to any other processors associated with this solution. The power integration systems 111, 131, and 151 may also include power integration mechanisms 116, 136, and 156, respectively, which enable the distribution of electricity to separate the power supply to auxiliary circuits, while providing protective fuses or circuit breakers to each circuit in a common enclosure, and to distribute electricity to each location such as a distribution board (e.g., an electrical panel, a circuit breaker panel, etc.).

[0028] In the example in Figure 1A, locations 110, 130, and 150 also include energy storage units 113, 133, and 153, respectively. Furthermore, energy storage units 113, 133, and 153 each include processors 115, 135, and 155 to enable communication with other processors associated with this solution. In addition, energy storage units 113, 133, and 153 may each include batteries 117, 137, and 157 (e.g., lithium-ion batteries, lead-acid batteries, etc.) to function as backup or auxiliary power sources for their respective locations. Energy storage units 113, 133, and 153 each also include sensors 118, 138, and 158 to detect battery capacity levels for batteries 117, 137, and 157.

[0029] Further reference to the example in Figure 1A, locations 130 and 150 each include energy generation systems 170 and 180 for generating energy from renewable sources (e.g., solar, wind, etc.). Energy generation systems 170 and 180 each include processors 172 and 182 for enabling communication with other processors associated with this solution. In addition, energy generation systems 170 and 180 each include energy generation mechanisms 176 and 186 (e.g., solar panels, wind turbines, etc.) for collecting renewable sources and converting said renewable sources into electricity.

[0030] Processors 112, 115, 122, 132, 135, 142, 152, 155, 162, 172, 182, 192, or any other processor associated with a location, vehicle, or device related to the Solution may be referred to as an Electronic Control Module ("ECM"). For example, the Solution described herein may occur, in whole or in part, in processor 102 or any other processor associated with any location (e.g., processor 112, processor 115, processor 132, processor 135, etc.), for example, in an Electronic Control Unit ("ECU"), in a computer in the infotainment system of a vehicle associated with the Solution (e.g., vehicle 120, vehicle 140, vehicle 160, etc.), in any device in the system (e.g., a mobile device, a tablet, etc.), and in a computer or server that may be located anywhere or outside the vehicle described herein. Data acquired from any vehicle or system associated with this solution (e.g., vehicle 120, power integration system 131, energy storage unit 153, etc.), including data from the batteries of such vehicles or systems (e.g., batteries 126, 137, 166, etc.) or data from the sensors of such vehicles or systems (e.g., sensors 128, 138, 168, etc.), may be transmitted to processor 102 for processing. Data acquired from any vehicle or system associated with this solution (e.g., vehicle 120, power integration system 131, energy storage unit 153, etc.), including data from the batteries of such vehicles or systems (e.g., batteries 126, 137, 166, etc.) or data from the sensors of such vehicles or systems (e.g., sensors 128, 138, 168, etc.), may also be transmitted to processors at any location associated with this solution (e.g., processors 112, 132, 162, etc.), for processing.Data and related instructions may be transmitted wirelessly (e.g., Bluetooth®, Wi-Fi network, cellular network, etc.) between vehicles, locations, computers / servers in the cloud / network, and any other components related to this solution.

[0031] In addition, data from processors 112, 115, 122, 132, 135, 142, 152, 155, 162, 172, 182, 192, or any other processors associated with the location, vehicle, or device associated with this solution may be transmitted to a computer / server in the cloud / network where it is processed and then stored in a database, which, along with other related data, may maintain the data in a single database (e.g., a database server) in numerous implementation embodiments. For example, the data may be maintained in a central computer associated with this solution, including processor 102. Information stored in a centralized database is typically accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, and are particularly security-oriented because they reside in a single location. Within a centralized database, having all data in a single storage location also means that a given dataset has only one primary record, thus minimizing data redundancy. In addition, blockchain may be used to store data and transactions related to vehicles. In other embodiments, data from the vehicle may be stored in multiple computers or servers, where the computers or servers may be redundant.

[0032] The processor 102 may execute an instruction 106 stored in memory 104 to cause the system 100 to determine that an entity cannot supply more electricity than a threshold to a location within the area. In the example in Figure 1A, the system 100 determines that the entity, the power distribution network 190, cannot supply more electricity than a threshold to location 110 located in area 109. In some embodiments, the threshold relates to the amount of electricity required to operate devices used at location 110 (e.g., HVAC systems, electrical appliances, car chargers, etc.). In such embodiments, the processor 102 may communicate with the processor 112 of the power integration system 111 and analyze real-time power usage data and historical power usage data stored in memory 114 to determine the amount of electricity required (or a range of electricity required) to operate devices used at location 110 and set an amount threshold (e.g., 30 kWh per day). Furthermore, in the event of a complete power outage (e.g., a blackout) or a partial power outage (e.g., a brownout), system 100 may communicate with the processor 192 of the power distribution network 190 and / or the processor 112 of the power integration system 111 to determine whether the power distribution network 190 has the capacity to provide electricity exceeding the quantity threshold by comparing the amount of input power at location 110 with a quantity threshold set at location 110. If the amount of input power at location 110 (or, for example, the expected amount of input power at location 100 based on a brownout warning from the processor 192 of the power distribution network 190) is less than the quantity threshold, system 100 may determine that the entity cannot provide electricity exceeding the quantity threshold. In this way, the solution defines what a location needs to do to remain fully operational during a blackout and prevent potential damage or other functional failures to devices operating at the moment of a partial power outage such as a brownout.

[0033] In other embodiments, the threshold may relate to the cost or price of electricity associated with the power supply to a location, where the processor 102 may execute an instruction 106 stored in memory 104 to cause the system 100 to determine that the entity cannot supply electricity below the threshold to a location within the area. In such embodiments, the processor 102 may communicate with the processor 112 of the power integration system 111 and analyze real-time power usage data, as well as historical power usage data stored in memory 114 and associated costs, to determine the cost of electricity required to operate the devices used at location 110 (or the range of electricity costs required) and set a price threshold (e.g., $10 per day). Furthermore, at a specific date and time (e.g., peak hours), the system 100 may communicate with the processor 192 of the distribution network 190 and / or the processor 112 of the power integration system 111 to determine whether the distribution network 190 has the ability to supply electricity below the price threshold by comparing the price of input power at location 110 with a price threshold set at location 110. If the price of input power at location 110 exceeds a price threshold, system 100 may determine that the entity cannot provide electricity below the threshold. In this way, the solution enables the location to find other sources of electricity that are more cost-effective for that location. In yet another embodiment, the solution may include simultaneous determination of both that the entity cannot provide electricity above a quantity threshold and that the entity cannot provide electricity below a price threshold.

[0034] If the threshold relates to an amount of electricity, the processor 102 may execute an instruction 106 stored in memory 104 to cause the system 100 to determine the amount of available energy exceeding the threshold from a group of electric vehicles and a group of energy storage units in the area. In some embodiments, a location may currently be receiving energy in the area (e.g., from a power grid 190), and this energy may contribute to the available energy from a group of vehicles or a group of energy storage units, provided that the group of vehicles and / or energy storage units are connected to an energy source (e.g., the connection device 149 of vehicle 140 is connected to the connection device 139 of the power integration system 131). In other embodiments, a location may not currently be receiving energy from the area, but may still have available energy stored in the location (e.g., an energy storage unit 133 in location 130) or generated from an "off-grid" source (e.g., an energy generation system 170 in location 130).

[0035] A group of electric vehicles may be located in the same place (e.g., a cluster of electric vehicles) or in different places (e.g., individual houses). In the example of Figure 1A, the group of vehicles includes vehicle 140 located at location 130 and vehicle 160 located at location 150. If the power grid 190 is unable to supply electricity to location 110 as described herein in excess of a quantity threshold, the processor 102 may communicate with the vehicle group's processors (e.g., processor 142 for vehicle 140, processor 162 for vehicle 160, etc.) and, based on data from the vehicle group's sensors (e.g., sensor 148 for vehicle 140, sensor 168 for vehicle 160, etc.), the system 100 may determine the available energy stored in the vehicle group's batteries (e.g., battery 146 for vehicle 140, battery 166 for vehicle 160, etc.).

[0036] Furthermore, a group of energy storage units may be located in the same place (e.g., a charging station) or in different places (e.g., individual homes). In the example of Figure 1A, the group of energy storage units includes an energy storage unit 133 located at location 130 and an energy storage unit 153 located at location 150. If the power grid 190 is unable to supply electricity to location 110 as described herein in excess of a quantity threshold, the processor 102 may communicate with the processors of the group of energy storage units (e.g., the processor 135 of energy storage unit 133, the processor 155 of energy storage unit 153, etc.) and, based on data from the sensors of the group of energy storage units (e.g., the sensor 138 of energy storage unit 133, the sensor 158 of energy storage unit 153, etc.), the system 100 may determine the available energy stored in the batteries of the group of energy storage units (e.g., the battery 137 of energy storage unit 133, the battery 157 of energy storage unit 153, etc.).

[0037] The availability of energy from groups of electric vehicles and groups of energy storage units may be influenced by several factors. In some embodiments, the availability of energy from groups of electric vehicles and groups of energy storage units may also include an expected surplus that is not currently realized at the location. For example, processor 102 may communicate with processors 132, 135, and 142 at location 130 to determine that the currently available energy from location 130 is 50 kWh (e.g., 40 kWh from battery 146 of vehicle 140 + 10 kWh from battery 137 of energy storage unit 133). However, based on historical data stored in memory 134 of power integration device 131, data from sensor 138 related to the battery capacity of battery 137 of energy storage unit 133, and real-time weather data specific to location 130 collected by processor 102, system 100 may determine that the energy generation system 170 will generate an additional 5 kWh of energy at location 130 that cannot be stored (e.g., battery 137 at full capacity). In such a case, processor 102 may communicate with processor 132 of power integration system 131 to cause energy storage unit 133 to transfer energy from battery 137 to battery 146 of vehicle 140, and as a result, vehicle 140 effectively receives its full charge from energy storage unit 133 rather than from the power grid 190. In this way, battery 137 of energy storage unit 133 can free up storage space to obtain the capacity needed to take in any expected surplus. As a result, if vehicle 140 is determined to be a delivery mechanism for available energy, previously only 40kWh may have been available, but now, after transferring 10kWh from battery 137 of energy storage unit 133 to battery 146 of vehicle 140 to "make space" for an expected surplus, vehicle 140 can deliver 50kWh of available energy to location.

[0038] In addition, the energy availability from the electric vehicle group and the energy storage unit group may also include energy consumption for traveling between locations. For example, processor 102 may analyze GPS data from locations 110 and 150 to determine that the distance between location 110 and location 150 is 5 miles (approximately 8.04672 km), and the round trip between locations totals 10 miles (approximately 16.09344 km). Furthermore, processor 102 may communicate with the processor 162 of vehicle 160 and analyze usage data stored in the memory 164 of vehicle 160 to determine the kWh / mile (approximately 1.609344 km) rate for vehicle 160. For example, if vehicle 160 uses 0.5 kWh / mile (approximately 1.609344 km), a round trip of 10 miles (approximately 16.09344 km) will consume approximately 5 kWh. Therefore, if system 100 initially determines that vehicle 160 can deliver 40 kW of available energy, the adjusted available energy, based on the estimated 5 kWh consumed during travel between locations, is 35 kWh (e.g., 40 kWh of available energy - 5 kWh consumed during travel between locations). Furthermore, additional reductions in available energy may include limitations on available energy for a particular location. For example, 35 kWh of energy (e.g., 40 kWh of available energy - 5 kWh consumed during travel between locations) may be available from location 150, but only 20 kWh may be supplied to another location (e.g., location 110), and as a result, it may be determined that the remaining 15 kWh (35 kWh available - 20 kWh made available) can be reserved for location 150. Such limits on the amount of energy that can be made available may be set manually by the user (for example, through the user interface of the power integration system 151) or automatically by system 100, which may determine the amount of energy to be made available based on a processor 102 that communicates with a location processor (for example, a processor 152 of the power integration system 151) and analyzes energy usage data stored in the memory of the power integration system 151 (for example, memory 154 of the power integration system 151).

[0039] If the threshold relates to the price of electricity (or includes price in addition to the amount of electricity threshold), processor 102 may execute instruction 106 stored in memory 104 to cause system 100 to determine that the available energy from a group of electric vehicles from locations currently receiving energy in the area, and from a group of energy storage units in the area, is less than the threshold. System 100 may determine a price range for both locations seeking available energy and locations that optionally provide available energy, based on the selling and repurchase prices offered by the distribution network. For example, referring to Figure 1A, processor 102 may communicate with processor 192 to determine that the distribution network 190 is currently selling electricity at $0.30 / kWh but repurchasing electricity at $0.10 / kWh (e.g., through net metering). In such a case, processor 102 may communicate with a processor at a location requesting the purchase of electricity (for example, processor 112 of the power integration system 111 at location 110) to set a price threshold for purchasing electricity to less than $0.30 / kWh. Furthermore, processor 102 may communicate with processors at locations offering electricity for sale (for example, processors 132 and 142 at location 130, processors 152 and 162 at location 150, etc.) to set a price threshold for selling electricity to more than $0.10 / kWh. In this way, system 100 can function as a broker to secure favorable deals for location 110 to purchase electricity from location 130 at a lower price than it would be to purchase it from the distribution network 190, and favorable deals for location 130 to sell electricity to location 110 at a higher price than it would be to sell it to the distribution network 190.

[0040] Processor 102 may execute an instruction 106 stored in memory 104 to cause system 100 to provide the determined available energy to locations that are not currently receiving energy from entities. Referring to the example in Figure 1A, system 100 determines that the power grid 190 cannot provide electricity to location 110 at a price exceeding a quantity threshold of 50 kWh and below a price threshold of $0.30 / kWh. As a result, processor 102 communicates with the processors at location 130 (e.g., processors 132, 142, etc.) and the processors at location 150 (e.g., processors 152, 162, etc.). System 100 may determine that location 130 has 60 kWh of available energy stored in the battery 146 of vehicle 140 at a price of $0.20 / kWh, and that location 150 has 40 kWh of available energy stored in the battery 166 of vehicle 160 at a price of $0.12 / kWh. However, based on historical data stored in the memory 154 of the power integration system 151, data from sensors 158 related to the battery capacity of the battery 157 of the energy storage unit 153, and real-time weather data specific to location 150 collected by the processor 102, system 100 may determine that the energy generation system 180 can generate an additional 10 kWh of energy that location 150 cannot store (for example, with a fully operational battery 157). In such a case, system 100 may transfer the energy stored in the battery 157 of the energy storage unit 153 (which had not previously been made available for sale) to the battery 166 of the vehicle 160. For example, if the battery 157 of the energy storage unit 153 had 10kWh of stored energy, after the move, location 150 now has 50kWh of available energy stored in the battery 166 of the car 160 at a price of $0.12 / kWh (40kWh initially stored in the battery 166 of the car 160 + 10kWh of energy transferred from the battery 157 of the energy storage unit 153).Since the available energy at both location 130 and location 150 is currently greater than the quantity threshold set by location 110, and the price of energy at both location 130 and location 150 is less than the price threshold set by location 110, system 100 may cause location 150 to provide location 110 with the determined amount of available energy, as location 150 provides the same amount of energy at a lower cost.

[0041] In some embodiments, providing determined available energy includes dispatching a vehicle from a group of electric vehicles to a location that is not currently receiving energy (and / or is requesting energy at a lower price). When dispatching a vehicle, processor 102 may send a notification to the vehicle's processor (e.g., processor 122 for vehicle 130, processor 162 for vehicle 160, etc.), where the notification may include an instruction 106 stored in the vehicle's memory (e.g., memory 124 for vehicle 120, memory 164 for vehicle 160, etc.) that can be executed to move the vehicle autonomously between locations. In other examples, the notification may include an instruction 106 stored in the vehicle's memory (e.g., memory 124 for vehicle 120, memory 164 for vehicle 160, etc.) that can provide instructions to move manually between locations. Figure 1B shows an exemplary system 105 for providing distributed power exchange by dispatching vehicles to locations that are not currently receiving energy. In the example in Figure 1B, vehicle 160 is dispatched from location 150 to location 110. In some examples, car 160 may be connected to car 120 (for example, by a power cord from car 160's connection device 169 to car 120's connection device 129) to transfer 50 kWh of available energy from car 160's battery 166 to car 120's battery 126 (for example, by peer-to-peer charging). In the example in Figure 1B, the power cord from car 160's connection device 169 connects to the power integration system 111's connection device 119 to facilitate the transfer of 50 kWh of available energy from car 160's battery 166 to the power integration system 111, where 50 kWh may be used instantaneously to power location 110, or some or all of the 50 kWh may be diverted to the battery 117 of the energy storage unit 113.

[0042] In other embodiments, providing determined available energy includes dispatching a vehicle from a location that is not currently receiving energy (and / or is requesting energy at a lower price) to a group of energy storage units. Figure 1C shows an exemplary system 107 for providing distributed power exchange by dispatching a vehicle from a location that is not currently receiving energy. In the example in Figure 1C, vehicle 120 is dispatched from location 110 to location 150. In some examples, vehicle 120 may be connected to a power integration system 151 (e.g., a power cord from the vehicle's connection device 129 to the power integration system 151's connection device 159) to move available energy from the battery 157 of an energy storage unit 153 to the vehicle's battery 126. In the example shown in Figure 1B, a power cord from the connection device 169 of vehicle 160 connects to the connection device 129 of vehicle 120, facilitating the transfer of 50 kWh of available energy from the battery 166 of vehicle 160 to the battery 126 of vehicle 120, where the 50 kWh of available energy can be transported back to location 110 and used as its power source.

[0043] The flowcharts depicted herein, such as Figures 1A, 1B, 1C, 2A, 2B, 2C, 2D, 2E, 3A, 3B, 3C, 4, 5A, 5B, 6A, 6B, 6C, 6D, and 7, are separate examples but may be the same or different embodiments. Any operation in one flowchart may be adopted and shared in another flowchart. The exemplary operations are not intended to limit any embodiment or the subject matter of the corresponding claims.

[0044] All flowcharts and corresponding processes derived from Figures 1A, 1B, 1C, 2A, 2B, 2C, 2D, 2E, 3A, 3B, 3C, 4, 5A, 5B, 6A, 6B, 6C, 6D, and 7 may be part of the same process or share subprocesses with each other. It is important to note that these diagrams can be combined into a single preferred embodiment that performs specific operations from one exemplary process and one or more additional processes, without requiring any single specific operation. All exemplary processes relate to the same physical system and can be used separately or interchangeably.

[0045] This solution can be used with one or more types of vehicles, namely, battery electric vehicles, hybrid vehicles, fuel cell vehicles, internal combustion engine vehicles, and / or vehicles that utilize renewable sources.

[0046] Figure 2A shows a transport means network diagram 200 according to an exemplary embodiment. The network comprises elements including a transport means 202 including a processor 204 and a transport means 202' including a processor 204'. The transport means 202 and 202' communicate with each other via processors 204 and 204', and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between transport means 202 and 202' may occur directly, via private and / or public networks (not shown), or via other transport means and elements comprising one or more of a processor, memory, and software. Although described as a single transport means and processor, multiple transport means and processors may exist. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by this element.

[0047] Figure 2B shows another transport means network, Figure 210, according to an exemplary embodiment. The network comprises elements including a transport means 202 including a processor 204 and a transport means 202' including a processor 204'. The transport means 202 and 202' communicate with each other via processors 204 and 204', and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between transport means 202 and 202' may occur directly, via private and / or public networks (not shown), or via other transport means and elements comprising one or more of processors, memory, and software. Processors 204 and 204' may further communicate with one or more elements 230, including sensors 212, wired devices 214, wireless devices 216, a database 218, a mobile phone 220, a transport means 222, a computer 224, an I / O device 226, and a voice application 228. Processors 204, 204' may further communicate with elements comprising one or more of the following: a processor, memory, and software.

[0048] Although described as a single means of transport, processor, and element, multiple means of transport, processors, and elements may exist. Information or communication may arise to and / or from any of the processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204 which can cause means of transport 202 to start operating, further provide information or additional information to processor 204' which can cause means of transport 202' to start operating, and further provide information or additional information to mobile phone 220, means of transport 222, and / or computer 224. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by this element.

[0049] Figure 2C shows yet another transport means network diagram 240 according to an exemplary embodiment. The network comprises elements including a transport means 202, a processor 204, and a non-temporary computer-readable medium 242C. The processor 204 is communicatively connected to the computer-readable medium 242C and element 230 (depicted in Figure 2B). The transport means 202 may be a transport means, server, or any device having a processor and memory.

[0050] The processor 204 performs one or more of the following: determining that an entity cannot supply electricity to an area in excess of a threshold 244C; determining that there is available energy in excess of a threshold from a group of electric vehicles and a group of energy storage units in the area that are currently receiving energy within the area 246C; and providing the determined available energy to locations that are not currently receiving energy from the entity 248C.

[0051] Figure 2D shows a further transport means network diagram 250 according to an exemplary embodiment. The network comprises elements including a transport means 202, a processor 204, and a non-temporary computer-readable medium 242D. The processor 204 is communicatively connected to the computer-readable medium 242D and element 230 (depicted in Figure 2B). The transport means 202 may be a transport means, server, or any device having a processor and memory.

[0052] The processor 204 does one or more of the following: the threshold is relating to the amount of electricity required to power a first location in the area 244D; the threshold is relating to the cost of electricity associated with powering a first location in the area 245D; determining the available energy from the group of electric vehicles and the group of energy storage units includes predicting an expected surplus of available energy 246D; determining the available energy from the group of electric vehicles and the group of energy storage units includes energy that will be traveled and consumed between locations that are not currently receiving energy from the entity and locations of the group of vehicles and the group of energy storage units 247D; providing the determined available energy includes dispatching vehicles from the group of electric vehicles to locations that are not currently receiving energy 248D; and providing the determined available energy includes dispatching vehicles from locations that are not currently receiving energy to the group of energy storage units 249D.

[0053] Figure 2E shows a diagram 260 of an additional means of transport network according to an exemplary embodiment. Referring to Figure 2E, the network diagram 260 includes means of transport 202 connected to update server node 203 and other means of transport 202' via blockchain network 206. Means of transport 202 and 202' may represent means of transport / vehicles. Blockchain network 206 may have a ledger 208 for storing software update verification data and sources 207 of verification for future use (e.g., in audits).

[0054] In this example, only one transport means 202 is described in detail, but multiple such nodes may be connected to the blockchain 206. It should be understood that the transport means 202 may include additional components, and that some of the components described herein may be removed and / or modified without departing from the scope of the Application. The transport means 202 may include a processor 204, which may have a computing device or server computer, or the same, and may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or another hardware device. Although a single processor 204 is depicted, it should be understood that the transport means 202 may include multiple processors, multiple cores, or the same without departing from the scope of the Application. The transport means 202 may be a transport means, server, or any device having a processor and memory.

[0055] The processor 204 receives confirmation of an event from one or more elements described or depicted herein, wherein the confirmation comprises a peer-to-peer blockchain consensus represented by any of the elements 244E, and performs one or more of the following: execute a smart contract to record the confirmation on the blockchain based on the blockchain consensus 246E. The consensus is formed between any element 230 and / or one or more of any elements described or depicted herein, including means of transport, servers, wireless devices, etc. In another example, means of transport 202 may be any element 230 and / or one or more of any elements described or depicted herein, including servers, wireless devices, etc.

[0056] The processor and / or computer-readable medium 242E may be located entirely or partially inside or outside the means of transport. Steps or functions stored in the computer-readable medium 242E may be performed entirely or partially by the processor and / or any of the elements in any order. Furthermore, additions, omissions, combinations, and subsequent executions may be performed on one or more steps or functions.

[0057] Figure 2F shows Figure 265 illustrating the power supply to one or more elements. In one example, a transport 266 may supply power stored in its battery to one or more elements, including other transports 268, charging stations 270, and a power grid 272. The power grid 272 is connected to one or more of the charging stations 270, and the charging stations 270 may be connected to one or more of the transports 268. This configuration allows for the distribution of electricity / power received from the transport 266. The transport 266 may also communicate with other transports 268 via vehicle-to-vehicle (V2V) technology, cellular communication, Wi-Fi, and similar technologies. The transport 266 may also communicate with other transports 268, charging stations 270, and / or the power grid 272 wirelessly and / or via wired connections. In one example, the transport means 266 is routed (or routes itself) to a power distribution network 272, a charging station 270, or another transport means 268 in a safe and efficient manner. Using one or more embodiments of this solution, the transport means 266 may provide energy to one or more of the elements described herein in various advantageous ways as described and / or depicted herein. Furthermore, the safety and efficiency of the transport means may be enhanced and may have a positive impact on the environment as described and / or depicted herein.

[0058] The terms “energy,” “electricity,” “power,” and similar terms may be used to describe any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be referred to in conjunction with voltage sources and / or current supplies relating to charges provided from an entity to a vehicle during a charge / use operation. Energy may also be in the form of fossil fuels (for example, for use in hybrid vehicles) or by alternative power sources including, but not limited to, lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy sources, and energy generated in-situ during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0059] In one example, the charging station 270 manages the amount of energy transferred from the transport means 266 so that the transport means 266 has enough remaining charge to reach its destination. In one example, a wireless connection is used to wirelessly instruct the amount of energy to be transferred between transport means 268, which may be traveling together. In one embodiment, wireless charging may occur via fixed chargers and transport means batteries aligned with each other (such as a charging mat in a garage or parking space). In one example, an unused vehicle, such as a car 266 (which may be autonomous), is instructed to provide a certain amount of energy to the charging station 270 and return to its original location (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect surplus energy from at least one other transport means 268 and transfer the stored surplus energy to the charging station 270. In one example, the amount of energy to be transferred to the charging station 270 is determined by factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (such as weight), the schedule of occupants using the vehicle, and the expected schedule of occupants waiting for the vehicle. In one example, the transport means 268, the charging station 270, and / or the power distribution network 272 may provide energy to the transport means 266.

[0060] In one embodiment, a location such as a building, house, or similar (not described) is communicatively connected to one or more of the following: a power distribution network 272, a transport means 266, and / or a charging station 270. The rate at which electricity flows to one or more of the location, the transport means 266, and the other transport means 268 is modified in accordance with external conditions such as weather. For example, if the external temperature is extremely high or extremely low, increasing the likelihood of a power outage, the flow of electricity to the connected vehicles 266 / 268 is slowed down to help minimize the likelihood of a power outage.

[0061] In one embodiment, the transport means 266 and 268 may be used as bidirectional transport means. The bidirectional transport means may function as a mobile microgrid that can assist in supplying power to the distribution grid 272 and / or reduce power consumption when the distribution grid is under stress. The bidirectional transport means incorporates bidirectional charging, and in addition to receiving charges to the transport means, the transport means may take energy from the transport means and “push” the energy back to the distribution grid 272, which is otherwise referred to as “V2G”. In bidirectional charging, electricity flows in both directions: to and from the transport means. When the transport means is being charged, alternating current (AC) electricity from the distribution grid 272 is converted to direct current (DC). This can be done by one or more converters in the transport means itself or in the charger 270. The energy stored in the transport means’s battery may be sent back to the distribution grid in the opposite direction. The energy is converted from DC to AC through a converter, usually located in the charger 270, which is otherwise referred to as a bidirectional charger. Furthermore, the solution described and depicted in relation to Figure 2F may be used in this network and / or system, as well as in other networks and / or systems.

[0062] Figure 2G is a diagram of Figure 275 illustrating the interconnections between different elements. The solution can be fully or partially stored and / or executed on and / or by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277', all associated with various entities and all communicatively connected to and communicating with the network 286. The database 287 is communicatively connected to the network, enabling the storage and retrieval of data. In one example, the database is an immutable ledger. One or more of the various entities could be a means of transport 276, one or more service providers 279, one or more public buildings 281, one or more transport infrastructure 282, one or more residential buildings 283, a power grid / charging station 284, a microphone 285, and / or another means of transport 277. Other entities and / or devices, such as one or more private users using a smartphone 278, a laptop 280, an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device, may also interact with this solution. The smartphone 278, the laptop 280, the microphone 285, and other devices may be connected to one or more of the connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various organizations. One or more public buildings 281 may utilize computing device 281'. One or more service providers 279 may include sales agents, towing truck services, collision centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computer devices may be connected to each other directly and / or communicate via wired networks, wireless networks, blockchain networks, and the like. For example, microphone 285 may be used as a virtual assistant. For example, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure.One or more transportation infrastructures 282 may utilize computing devices 282'.

[0063] In one embodiment, whenever electricity is charged to / from a charging station and / or a power distribution network, the entities that enable this to occur are one or more of the vehicle, the charging station, the server, and networks that are communicably connected to the vehicle, the charging station, and the power distribution network.

[0064] In one example, the transport means 277 / 276 can transport people, objects, permanently or temporarily attached devices, and the like. In one example, the transport means 277 can communicate with the transport means 276 via V2V communication through computers 276' and 277' associated with each transport means, and may be referred to as transport means, passenger cars, cars, automobiles, and the like. The transport means 276 / 277 may be self-propelled, wheeled vehicles such as passenger cars, sports utility vehicles, trucks, buses, vans, or other transport means that are motor-driven, battery-driven, or fuel cell-driven. For example, the transport means 276 / 277 may be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of transportable vehicle. The transport means 276 / 277 may be semi-autonomous or autonomous. For example, the transport means 276 / 277 may be autonomous and be operated without human input. The autonomous vehicle may have one or more sensors and / or navigation units and use them to drive autonomously.

[0065] Figure 2H is another block diagram 290 showing the interconnections between different elements in one example. A transport vehicle 276 is represented and includes ECUs 295, 296 and a head unit (otherwise known as the infotainment system) 297. An Electrical Control Unit (ECU) is a system incorporated within automotive electronics that controls one or more of the electrical systems or subsystems within the transport vehicle. An ECU may include, but is not limited to, the control of the transport vehicle's engine, brake system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the transport vehicle's Controller Area Network (CAN) bus 294. The ECU may also communicate with the transport vehicle's computer 298 via the CAN bus 294. The transport vehicle's processor / sensor 298 (such as the transport vehicle's computer) may communicate with external elements such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296 and head unit 297 may contain its own security policy. The security policy defines the permissible processes that can be performed in the appropriate context. For example, the security policy may be provided, in part or in whole, within the transport's computer 298.

[0066] ECUs 295, 296, and head unit 297 may each include custom security feature elements 299 that define authorized processes and the contexts in which those processes are permitted to operate. Context-based authorization, which determines the validity of whether a process is executable, allows the ECU to maintain secure operation and prevent unauthorized access from elements such as the transport's controller area network (CAN bus). If an ECU encounters an unauthorized process, it may prevent that process from operating. Automotive ECUs may use a variety of contexts, such as proximity context (near objects, distance to approaching objects, speed, trajectory relative to other moving objects), operational context (indication whether the transport is moving or parked, current speed of the transport, transmission status), user-related context (devices connected to the transport via wireless protocols, infotainment use, cruise control, parking assist, driving assistance), location-based context, and / or other contexts, to determine whether a process is operating within its permitted boundaries.

[0067] Referring to Figure 2I, an operating environment 290A of a connected transport means in one embodiment is shown. As depicted, the transport means 276 includes a Controller Area Network (CAN) bus 291A connecting elements 292A to 299A of the transport means. Other elements may be connected to the CAN bus but are not depicted herein. Depicted elements connected to the CAN bus include a sensor set 292A, an electronic control unit 293A, an autonomous function or advanced driver-assistance system (ADAS) 294A, and a navigation system 295A. In one embodiment, the transport means 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0068] The processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array, which performs calculations and provides electronic display signals to the display unit 299A. The processor 296A processes data signals and may include various computing architectures, including a composite instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. The transport means 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not described) that are communicated with each other may be used in this solution.

[0069] Memory 297A is a non-temporary memory that stores instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include code for performing the techniques described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or another memory device. In some embodiments, memory 297A may also include non-volatile memory or similar permanent storage devices and media, which may include a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or any other mass storage device for permanently storing information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). The transport means 276 may include one or more memories 297A without departing from this solution.

[0070] The memory 297A of the transport means 276 may store one or more of the following types of data: navigation route data 295A and autonomous function data 294A. In some embodiments, the memory 297A stores data that may be necessary for the navigation application 295A to provide its functions.

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

[0072] The ECU 293A controls the operation of numerous systems of the transport means 276, including the ADAS system 294A. The ECU 293A may, in response to commands received from the navigation system 295A, disable any dangerous and / or unselected autonomous functions during the duration of a journey controlled by the ADAS system 294A. In this manner, the navigation system 295A can control whether to activate or enable the ADAS system 294A so that it can operate along a given navigation route.

[0073] Sensor set 292A may include any sensors that generate sensor data in the transport means 276. For example, sensor set 292A may include short-range and long-range sensors. In some embodiments, sensor set 292A of transport means 276 may include one or more of the following automotive sensors: cameras, lidar sensors, ultrasonic sensors, automotive engine sensors, radar sensors, laser altimeters, manifold absolute pressure sensors, infrared detectors, motion detectors, thermostats, sound detectors, carbon monoxide sensors, carbon dioxide sensors, oxygen sensors, mass airflow sensors, engine coolant temperature sensors, throttle position sensors, crankshaft position sensors, valve timers, air-fuel ratio meters, blind spot meters, curve feelers, defect detectors, Hall effect sensors, parking sensors, speed guns, speedometers, speed sensors, tire pressure monitoring sensors, torque sensors, transmission fluid temperature sensors, turbine speed sensors (TSS), variable reluctance sensors, vehicle speed sensors (VSS), moisture sensors, wheel speed sensors, GPS sensors, mapping functions, and any other types of automotive sensors. The navigation system 295A can store sensor data in memory 297A.

[0074] The communication unit 298A transmits and receives data to and from the network 292 or to another communication channel. In some embodiments, the communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make the transport means 276 a DSRC-enabled device.

[0075] The transport means 276 may communicate with other transport means 277 via V2V technology. In one example, V2V communication includes detecting radar information corresponding to the relative distance to an external object, receiving GPS information of the transport means, setting an area based on the detected radar information as the area where the other transport means 277 is located, calculating the probability that the target vehicle's GPS information is located in the set area, and identifying the transport means and / or object corresponding to the target vehicle's radar information and GPS information based on the calculated probability.

[0076] To ensure that a means of transport is sufficiently secure, it must be protected from unauthorized physical and remote access (e.g., cyber threats). For example, to prevent unauthorized physical access, the means of transport may be equipped with a secure access system such as keyless entry. On the other hand, for example, security protocols may be added to the transport's computers and computer network to facilitate secure remote communication with the transport.

[0077] Electronic control units (ECUs) are nodes within a vehicle that control tasks ranging from operating windshield wipers to implementing anti-lock braking systems. ECUs are often connected to each other through a central network of the vehicle, often referred to as a Controller Area Network (CAN). Advanced features such as autonomous driving heavily rely on the implementation of new and complex ECUs, including advanced driver-assistance systems (ADAS), sensors, and similar technologies. While these new technologies help improve the safety and driving experience of vehicles, they also increase the number of external communication units within the vehicle, making it more vulnerable to attacks. The following are some examples of protecting vehicles from physical and remote intrusions.

[0078] Figure 2J shows a keyless entry system 290B for preventing unauthorized physical access to the transport means 291B according to an exemplary embodiment. Referring to Figure 2J, in one example, a key fob 292B transmits commands to the transport means 291B using radio frequency signals. In this example, the key fob 292B includes a transmitter 2921B having an antenna capable of transmitting short-range radio signals. The transport means 291B includes a receiver 2911B having an antenna capable of receiving short-range radio signals transmitted from the transmitter 2921B. The key fob 292B and the transport means 291B also include CPUs 2922B and 2913B, respectively, which control their respective devices, where CPUs 2922B and 2913B have (or CPU-accessible) memory. In one example, the key fob 292B and the transport means 291B each include power supply units 2924B and 2915B that supply power to their respective devices.

[0079] When a user presses button 293B on key fob 292B (or otherwise activates the fob, etc.), CPU 2922B activates within key fob 292B and transmits a data stream output via the antenna to transmitter 2921B. In other embodiments, user intent is recognized in key fob 292B via other means such as a microphone that accepts voice, a camera that captures images and / or video, or other sensors commonly used in the art to detect user intent, including the reception of gestures, motion, eye movements, and the like. The data stream may be a long signal ranging from 64 bits to 128 bits, including one or more of a preamble, command code, and rolling code. The signal may be transmitted at a speed between 2 kHz and 20 kHz, but embodiments are not limited thereto. In response, the receiver 2911B of the transport means 291B receives the signal from the transmitter 2921B, demodulates the signal, and sends the data stream to the CPU 2913B, which decodes the signal and sends commands (e.g., locking a door, unlocking a door, etc.) to the command module 2912B.

[0080] If the key fob 292B and the transport device 291B use a fixed code between them, a replay attack may be possible. In this case, if an attacker can intercept / discover the fixed code during short-range communication, the attacker can replay this code to gain access to the transport device 291B. To improve security, the key fob and the transport device 291B may use a rolling code that changes after each use. Here, the key fob 292B and the transport device 291B are synchronized with an initial seed 2923B (e.g., a random number, a pseudorandom number, etc.). This is referred to as pairing. The key fob 292B and the transport device 291B also include a shared algorithm that modifies the initial seed 2914B each time button 293B is pressed. The next key press takes the result of the previous key press as input and converts it to the next number in the sequence. In some cases, the transport means 291B may store multiple next codes (e.g., 255 next codes) if a key press on the key fob 292B is not detected by the transport means 291B. Therefore, a large number of key presses on the key fob 292B that are not recognized by the transport means 291B do not prevent the transport means from becoming asynchronous.

[0081] In addition to rolling code, the key fob 292B and the transport means 291B may employ other methods to make attacks more difficult. For example, various frequencies may be used to transmit rolling code. As another example, two-way communication between the transmitter 2921B and the receiver 2911B may be used to establish a secure session. As yet another example, the code may have a limited duration or timeout. Furthermore, the present solution, as described and depicted with respect to Figure 2J, may be used in this network and / or system, including those described and depicted herein, as well as in other networks and / or systems.

[0082] Figure 2K shows a Controller Area Network (CAN) 290C within a transport vehicle according to an exemplary embodiment. Referring to Figure 2K, CAN 290C includes a CAN bus 297C having high and low terminals, and a number of electronic control units (ECUs) 291C, 292C, 293C, etc., connected to CAN bus 297C via wired connections. CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without the use of a host computer. CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard) that enables ECUs 291C-293C to send commands to each other at the root level. Meanwhile, ECUs 291C-293C represent controllers that control electrical systems or subsystems within the transport vehicle. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and numerous other functions.

[0083] In this example, ECU291C includes transceiver 2911C and microcontroller 2912C. The transceiver may be used to send and receive messages to and from CAN bus 297C. For example, transceiver 2911C may convert data from microcontroller 2912C to the format of CAN bus 297C and convert data from CAN bus 297C to the format for microcontroller 2912C. On the other hand, in one example, microcontroller 2912C interprets the messages and determines which messages to send using ECU software installed on microcontroller 2912C.

[0084] Various security protocols can be implemented to protect CAN290C from cyber threats. For example, subnetworks (e.g., subnetworks A and B) can be used to divide CAN290C into smaller sub-CANs to limit an attacker's ability to remotely access the transport. In the example in Figure 2K, ECUs 291C and 292C may be part of the same subnetwork, while ECU 293C is part of an independent subnetwork. Furthermore, a firewall 294C (or gateway, etc.) may be added to prevent messages from traversing the CAN bus 297C across subnetworks. If an attacker accesses a subnetwork, they will not have access to the entire network. In one example, to make subnetworks more secure, the most critical ECUs are not placed in the same subnetwork.

[0085] Although not shown in Figure 2K, other examples of security controls within CAN include an intrusion detection system (IDS) that can be added to each subnetwork to read all passing data and detect malicious messages. If a malicious message is detected, the IDS may notify the vehicle's user. Other possible security protocols include encryption / security keys that can be used to obscure messages. Another example, in one example, is the implementation of an authentication protocol that allows messages to authenticate themselves.

[0086] In addition to protecting the internal network of the means of transport, the means of transport can also be protected when communicating with external networks such as the Internet. One advantage of connecting the means of transport to data sources such as the Internet is that information from the means of transport can be transmitted remotely through the network for analysis. Examples of means of transport information include GPS, onboard diagnostics, tire pressure, and similar. These communication systems often involve a combination of telecommunications and informatics and are therefore referred to as telematics. Furthermore, the present solution, as described and depicted with respect to Figure 2K, may be used in this network and / or system, including those described and depicted herein, as well as in other networks and / or systems.

[0087] Figure 2L shows a secure end-to-end transport means communication channel according to an exemplary embodiment. Referring to Figure 2L, the telematics network 290D includes a transport means 291D and a host server 295D located remotely (e.g., a web server, cloud platform, database, etc.) and connected to the transport means 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D may be located within the transport means 291D in the network. Furthermore, although not shown, device 296D may be connected to other elements of the transport means 291D, such as a CAN bus, an onboard diagnostic (ODBII) port, a GPS system, a SIM card, a modem, and similar devices. Device 296D may collect data from any of these systems and transfer the data to the server 295D via the network.

[0088] Secure data management begins with the transport means 291D. In some embodiments, device 296D may collect information before, during, and after travel. The data may include GPS data, travel data, passenger information, diagnostic data, fuel data, speed data, and similar data. However, device 296D may simply communicate and return the collected information to the host server 295D in response to the ignition of the transport means and the completion of travel. Furthermore, communication may only be initiated by device 296D and not by the host server 295D. Therefore, in one example, device 296D does not accept communication initiated by an external source.

[0089] To communicate, device 296D may establish a secure private network between device 296D and host server 295D. Here, device 296D may include a tamper-proof SIM card that provides secure access to carrier network 294D via cell tower 292D. When preparing to send data to host server 295D, device 296D may establish a one-way secure connection with host server 295D. Carrier network 294D may communicate with host server 295D using one or more security protocols. As a non-limiting example, carrier network 294D may communicate with host server 295D via a VPN tunnel that allows access through the host server 295D's firewall 293D. As another example, carrier network 294D may use data encryption (e.g., AES encryption) when sending data to host server 295D. In some cases, the system may use multiple security measures, such as both VPN and encryption, to further secure the data.

[0090] In addition to communication with external servers, means of transport can also communicate with each other. In particular, means-to-means (V2V) communication systems enable means of transport to communicate with each other via a wireless network, as well as with roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.) and similar devices. Wireless networks may include one or more of the following: Wi-Fi networks, cellular networks, dedicated short-range communication (DSRC) networks, and similar devices. Means of transport may use V2V communication to provide other means of transport with information about their speed, acceleration, braking, and direction, to name a few. Thus, means of transport can receive insights into conditions ahead before those conditions become visible, thus significantly reducing collisions. Furthermore, the present solution, as described and depicted with respect to Figure 2L, may be used with this network and / or system, including those described and depicted herein, as well as with other networks and / or systems.

[0091] Figure 2M shows Example 290E of transport means 293E and 292E performing secure V2V communication using security certificates, according to an exemplary embodiment. Referring to Figure 2M, transport means 293E and 292E may communicate via V2V communication over a short-range network, a cellular network, or similar. Before sending a message, transport means 293E and 292E may sign the message using their respective public key certificates. For example, transport means 293E may sign a V2V message using public key certificate 294E. Similarly, transport means 292E may sign a V2V message using public key certificate 295E. In one example, public key certificates 294E and 295E are associated with transport means 293E and 292E, respectively.

[0092] Upon receiving communications from each other, the transporters may verify the signature with a Certificate Authority 291E or an equivalent. For example, transporter 292E may verify with Certificate Authority 291E that the public key certificate 294E used by transporter 293E to sign the V2V communication is authenticated. If transporter 292E successfully verifies the public key certificate 294E, the transporter recognizes that the data is from a legitimate source. Similarly, transporter 293E may verify with Certificate Authority 291E that the public key certificate 295E used by transporter 292E to sign the V2V communication is authenticated. Furthermore, the present solution, as described and depicted with respect to Figure 2M, may be used in this network and / or system, including those described and depicted herein, as well as in other networks and / or systems.

[0093] Figure 2N shows an additional Figure 290F illustrating an example of a transport means interacting with a security processor and a wireless device according to an exemplary embodiment. In some embodiments, the computer 224 shown in Figure 2B may include a security processor 292F, such as the process 290F in the example of Figure 2N. In particular, the security processor 292F may perform authorization, authentication, cryptography (e.g., encryption), and similar functions for data transmission between the ECU and other devices on the vehicle's CAN bus, and for data messages transmitted between different vehicles.

[0094] In the example of Figure 2N, the security processor 292F may include an authorization module 293F, an authentication module 294F, and a cryptography module 295F. The security processor 292F may be implemented within the computer of the transport and may communicate with other transport elements, such as the ECU / CAN network 296F and wired and wireless devices 298F, such as wireless network interfaces, input ports, and similar devices. The security processor 292F may ensure that data frames (e.g., CAN frames) transmitted internally within the transport (e.g., via the ECU / CAN network 296F) are secure. Similarly, the security processor 292F may also ensure that messages transmitted between different transports and between devices attached to or connected via wires to the computer of the transport are secure.

[0095] For example, the authorization module 293F may store passwords, usernames, PIN codes, biometric scans, and similar information for users of various modes of transport. The authorization module 293F may determine whether the user (or technician) has permission to access specific settings, such as the computer of the mode of transport. In some embodiments, the authorization module may communicate with a network interface to download any necessary authorization information from an external server. When a user requests to make changes to the settings of the mode of transport or modify the technical details of the mode of transport via a console or GUI within the mode of transport, or via an attached / connected device, the authorization module 293F may require the user to verify themselves in some way before such settings are changed. For example, the authorization module 293F may require a username, password, PIN code, biometric scan, default line drawing or gesture, and similar information. Accordingly, the authorization module 293F may determine whether the user has the necessary permissions (such as access) being requested.

[0096] The authentication module 294F can be used to authenticate internal communication between ECUs on a vehicle's CAN network. For example, the authentication module 294F may provide information for authenticating communication between ECUs. For example, the authentication module 294F may send a bit signature algorithm to the ECUs on the CAN network. The ECUs can use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. Each time a new CAN frame is generated by one of the ECUs, the bit signature algorithm may dynamically change the position, amount, etc., of the authentication bits. The authentication module 294F may also provide a list of ECUs that are exempt (a safe list) and do not need to use the authentication bits. The authentication module 294F may communicate with a remote server to retrieve updates and similar information for the bit signature algorithm.

[0097] The encryption module 295F may store an asymmetric key pair used by the transport to communicate with other external user devices and transports. For example, the encryption module 295F may provide a private key used by the transport to encrypt / decrypt communications, while the corresponding public key may be provided to other user devices and transports to enable those devices to decrypt / encrypt communications. The encryption module 295F may communicate with a remote server to receive new keys, updates to keys, keys for new transports or users, and similar items. The encryption module 295F may also send any updates to the local private / public key pair to the remote server. Figure 3A shows a flowchart 300 according to an exemplary embodiment. Referring to Figure 3A, the solution includes one or more of the following: determining that an entity cannot supply electricity to an area above a threshold 302; determining available energy above a threshold from a group of electric vehicles and a group of energy storage units in the area from locations currently receiving energy within the area 304; and providing the determined available energy to locations not currently receiving energy from the entity 306.

[0098] Figure 3B shows another flowchart 320 according to an exemplary embodiment. Referring to Figure 3B, the solution does one or more of the following: the threshold is the amount of electricity required to power a first location in the area 322; the threshold is the cost of electricity associated with powering the first location in the area 323; determining the available energy from the group of electric vehicles and the group of energy storage units includes predicting the expected surplus of available energy 324; determining the available energy from the group of electric vehicles and the group of energy storage units includes the energy that will be moved and consumed between locations that are not currently receiving energy from the entity and locations of the group of vehicles and the group of energy storage units 325; providing the determined available energy includes dispatching vehicles from the group of electric vehicles to locations that are not currently receiving energy 326; and providing the determined available energy includes dispatching vehicles from locations that are not currently receiving energy to the group of energy storage units 327.

[0099] Figure 3C shows yet another flowchart 340 according to an exemplary embodiment. Referring to Figure 3C, the flowchart includes receiving confirmation of an event from one or more elements described or depicted herein, wherein the confirmation comprises a peer-to-peer blockchain consensus represented by any of the elements 342, and executing a smart contract 344 to record the confirmation on a blockchain based on the blockchain consensus.

[0100] Figure 4 shows a machine learning transport network diagram 400 according to an exemplary embodiment. The network 400 includes a transport means 402 which is coupled to a machine learning subsystem 406. The transport means includes one or more sensors 404.

[0101] The machine learning subsystem 406 includes a training model 408, which is an artifact created by a machine learning training system 410 that generates predictions by finding patterns within one or more training datasets. In some embodiments, the machine learning subsystem 406 resides within a node 402 of the transport. Artifacts are used to describe outputs created by the training process, such as checkpoints, files, or models. In other embodiments, the machine learning subsystem 406 resides outside of node 402 of the transport.

[0102] The transport means 402 transmits data from one or more sensors 404 to the machine learning subsystem 406. The machine learning subsystem 406 provides the data from one or more sensors 404 to the learning model 408, and the learning model 408 returns one or more predictions. Based on the predictions from the learning model 408, the machine learning subsystem 406 transmits one or more commands to the transport means 402.

[0103] In a further embodiment, the transport means 402 may transmit data from one or more sensors 404 to a machine learning training system 410. In yet another example, the machine learning subsystem 406 may transmit data from sensor 404 to the machine learning subsystem 410. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may utilize a machine learning network 400 as described herein.

[0104] Figure 5A shows an exemplary vehicle configuration 500 that manages database transactions associated with a vehicle according to an exemplary embodiment. Referring to Figure 5A, a particular means of transport / vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, means of transport service, etc.), and the vehicle may receive (510) and / or send / transfer (512) assets in accordance with the transaction. A means of transport processor 526 resides within the vehicle 525, and communication exists between the means of transport processor 526, the database 530, and the transaction module 520. The transaction module 520 may record information such as assets, parties, credits, service descriptions, dates, times, locations, results, notices, and unexpected events. Those transactions within the transaction module 520 may be replicated in the database 530. Database 530 may be one of the following: an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger; it may be mounted on a means of transport or not; it may be accessed directly and / or through a network; or it may be accessible to a means of transport.

[0105] Figure 5B shows an exemplary vehicle configuration 550 that manages various inter-vehicle database transactions according to an exemplary embodiment. When a vehicle reaches a situation where a service needs to be shared with another vehicle, vehicle 525 may engage with another vehicle 508 to perform various operations such as sharing, transferring, and retrieving service requests. For example, vehicle 508 may have a battery charge scheduled and / or a tire problem and may be on a route to pick up a delivery package. A transport means processor 528 resides in vehicle 508, and communication exists between the transport means processor 528, the database 554, and the transaction module 552. Vehicle 508 may notify another vehicle 525 that is on its network and operating on its blockchain member service. A transport means processor 526 resides in vehicle 525, and communication exists between the transport means processor 526, the database 530, the transport means processor 526, and the transaction module 520. Vehicle 525 may then receive information via wireless communication requests to pick up packages from vehicle 508 and / or from a server (not shown). Transactions are recorded in transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525, and records of the services transferred are recorded in databases 530 / 554, assuming the blockchains are different from each other, or on the same blockchain used by all members. Database 554 may be one of the following: an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger, and may or may not be mounted on a means of transport, and may be accessible directly and / or through a network.

[0106] Figure 6A shows a blockchain architecture configuration 600 according to an exemplary embodiment. Referring to Figure 6A, the blockchain architecture 600 may include a group of blockchain member nodes 602-606 as part of a specific blockchain element, for example, a blockchain group 610. In one exemplary embodiment, a permissioned blockchain is accessible only to members who have permission to access blockchain data, rather than all parties. Blockchain nodes are involved in numerous activities, such as adding and verifying blockchain entries (consensus). One or more blockchain nodes may approve entries based on an endorsement policy and may provide ordering services to all blockchain nodes. Blockchain nodes may initiate blockchain operations (such as authentication) and attempt to write to the blockchain immutable ledger stored on the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0107] Once a transaction is received and approved by a consensus model determined by the member nodes, the blockchain transaction 620 is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and committed to the blockchain via a commit procedure, which includes hashing 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 conditions for agreement and operation of transactions contained within smart contract executable application code 632, such as registered recipients, vehicle functions, requirements, permissions, and sensor thresholds. The code may be configured to identify whether the requesting entity is registered to receive vehicle services, what service functions the entity is eligible for / needs to receive, and whether to monitor the entity's behavior in subsequent events, taking into account the entity's profile status. For example, if a service event occurs and a user is in the car, sensor data monitoring may be activated, and certain parameters, such as the car's charge level, may be identified as being above / below a certain threshold for a specific period, and as a result, the current status may change, and the service may be identified and stored for reference so that the current status requires sending an alert to the managing party (i.e., the car owner, the car operator, the server, etc.). The car sensor data collected may be based on the type of sensor data used to collect information about the status of the car. The sensor data may also be the basis for car event data 634 such as where the car is moving, average speed, maximum speed, acceleration, whether there was any collision, whether the expected route was taken, where the next destination is, whether safety measures are being implemented, and whether the car has sufficient charge / fuel. All such information may be the basis for smart contract conditions 630, which are then stored on the blockchain.For example, sensor thresholds stored in a smart contract can be used as a basis for determining whether a detected service is needed and when and where that service should be performed.

[0108] Figure 6B shows a shared ledger configuration according to an exemplary embodiment. Referring to Figure 6B, blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application that connects to computing devices and execution platforms for specific transactions. Blockchain configuration 640 may include one or more applications that connect to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), the program / application code may be created according to a customized configuration requested by the participant, maintain its own state, control its own assets, and receive external information. This may be deployed and installed as an entry by appending to the distributed ledger on all blockchain nodes.

[0109] The smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, when executed, enables transaction conditions and states. The smart contract 630, when executed, generates a specific approved transaction 626, which is then transferred to the blockchain platform 652. The platform includes security / approval 658, a computing device 656 that performs transaction management, and a storage unit 654 as memory for storing transactions and smart contracts in the blockchain.

[0110] A blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments), and an underlying physical computing infrastructure that can be used to receive and store new entries and provide access to auditors seeking to access data entries. The blockchain may expose interfaces that provide access to virtual execution environments necessary to process program code and engage with the physical infrastructure. Cryptographic trust services may be used to verify entries, such as asset exchange entries, and to keep information confidential.

[0111] The blockchain architecture configurations in Figures 6A and 6B allow the blockchain platform to process and execute program / application code through one or more publicly accessible interfaces and provided services. As a non-limiting example, smart contracts may be created to perform reminders, updates, and / or other notifications subject to change or update. Smart contracts themselves may be used to identify approval and access requirements and rules associated with the use of the ledger. For example, information may include new entries that can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results may include decisions to reject or approve new entries based on criteria defined in the smart contract and / or peer consensus. Physical infrastructure may be used to retrieve any of the data or information described herein.

[0112] Within smart contract executable code, smart contracts can be created via high-level application and programming languages ​​and then written to blocks in the blockchain. Smart contracts may contain executable code that is registered, stored, and / or replicated using the blockchain (e.g., a decentralized network of blockchain peers). An entry is the execution of smart contract code, which may occur when the conditions associated with the smart contract are met. The execution of a smart contract can result in a reliable modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated across the entire decentralized network of blockchain peers by one or more consensus protocols.

[0113] Smart contracts can write data to the blockchain in the format of key-value pairs. Furthermore, smart contract code can read values ​​stored on the blockchain and use those values ​​when the application is running. Smart contract code can write the output of various logical operations into the blockchain. The code can be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be made public and / or kept private by encryption. Temporary data used / generated by smart contracts is held in memory by the supplying execution environment and then deleted when the data required by the blockchain is identified.

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

[0115] Figure 6C shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment. Referring to Figure 6C, the exemplary configuration 660 provides a car 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that queries the car service provider to share user profile rating information when a known established user profile attempts to rent a car using an established rating profile. The server 666 may receive and process data related to the car's service requirements. When a service event occurs, such as car sensor data indicating the need for fuel / charging, maintenance services, etc., a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke the car service event. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the car's service status, and event updates. A transaction may include the parties, requirements (e.g., age 18, eligible candidate for service, valid driver's license, etc.), compensation level, distance traveled between events, registered beneficiaries authorized to access the event and provide vehicle services, rights / permissions, sensor data taken during vehicle event operation to record details of the next service event and identify the vehicle's status, and thresholds used to make decisions regarding whether the service event is complete and whether the vehicle's status has changed.

[0116] Figure 6D shows the contents of blockchain block 680 and block structures 682A-682n that may be added to the distributed ledger in an exemplary embodiment. Referring to Figure 6D, a client (not shown) can perform activities on the blockchain by submitting entries to a blockchain node. As an example, a client may be an application that acts on behalf of a requester, such as a device, person, or entity, and proposes entries to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) may maintain the state of the blockchain network and copies of the distributed ledger. Various types of blockchain nodes / peers may exist in a blockchain network that include approval peers that simulate and approve entries proposed by clients, and commit peers that confirm endorsements, validate entries, and commit entries to the distributed ledger. In this example, a blockchain node may perform the roles of endorser node, committer node, or both.

[0117] This system includes a blockchain that stores immutably ordered records in blocks, and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger may exist for each channel, and each peer maintains its own copy of the distributed ledger for each channel it is a member of. This blockchain is an entry log constructed as hash link blocks, and each block contains a sequence of N entries. Blocks may contain various components, such as those shown in Figure 6D. Block joining can be generated by adding the hash of the header of the previous block to the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically joined, preventing tampering with blockchain data without breaking the hash link. Furthermore, because they are joined, the most recent block in the blockchain represents all entries that occurred before it. This blockchain may be stored on a peer file system (local or attached storage) that supports the blockchain workload dedicated to appending.

[0118] The current state of a blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the most recent values ​​for all keys to date, contained in the blockchain's chain entry log. Calls to smart contract executable code execute entries against the current state in the state database. To make these smart contract executable code interactions highly efficient, the most recent values ​​for all keys are stored in the state database. The state database may contain an indexed view of the blockchain's entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) when a peer is invoked, before entries are accepted.

[0119] The approval node receives entries from clients and approves them based on simulated results. The approval node maintains a smart contract that simulates entry proposals. When the approval node approves an entry, it creates an entry endorsement, which is a signed response from the approval node to the client application indicating endorsement of the simulated entry. How entries are approved depends on the endorsement policy, which may be specified within the smart contract executable code. An example of an endorsement policy is that "the majority of approval peers must approve the entry." Different channels may have different endorsement policies. Approved entries are forwarded by the client application to the ordering service.

[0120] An ordering service accepts approved entries, orders those entries within a block, and delivers the block to commit peers. For example, an ordering service may initiate a new block when an entry threshold is reached, a timer times out, or under other conditions. In this example, the blockchain node is a commit peer that receives data block 682A to store on the blockchain. An ordering service may consist of a cluster of orderers. An ordering service does not process entries, smart contracts, or maintain a shared ledger. Rather, an ordering service may accept approved entries and specify the order in which those entries are committed to the distributed ledger. The architecture of a blockchain network may be designed so that a particular implementation of “ordering” (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0121] 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 the entries are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs 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.

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

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

[0124] In some embodiments, the 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. Thus, the data 686A may be stored in an immutable log of the block on the distributed ledger. Some of the advantages of storing such data 686A are reflected in the various embodiments disclosed and described herein. The block metadata 688A may store several fields of metadata (e.g., as a byte array). Metadata fields may include the signature in block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, the last surviving offset of the ordering service that orders the blocks, and similar information. The signature, last constituent block, and orderer metadata may be added by the ordering service. On the other hand, the block committer (such as a blockchain node) may add valid / invalid information based on endorsement policies, read / write set verification, and similar information. The entry filter may include a byte array of a size equal to the number of entries in block data 610A, and validation code that identifies whether an entry was valid or invalid.

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

[0126] The embodiments described above 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 random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, hard disks, removable disks, compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0127] A preferred storage medium may be connected to the processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage medium may reside within an application-specific integrated circuit ("ASIC"). Alternatively, the processor and storage medium may exist as separate components. For example, Figure 7 shows an exemplary computer system architecture 700 which may represent or be integrated into any of the above-mentioned components.

[0128] Figure 7 is not intended to imply any limitation on the scope of use or functionality of the embodiments of the Application described herein. Nevertheless, the compute node 700 is implementable and / or capable of performing any of the functions described herein.

[0129] Within the compute node 700, there are computer systems / servers 702 capable of operating in the environments or configurations of many other general-purpose or dedicated computing systems. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer systems / servers 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments including any of the above systems or devices, and similar.

[0130] A computer system / server 702 can be described in the general context of computer system executable instructions, such as program modules, that are executed by the computer system. Generally, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. A computer system / server 702 may run in a distributed cloud computing environment where tasks are executed by remote processing devices connected via a communication network. In a distributed cloud computing environment, program modules may reside in both local and remote computer system storage media, including memory storage devices.

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

[0132] A bus represents one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using various bus architectures. Examples of such architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Expansion ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0133] The computer system / server 702 typically includes various computer system-readable media. These media can be any available media accessible by the computer system / server 702, and include both volatile and non-volatile media, and removable and non-removable media. For example, system memory 706 implements the flow diagram in another figure. System memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. The computer system / server 702 may further include other removable / non-removable volatile / non-volatile computer system storage media. As just one example, memory 706 may be provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown, typically referred to as a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to removable non-volatile magnetic disks (e.g., “floppy disks”) and an optical disk drive for reading from and writing to removable non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media may be provided. In such cases, each may be connected to the bus by one or more data media interfaces. As further described and mentioned below, the memory 706 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of various embodiments of the present application.

[0134] A program / utility having a set of program modules (at least one) may be stored, for example, in memory 706, as well as in 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 any combination thereof, may include an implementation of a network environment. The program modules generally perform functions and / or methods of the various embodiments of the present application described herein.

[0135] As will be understood by those skilled in the art, aspects of the present application may be embodied as systems, methods, or computer program products. Accordingly, aspects of the present application may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware embodiments, all of which may be generally referred to herein as “circuits,” “modules,” or “systems.” Furthermore, aspects of the present application may take the form of computer program products embodied in one or more computer-readable media, the computer-readable media having computer-readable program code embodied on the computer-readable media.

[0136] The computer system / server 702 may also communicate with one or more external devices via I / O devices 712 (such as I / O adapters), which may include keyboards, pointing devices, displays, speech recognition modules, etc.; one or more devices that enable a user to interact with the computer system / server 702; and / or any devices that enable the computer system / server 702 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may occur via the I / O interface of device 712. Furthermore, the computer system / server 702 may communicate with one or more networks, such as a local area network (LAN), a general wide network (WAN), and / or a public network (e.g., the Internet), via a network adapter. As depicted, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that other hardware and / or software components, not shown, may be used with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data storage systems.

[0137] While at least one preferred embodiment of the system, method, and non-temporary computer-readable medium is shown in the accompanying drawings and described in the above detailed description, it will be understood that the application is not limited to the disclosed embodiments and that many rearrangements, modifications, and substitutions are possible as described and defined by the following claims. For example, the capabilities of the various diagrammatic systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, including transmitters, receivers, or pairs thereof. For example, all or part of the functions performed by individual modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various times in relation to various events inside or outside the modules or components. Also, information transmitted between various modules may be transmitted between modules via data networks, the internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or at least one of several protocols. Also, messages transmitted or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0138] Those skilled in the art will understand that the “System” may be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device, or combination of devices. Presenting the functions described above as being performed by the “System” is not intended to limit the scope of this application in any way, but rather to provide an example of a number of embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing techniques.

[0139] It should be noted that some of the system functions described herein are presented as modules to more specifically emphasize the independence of their implementation. For example, modules may be implemented as hardware circuits comprising custom very large-scale integrated (VLSI) circuits or gate arrays, or off-the-shelf semiconductors such as logic chips, transistors, or other individual components. Modules may also be implemented within programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or similar.

[0140] Modules can also be implemented in software, at least partially, for execution by various types of processors. For example, an identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized as, for example, objects, procedures, or functions. Nevertheless, the executable files of an identified module do not need to be physically located together, and may comprise different instructions stored in different locations that, when logically combined, comprise the module and achieve a specified purpose for the module. Furthermore, modules may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, random access memory (RAM), tape, or any other such medium used to store data.

[0141] In fact, a module of executable code may be a single instruction or a number of instructions, and may be distributed across several different code segments, between different programs, and across several memory devices. Similarly, computational data may be identified and shown herein within a module, embodied in any preferred form, and organized within any preferred type of data structure. Computational data may be collected as a single dataset, or distributed across different locations including different storage devices, and may exist at least partially as mere electronic signals on a system or network.

[0142] It will be readily apparent that the components of the present application, as outlined herein and shown in the figures, can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the application.

[0143] Those skilled in the art will readily understand that the above can be performed in a different sequence of steps and / or with hardware elements of a configuration different from that disclosed. Therefore, although this application is based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative structures are also apparent.

[0144] While preferred embodiments of this application are described, it should be understood that these embodiments are illustrative only, and the scope of this application should be defined solely by the appended claims, when considered in relation to all equivalents and modifications to the appended claims (e.g., protocols, hardware devices, software platforms, etc.). The inventions disclosed herein include the following embodiments: [Aspect 1] Determining that an entity cannot provide electricity to an area exceeding a threshold, To determine the available energy exceeding the threshold from a group of electric vehicles and a group of energy storage units currently receiving energy within the area, The determined available energy is to be provided to locations that are not currently receiving energy from the entity, Methods that include... [Aspect 2] The method according to embodiment 1, wherein the threshold is the amount of electricity required to supply power to a first location within the area. [Aspect 3] The method according to embodiment 1, wherein the threshold relates to the cost of electricity associated with supplying power to a first location within the area. [Aspect 4] The method according to embodiment 1, wherein determining the available energy from the group of electric vehicles and the group of energy storage units includes predicting the expected surplus of available energy. [Aspect 5] The method according to embodiment 1, wherein determining the available energy from the group of electric vehicles and the group of energy storage units includes energy that is moved and consumed between the location that is not currently receiving energy from the entity and the location of the group of vehicles and the group of energy storage units. [Aspect 6] The method according to embodiment 1, wherein providing the determined available energy includes dispatching a vehicle from the group of electric vehicles to a location that is not currently receiving energy. [Aspect 7] The method according to embodiment 1, wherein providing the determined available energy includes dispatching a vehicle from a location that is not currently receiving energy to the group of energy storage units. [Aspect 8] It is a system, Memory for storing a set of instructions, A processor for executing the aforementioned set of instructions, The processor is provided with the system, Determine that the entity cannot supply more electricity than the threshold required for the area. Determine the amount of available energy exceeding the threshold from a group of electric vehicles currently receiving energy within the area and a group of energy storage units within the area. The determined available energy is provided to locations that are not currently receiving energy from the entity. system. [Aspect 9] The system according to embodiment 8, wherein the threshold is the amount of electricity required to supply power to a first location within the area. [Aspect 10] The system according to embodiment 8, wherein the threshold relates to the cost of electricity associated with power supply to a first location within the area. [Aspect 11] The system according to embodiment 8, further comprising instructions executable by the processor to cause the system to determine the available energy from the group of electric vehicles and the group of energy storage units, including predicting an expected surplus of available energy. [Aspect 12] The system according to embodiment 8, further comprising instructions executable by the processor to cause the system to determine available energy from the group of electric vehicles and the group of energy storage units, including energy that is moved and consumed between the location not currently receiving energy from the entity and the location of the group of vehicles and the group of energy storage units. [Aspect 13] The system according to embodiment 8, further comprising instructions executable by the processor to cause the system to provide the determined available energy, including dispatching a vehicle from the group of electric vehicles to a location that is not currently receiving energy. [Aspect 14] The system according to embodiment 8, wherein providing the determined available energy includes dispatching a vehicle from a location that is not currently receiving energy to the group of energy storage units. [Aspect 15] A computer-readable storage medium comprising instructions, wherein, when the instructions are read by a processor, the instructions are communicated to the processor: Determining that an entity cannot provide electricity to an area exceeding a threshold, To determine the available energy exceeding the threshold from a group of electric vehicles and a group of energy storage units currently receiving energy within the area, The determined available energy is to be provided to locations that are not currently receiving energy from the entity, A computer-readable storage medium that enables the following process. [Aspect 16] The computer-readable medium according to embodiment 15, wherein the threshold relates to the amount of electricity required to supply power to a first location within the area. [Aspect 17] The threshold is a computer-readable medium according to embodiment 15 relating to the cost of electricity associated with power supply to a first location within the area. [Aspect 18] The computer-readable medium according to embodiment 15, wherein determining the available energy from the group of electric vehicles and the group of energy storage units includes predicting the expected surplus of available energy. [Aspect 19] The computer-readable medium according to embodiment 15, wherein providing the determined available energy includes dispatching a vehicle from the group of electric vehicles to a location that is not currently receiving energy. [Aspect 20] The computer-readable medium according to embodiment 15, wherein providing the determined available energy includes dispatching a vehicle from a location not currently receiving energy to the group of energy storage units.

Claims

1. Determining that an entity cannot provide electricity to an area exceeding a threshold, To determine the available energy exceeding the threshold from a group of electric vehicles and a group of energy storage units currently receiving energy within the area, The determined available energy is to be provided to locations that are not currently receiving energy from the entity, Includes, Providing the determined available energy includes dispatching vehicles from locations that are not currently receiving energy to the group of energy storage units. method.

2. The method according to claim 1, wherein the threshold is the amount of electricity required to supply power to a first location within the area.

3. The method according to claim 1, wherein the threshold relates to the cost of electricity associated with supplying power to a first location within the area.

4. The method according to claim 1, wherein determining the available energy from the group of electric vehicles and the group of energy storage units includes predicting the expected surplus of available energy.

5. The method according to claim 1, wherein determining the available energy from the group of electric vehicles and the group of energy storage units includes energy that is moved and consumed between the location that is not currently receiving energy from the entity and the location of the group of vehicles and the group of energy storage units.

6. The method according to claim 1, wherein providing the determined available energy includes dispatching a vehicle from the group of electric vehicles to a location that is not currently receiving energy.

7. It is a system, Memory for storing a set of instructions, A processor for executing the aforementioned set of instructions, The processor is provided with the system, Determine that the entity cannot supply more electricity than the threshold required for the area. Determine the amount of available energy exceeding the threshold from a group of electric vehicles currently receiving energy within the area and a group of energy storage units within the area. The determined available energy is provided to locations that are not currently receiving energy from the entity. Providing the determined available energy includes dispatching vehicles from locations that are not currently receiving energy to the group of energy storage units. system.

8. The system according to claim 7, wherein the threshold is the amount of electricity required to supply power to a first location within the area.

9. The system according to claim 7, wherein the threshold relates to the cost of electricity associated with power supply to a first location within the area.

10. The system according to claim 7, further comprising instructions executable by the processor to cause the system to determine the available energy from the group of electric vehicles and the group of energy storage units, including predicting an expected surplus of available energy.

11. The system according to claim 7, further comprising instructions executable by the processor to cause the system to determine available energy from the group of electric vehicles and the group of energy storage units, including energy that is moved and consumed between the location where energy is not currently being received from the entity and the location of the group of vehicles and the group of energy storage units.

12. The system according to claim 7, further comprising instructions executable by the processor to cause the system to provide the determined available energy, including dispatching a vehicle from the group of electric vehicles to a location that is not currently receiving energy.

13. A computer-readable storage medium comprising instructions, wherein, when the instructions are read by a processor, the instructions are communicated to the processor: Determining that an entity cannot provide electricity to an area exceeding a threshold, To determine the available energy exceeding the threshold from a group of electric vehicles and a group of energy storage units currently receiving energy within the area, The determined available energy is to be provided to locations that are not currently receiving energy from the entity, Have them do it, Providing the determined available energy includes dispatching vehicles from locations that are not currently receiving energy to the group of energy storage units. Computer-readable storage medium.

Images