Predicting grid-related events

Abstract

Example operations include one or more of determining that there is a problem with resource delivery to an electricity provider, determining an electrical impact based on the problem, determining an area affected by the electrical impact, and dispatching vehicles to provide electricity to locations in the area.

Description

[Background technology]

[0001] Generally, vehicles or transportation means, such as cars, motorcycles, trucks, airplanes, trains, etc., provide transportation needs for passengers and / or goods in a variety of ways. Functionality associated with the transportation means may be identified and utilized by various computing devices, such as smartphones or computers, located on and / or remote from the transportation means. Summary of the Invention

[0002] An example embodiment provides a method that includes one or more of determining that there is a problem with resource delivery to an electricity provider, determining an electrical impact based on the problem, determining an area affected by the electrical impact, and dispatching vehicles to provide electricity to locations in the area.

[0003] Another exemplary embodiment provides a system including a memory communicatively connected to a processor, the processor performing one or more of: determining that there is a problem with resource delivery to an electricity provider; determining an electrical impact based on the problem; determining an area affected by the electrical impact; and dispatching vehicles to provide electricity to locations in the area.

[0004] A further exemplary embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: determine that there is a problem with resource delivery to an electricity provider; determine an electrical impact based on the problem; determine an area affected by the electrical impact; and dispatch vehicles to provide electricity to locations in the area. [Brief explanation of the drawings]

[0005] [Figure 1A]FIG. 1 illustrates a network diagram of a system for predicting grid-related events in accordance with an illustrative embodiment. [Figure 1B] FIG. 1 illustrates an exemplary diagram of a grid-related event prediction system according to an exemplary embodiment. [Figure 2A] FIG. 1 illustrates a transportation network diagram according to an exemplary embodiment. [Figure 2B] FIG. 10 illustrates another transportation network diagram according to an exemplary embodiment. [Figure 2C] FIG. 10 illustrates yet another transportation network diagram according to an illustrative embodiment. [Figure 2D] FIG. 10 illustrates a further transportation network diagram according to an exemplary embodiment. [Figure 2E] FIG. 10 illustrates an additional transportation network diagram according to an exemplary embodiment. [Figure 2F] FIG. 1 illustrates a diagram depicting powering of one or more elements according to an exemplary embodiment. [Figure 2G] FIG. 1 illustrates a diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 2H] FIG. 10 illustrates a further diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 2I] FIG. 10 illustrates yet another diagram depicting interconnections between elements according to an exemplary embodiment. [Figure 2J] 10A-10C illustrate additional views depicting a keyless entry system according to an exemplary embodiment. [Figure 2K] FIG. 10 illustrates an additional view depicting a CAN within a vehicle in accordance with an exemplary embodiment. [Figure 2L] FIG. 10 illustrates yet another diagram depicting an end-to-end communication channel according to an exemplary embodiment. [Figure 2M] FIG. 10 shows yet an additional diagram depicting an example vehicle using security certificates for secure V2V communication, according to an exemplary embodiment. [Figure 2N]10A-10C show further diagrams depicting example vehicles interacting with security processors and wireless devices according to exemplary embodiments. [Figure 3A] FIG. 1 illustrates a flow diagram according to an exemplary embodiment. [Figure 3B] FIG. 10 illustrates another flow diagram according to an exemplary embodiment. [Figure 3C] FIG. 10 illustrates yet another flow diagram according to an exemplary embodiment. [Figure 4] FIG. 1 is a diagram illustrating a machine learning vehicle network diagram according to an exemplary embodiment. [Figure 5A] FIG. 1 illustrates an exemplary vehicle configuration for managing database transactions associated with a vehicle, according to an exemplary embodiment. [Figure 5B] FIG. 1 illustrates another exemplary vehicle configuration for managing database transactions between various vehicles, according to an exemplary embodiment. [Figure 6A] FIG. 1 illustrates a blockchain architecture configuration, according to an exemplary embodiment. [Figure 6B] FIG. 1 illustrates another blockchain configuration, according to an exemplary embodiment. [Figure 6C] FIG. 1 illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. [Figure 6D] FIG. 2 illustrates an exemplary data block according to an exemplary embodiment. [Figure 7] FIG. 1 illustrates an exemplary system that supports one or more of the exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

[0007] Communications between a vehicle and a particular entity, such as a remote server, another vehicle, and a local computing device (e.g., a smartphone, a personal computer, a computer integrated into the vehicle, etc.), may be sent and / or received and processed by one or more “components,” which may be hardware, firmware, software, or a combination thereof. A component may be part of either the entity or computing device or a particular other computing device. In one example, consensus decisions related to blockchain transactions may be made by one or more computing devices or components associated with the vehicle (which may be any of the elements described and / or depicted herein) and by one or more components external to or remote from the vehicle.

[0008] The features, structures, or characteristics described herein may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase “exemplary embodiment,” “some embodiments,” or other similar terms indicates that a particular feature, structure, or feature described in connection with an embodiment may be included in at least one example. Thus, appearances of the phrases “exemplary embodiment,” “in some embodiments,” “in other embodiments,” or other similar terms throughout this specification do not necessarily refer to the same group of embodiments, and the described features, structures, or features may be combined in any suitable manner in one or more embodiments. In the figures, any connection between elements may enable one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. In this solution, the vehicle or transportation means may include one or more of a car, truck, pedestrian-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 location to another.

[0009] Additionally, although the term "message" may be used in describing the embodiments, other types of network data may be used, such as packets, frames, datagrams, etc. Furthermore, although particular types of messages and signaling may be depicted in preferred embodiments, they are not limited to particular types of messages and signaling.

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

[0011] Within a communications infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. A blockchain is an example of a distributed database that includes an append-only, immutable data structure (i.e., a distributed ledger) that allows records to be maintained among untrusted parties. The untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no peer can modify the database record without reaching consensus among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain storage entries, organize the storage entries into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary for consistency. In a public or permissionless blockchain, anyone can participate without specific identity. Public blockchains are involved in cryptocurrencies and may use consensus based on various protocols, such as proof-of-work (PoW). Conversely, a permissioned blockchain database can ensure interactions between groups of entities that share a common goal but do not or cannot fully trust each other, such as entities exchanging funds, goods, information, and the like. The 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 be in the form of a blockchain) and an underlying agreement between member nodes called an endorsement or endorsement policy. Generally, blockchain entries are "approved" before being committed to the blockchain, while entries that are not endorsed are ignored. A typical endorsement policy allows the smart contract executable code to specify an endorser for the entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified in the endorsement policy, the policy is executed to validate the entry. After validation, the entry enters an ordering phase, during which a consensus protocol generates an ordered sequence of endorsed entries organized into blocks.

[0013] A node is a communicating entity in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped together within a trust domain and associated with logical entities that control the node in various ways. Nodes may include different types, such as client or submitting client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which may receive client-submitted entries, commit the entries, and maintain a ledger state and copy of the blockchain entries. A peer may also have the role of an endorser. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system, when committing entries and modifying the blockchain's world state. The world state may constitute the initial blockchain entry, typically including control and configuration information.

[0014] A ledger is an ordered, tamper-resistant record of all state transitions of a blockchain. State transitions can result from invocations (i.e., entries) of smart contract executable code submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of key-value pairs of assets being committed to the ledger as one or more operands, such as creation, update, deletion, and the like. A ledger includes a blockchain (also called a chain) that stores immutably ordered records in blocks. A ledger also includes a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel in which it is a member.

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

[0016] The current state of the immutable ledger represents the most recent values for all keys contained in the chain entry log. Because the current state represents the most recent key values known on the channel, it is sometimes referred to as the world state. Invocations of smart contract executable code execute entries against the ledger's current state data. To streamline interactions with the smart contract executable code, the most recent values of keys may be stored in a state database. The state database may simply be an indexed view onto the chain's entry log, and therefore may be regenerated from the chain at any time. The state database may be automatically restored (or generated if necessary) upon peer node startup and before entries are accepted.

[0017] Blockchains differ from traditional databases in that they are not centralized storage, but rather distributed, immutable, and secure storage, where nodes must share changes to records in storage. Some properties inherent in blockchains and that aid in their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

[0018] Exemplary embodiments provide service for a particular vehicle and / or a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or an operator of a vehicle owned by another party. The vehicle may require service at specific intervals, and service requests may require approval before service is permitted. A service center may also provide service to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirement (e.g., urgent, critical, moderate, minor, etc.). Vehicle requests may be monitored via one or more vehicle and / or roadway sensors or cameras that report sensed data to a central controller computing device within the vehicle and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the following: inside the vehicle, outside the vehicle, on fixed objects remote from the vehicle, and on another vehicle in close proximity to the vehicle. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, requests for service, vehicle gear shifting, vehicle steering, and the like. Sensors as described herein may also be devices, such as wireless devices, within and / or in proximity to the vehicle. Sensor information may also be used to identify whether the vehicle is operating safely and whether the occupant has engaged in any unexpected vehicle conditions, such as during vehicle access and / or usage. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be created and committed to an immutable ledger as determined in a “decentralized” manner by a permission-granting consortium, and thus by a blockchain membership group, etc.

[0019] Each interested party (i.e., owner, user, company, agency, etc.) may want to limit the exposure of private information, and therefore, blockchain and its immutability can be used to manage permissions for each specific user-vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is needed, identify collision events and / or degradation events, identify events that pose safety concerns, identify event participants, and distribute the vehicle event data to registered entities seeking access to the data. Results can also be identified, and necessary information can be shared among registered companies and / or individuals based on a consensus method associated with the blockchain. This method could not be implemented with traditional centralized databases.

[0020] To create maps of terrain and roads that the vehicle can use for navigation and other purposes, the various driving systems of the present solution may utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (lidar) projectors, radar, ultrasonic sensors, etc. In some embodiments, instead of lidar, GPS, maps, cameras, sensors, and the like may also be used in autonomous vehicles.

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

[0022] The shared and received data may be stored in a database, which generally maintains the 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 central processing unit (CPU), a server 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 are particularly suitable for security purposes because the centralized database is in a single location. In a centralized database, having all data in a single storage location also means that a given data set has only one primary record, thereby minimizing data redundancy. Blockchains can be used to store data and transactions related to transportation means.

[0023] Any of the operations described herein may be performed by one or more processors (e.g., microprocessors, sensors, electronic control units (ECUs), head units, and the like) with or without memory that may be located onboard the vehicle and / or offboard the vehicle (e.g., servers, computers, mobile / wireless devices, etc.). The one or more processors may communicate with other memory and / or other processors onboard or offboard in other vehicles to utilize data being transmitted by and / or to the vehicle. The 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] FIG. 1A illustrates a network diagram of a system 100 for predicting grid-related events, according to an exemplary embodiment. The system 100 may include one or more vehicles 104, a resource provider 110, an electricity provider 120, a processor 130, and one or more locations 140 within an area. The vehicles 104 may include cars, trucks, recreational vehicles, construction vehicles, motorcycles, mopeds, electric bicycles, trains, aircraft, and the like. In one embodiment, the vehicles 104 may be at least partially powered by electrical energy (i.e., electric vehicles). The resource provider 110 may include an entity that provides resources 106 to the electricity provider 120. For example, the resources 106 may include natural gas, coal, nuclear fuel, hydroelectric power, wind, and the like. The electricity provider may include a local or regional electric utility. The electricity provider 120 may receive the resources 106 from the resource provider 110 and convert the resources 106 into grid electricity 112. Grid electricity 112 is distributed to one or more areas proximate to an electric utility, the areas including locations 140 .

[0025] The processor 130 may determine (108) that a resource delivery issue exists from communication with the resource provider 110. The processor 130 may determine (114) an electrical impact from communication with the electricity provider 120. The processor 130 may determine (116) an affected area from communication with the electricity provider 120 and one or more locations 140 within the area. Then, as a result of the determination 108 that a resource delivery issue exists, the determination 114 of the electrical impact, and the determination 116 of the affected area, the processor 130 may dispatch (118) one or more vehicles to locations within the area. Once dispatched, the vehicles 104 may travel to one or more locations 140 within the area to provide vehicle electricity 122 to the one or more locations in a vehicle-to-grid (V2G) operation.

[0026] 1B shows an example diagram of a grid-related event prediction system 150 according to an example embodiment. System 150 may include one or more vehicles 104 that may transport passengers and / or cargo from one location to another. Vehicle 104 may include one or more processors and associated memory devices, including, but not limited to, vehicle processor 160 or other vehicle processors, navigation processors, communication processors, ECUs, sensor processors, and the like.

[0027] System 150 may include server 170. Server 170 may include one or more computers communicatively coupled to vehicle processor 160 and energy source processor 180. Server 170 may include one or more processors and a memory device for storing applications and data. In one embodiment, server 170 may be associated with the management or distribution of electricity for an area, an electric utility, and the like. An area may be a neighborhood, city, town, district, or group of locations in close proximity to one another. In one embodiment, server 170 may be located on a network or in the cloud, may be part of vehicle 104, and / or may be at or connected to one or more vehicle charging stations. In one embodiment, server 170 may include processor 130.

[0028] The system 150 may also include an energy source processor 180. The energy source processor 180 may be associated with a source of the resource 160, such as the resource provider 110. The energy source processor may also or alternatively be associated with an electricity provider 120, such as a power plant, solar farm, wind farm, nuclear energy facility, hydroelectric facility, and the like. In one embodiment, successful production of electrical energy 112 may depend on the supply of natural gas resources 106 via pipelines to gas generators, water to hydroelectric turbines, nuclear fuel to nuclear reactors, solar energy to solar panels, or wind to wind turbines. For example, predictions of electrical grid conditions may be accurate, but if there are generation or mechanical issues with the delivery of the natural gas resource 106, the electrical grid 112 may not produce the required level of electricity. Furthermore, the natural gas provider 110 may not be required to winterize its equipment like the electricity provider 120. Thus, shortages in natural gas resources 106 may be difficult to predict but may be able to affect the electrical grid 112. Dependence on weather (such as wind and sunlight) is unpredictable and may contribute to unexpected interruptions in energy generation.

[0029] In one embodiment, vehicle processor 160 may determine 162 the current location and status of the associated vehicle and may send a notification of the current location and status 164 to server 170. In one embodiment, vehicle processor 160 may determine 162 the current location and status periodically, for example, every 15 minutes. In another embodiment, server 170 may send a request to vehicle processor 160 to provide the current location and status. The request may be sent periodically or in response to a received energy supply status 172.

[0030] In one embodiment, the current location may include one or more of GPS coordinates, a street address, a business name, a zip code, and the like. In one embodiment, the status may include one or more of the current charge level of the vehicle 104, the amount of charge needed, the distance from a charging station, a schedule associated with the vehicle 104 (or a user associated with the vehicle 104), a time frame during which the vehicle 104 may be available for travel within the area, the distance from the area, and the like.

[0031] In one embodiment, vehicle processor 160 may communicate with one or more other vehicle processors 160 associated with other vehicles 104, and the one or more other vehicle processors 160 may communicate with server 170. In one embodiment, each of the other vehicle processors 160 may transmit the current location and status 164 for each of the other vehicles 104 in a similar manner to vehicle 104 and vehicle processor 160. In this manner, server 170 may be a recipient of the current location and status 164 for a group of related vehicles 104 (e.g., a company's repair fleet, vehicles owned by a family, a group of commonly owned package delivery vehicles, a group of taxis, a company's construction-related vehicles, etc.).

[0032] In one embodiment, server 170 may send a notification to energy source processor 180, which may include energy supply status request 166. The notification may be sent in response to server 170 receiving information about a possible event related to electric energy supply. For example, server 170 may receive an email from natural gas provider 110 indicating that pipeline repairs or other forms of construction are scheduled for an upcoming timeframe, may receive a text message from a weather forecasting website providing a warning of an upcoming severe weather event that may affect power distribution, or may receive a notification from an emergency services organization that a fire, flood, or other natural disaster may disrupt electric energy availability from grid 112 in the area.

[0033] In one embodiment, in response to energy source processor 180 receiving energy supply status request 166, energy source processor 180 may determine 168 an energy supply status and transmit energy supply status 172 to server 170. Energy supply status 172 may include one or more of an amount of electrical energy 112 that the energy source may provide, a time or time frame during which electrical energy may be provided, an indication of the amount of fluctuation in electrical energy 112, and one or more areas that may be affected by a limited amount or lack of electrical energy 112.

[0034] Server 170 may receive energy supply status 172 from any number of electricity providers 120 and associated energy source processors 180. In one embodiment, server 170 may determine 174 an electricity impact on electricity generation based on the energy supply status 172 received from one or more energy source processors 180. The electrical energy impact may reflect the amount of electrical energy over time, for example, a 50% reduction in normal electrical energy over a period of time. For example, normal electrical energy may be an average of historical amounts of electricity.

[0035] In one embodiment, server 170 may determine 176 areas affected by the impact of the electrical energy. In one embodiment, energy supply status 172 may include an indication of one or more areas affected by the impact of the electrical energy. For example, a first energy source may provide electrical energy to locations within a first zip code or a portion of the first zip code, and a second energy source may provide electrical energy to locations within a second zip code or a portion of the second zip code. Energy supply status 172 may indicate a 50% reduction in electrical energy from the first energy source, and server 170 may store an association of the first energy source and the first zip code in an accessible memory device. Energy supply status 172 may indicate a 10% reduction in electrical energy from the second energy source, and server 170 may store an association of the second energy source and the second zip code in an accessible memory device. From this information, server 170 may determine that locations within the first zip code have the greatest risk of electrical energy loss.

[0036] In one embodiment, server 170 may dispatch 178 one or more vehicles to an area to provide vehicle-to-grid (V2G) electric energy transfer to one or more locations within the area. One or more vehicles 104 may be commonly owned by an entity (e.g., a household or family, a business, a city, etc.) and may be capable of supplying and providing V2G service to locations needing electric energy 112. Server 170 may send a notification 182 to vehicle processor 160 of one or more vehicles 104 to move to a location proximate to the area needing energy. In one embodiment, the notification may include one or more of the following: an address or location name in area 140, the amount of electric energy to provide to the location, the time to provide the electric energy, a description of other vehicles 104 providing energy to the location (e.g., license plate number, VIN number, vehicle description, driver name, etc.), and the like.

[0037] In one embodiment, vehicle processor 110 may, in some cases, need to obtain more charge than is available to the vehicle 104 corresponding to vehicle processor 160. For example, vehicle processor 160 may communicate with the vehicle's 104 charge processor to obtain the vehicle's 104 current charge level and with the vehicle's 104 navigation processor to determine the amount of charge needed to travel to a home or business location where a charging station is located. If the requested amount of charge to provide to a location (specified in notification 182 of travel to a location proximate to an area) is greater than the sum of the vehicle's 104 current charge level and the amount of charge needed to travel to the home or business location, vehicle 104 may need to obtain more charge (184). For example, vehicle processor 160 may request directions to the nearest available charging station from the vehicle's 104 navigation processor. The navigation processor may navigate vehicle 104 to the nearest available charging station, or the navigation processor may provide directions to the driver of vehicle 104 audibly and / or displayed on the vehicle's 104 head unit. The vehicle 104 may then travel to the nearest available charging station and receive an amount of charge up to the vehicle's 104 maximum amount of charge.

[0038] In one embodiment, the vehicle processor 160 may instruct the vehicle 104 to travel to the location and provide 186 an amount of charge to the location. For example, the location and the amount of charge to provide may be specified in a notification 182 that travels to a location proximate to the area.

[0039] In one embodiment, determining 108 that a problem with resource delivery exists may include receiving a notification from a resource provider 110 of a limited resource supply 108, comparing the level of the resource 106 to a threshold, and notifying an electricity provider 120 in response to the current level of the resource 106 being below the threshold.

[0040] For example, natural gas supply (i.e., resource 106) may be limited for various reasons. However, that in itself may not mean that a problem exists. The resource 106 level for the electricity provider 120 may need to be compared to a predetermined threshold in a memory device accessible to the processor 130 or server 170 to see if it is, in fact, low enough to pose a problem that justifies dispatching the vehicle 104. If the resource 106 level is below the predetermined threshold, the processor 130 or server 170 may determine that a problem exists. If the resource 106 level is above the predetermined threshold, the processor 130 or server 170 may determine that no problem currently exists.

[0041] In another embodiment, the electricity provider 120 may compare the level of resources 106 that the electricity provider 120 is receiving from the resource provider 110 and may determine that the current level of provided resources 106 is above / at / below a threshold value of the electricity provider 120. If the level of resources 106 that the electricity provider 120 is receiving from the resource provider 110 is below the threshold value of the electricity provider 120, the electricity provider 120 or the energy source processor 180 may provide an energy supply status 172 to the server 170 indicating that a problem exists.

[0042] In one embodiment, the method may include determining that a dispatched vehicle 104 has a low electricity level, identifying available charging stations in the area, and traveling to the available charging station to receive additional electricity. In one embodiment, the vehicle processor 160 may receive a notification 182 to travel to an area but determine that the vehicle 104 currently has a low charge level (i.e., meaning that little V2G energy may be available). The vehicle processor 160 may instruct the vehicle 104 to proceed to a charging station in the area to receive additional charge, preferably to a full level.

[0043] In one embodiment, determining the electricity impact 114 may include determining 108 that a resource delivery problem exists for a future time period, determining the demand for electricity during that time period, and determining a discrepancy between the resource problem 108 and the demand for electricity. In one embodiment, the resource provider 110 may send a notification to the processor 130 that a limited amount of the resource 106 may be provided to the electricity provider 120 for a future time period. The amount of the resource 106 may be convertible to (i.e., they may be similar to) the amount of electricity 112 provided by the electricity provider 120. The amount of the resource 106 and the demand by locations 140 within the area may typically vary depending on the time of day, season, weather, and other factors. Thus, the discrepancy may be the amount of the electrical impact 114 resulting from the resource shortage.

[0044] In one embodiment, the problem 108 may be applied to a future time frame, and the method may include determining electricity restoration after the time frame and notifying dispatched vehicles 104 of the restoration of electricity in the area. While many electricity interruption events are unplanned and of unknown duration, some may be known and of fixed duration. For example, replacement of faulty resource-related equipment or other construction- or repair-related activity may be scheduled for a particular time frame on a particular day. Once the time frame has expired, power restoration may be expected.

[0045] In one embodiment, determining the affected area may include requesting a district served by electricity provider 120 and designating a portion of the district as the affected area based on electricity lost in the portion of the district.

[0046] In one embodiment, processor 130 may transmit the request to a processor associated with electricity provider 120, such as energy source processor 180. The request may include the district served by electricity provider 120. The district may include various areas, neighborhoods, towns, villages, cities, counties, and the like. In one embodiment, the district may include one or more roadways, latitude / longitude measurements, and / or boundaries. Electricity provider 120 may review limited resources 106 and determine that grid electricity 112 may not be available to supply the entire district. A response to the request may specify the areas or portions of the district that will experience electricity impacts (114).

[0047] In one embodiment, the electricity provider 120 may obtain the level of the resource 106 that the electricity provider 120 is receiving from the resource provider 110 and determine whether the current level of the provided resource 106 is above, at, or below a threshold value of the electricity provider 120. The processor 130 may receive the amount or level of the resource 106 that the resource provider 110 is transmitting to the electricity provider 120. The processor 130 may request the threshold level from the electricity provider 120, and a processor associated with the electricity provider 120 (e.g., energy source processor 180) may transmit the threshold amount to the processor 130. The processor 130 may compare the amount or level of the resource 106 from the resource provider 110 with the threshold value received from the electricity provider 120. If the amount or level of the resource 106 is above the threshold value, the processor 130 may determine that a sufficient amount of the resource 106 is being generated and no negative impact on the grid electricity 112 is expected to occur. If the amount or level of the resource 106 is below the threshold, the processor 130 may determine that an insufficient amount of the resource 106 is being produced and that a negative impact on the grid electricity 112 is expected to occur.

[0048] In one embodiment, the method includes determining that a number of vehicles 104 to be dispatched may have a current energy level below a threshold and may instruct one or more of the number of vehicles 104 to obtain more electricity before traveling to the area. The server 170 may receive a current location and status 164 from each of the vehicles 104 in the group. The status may indicate a current charge level, and the server 170 may sum the received current charge levels to obtain a total current charge level. In one embodiment, once the server 170 determines 176 an area affected by the impact of the electric energy, the server 170 may request a required amount of electric energy for the area from the energy source processor 180. The server 170 may compare the required amount of electric energy with the total current charge level and find that the total current charge from the vehicles 104 is insufficient to meet the required amount of electric energy. The server 170 may store a threshold in an accessible memory device specifying a minimum acceptable level of electric energy stored in each vehicle 104. In such cases, it may be useful to dispatch only vehicles 104 that are currently above the threshold level of electricity to the area, while instructing vehicles 104 that are currently below the threshold level of electricity to first proceed to a charging station to obtain more charge.

[0049] In one embodiment, dispatching vehicles 104 to provide electricity may include determining 176 vehicles 104 proximate to an area, determining a subset of vehicles 104 that have available electricity, notifying 182 the subset of vehicles 104 to proceed to a location within the area, and providing 186 the available electricity to the location.

[0050] In one embodiment, server 170 may receive notifications 164 from each vehicle processor 160 of each vehicle 104 indicating the current location and status for each vehicle 104. From the current location, server 170 may determine 176 the distance or proximity to the area affected by the effects of electrical energy. For example, the current location may include GPS coordinates for each vehicle 104, which vehicle processor 160 in each vehicle 104 receives from a GPS receiver in each vehicle 104. Server 170 may compare the received GPS coordinates with GPS coordinates for the area stored in an accessible memory device. For example, server 170 may select only vehicles 104 that are within a certain time or distance proximity to area 176. For example, the time or distance proximity may be 15 minutes or 5 miles (approximately 8.046 km).

[0051] In one embodiment, server 170 may receive an indication of the current charge level and the maximum level of charge in current status and location notification 164. Current status and location notification 164 may also include the distance vehicle 104 can travel given its current charge level. From this, server 170 may determine whether vehicle 104 has available electricity by subtracting the distance to travel to a location within the area from the distance vehicle 104 can travel given its current charge level. If the difference is greater than the number stored in the accessible memory device, vehicle 104 may have available electricity. If the difference is negative or less than the number stored in the accessible memory device, vehicle 104 may not have available electricity. This determination from each vehicle 104 may result in only a subset of vehicles 104 proximate to the area having available electricity.

[0052] In one embodiment, server 170 may notify a subset of vehicles 104 that have available electricity to proceed to locations 140 in the area and provide 186 the available electricity to the locations in the area. The locations may receive the available electricity and continue to operate by keeping lights on, powering selected appliances, powering HVAC devices, and / or the like.

[0053] In another embodiment, the method may include determining that a schedule for a dispatched vehicle 104 limits the amount of electricity the dispatched vehicle 104 can provide to an area, identifying one or more other vehicles 104 that can provide electricity, and dispatching the one or more other vehicles 104 to the area.

[0054] In one embodiment, when vehicle 104 receives dispatch notification 182, vehicle 104 may determine that the schedule for vehicle 104 allows for the transmission of less than all available electricity. For example, the schedule may require vehicle 104 to transport a driver / passenger to a reserved location. Vehicle processor 160 may determine an amount of electricity to travel from the location to provide electrical energy in the area, and the reserved location may reduce the amount of available electrical energy. Vehicle processor 160 may send a notification of the reduced amount of electrical energy to server 170.

[0055] In one embodiment, server 170 may determine a difference between the original amount of electric energy that vehicle 104 could provide to the location and the reduced amount of electric energy, the difference reflecting the amount of electric energy provided to locations 140 in the area from other vehicles 104. In one embodiment, as further disclosed herein, server 170 may identify the vehicle 104 closest to the area by checking the current location and status 164 from other vehicles 104 that are not proximate to the area and comparing GPS coordinates. Server 170 may obtain the current available amount of electricity from each of the nearest non-proximate vehicles 104 and determine a group of vehicles 104 that have a cumulative amount of available electric energy equal to at least the difference between the original amount of electric energy that vehicle 104 could provide to the location and the reduced amount of electric energy. Server 170 may send a notification 164 to selected non-proximate vehicles 104 to move into the area and provide available charge to locations 140 in the area.

[0056] In one embodiment, the method may include obtaining available electricity and vehicle availability from vehicles 104 proximate to the area, selecting vehicles 104 having available electricity above a first threshold and vehicle availability above a second threshold, and dispatching the selected vehicles 104 to provide electricity to locations 140 in the area. For example, it may be advantageous to verify each vehicle 104 proximate to the area to ensure it is available and has sufficient electricity to make the vehicle 104 available. As disclosed further herein, the current location and status 164 may also include the current electricity level of the vehicle 104. The server 170 may compare the current electricity level received from each vehicle 104 and compare it to a first threshold stored in an accessible memory device.

[0057] Vehicle availability may be determined by comparing the estimated time to travel to a location within the area and provide available electricity. As further disclosed herein, the estimated time to travel to the location may be determined by comparing the GPS coordinates of the vehicle's current location and the location providing available charge. The time to provide available electricity may be determined by multiplying the amount of available electricity by the rate of discharge through charging stations at the location within the area. For example, if the estimated time to travel to (and, possibly, from) the location is 35 minutes and the time to provide available electricity is 25 minutes, the total time may be 1 hour. Vehicle processor 160 may compare the 1-hour total time with a schedule stored in an accessible memory device, which may indicate that the next appointment is 2 hours away. From this comparison, vehicle processor 160 may determine that vehicle 104 availability is equal to the difference (e.g., 1 hour) between the total time and the time until the next appointment. Vehicle 104 availability may be above a second threshold (e.g., 0 hours), and therefore, vehicle 104 may be considered a selected vehicle 104 that can provide electricity to locations within the area (186). In one embodiment, vehicle processor 160 may make an availability determination and provide an indication that a vehicle 104 is available or unavailable to server 170. If the current electrical level received from each vehicle 104 is above a first threshold and server 170 receives an indication that a vehicle 104 is available, server 170 may dispatch 178 the vehicle.

[0058] In one embodiment, the method may include determining an available electricity level for each of the dispatched vehicles 104, matching the electricity needs at locations 140 in the area with the available electricity levels from a subset of the dispatched vehicles 104, and dispatching the subset to the locations 140. For example, it may be most efficient to match the electricity needs at one or more particular locations 140 in the area with particular vehicles 140. In that way, V2G electricity may be most efficiently distributed to the locations 140 in the area.

[0059] In one embodiment, the current location and status 164 from each vehicle processor 160 may include the vehicle's 104 current electricity level and / or the available electricity level for the vehicle 104 (i.e., the level of energy that could potentially be provided to a location, taking into account other destinations the vehicle 104 needs to travel to, the locations of available charging stations, and the schedule associated with one or more vehicle occupants). The server 170 may determine the electricity demand (e.g., 500 kilowatt-hours or kWh) for one or more locations 140 in the area and match the required amount of electricity to a subset of the dispatched vehicles 104. For example, five dispatched vehicles 104 may have available electricity levels of 100 kilowatts (kW), 150 kW, 200 kW, 50 kW, and 250 kW. The server 170 may identify the number of dispatched vehicles 104 that have available electricity minimally greater than the identified location's electricity demand (e.g., 500 kWh). Thus, for a one-hour electricity loss event, server 170 may select vehicles 104 with available electricity levels of 250 kW, 200 kW, and 50 kW (500 kW total available electricity), or vehicles 104 with available electricity levels of 100 kW, 150 kW, and 250 kW (500 kW total available electricity). Server 170 may dispatch the selected vehicles 104 by providing a notification to vehicle processor 160 of the selected vehicles 104 to proceed to the identified location and provide available electricity to the location (186). While there can potentially be numerous ways to identify and select which particular vehicles 104 should proceed to the identified location, server 170 may include other criteria for selecting a particular vehicle 104, including, but not limited to, proximity to the identified location, a schedule associated with the particular vehicle, proximity to a charging station, and the like.

[0060] The flow diagrams depicted herein, such as Figures 1A, 1B, 2C, 2D, 2E, 3A, 3B, and 3C, are separate examples that may be the same or different embodiments. Any of the operations in one flow diagram may be employed in and shared with another flow diagram. The example operations are not intended to limit the subject matter of any embodiment or corresponding claims.

[0061] It is important to note that all flow diagrams and corresponding processes derived from Figures 1A, 1B, 2C, 2D, 2E, 3A, 3B, and 3C may be part of the same process or may share sub-processes with each other, thus making the diagrams combinable into a single preferred embodiment that does not require any one specific operation, but performs specific operations from one exemplary process and one or more additional processes. All exemplary processes relate to the same physical system and may be used separately or interchangeably.

[0062] FIG. 2A illustrates a vehicle network diagram 200 according to an exemplary embodiment. The network includes elements including a vehicle 202 including a processor 204 and a vehicle 202' including a processor 204'. Vehicles 202, 202' communicate with each other via processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between vehicles 202, 202' may occur directly, via private and / or public networks (not shown), or via other vehicles and elements comprising one or more processors, memory, and software. While depicted as a single vehicle and processor, multiple vehicles and processors may be present. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the elements.

[0063] FIG. 2B shows another vehicle network diagram 210 according to an exemplary embodiment. The network comprises elements including a vehicle 202 including a processor 204 and a vehicle 202' including a processor 204'. Vehicles 202, 202' communicate with each other via processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between vehicles 202, 202' may occur directly, via private and / or public networks (not shown), or via other vehicles and elements comprising one or more of a processor, memory, and software. Processors 204, 204' may further communicate with one or more elements 230 including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicle 222, computers 224, I / O devices 226, and voice applications 228. The processor 204, 204' may further communicate with elements comprising one or more of a processor, memory, and software.

[0064] Although depicted as a single vehicle, processor, and element, there may be multiple vehicles, processors, and elements. Information or communication may occur to and / or from any of processors 204, 204′ and element 230. For example, mobile phone 220 may provide information to processor 204, which may cause vehicle 202 to initiate an action, may further provide information or further information to processor 204′, which may cause vehicle 202′ to initiate an action, may further provide information or further information to mobile phone 220, vehicle 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 the elements.

[0065] 2C illustrates yet another vehicle network diagram 240, according to an exemplary embodiment. The network comprises elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and to element 230 (depicted in FIG. 2B). The vehicle 202 may be a vehicle, a server, or any device having a processor and memory.

[0066] The processor 204 performs one or more of determining 244C that there is a problem with resource delivery to the electricity provider, determining 246C an electrical impact based on the problem, determining 248C an area affected by the electrical impact, and dispatching 250C a vehicle to provide electricity to locations in the area.

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

[0068] The processor 204 receives notification from the resource provider of limited resource supply, compares the level of the resource to a threshold, and notifies the electricity provider 244D in response to the current level of the resource being less than the threshold; determines that there will be a problem with resource delivery in the upcoming time period, determines the demand for electricity during the time period, and determines the discrepancy between the problem with the resource and the demand for electricity 245D; requests a district served by the electricity provider and designates a portion of the district as an affected area based on electricity lost in the portion of the district 246D; determines vehicles proximate to the area, and designates a subset of vehicles with available electricity. and notifying a subset of vehicles to proceed to locations within the area and providing available electricity to the locations 247D; obtaining available electricity and vehicle availability from vehicles proximate to the area, selecting vehicles having available electricity above a first threshold and vehicle availability above a second threshold, and dispatching the selected vehicles to provide electricity to the locations within the area 248D; and determining an available electricity level for each of the dispatched vehicles, matching the amount of electricity required at the locations within the area with the available electricity level from the subset of dispatched vehicles, and dispatching the subset to the locations 249D.

[0069] 2E illustrates yet another vehicle network diagram 260 according to an exemplary embodiment. Referring to FIG. 2E, network diagram 260 includes a vehicle 202 connected to other vehicles 202′ and an update server node 203 in a blockchain network 206. Vehicles 202 and 202′ may represent vehicles / vehicles. Blockchain network 206 may have a ledger 208 that stores software update verification data and sources of verification 207 for future use (e.g., in audits).

[0070] While this example details only one vehicle 202, multiple such nodes may be connected to the blockchain 206. It should be understood that vehicle 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 present application. Vehicle 202 may comprise a computing device or server computer, or the like, and may include a processor 204, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or another hardware device. While a single processor 204 is depicted, it should be understood that vehicle 202 may include multiple processors, multiple cores, or the like without departing from the scope of the present application. Vehicle 202 may be a vehicle, a server, or any device having a processor and memory.

[0071] The processor 204 performs one or more of: receiving 244E a confirmation of an event from one or more elements described or depicted herein, the confirmation comprising a blockchain consensus between peers represented by any of the elements; and executing 246E a smart contract to record the confirmation in the blockchain based on the blockchain consensus. The consensus is formed between any of the elements 230 and / or one or more of the elements described or depicted herein, including a vehicle, a server, a wireless device, etc. In another example, the vehicle 202 can be any of the elements 230 and / or one or more of the elements described or depicted herein, including a server, a wireless device, etc.

[0072] The processor and / or computer-readable medium 242E may reside, completely or partially, inside or outside the vehicle. The steps or functions stored in the computer-readable medium 242E may be performed, completely or partially, in any order by any of the processors and / or elements. Furthermore, one or more steps or functions may be added, omitted, combined, performed later, etc.

[0073] 2F shows a diagram 265 depicting the powering of one or more elements. In one example, a vehicle 266 may provide power stored in its batteries to one or more elements, including other vehicles 268, charging stations 270, and an electrical grid 272. The electrical grid 272 may be connected to one or more of the charging stations 270, which may be connected to one or more of the vehicles 268. This configuration allows for the distribution of electricity / power received from the vehicle 266. The vehicle 266 may also communicate with the other vehicles 268 via vehicle-to-vehicle (V2V) technology, cellular communications, Wi-Fi, and the like. The vehicle 266 may also communicate with the other vehicles 268, charging stations 270, and / or the electrical grid 272 wirelessly and / or via wires. In one example, vehicle 266 is routed (or routes itself) to electric grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the present solution, vehicle 266 may provide energy to one or more of the elements depicted herein in various advantageous ways as described and / or depicted herein. Additionally, vehicle safety and efficiency may be enhanced, and environmental impacts may be positively impacted as described and / or depicted herein.

[0074] The term "energy" may be used to refer to any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be referenced in relation to a voltage source of electrical charge and / or current supply provided from an entity to a vehicle during charging / use operations. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or from 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 that increase or decrease the energy level of one or more vehicles at a given time.

[0075] In one example, charging station 270 manages the amount of energy transferred from vehicle 266 so that vehicle 266 has enough charge remaining to reach its destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transfer between vehicles 268, and both vehicles may be moving. In one embodiment, wireless charging may occur via a stationary charger (such as a charging mat in a garage or parking space) and the vehicle's battery aligned with each other. In one example, an idle vehicle, such as vehicle 266 (which may be autonomous), is instructed to provide an amount of energy to 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 excess energy from at least one other vehicle 268 and transfer the stored excess energy at charging station 270. In one example, factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (e.g., weight), schedules of occupants using the vehicle, and anticipated schedules of occupants waiting for the vehicle determine the amount of energy transferred to charging station 270. In one example, vehicle 268, charging station 270, and / or electrical grid 272 may provide energy to vehicle 266.

[0076] In one embodiment, a location, such as a building, residence, or the like (not depicted), is communicatively connected to one or more of an electric grid 272, a vehicle 266, and / or a charging station 270. The rate of current flow to one or more of the location, vehicle 266, and other vehicles 268 is modified in response to external conditions, such as weather. For example, when the external temperature is very hot or very cold, increasing the likelihood of a power outage, the flow of electricity to connected vehicles 266 / 268 is slowed to help minimize the likelihood of a power outage.

[0077] In one example, the solutions described and depicted herein may be used to determine load impacts on a vehicle and / or system, provide energy to a vehicle and / or system based on future demand and / or priority, provide information between a device including a module and a vehicle, and enable a processor of the device to wirelessly communicate with a vehicle regarding the amount of battery energy storage in the vehicle. In one example, the solutions may also be used to provide charge from a vehicle to a location based on factors such as the temperature of the location, the cost of energy, and the power level of the location. In one example, the solutions may also be used to manage the amount of energy remaining in a vehicle after a portion of the charge has been transferred to a charging station. In one example, the solutions may also be used to notify a vehicle to provide an amount of battery energy in the vehicle, the amount of energy to transfer being based on the distance of the vehicle to the module to receive energy.

[0078] In one example, the solution may also be utilized to use a mobile energy storage unit that travels to a vehicle with excess energy using a determined route to deposit the stored energy into the electric grid. In one example, the solution may also be utilized to determine the priority of a vehicle's determination of demand to provide energy to the grid and the priority of current demands on the vehicle, such as passengers or future passengers or current or future cargo. In one example, the solution may also be utilized to determine when a vehicle is not being used, to maneuver to a location to discharge excess energy into the energy grid, and then return to the previous location. In one example, the solution may also be utilized to determine the amount of energy a vehicle needs to provide needed energy to another vehicle through energy transfer between vehicles based on one or more conditions, such as weather, traffic, road conditions, vehicle status, and occupants and / or goods in the other vehicle, and to instruct the vehicle to route to the other vehicle to provide energy. In one example, the solution may also be utilized to transfer energy from one moving vehicle to another moving vehicle. In one example, the solution may also be used to extract energy by a vehicle based on the energy consumed by the vehicle to reach and provide service at a meeting point with another vehicle and the estimated energy consumed to return to the original location. In one example, the solution may also be used to provide a remaining distance required to a charging station, where the charging station determines the amount of energy to extract from the vehicle, and the amount of remaining charge is based on the remaining distance. In one example, the solution may also be used to manage a vehicle being charged by more than one point at the same time, for example, by both a charging station via a wired connection and another vehicle via a wireless connection.In one example, the solution may also be utilized to apply priorities to the distribution of energy to vehicles, with priority being given to vehicles that provide a portion of their stored charge to another entity, such as the electric grid, homes, and the like.

[0079] In one embodiment, vehicles 266 and 268 may be utilized as bidirectional vehicles. Bidirectional vehicles may function as mobile microgrids that can assist in providing power to grid 272 and / or reduce power consumption when the grid is stressed. In addition to receiving charge for the vehicle, bidirectional vehicles may incorporate bidirectional charging, where the vehicle takes energy from the vehicle and “push” the energy back to grid 272, otherwise referred to as “V2G.” In bidirectional charging, electricity flows both to and from the vehicle. When the vehicle is charging, alternating current (AC) electricity from grid 272 is converted to direct current (DC). This may be done by one or more converters on the vehicle itself or in charger 270. Energy stored in the vehicle's battery may be sent back to the grid in the opposite direction. Energy is converted from DC to AC through a converter, usually located in charger 270, otherwise referred to as a bidirectional charger. Moreover, the solution as described and depicted with respect to FIG. 2F may be utilized in this network and / or system, as well as other networks and / or systems.

[0080] FIG. 2G is a diagram 275 illustrating the interconnections between different elements. The solution may be stored and / or executed, in whole or in part, on and / or by one or more computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′ associated with various entities, all communicatively coupled to and in communication with a network 286. A database 287 is communicatively coupled to the network and enables data storage and retrieval. In one example, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructure 282, one or more residential buildings 283, an electric grid / charging station 284, a microphone 285, and / or another vehicle 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 the 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 institutions. One or more public buildings 281 may utilize computing devices 281′. One or more service providers 279 may include dealerships, tow truck services, collision centers, or other repair shops. One or more service providers 279 may utilize computing devices 279′. These various computing devices may be directly and / or communicatively connected to one another via wired networks, wireless networks, blockchain networks, and the like. In one example, the microphone 285 may be utilized as a virtual assistant. In one example, the one or more traffic infrastructure 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'.

[0081] In one example, vehicles 277 / 276 may transport people, objects, permanently or temporarily attached equipment, and the like. In one example, vehicles 277 may communicate with vehicles 276 via V2V communications through computers 276′ and 277′ associated with each vehicle and may be referred to as vehicles, cars, vehicles, automobiles, and the like. Vehicles 276 / 277 may be self-propelled, wheeled vehicles such as cars, sport utility vehicles, trucks, buses, vans, or other motor- or battery-powered or fuel-cell-powered vehicles. For example, vehicles 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 vehicle capable of transportation. Vehicles 276 / 277 may be semi-autonomous or autonomous. For example, the vehicle 276 / 277 may be self-piloted and operated without human input. An autonomous vehicle may have and use one or more sensors and / or navigation units to drive autonomously.

[0082] In one example, the solutions described and depicted herein may be utilized to determine access to a vehicle via blockchain consensus. In one example, the solutions may also be utilized to perform profile verification before allowing a vehicle occupant to use the vehicle. In one example, the solutions may also be utilized to have the vehicle indicate (visually, but in another example, verbally, etc.) on or from the vehicle an action (which may be pre-recorded) that the user needs to perform and confirm that the action is the correct action. In one example, the solutions may also be utilized to bifurcate data and provide the vehicle with the ability to decide, based on the risk level associated with the data and the driving environment, how to distribute a portion of the bifurcation data to the occupant with a lower risk level in a safe driving environment and later distribute the remaining portion of the bifurcation data with a higher risk level to the occupant after the occupant has left the vehicle. In one example, the solutions may also be utilized to address vehicle movement across (country / state / etc.) borders and apply new area rules to the vehicle using blockchain and / or smart contracts.

[0083] In one example, the solution may also be utilized to allow a vehicle to continue operating outside a boundary when a consensus is reached by the vehicle based on the vehicle's behavior and the vehicle's occupant characteristics. In one example, the solution may also be utilized to analyze the vehicle's available data upload / download rate, file size, and the speed / direction the vehicle is traveling to determine the distance required to complete the data upload / download and assign a secure area boundary for the data upload / download to be performed. In one example, the solution may also be utilized to instruct a subject vehicle and other nearby vehicles to safely perform a normally dangerous maneuver to allow the subject vehicle to exit in a safe manner, such as when the system determines that an exit is approaching or when the vehicle does not appear ready to exit (e.g., is in the wrong lane or traveling at a speed that is not appropriate for the upcoming exit). In one example, the solution may also be utilized to verify the diagnosis of another vehicle using one or more vehicles while both the one or more vehicles and the other vehicle are traveling.

[0084] In one example, the solution may also be used to detect lane usage at a certain location and time and notify or instruct a vehicle occupant to recommend or not recommend a lane change. In one example, the solution may also be used to eliminate the need to send information via email and the need for the driver / occupant to respond by making payments via email or in person. In one example, the solution may also be used to provide services to vehicle occupants, where the services provided are subscription-based and permissions are obtained from other vehicles connected to the occupant's profile. In one example, the solution may also be used to record changes in the state of rented objects. In one example, the solution may also be used to seek blockchain consensus from other vehicles in proximity to a damaged vehicle. In one example, the solution may also be used to receive media from a server, such as an insurance entity server, or from a vehicle computer that may be related to an accident. The server accesses one or more media files to access damage to the vehicle and stores a damage assessment on the blockchain. In one example, the solution may also be utilized to obtain consensus to determine the severity of an event from several devices at various times prior to the vehicle-related event.

[0085] In one example, the solution may also be utilized to solve the problem of a lack of video evidence of an accident involving a vehicle. The solution details accident-related media inquiries by a vehicle involved in the accident to other vehicles that may have been in the vicinity of the accident. In one example, the solution may also be utilized to record specific portions of the damaged vehicle using the vehicle and other devices (e.g., pedestrian cell phones, street light cameras, etc.).

[0086] In one example, the solution may also be utilized to alert occupants when a vehicle is maneuvering toward a dangerous area and / or event, and to enable the vehicle to notify occupants or a central controller of possible dangerous areas on or near the current vehicle path. In one example, the solution may also be utilized to detect when a vehicle is traveling at a high speed and to use at least one other vehicle to assist in slowing the vehicle so that impacts on traffic are minimized. In one example, the solution may also be utilized to identify a dangerous driving situation, where media is captured by a vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one example, the solution may also be utilized to send a notification to one or more occupants of a vehicle that the vehicle is approaching a traffic control sign on a road, and then receive an indication of poor driving from other nearby vehicles if the vehicle passes the sign. In one example, the solution may also be utilized to partially disable a vehicle by (in certain embodiments) limiting speed, limiting the ability to approach another vehicle, limiting speed to a maximum, and only allowing a given number of miles (approximately 1.609 km) per time period.

[0087] In one example, the solution may also be utilized to correct problems with a vehicle when it is not operating correctly, overcoming the need to rely on software updates. Through observations of other vehicles along a route, a server receives data from multiple other vehicles that may be observing unsafe or erroneous operation of the vehicle. Through analysis, the observations may result in notification to the vehicle when the data suggests unsafe or erroneous operation. In one example, the solution may also be utilized to notify between the vehicle and a dangerous situation that may involve persons unrelated to the vehicle. In one example, the solution may also be utilized to transmit data to a server by either a device associated with an incident with the vehicle or a device in proximity to the incident. Based on the severity of the incident or nearby incident, the server notifies the sender of the data. In one example, the solution may also be utilized to provide recommendations for vehicle operation to either the driver or passengers of the vehicle based on data analysis. In one example, the solution may also be utilized to establish geofences associated with physical structures to determine payment liability for the vehicle. In one example, the solution may also be utilized to coordinate the ability to drop off a vehicle at a location using both the current state and proposed future state of the location and the navigation destination of other vehicles. In one example, the solution may also be utilized to coordinate the ability to automatically arrange for a vehicle to be dropped off at a location, such as a transportation rental entity.

[0088] In one example, the solution may also be utilized to move a vehicle to a different location based on a user event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user based on the results of the original event or a modified event. In one example, the solution may also be utilized to enable verification of available locations within an area through vehicles present in the area. An approximate time when a location may be available is also determined based on verification from the vehicles present. In one example, the solution may also be utilized to move a vehicle to a closer parking space if a parking space becomes available and the elapsed time since initial parking is less than the average event time. Furthermore, the vehicle is moved to a final parking space upon completion of the event or depending on the location of a device associated with at least one occupant of the vehicle. In one example, the solution may also be utilized to plan parking in advance of an upcoming congestion. The system may interact with vehicles to offer some services below the regular rate and / or guide vehicles to alternative parking locations based on the vehicle's priority, thereby improving pre-arrival optimization of parking conditions.

[0089] In one example, the solution may also be used to sell fractional ownership of a vehicle or determine pricing and availability for ride-sharing applications. In one example, the solution may also be used to provide accurate and timely reporting of dealership sales activities, far superior to what is currently available. In one example, the solution may also be used to enable dealerships to request assets on the blockchain. By using the blockchain, consensus is obtained before any asset is transferred. Furthermore, the process may be automated and payments may be initiated on the blockchain. In one example, the solution may also be used to prepare agreements to be made with multiple entities (such as service centers), consensus is obtained, and actions (such as diagnostics) are performed. In one example, the solution may also be used to associate digital keys with multiple users. A first user may be the operator of the vehicle, and a second user is the party responsible for the vehicle. The key is authorized by a server, where the proximity of the key is verified against the location of the service provider. In one example, the solution may also be used to determine services needed at the destination of the vehicle. One or more service locations that can provide the required service are located within an area on the route to the destination and are available to perform the service. Navigation of the vehicle is updated with the determined service locations. A smart contract containing a compensation value for the service is identified, and a blockchain transaction is stored on the distributed ledger for the transaction.

[0090] In one example, the solution may also be used to link a service provider's vehicle with a vehicle occupant's profile to determine services and goods that may be of interest to the occupant in the vehicle. The services and goods are determined by the occupant's history and / or preferences. The vehicle then receives offers from the service provider's vehicle, or in another example, meets with the vehicle that provides the service / goods. In one example, the solution may also be used to detect vehicle(s) within a certain range and send service offers (such as maintenance offers, product offers, or the like) to the vehicle. An agreement is made between the system and the vehicle, and a service provider is selected by the system to provide the agreement. In one example, the solution may also be used to assign one or more vehicle(s) as road managers, who assist in traffic control. Road managers may generate road indicators (such as signal lights, displays, and sounds) to assist traffic flow. In one example, the solution may also be used to alert the vehicle driver via a device, which may be a traffic light or near an intersection. An alert is sent upon an event such as when a traffic light turns green and the vehicle ahead in the list of vehicles does not move.

[0091] FIG. 2H is another block diagram 290 illustrating the interconnections between different elements in one example. A vehicle 276 is presented and includes ECUs 295, 296 and a head unit (otherwise known as an infotainment system) 297. An electronic control unit (ECU) is a system embedded in automotive electronics that controls one or more of the electrical systems or subsystems within the vehicle. ECUs may include, but are not limited to, managing the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECUs are connected to the vehicle's CAN bus 294. The ECUs may also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor 298 (e.g., vehicle computer) may communicate with external elements, such as a server 293, via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 may include its own security policy. The security policy defines the permissible processes that can be executed in the appropriate context. In one example, the security policy can be provided partially or entirely in the vehicle computer 298.

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

[0093] In one example, the solutions described and depicted herein may be utilized to partially disable a vehicle by (in certain embodiments) limiting its speed, limiting its ability to approach another vehicle, limiting its speed to a maximum, and only allowing a given number of miles per time period. In one example, the solution may also be utilized to facilitate vehicle ownership exchanges using blockchain, where data is transmitted to a server by either a device associated with an incident with the vehicle or a device in close proximity to the incident. Based on the severity of the incident or nearby incident, the server notifies the sender of the data. In one example, the solution may also be utilized to help a vehicle avoid an accident, such as when the vehicle is involved in an accident, by the server querying other vehicles in close proximity to the incident. The server attempts to obtain data from the other vehicles, allowing the server to understand the nature of the incident from multiple perspectives. In one example, the solution may also be utilized to determine that a sound from the vehicle is abnormal and transmit data related to the sound and the location of the possible source to a server, which may determine the possible cause and avoid a potentially dangerous situation. In one example, the solution may also be utilized to establish a location boundary through the system when a vehicle is involved in an accident. The boundary is based on decibels associated with the accident. Multimedia content for devices within the boundary is captured to assist in further understanding the accident scenario. In one example, the solution may also be utilized to associate a vehicle with an accident and then capture media captured by devices proximate to the accident location. The captured media is saved as media segments. The media segments are transmitted to another computing device that builds a sound profile of the accident. This sound profile may assist in understanding further details surrounding the accident.

[0094] In one example, the solution may also be utilized to record areas where a potential event occurred, such as when a vehicle comes into or may come into contact with another vehicle (whether moving or parked), using sensors to record audio, video, motion, etc., and the system captures data from sensors that may be on one or more of the vehicles and / or fixed or movable objects. In one example, the solution may also be utilized to determine that a vehicle has been damaged by using sensor data to identify the new condition of the vehicle during a vehicle event and comparing that condition to a vehicle condition profile, thereby enabling the safe and secure capture of important data from a vehicle that is about to be involved in an adverse event.

[0095] In one example, the solution may also be utilized to alert a vehicle occupant when the vehicle determines via one or more sensors that the vehicle is approaching or traveling in the wrong direction on a one-way road. The vehicle has sensors / cameras / maps that interact with the solution's system. The system recognizes the geographic location of the one-way road. The system may audibly notify the occupant, for example, "approaching a one-way road." In one example, the solution may also be utilized to enable vehicles to earn rewards, allowing autonomous vehicle owners to monetize the data collected and stored by their vehicle sensors, creating incentives for vehicle owners to share their data and provide further data to entities that will improve future vehicle performance, provide services to vehicle owners, etc.

[0096] In one example, the solution may also be utilized to increase or decrease vehicle functionality depending on the vehicle's operation over a period of time. In one example, the solution may also be utilized to assign fractional ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine the vehicle's status. Fractional ownership of the vehicle is determined based on the status, and new vehicle responsibilities are established. In one example, the solution may also be utilized to provide data to a replacement / upfitting part, where the data attempts to destroy the replacement / upfit part's authorized functionality and, in response to the unauthorized destruction of the authorized functionality, allows the part to use the replacement / upfit part's authorized functionality.

[0097] In one example, the solution may also be used to allow an individual to assure themselves that they are in the vehicle and should reach a specific destination. Furthermore, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other vehicle occupants are authorized to interact with the vehicle. Pickup, drop-off, and location are also mentioned. All of the above are immutably stored on the blockchain. In one example, the solution may also be used to determine driver characteristics through analysis of driving style and other factors to take action if the driver is not driving as they normally would, such as if the driver has previously driven in certain conditions, such as during the day, at night, in rain, or in snow. Furthermore, vehicle attributes may also be taken into account. Attributes include weather, whether headlights are on, whether navigation is in use, whether a HUD is in use, whether media is playing at a certain volume, etc. In one example, the solution may also be used to notify vehicle occupants of dangerous situations when items in the vehicle indicate that the occupants may not be aware of the dangerous situation.

[0098] In one example, the solution may also be utilized to attach a calibration device to equipment fixed to the vehicle, and various sensors on the vehicle may automatically self-calibrate based on what should be detected by the calibration device compared to what is actually detected. In one example, the solution may also be utilized to enable remote diagnostic capabilities, requiring consensus from multiple service centers using blockchain when a vehicle requiring service transmits malfunction information, and consensus is required from other service centers regarding what the severity threshold is for the data. Once consensus is received, the service center may transmit the malfunction security level to the blockchain where it is stored. In one example, the solution may also be utilized to determine discrepancies between sensor data external to the vehicle and the vehicle's own sensor data. The vehicle then requests software from a server to correct the problem. In one example, the solution may also be utilized to enable messaging of vehicles near or within an area when an event (e.g., a collision) occurs.

[0099] Referring to FIG. 21, a connected vehicle operating environment 290A is shown, according to some embodiments. As depicted, vehicle 276 includes a CAN bus 291A connecting vehicle elements 292A-299A. Other elements may be connected to the CAN bus but are not depicted herein. The 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 some embodiments, vehicle 276 includes a processor 296A, memory 297A, a communication unit 298A, and an electronic display 299A.

[0100] Processor 296A may include an arithmetic logic unit, microprocessor, general purpose controller, and / or similar processor array to perform calculations and provide electronic display signals to display unit 299A. Processor 296A processes data signals and may include a variety of computing architectures, including complex instruction set computer (CISC) architecture, reduced instruction set computer (RISC) architecture, or architectures implementing a combination of instruction sets. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not depicted) communicatively coupled to each other may be used in the present solution.

[0101] Memory 297A is non-transitory memory that stores instructions or data that can be accessed and executed by processor 296A. The 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 that permanently stores information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Vehicle 276 may include one or more memories 297A without departing from the present solution.

[0102] The memory 297A of the vehicle 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 functionality.

[0103] Navigation system 295A may represent at least one navigation route including a start point and an end point. In some embodiments, navigation system 295A of vehicle 276 receives a request from a user for a navigation route, the request including a start point and an end point. Navigation system 295A may query a real-time data server 293 (via network 292), such as a server providing driving directions, for navigation route data corresponding to the navigation route including the start point and the end point. Real-time data server 293 transmits the navigation route data to vehicle 276 via wireless network 292, and communication system 298A stores navigation data 295A in memory 297A of vehicle 276.

[0104] ECU 293A controls the operation of multiple systems of vehicle 276, including ADAS system 294A. ECU 293A may disable any unsafe and / or unselected autonomous functions during a journey controlled by ADAS system 294A in response to instructions received from navigation system 295A. In this manner, navigation system 295A may control whether ADAS system 294A is enabled or enabled so that it may be enabled on a given navigation route.

[0105] Sensor set 292A may include any sensor in vehicle 276 that generates sensor data. For example, sensor set 292A may include short-range and long-range sensors. In some embodiments, sensor set 292A of vehicle 276 may include one or more of the following vehicle sensors: a camera, a LiDAR sensor, an ultrasonic sensor, an automobile engine sensor, a radar sensor, a laser altimeter, a manifold absolute pressure sensor, an infrared detector, a motion detector, a thermostat, a sound detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, a mass airflow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timer, an air-fuel ratio meter, a blind spot meter, a curb feeler, a fault detector, a Hall effect sensor, a parking sensor, a speed gun, a speedometer, a speed sensor, a tire pressure monitoring sensor, a torque sensor, a transmission fluid temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a moisture sensor, a wheel speed sensor, a GPS sensor, a mapping function, and any other type of automotive sensor. The navigation system 295A may store the sensor data in memory 297A.

[0106] Communications unit 298A transmits and receives data to and from network 292 or another communications channel. In some embodiments, communications unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make vehicle 276 a DSRC-equipped device.

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

[0108] In one example, the solutions described and depicted herein may be utilized to manage emergency scenarios and vehicle functionality when a vehicle is determined to be entering an area without network access. In one example, the solutions may also be utilized to manage and provide functionality (such as voice, video, navigation, etc.) in a vehicle without network connectivity. In one example, the solutions may also be utilized to determine when a profile of a person in proximity to the vehicle matches profile attributes of a profile of at least one occupant within the vehicle. A notification is sent from the vehicle to establish communication.

[0109] In one example, the solution may also be utilized to analyze the availability of occupants in each vehicle where voice communication is available based on the amount of time remaining in the vehicle and the context of the communication. In one example, the solution may also be utilized to determine two threat levels for obstacles in a roadway and receive gestures that may indicate that the obstacle does not reach a threshold warning and proceed along the roadway by the vehicle. In one example, the solution may also be utilized to delete sensitive data from a vehicle when the vehicle suffers damage that renders the vehicle unusable.

[0110] In one example, the solution may also be utilized to verify that customer data to be removed is truly removed from all necessary locations within a company demonstrating GDPR compliance. In one example, the solution may also be utilized to offer compensation from one vehicle to another vehicle in exchange for safety-related data, important notifications, etc., to enhance the autonomy capabilities of lower-level autonomous vehicles. In one example, the solution may also be utilized to provide the vehicle with the ability to receive data based on a first biometric associated with the occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, the second biometric being contiguous with the first biometric. The vehicle provides the decrypted data to the occupant only when the occupant is able to receive it, deletes the sensitive portion of the decrypted data when the sensitive portion is provided, and deletes the non-sensitive portion after a period associated with the biometric has elapsed. In one example, the solution may also be utilized to provide the vehicle with the ability to verify an individual based on weight and grip pressure applied to the vehicle's steering wheel. In one example, the solution may also be utilized to provide existing but not currently enabled features to a passenger vehicle, presenting features to the vehicle's occupants that reflect their characteristics.

[0111] In one example, the solution may also be utilized to enable the reflection of modifications related to the vehicle, particularly the interior of the vehicle and the exterior of the vehicle, to assist at least one occupant in one example. In another example, the recreation of a occupant's work environment and / or home environment is disclosed. If the vehicle determines that the user is in "work mode" or "home mode," the system may attempt to "recreate" the user's work / home environment while the user is within the vehicle. All data related to the interior and exterior of the vehicle and various occupants using the vehicle is stored on a blockchain and executed via smart contracts. In one example, the solution may also be utilized to detect occupant gestures and assist in communication with nearby vehicles, so that the vehicle can be steered accordingly. In one example, the solution may also be utilized to provide the vehicle with the ability to detect intended gestures using a gesture definition data store. In one example, the solution may also be utilized to provide the vehicle with the ability to take various actions based on gait and user gestures. In one example, the solution may also be utilized to ensure that a vehicle driver currently engaged in various activities (e.g., driving while navigating and talking) does not exceed a number of risky activities before allowing a gesture.

[0112] In one example, the solution may also be utilized to assign a status to each occupant in a vehicle and validate gestures from the occupants based on the occupant's status. In one example, the solution may also be utilized to collect and provide to a system details of sounds associated with a collision (where, what direction, whether it's getting louder or quieter, from which device, data associated with the device, such as type, manufacturer, owner, and the number of sounds occurring simultaneously and the time the sounds were emitted) if analysis of the data assists in determining details about the collision. In one example, the solution may also be utilized to determine whether operation of the vehicle is unsafe. A vehicle includes multiple components that interact to control the vehicle, each associated with a separate component key. An encryption key is transmitted to the vehicle to reduce the functionality of the vehicle. In response to receiving the encryption key, the vehicle disables one or more of the component keys. Disabling one or more component keys results in one or more of restricting the vehicle from moving faster than a given speed, restricting the vehicle from moving closer than a certain distance to another vehicle, and restricting the vehicle from moving farther than a threshold distance.

[0113] In one example, the solution may also be utilized to provide an indication from one particular vehicle (trying to vacate) to another particular vehicle (trying to occupy), with blockchain being used to authenticate and reconcile. In one example, the solution may also be utilized to determine partial responsibility for a vehicle, such as when multiple people own a single vehicle and vehicle use may change over time, with the system being used to update fractional ownership. Other embodiments are included in applications including minimum vehicle ownership based on vehicle availability and vehicle driver determination, as well as other factors, rather than vehicle use.

[0114] In one example, the solution may also be utilized to allow a user to authorize their subscriptions for a closed group of people, such as family or friends, in a transportation vehicle. For example, a user may want to share membership, in which case the associated transaction is stored in a blockchain or traditional database. When subscription material is requested by a user who is not the primary subscriber, the blockchain node (i.e., the transportation vehicle) may verify that the person requesting the service is an authorized person with whom the subscriber shared their profile. In one example, the solution may also be utilized to allow a person to reach an intended destination using paratransit. Functional relationship values (e.g., values indicating various parameters and their importance in determining what type of alternative transportation to use) are used in determining the paratransit. In one example, the solution may also be utilized to allow occupants in an accident to access other transportation and continue to their original destination.

[0115] In one example, the solution may also be utilized to communicate software / firmware uploads to a first subset of vehicles. This first set of vehicles tests the update, and if the test is successful, the update is communicated to additional sets of vehicles. In one example, the solution may also be utilized to communicate software / firmware updates from a master vehicle to vehicles, where the update is communicated through a network of vehicles from the first subset, then a larger subset, and so on. A portion of the update may be sent first, and then the remaining portion may be sent from the same vehicle or another vehicle. In one example, the solution may also be utilized to provide updates for the vehicle's computer to the vehicle and the vehicle operator's / occupant's devices. The update may be approved by all drivers and / or all occupants. The software update is provided to the vehicle and device. The user does not need to do anything other than go near the vehicle; the functionality occurs automatically. A notification is sent to the device indicating the software update is complete. In one example, the solution may also be utilized to verify that an OTA software update is performed by an authorized technician and that the source of the verification code, the procedure for receiving the software update over the air, the information contained in the software update, and the status related to the results of the verification are generated by one or more vehicle components.

[0116] In one example, the solution may also be utilized to provide the ability for a second component to parse software updates located in a first component. Then, a first portion of critical updates and a second portion of non-critical updates may be identified, and the identified first portion may be assigned to a process in the vehicle, running the identified first portion in the process for a certain period of time, and, depending on a positive outcome based on the period, running the identified first portion in another process after the period of time. In one example, the solution may also be utilized to provide a selection of services to a vehicle occupant, the services based on a profile of the vehicle occupant and a shared profile shared with the occupant's profile. In one example, the solution may also be utilized to store user profile data on a blockchain and intelligently present offers and recommendations to a user based on the user's automatically collected purchase history and preferences obtained from the user profile on the blockchain.

[0117] To be sufficiently secure, a vehicle must be protected from unauthorized physical access and unauthorized remote access (e.g., cyber threats). In one example, to prevent unauthorized physical access, the vehicle is equipped with a secure access system, such as keyless entry, while in one example, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications to and from the vehicle.

[0118] Electronic control units (ECUs) are nodes within a vehicle that control tasks ranging from windshield wiper operation to anti-lock braking systems. ECUs are often connected to one another through a central network in the vehicle, which may be referred to as a CAN bus. Cutting-edge features such as autonomous driving heavily rely on new and complex ECU implementations such as advanced driver assistance systems (ADAS), sensors, and the like. While these new technologies are helping to improve vehicle safety and the driving experience, they also increase the number of external communication units within the vehicle, making them more vulnerable to attack. Below are some examples of securing vehicles from physical and remote intrusions:

[0119] FIG. 2J illustrates a keyless entry system 290B for preventing unauthorized physical access to a vehicle 291B, according to an exemplary embodiment. Referring to FIG. 2J, in one example, a key fob 292B transmits commands to the vehicle 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 wave signals. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving the short-range radio signals transmitted from the transmitter 2921B. The key fob 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, that control the respective devices, where there is memory in (or accessible to) the CPUs 2922B and 2913B. In one example, the key fob 292B and the vehicle 291B each include a power supply 2924B and 2915B that powers the respective devices.

[0120] 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 to transmitter 2921B, which outputs the data stream via the antenna. In other embodiments, the user's intent is recognized in key fob 292B through other means, such as a microphone for accepting audio, a camera for capturing images and / or video, or other sensors commonly employed in the art for detecting intent from a user, including receiving gestures, movement, eye movements, and the like. The data stream can be a signal between 64 and 128 bits in length, including one or more of a preamble, a command code, and a rolling code. The signal can be transmitted at a rate between 2 KHz and 20 KHz, although embodiments are not limited thereto. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends the data stream to CPU 2913B, which decodes the signal and sends a command (e.g., lock door, unlock door, etc.) to command module 2912B.

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

[0122] In addition to rolling codes, key fob 292B and vehicle 291B may employ other methods to make attacks even more difficult. For example, various frequencies may be used to transmit the rolling codes. As another example, two-way communication between transmitter 2921B and receiver 2911B may be used to establish a secure session. As another example, the code may have a limited expiration or timeout. Furthermore, the solution as described and depicted with respect to FIG. 2J may be utilized in this and other networks and / or systems, including those described and depicted herein.

[0123] FIG. 2K illustrates a CAN bus 290C within a vehicle according to an exemplary embodiment. Referring to FIG. 2K, CAN 290C includes a CAN bus 297C having high and low terminals and multiple 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 in applications to communicate with each other without the use of a host computer. CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard) that allows 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 vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and numerous other functions.

[0124] In this example, ECU 291C includes a transceiver 2911C and a 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 into a format for CAN bus 297C and may also convert data from CAN bus 297C into a format for microcontroller 2912C. Meanwhile, in one example, microcontroller 2912C interprets messages and determines which messages to send using ECU software installed on microcontroller 2912C.

[0125] Various security protocols can be implemented to protect CAN 290C from cyber threats. For example, subnetworks (e.g., subnetworks A and B) can be used to divide CAN 290C into smaller sub-CANs to limit an attacker's ability to remotely access the vehicle. In the example of FIG. 2K, ECUs 291C and 292C can be part of the same subnetwork, while ECU 293C is part of a separate subnetwork. Additionally, a firewall 294C (or gateway, etc.) can be added to prevent messages from crossing subnetworks and traversing CAN bus 297C. If an attacker gains access to one subnetwork, the attacker does not have access to the entire network. In one example, to further secure the subnetworks, the most critical ECUs are not placed in the same subnetwork.

[0126] Although not shown in FIG. 2K, other examples of security controls within the CAN include an intrusion detection system (IDS), which may 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 user. Other possible security protocols include encryption / security keys that may be used to obfuscate messages. As another example, an authentication protocol may be implemented that allows messages to authenticate themselves.

[0127] In addition to protecting a vehicle's internal network, the vehicle may also be protected when communicating with external networks, such as the Internet. One advantage of having a vehicle's connection to a data source, such as the Internet, is that information from the vehicle can be transmitted over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, and the like. Because these communication systems involve a combination of telecommunications and informatics, the communication systems are often referred to as telematics. Furthermore, the present solution, such as that described and depicted with respect to FIG. 2K, may be utilized with this and other networks and / or systems, including those described and depicted herein.

[0128] FIG. 2L illustrates a secure end-to-end vehicle communication channel according to an exemplary embodiment. Referring to FIG. 2L, telematics network 290D includes vehicle 291D and host server 295D located at a remote location (e.g., a web server, cloud platform, database, etc.) and connected to vehicle 291D via a network such as the Internet. In this example, device 296D associated with host server 295D may be located within vehicle 291D within the network. Additionally, although not shown, device 296D may connect to other elements of vehicle 291D, such as a CAN bus, an on-board diagnostics (ODBII) port, a GPS system, a SIM card, a modem, and the like. Device 296D may collect data from any of these systems and transmit the data to server 295D over the network.

[0129] The secure management of data begins with the vehicle 291D. In some embodiments, the device 296D may collect information before, during, and after a trip. The data may include GPS data, movement data, passenger information, diagnostic data, fuel data, speed data, and the like. However, the device 296D may simply communicate collected information back to the host server 295D upon the vehicle ignition and completion of a trip. Furthermore, communications may only be initiated by the device 296D, not by the host server 295D. Thus, in one example, the device 296D does not accept communications initiated by external sources.

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

[0131] In addition to communicating with external servers, vehicles may also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other, roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.), and the like through wireless networks. The wireless networks may include one or more of a Wi-Fi network, a cellular network, a dedicated short-range communications (DSRC) network, and the like. Vehicles may use V2V communications to provide other vehicles with information regarding the vehicle's speed, acceleration, braking, and direction, to name a few. Thus, vehicles may receive insight into conditions ahead before those conditions become visible, thus significantly reducing collisions. Furthermore, the present solution, as described and depicted with respect to FIG. 2L, may be utilized in this and other networks and / or systems, including those described and depicted herein.

[0132] FIG. 2M illustrates example 290E of vehicles 293E and 292E using security certificates to secure V2V communication, according to an exemplary embodiment. Referring to FIG. 2M, vehicles 293E and 292E may communicate via V2V communication over a short-range network, a cellular network, or the like. Prior to sending a message, vehicles 293E and 292E may sign the message using their respective public key certificates. For example, vehicle 293E may sign a V2V message using public key certificate 294E. Similarly, vehicle 292E may sign a V2V message using public key certificate 295E. In one example, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0133] Upon receiving communications from each other, the transport means may verify the signature with a certificate authority 291E or the like. For example, the transport means 292E may verify with the certificate authority 291E that the public key certificate 294E used by the transport means 293E to sign the V2V communication is authentic. If the transport means 292E successfully verifies the public key certificate 294E, the transport means knows that the data is from a legitimate source. Similarly, the transport means 293E may verify with the certificate authority 291E that the public key certificate 295E used by the transport means 292E to sign the V2V communication is authentic. Furthermore, the solution as described and depicted with respect to FIG. 2M may be utilized in this and other networks and / or systems, including those described and depicted herein.

[0134] 2N shows yet another diagram 290F depicting an example vehicle interacting with a security processor and a wireless device, according to an exemplary embodiment. In some embodiments, the computer 224 shown in FIG. 2B may include a security processor 292F as shown in example process 290F of FIG. 2N. In particular, the security processor 292F may perform authorization, authentication, cryptography (e.g., encryption), and the like, for data transmissions sent between the ECU and other devices on the vehicle's CAN bus, and for data messages sent between different vehicles.

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

[0136] For example, the authorization module 293F may store passwords, usernames, PIN codes, biometric scans, and the like for various vehicle users. The authorization module 293F may determine whether a user (or technician) has permission to access certain settings, such as the vehicle's computer. 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 a change to the vehicle's settings or modify the vehicle's technical details through a console or GUI within the vehicle or through an attached / connected device, the authorization module 293F may require the user to identify themselves in some way before the settings are changed. For example, the authorization module 293F may require a username, password, PIN code, biometric scan, a predefined line drawing or gesture, and the like. In response, the authorization module 293F may determine whether the user has the necessary permission (e.g., access) being requested.

[0137] The authentication module 294F may be used to authenticate internal communications between ECUs in a vehicle's CAN network. As an example, the authentication module 294F may provide information to authenticate communications between ECUs. As an example, the authentication module 294F may send a bit signature algorithm to the ECUs in the CAN network. The ECUs may use the bit signature algorithm to insert authentication bits into the CAN field of a 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 (safe list) and do not need to use authentication bits. The authentication module 294F may communicate with a remote server to retrieve updates to the bit signature algorithm and the like.

[0138] The encryption module 295F may store asymmetric key pairs used by the vehicle to communicate with other external user devices and vehicles. For example, the encryption module 295F may provide a private key used by the vehicle to encrypt / decrypt communications, while a corresponding public key may be provided to other user devices and vehicles to enable them to decrypt / encrypt communications. The encryption module 295F may communicate with a remote server to receive new keys, updates to keys, new vehicle or user keys, and the like. The encryption module 295F may also send any updates to the local private / public key pair to the remote server.

[0139] 3A illustrates a flow diagram 300 according to an example embodiment. Referring to FIG. 3A, the flow diagram includes one or more of determining 302 that there is a problem with resource delivery to an electricity provider, determining 304 an electrical impact based on the problem, determining 306 an area affected by the electrical impact, and dispatching 308 vehicles to provide electricity to locations within the area.

[0140] 3B illustrates another flow diagram 320 according to an exemplary embodiment. Referring to FIG. 3B, the flow diagram includes receiving notification from a resource provider about limited resource supply, comparing the level of the resource to a threshold, and notifying an electricity provider 322 in response to the current level of the resource being less than the threshold; determining that there will be a problem with resource delivery in a future time period, determining the demand for electricity during the time period, and determining the discrepancy between the resource problem and the demand for electricity 323; requesting a district served by the electricity provider and designating a portion of the district as an affected area based on electricity lost in the portion of the district 324; determining vehicles proximate to the area, and designating a subset of vehicles with available electricity. determining a target location for the area, notifying a subset of vehicles to proceed to locations within the area, and providing available electricity to the locations 325; obtaining available electricity and vehicle availability from vehicles proximate to the area, selecting vehicles having available electricity above a first threshold and vehicle availability above a second threshold, and dispatching the selected vehicles to provide electricity to the locations within the area 326; and determining an available electricity level for each of the dispatched vehicles, matching the amount of electricity required at the locations within the area with the available electricity level from the subset of dispatched vehicles, and dispatching the subset to the locations 327.

[0141] 3C illustrates yet another flow diagram 340 according to an example embodiment. Referring to FIG. 3C, the flow diagram includes one or more of receiving a confirmation of an event from one or more elements described or depicted herein, where the confirmation comprises a blockchain consensus between peers represented by any of the elements 342, and executing a smart contract to record the confirmation in the blockchain based on the blockchain consensus 344.

[0142] 4 illustrates a machine learning vehicle network diagram 400 according to an example embodiment. Network 400 includes a vehicle 402 coupled with a machine learning subsystem 406. The vehicle includes one or more sensors 404.

[0143] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact produced by a machine learning training system 410 that generates predictions by finding patterns in one or more training datasets. In some embodiments, the machine learning subsystem 406 resides within the vehicle 402. In other embodiments, the machine learning subsystem 406 resides external to the vehicle 402.

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

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

[0146] FIG. 5A illustrates an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an exemplary embodiment. Referring to FIG. 5A , when a particular vehicle / vehicle 525 is involved in a transaction (e.g., vehicle service, dealership transaction, delivery / pickup, transportation service, etc.), the vehicle may receive (510) assets and / or issue / transfer (512) assets according to the transaction. A vehicle processor 526 resides within the vehicle 525, and communication exists between the vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Transaction module 520 may record information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, unexpected events, etc. The transactions in transaction module 520 may be replicated in database 530. The database 530 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle, off-board the vehicle, accessed directly and / or through a network, or accessible to the vehicle.

[0147] FIG. 5B illustrates an exemplary vehicle configuration 550 that manages database transactions between various vehicles, according to an exemplary embodiment. When a vehicle reaches a situation where services need to be shared with another vehicle, the vehicle 525 may engage with another vehicle 508 to perform various operations, such as sharing, transmitting, or obtaining a service request. For example, the vehicle 508 may be due for battery charging and / or may have a tire problem and may be on route to pick up a delivery package. A vehicle processor 528 resides within the vehicle 508, and communication exists between the vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 may notify another vehicle 525 within its network and operating on its blockchain member services. A vehicle processor 526 resides within the vehicle 525, and communication exists between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The vehicle 525 may then receive information via a wireless communication request to pick up the package from the vehicle 508 and / or from a server (not shown). The transaction is logged in transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525, and a record of the transferred service is logged in database 530 / 554, assuming the blockchains are different from each other, or logged in the same blockchain used by all members. Database 554 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, may be onboard the vehicle, may be offboard the vehicle, and may be accessible directly and / or through a network.

[0148] FIG. 6A illustrates a blockchain architecture configuration 600 according to an example embodiment. Referring to FIG. 6A, the blockchain architecture 600 may include a group of blockchain member nodes 602-606 as part of a particular blockchain element, e.g., a blockchain group 610. In an example embodiment, a permissioned blockchain is accessible only to members who have permission to access the blockchain data, rather than all parties. Blockchain nodes participate in numerous activities, such as the addition and validation process (consensus) of blockchain entries. One or more of the blockchain nodes may approve entries based on an endorsement policy and provide an ordering service for all blockchain nodes. Blockchain nodes may initiate blockchain operations (e.g., authentication) and attempt to write to the blockchain immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0149] 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. Approved transactions 626 are stored in the blockchain's current block and committed to the blockchain via a commit procedure, which involves hashing the data content of the transaction in the current block and referencing a previous hash in the previous block. Within the blockchain, one or more smart contracts 630 may exist that define the terms of transaction agreement and operation, such as registered recipients, vehicle capabilities, requirements, permissions, and sensor thresholds, contained within smart contract executable application code 632. The code may be configured to identify whether a requesting entity is registered for vehicle service, which service features the entity is eligible / required to receive given the entity's profile status, and whether to monitor the entity's behavior at a later time. For example, when a service event occurs and a user is in the vehicle, monitoring of sensor data may be triggered, and a certain parameter, such as the vehicle's charge level, may be identified as being above / below a certain threshold for a certain period of time, which may then result in a change in the current status, necessitating the sending of an alert to a controlling party (i.e., the vehicle owner, the vehicle operator, a server, etc.), so that a service can be identified and stored for reference. The vehicle sensor data collected may be based on the type of sensor data used to collect information about the vehicle's status. The sensor data may also be the basis for vehicle event data 634, such as where traveled, average speed, maximum speed, acceleration, whether there have been any collisions, whether the expected route has been taken, where the next destination is, whether safety measures have been implemented, whether the vehicle has sufficient charge / fuel, etc. All such information may be the basis for smart contract terms 630, which are then stored on the blockchain.For example, sensor thresholds stored in a smart contract can be used as the basis for whether a service needs to be detected and when and where the service should be performed.

[0150] FIG. 6B illustrates a shared ledger configuration, according to an example embodiment. Referring to FIG. 6B, example blockchain logic 640 includes a blockchain application interface 642 as an API or plug-in application that couples to a computing device and execution platform for a particular transaction. The blockchain configuration 640 may include one or more applications coupled to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which may be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information. This may be deployed and installed as an entry by appending it to the distributed ledger on all blockchain nodes.

[0151] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, when executed, enables transaction conditions and states. Smart contracts 630, when executed, result in the creation of specific approved transactions 626, which are then forwarded to a blockchain platform 652. The platform includes security / authorization 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.

[0152] A blockchain platform may include various layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), as well as an underlying physical computer 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 the virtual execution environments necessary to process program code and interact with the physical infrastructure. Cryptographic trust services may be used to verify entries, such as asset exchange entries, and keep information private.

[0153] The blockchain architecture configurations of Figures 6A and 6B may process and execute program / application code through one or more interfaces exposed and services provided by the blockchain platform. As a non-limiting example, smart contracts may be created to implement reminders, updates, and / or other notifications of changes, updates, etc. The smart contract itself may be used to identify authorization and access requirements and rules associated with use of the ledger. For example, information may include new entries that may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. 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 utilized to retrieve any of the data or information described herein.

[0154] Within smart contract executable code, smart contracts may be authored via high-level application and programming languages and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a decentralized network of blockchain peers). Entry is the execution of smart contract code, which may occur in response to conditions associated with the smart contract being met. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from smart contract execution may be automatically replicated throughout the decentralized network of blockchain peers via one or more consensus protocols.

[0155] A smart contract may write data to the blockchain in the format of key-value pairs. Additionally, smart contract code may read values stored in the blockchain and use those values during application operation. Smart contract code may write the output of various logical operations into the blockchain. The code may be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain may be public and / or encrypted and kept private. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and then deleted once the data needed by the blockchain is identified.

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

[0157] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. Referring to FIG. 6C, the exemplary configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., a blockchain) 668. In the event that a known, established user profile attempts to rent a vehicle with an established rating profile, the server may represent a service provider entity that queries a vehicle service provider to share user profile rating information. The server 666 may receive and process data related to the vehicle's service requirements. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charge or maintenance service, a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., that may be used to invoke a vehicle service event. Blockchain transaction data 670 is stored for each transaction, such as an access event, subsequent updates to the vehicle's service status, and event updates. The transaction may include the parties, requirements (e.g., age 18, eligible candidate for service, valid driver's license, etc.), coverage level, distance traveled during the event, registered recipients authorized to access the event and provide vehicle service, rights / permissions, sensor data retrieved during vehicle event operation to log details of the upcoming service event and identify vehicle condition status, and thresholds used to make decisions regarding whether the service event is completed and whether the vehicle condition status has changed.

[0158] FIG. 6D illustrates a blockchain block 680 and the contents of block structures 682A-682n that may be added to a distributed ledger, according to an example embodiment. Referring to FIG. 6D , a client (not shown) may submit entries to a blockchain node to perform activities on the blockchain. As an example, a client may be an application that acts on behalf of a requester, such as a device, person, or entity, to propose entries to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) may maintain copies of the blockchain network state and the distributed ledger. Various types of blockchain nodes / peers may exist in a blockchain network, including endorsing peers that simulate and approve entries proposed by clients, and committing peers that confirm the endorsements, validate the entries, and commit the entries to the distributed ledger. In this example, a blockchain node may act as an endorser node, a committer node, or both.

[0159] The 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 per channel, with each peer maintaining its own copy of the distributed ledger for each channel in which it is a member. The blockchain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries. Blocks may contain various components, such as those shown in Figure 6D. Block combinations may be generated by appending a hash of the previous block's header to the current block's block header. In this way, all entries in the blockchain are ordered and cryptographically linked, preventing tampering with blockchain data without breaking the hash link. Furthermore, because they are linked, the latest block in the blockchain represents all entries that occurred before it. The blockchain may be stored on a peer file system (local or attached storage) to support append-only blockchain workloads.

[0160] The current state of the blockchain and distributed ledger may be stored in a state database, where the current state data represents the most recent values for all keys to date contained in the blockchain's on-chain entry log. Invocations of smart contract executable code execute entries against the current state in the state database. To make interactions with the smart contract executable code highly efficient, the most recent values for all keys are stored in the state database. The state database may contain an indexed view into the blockchain's entry log, so it can be regenerated off-chain at any time. The state database may be automatically restored (or generated if necessary) at peer startup before entries are accepted.

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

[0162] The ordering service accepts approved entries, orders the entries into blocks, and distributes the blocks to committing peers. For example, the ordering service may initiate a new block when a threshold number of entries is reached, a timer times out, or another condition. In this example, a blockchain node is a committing peer that receives data block 682A for storage on the blockchain. The ordering service may consist of a cluster of orderers. The ordering service does not process entries or smart contracts, nor does it maintain a shared ledger. Rather, the ordering service may accept approved entries and specify the order in which the entries are committed to the distributed ledger. The architecture of a blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0163] 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 through solving cryptographic puzzles or through mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that best suits their network.

[0164] Referring to FIG. 6D , block 682A (also referred to as a data block) stored on a blockchain and / or distributed ledger may include multiple data segments, such as block headers 684A-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 meant to limit the scope of the illustrative embodiments. In some cases, both block header 684A and block metadata 688A may be smaller than transaction-specific data 686A, which stores entry data, although this is not a requirement. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) in block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on the blockchain) in block header 684A. In particular, the block header 684A may include a hash of the previous block's header. The block header 684A may also include a unique block number, a hash of the block data 690A of the current block 682A, and the like. The block numbers of the blocks 682A may be unique and assigned in increasing / consecutive order starting from zero. The first block in a blockchain may be referred to as the genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

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

[0166] In some embodiments, block data 690A may also store transaction-specific data 686A that adds further information to the block's hash-linked chain in the blockchain. Thus, data 686A may be stored in an immutable log of blocks in the distributed ledger. Some of the advantages of storing such data 686A are reflected in various embodiments disclosed and depicted herein. Block metadata 688A may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the creation of the block, 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 ordered the block, and the like. The signature, last constituent block, and orderer metadata may be added by the ordering service. Alternatively, the block's committer (e.g., a blockchain node) may add valid / invalid information based on endorsement policies, validation of the read / write set, and the like. The entry filter may include a byte array of a size equal to the number of entries in the block data 610A and a verification code that identifies whether the entry was valid / invalid.

[0167] The other blocks 682B-682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the headers 684A-684n in the other blocks includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be a hash of the previous block's header, or it may be a hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, tracking may be performed block by block, from the Nth block back to the genesis block (and associated original files), as shown by arrow 692, establishing an auditable and immutable chain of custody.

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

[0169] A suitable storage medium may be coupled to the processor such 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 the storage medium may reside in an application-specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may reside as discrete components. For example, FIG. 7 shows an exemplary computer system architecture 700 that may represent or be integrated with any of the components described above.

[0170] 7 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein, although the computational node 700 may nonetheless implement and / or perform any of the functions described herein.

[0171] Within computing node 700 is computer system / server 702, which is capable of operating in many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, 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 that include any of the above systems or devices, and the like.

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

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

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

[0175] Computer system / server 702 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system / server 702, including both volatile and nonvolatile media, removable and non-removable media. In one example, system memory 706 implements the flow diagrams of other figures. System memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, memory 706 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive that reads from and writes to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive that reads from or writes to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, 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 depicted and described below, memory 706 may include at least one program product having a set (e.g., at least one) program module configured to perform the functions of various embodiments of the present application.

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

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

[0178] 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 a keyboard, a pointing device, a display, a voice recognition module, etc., one or more devices that allow a user to interact with the computer system / server 702, and / or any device (e.g., a network card, a modem, etc.) that allows the computer system / server 702 to communicate with one or more other computing devices. Such communication may occur through I / O interfaces of the devices 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, the devices 712 communicate with the 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 in connection with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.

[0179] At least one preferred embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description; however, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the functions of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, including pairs of transmitters, receivers, or both. 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 and in conjunction with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or multiple protocols. Furthermore, messages sent or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0180] Those skilled in the art will appreciate that the "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a smartphone, or any other suitable computing device or combination of devices. Presenting the above-described functions as being performed by the "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in both local and distributed fashions consistent with computing technology.

[0181] It should be noted that some of the system functionality described herein has been presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

[0182] Modules may also be implemented at least partially in software 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, for example, as an object, procedure, or function. Nevertheless, the executable files of an identified module need not be physically located together, but may comprise different instructions stored in different locations that, when logically combined, comprise the module and achieve the 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, a random access memory (RAM), a tape, or any other such medium used to store data.

[0183] Indeed, a module of executable code may be a single instruction or many instructions, and may even be distributed in several different code segments, among different programs, and across several memory devices. Similarly, computational data may be identified and depicted herein in modules, and may be embodied in any suitable form and organized within any suitable type of data structure. Computational data may be collected as a single data set or distributed among different locations, including different storage devices, and may exist at least in part as simple electronic signals over a system or network.

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

[0185] Those skilled in the art will readily appreciate that the foregoing may be performed in a different order of steps and / or with hardware elements in different configurations than those disclosed. Thus, while the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0186] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are exemplary only, and that the scope of the present application should be determined solely by the appended claims when considered in light of the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.) to which the claims apply.

Claims

1. A method performed by a processor, To analyze the impact on the electrical grid caused by problems associated with resource delivery, Identifying the area affected by the aforementioned influence, To dispatch vehicles to provide electricity to locations within the aforementioned area, Controlling the vehicle at the aforementioned location to perform vehicle-to-grid (V2G) energy transmission to the electric grid, During the aforementioned transmission, the charging status of each dispatched vehicle is monitored in real time, Dynamically adjusting the amount of energy transmitted from each vehicle based on grid demand, vehicle constraints, and energy reserve thresholds, To ensure that each vehicle maintains the minimum charge level necessary for one or more of the following: to return to its base or to perform subsequent tasks, Methods that include...

2. Identifying the problems associated with the delivery of the aforementioned resources is, To receive notification from resource providers regarding limited resource availability, Comparing the current level of the aforementioned resource with a threshold, In accordance with the current level of the resource being below the threshold, the electricity provider shall be notified, The method according to claim 1, including the method described in claim 1.

3. Analyzing the aforementioned effects is, To predict that the aforementioned problem associated with resource delivery will exist during a certain period, To estimate the demand for electricity during the aforementioned period, To calculate the difference between the problem associated with the resource and the demand for electricity, The method according to claim 1, including the method described in claim 1.

4. Identifying the area means, To acquire the area where the aforementioned electricity provider provides services, The aforementioned area is designated as a part of the district based on the electricity lost in that part of the district, The method according to claim 1, including the method described in claim 1.

5. The dispatch of the vehicles for providing electricity is Identifying vehicles approaching the aforementioned area, Selecting a subset of the aforementioned vehicles that have V2G functionality and sufficient storage capacity, Sending instructions to the subset of vehicles to proceed to the location within the area, To provide electricity to locations within the area, coordinate V2G energy transmission between the subset of vehicles and the grid infrastructure of the area, The method according to claim 1, including the method described in claim 1.

6. Selecting a vehicle having an available amount of electricity above a first threshold and a vehicle availability above a second threshold, To provide electricity to a location within the aforementioned area, the selected vehicle is dispatched. The method according to claim 1, including the method described in claim 1.

7. It is a system, The system includes a processor, and when the processor executes an instruction stored in memory, We analyze the impact on the electrical grid caused by resource delivery problems. Identify the area affected by the aforementioned influence, Vehicles are dispatched to provide electricity to locations within the aforementioned area. At the aforementioned location, the vehicle is controlled to perform vehicle-to-grid (V2G) energy transmission to the electric grid. During the aforementioned transmission, the charging status of each dispatched vehicle is monitored in real time. Based on grid demand, vehicle constraints, and energy reserve thresholds, the amount of energy transmitted from each vehicle is dynamically adjusted. Each vehicle is configured to ensure that it maintains the minimum charge level necessary for one or more of the following: returning to its base or performing a subsequent task. system.

8. When the processor identifies the problem associated with the delivery of the resource, We received notification from the resource provider about limited resource availability. Compare the current level of the aforementioned resource with a threshold, The system according to claim 7, further configured to notify the electricity provider in accordance with whether the current level of the resource is below the threshold.

9. When the processor analyzes the effects, We anticipate that the aforementioned problems related to resource delivery will exist in the coming period. The demand for electricity during the aforementioned period is estimated, The system according to claim 7, further configured to calculate the difference between the problem associated with the resource and the demand for electricity.

10. When the processor identifies the area, Acquire the area where the electricity provider provides services, The system according to claim 7, further configured to designate a part of the district as the area based on the electricity lost in that part of the district.

11. When the processor dispatches the vehicle to provide electricity, Identify vehicles approaching the aforementioned area, Select a subset of the vehicles having V2G functionality and sufficient storage capacity. Instructions are sent to the subset of vehicles to proceed to the location within the area. The system according to claim 7, further configured to coordinate V2G energy transmission between the subset of vehicles and the grid infrastructure of the area in order to provide electricity to locations within the area.

12. The processor is Select a vehicle having an available amount of electricity above a first threshold and a vehicle availability above a second threshold. The system according to claim 7, configured to dispatch the selected vehicles in order to provide electricity to locations within the area.

13. A computer-readable storage medium comprising instructions, wherein, when the instructions are executed by a processor, the instructions provide to the processor: To analyze the impact on the electrical grid caused by problems associated with resource delivery, Identifying the area affected by the aforementioned influence, To dispatch vehicles to provide electricity to locations within the aforementioned area, Controlling the vehicle at the aforementioned location to perform vehicle-to-grid (V2G) energy transmission to the electric grid, During the aforementioned transmission, the charging status of each dispatched vehicle is monitored in real time, Dynamically adjusting the amount of energy transmitted from each vehicle based on grid demand, vehicle constraints, and energy reserve thresholds, To ensure that each vehicle maintains the minimum charge level necessary for one or more of the following: to return to its base or to perform subsequent tasks, A computer-readable storage medium that enables the following process.

14. Identifying the problem associated with resource delivery means that the instruction to the processor To receive notification from resource providers regarding limited resource availability, Comparing the current level of the aforementioned resource with a threshold, In accordance with the current level of the resource being below the threshold, the electricity provider shall be notified, A computer-readable storage medium according to claim 13, which includes causing the following to occur.

15. Analyzing the aforementioned effects indicates that the instruction affects the processor, It is anticipated that the aforementioned problems related to resource delivery will exist in the coming period, To estimate the demand for electricity during the aforementioned period, To calculate the difference between the problem associated with the resource and the demand for electricity, A computer-readable storage medium according to claim 13, which includes causing the following to occur.

16. Identifying the area means that the instruction to the processor To acquire the area where the aforementioned electricity provider provides services, The aforementioned area is designated as a part of the district based on the electricity lost in that part of the district, A computer-readable storage medium according to claim 13, which includes causing the following to occur.

17. Dispatching the vehicle to provide electricity means that the instruction to the processor Identifying vehicles approaching the aforementioned area, Selecting a subset of the aforementioned vehicles that have V2G functionality and sufficient storage capacity, Sending instructions to the subset of vehicles to proceed to the location within the area, To provide electricity to the said location within the said area, to coordinate V2G energy transmission between the said subset of vehicles and the grid infrastructure of the said area, A computer-readable storage medium according to claim 13, which includes causing the following to occur.

18. To analyze the impact on the electrical grid caused by problems associated with resource delivery, Identifying the area affected by the aforementioned influence, To dispatch vehicles to provide electricity to locations within the aforementioned area, Controlling the vehicle at the aforementioned location to perform vehicle-to-grid (V2G) energy transmission to the electric grid, During the aforementioned transmission, the charging status of each dispatched vehicle is monitored in real time, Dynamically adjusting the amount of energy transmitted from each vehicle based on grid demand, vehicle constraints, and energy reserve thresholds, To ensure that each vehicle maintains the minimum charge level necessary for one or more of the following: to return to its base or to perform subsequent tasks, A computer program that instructs the processor to perform a specific action.

Images