Event Energy Containment and Management

Abstract

Exemplary operations include one or more of determining locations within an area that may lose electricity during a grid-related event, conserving energy through curtailment of energy consumption at the locations, storing the retained energy in an energy storage device at the locations, and using the retained energy at the locations when an event occurs.

Description

[Background technology]

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

[0002] One example embodiment provides a method that includes one or more of determining locations within an area that may lose electricity during a grid-related event, conserving energy through curtailment of energy consumption at the locations, storing the retained energy in an energy storage device at the locations, and using the retained energy at the locations when the event occurs.

[0003] Another example embodiment provides a system including a memory communicatively connected to a processor, the processor performing one or more of determining locations within an area that may lose electricity during a grid-related event, conserving energy through curtailment of energy consumption at the locations, storing the retained energy in an energy storage device at the locations, and using the retained energy at the locations when the event occurs.

[0004] A further exemplary embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to do one or more of: determine locations within an area that may lose electricity during a grid-related event; conserve energy through curtailment of energy consumption at the locations; store the conserved energy in an energy storage device at the locations; and use the conserved energy at the locations when an event occurs. [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 illustrates an exemplary diagram of energy containment and management of a vehicle event according to an exemplary embodiment. [Figure 2A] FIG. 1 illustrates a transportation network diagram according to an exemplary embodiment. [Figure 2B] FIG. 1 illustrates another transportation network diagram according to an exemplary embodiment. [Figure 2C] FIG. 13 illustrates yet another transportation network diagram according to an exemplary embodiment. [Figure 2D] FIG. 13 illustrates a further transportation network diagram according to an exemplary embodiment. [Figure 2E] FIG. 13 illustrates yet 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. 2 illustrates a diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 2H] FIG. 13 illustrates a further diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 2I] FIG. 13 illustrates yet an additional view depicting interconnections between elements in accordance with an exemplary embodiment. [Figure 2J] FIG. 2 illustrates yet an additional view depicting a keyless entry system according to an exemplary embodiment. [Figure 2K] FIG. 13 illustrates yet an additional view depicting a CAN within a vehicle in accordance with an exemplary embodiment. [Figure 2L] FIG. 13 illustrates yet another diagram depicting an end-to-end communication channel according to an exemplary embodiment. [Figure 2M] FIG. 13 illustrates yet an additional diagram depicting an example vehicle using security certificates for secure V2V communications according to an exemplary embodiment. [Figure 2N]FIG. 13 shows yet an additional diagram depicting an example of a vehicle interacting with a security processor and a wireless device according to an exemplary embodiment. [Figure 3A] FIG. 1 illustrates a flow diagram according to an exemplary embodiment. [Figure 3B] FIG. 13 illustrates another flow diagram according to an exemplary embodiment. [Figure 3C] FIG. 13 illustrates yet another flow diagram according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a machine learning vehicle network diagram in accordance with an illustrative embodiment. [Figure 5A] FIG. 2 illustrates an example vehicle configuration for managing database transactions associated with a vehicle according to an example embodiment. [Figure 5B] FIG. 1 illustrates another exemplary vehicle configuration for managing database transactions conducted between various vehicles, according to an exemplary embodiment. [Figure 6A] FIG. 1 illustrates a block chain 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 example system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] It will be readily understood that the components generally described herein and illustrated in the figures can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, an apparatus, a computer-readable storage medium, and a 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, other vehicles, and a local computing device (e.g., a smart phone, 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 one or more of the components outside or remote from the vehicle.

[0008] The features, structures, or characteristics as described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, use of the phrases "exemplary embodiment," "some embodiments," or other similar terms throughout this specification refers to the fact 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 all 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 allow for one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. In this solution, the transportation means may include one or more of a car, a truck, a pedestrian area battery electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that may be used to transport people and / or goods from one place to another.

[0009] In addition, 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 the preferred embodiments, they are not limited to the particular types of messages and signaling.

[0010] Exemplary embodiments provide methods, systems, components, non-transitory computer readable media, devices, and / or networks that provide at least one of a vehicle (also referred to herein as a vehicle or passenger car), 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, may be processed to identify vehicle / vehicle status conditions and provide feedback regarding vehicle status and / or changes. In one example, a user profile may be applied to a particular vehicle / vehicle to authorize current vehicle events at a service station, service outages, 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 that communicate 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 can maintain records 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 a consensus among the distributed peers. For example, peers may run a consensus protocol to validate blockchain storage entries, organize the storage entries into blocks, and build a hash chain over 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 having a 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 may ensure interactions between groups of entities that share a common goal but do not or cannot fully trust one another, such as entities exchanging funds, goods, information, and the like. The solution may function in permissioned and / or permissionless blockchain settings.

[0012] A smart contract is a trusted decentralized application that leverages 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 "endorsed" 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 an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified in the endorsement policy, the policy is executed to validate the entry. After validation, the entry enters an ordering phase, in which a consensus protocol is used to generate an ordered sequence of endorsed entries organized into blocks.

[0013] A node is a communicating entity of 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 organized in a trust domain and associated with a logical entity that controls the node in various ways. Nodes may include different types such as client or submitting client nodes that 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 and commit the entries to maintain the state and copy of the ledger of blockchain entries. A peer may also have the role of an endorser. An ordering service node or orderer is a node that performs a communication service for all nodes and implements delivery guarantees such as broadcasts to each of the peer nodes in the system when committing an entry to modify the blockchain's world state. The world state may constitute the initial blockchain entry, which typically includes control and configuration information.

[0014] A ledger is an ordered, tamper-resistant record of all state transitions of a blockchain. A state transition may result from an invocation (i.e., an entry) of a smart contract executable code submitted by a participating party (e.g., a client node, an ordering node, an endorser node, a peer node, etc.). An entry may result in a set of key-value pairs of assets that are 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 is used to store immutably ordered records in blocks. A ledger also includes a state database that maintains the current state of the blockchain. There is usually 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 can be ordered and cryptographically bound together. Thus, 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, which ensures that all peer nodes are in a consistent and trusted state. Chains can be stored in the peer node filesystem (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 latest values ​​for all keys contained in the chain's entry log. The current state is sometimes referred to as the world state, since it represents the most recent key values ​​known on the channel. Invocations of smart contract executable code execute entries against the ledger's current state data. To make interactions with the smart contract executable code efficient, the latest 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) at peer node startup and before entries are accepted.

[0017] Blockchain differs from traditional databases in that it is not a centralized storage, but a distributed, immutable, secure storage, and nodes must share changes to records in the storage. Some properties that are inherent in blockchain and aid in its implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

[0018] Exemplary embodiments provide services for a particular vehicle and / or a user profile that is 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 certain intervals and requests for service may require approval before being allowed to receive service. The service center may also provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirement (e.g., emergency, critical, moderate, minor, etc.). The vehicle's 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. The sensors may be located on one or more of the interior of the vehicle, the exterior of the vehicle, on fixed objects remote from the vehicle, and on another vehicle close to the vehicle. The 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 proximate 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 utilization. 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 generated 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 the 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 the user profile score / rating / review, apply vehicle event permissions, determine when service is needed, identify collision events and / or degradation events, identify events that are safety concerns, identify the parties to the event, and distribute to registered entities seeking to access the vehicle event data. Also, results can be identified and the necessary information can be shared among registered companies and / or individuals based on a consensus methodology associated with the blockchain. Such a methodology could not be implemented with a traditional centralized database.

[0020] To create maps of terrain and roads that the vehicle can use for navigation and other purposes, various driving systems of the 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 the autonomous vehicle.

[0021] In certain embodiments, the solution includes authorizing a vehicle for service via an automated and rapid authentication scheme. For example, driving to a charging station or fuel pump can be done 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 that provides an identification of the vehicle, with a currently active profile linked to an account authorized to receive service that can later be modified by 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 operation between the vehicle and the service center with an additional authorization operation.

[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 usually accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, and are especially for security purposes because they are in a single location. In a centralized database, all data is in a single storage location, which also means that a given data set has only one primary record, so data redundancy is minimized. Blockchain may 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) that may be located on-board or off-board the vehicle. The one or more processors may communicate with other processors on-board or off-board in other vehicles to utilize data being transmitted by 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] 1 illustrates an example diagram of vehicle event energy containment and management according to an example embodiment. System 100 may include one or more servers 110, one or more location processors 120, and one or more vehicle processors 130. As discussed herein, system 100 of the present application may incorporate other computing devices.

[0025] Server 110 may be one or more computing devices communicatively connected to one or more location processors 120 and one or more vehicle processors 130. Server 110 may represent a single computing device or multiple computing devices in multiple locations and / or a cloud. Server 110 may communicate with other servers to obtain weather reports and forecasts, road conditions, traffic conditions, and location / information for homes, businesses, and vehicles. In one embodiment, the information may relate to current stored charge levels, charge percentages, maximum capacity of stored charge, and the like.

[0026] Location processors 120 include computing devices associated with a fixed location, e.g., a home or business location. Location processors 120 may include any number of processors and associated memory devices that store software applications, data, and metadata. Each location processor 120 may monitor and control electrical charging and charge transfer to energy storage devices associated with the fixed location (i.e., providing charge to other devices, e.g., appliances, heating units, air conditioning units, and / or lights).

[0027] The vehicle processor 130 may include a main processor of the vehicle, such as an electronic control module (ECM), and may be communicatively connected to one or more other processors of the vehicle, including one or more processors associated with performing the methods of the present application. The vehicle processor 130 may also be communicatively connected to other vehicle processors, servers (including server 110), location processor 120, and the like. In one embodiment, the vehicle processor 130 may send and receive messages to and from the location processor 120, the server 110, another vehicle, and / or a passenger device associated with a passenger of the vehicle through a wireless communication interface. In another embodiment, the vehicle processor 130 may send and receive messages to and from another vehicle and / or other processors through a wired communication interface (e.g., through a wired communication interface associated with a charging station connected to the vehicle, a wired charging interface such as a Universal Serial Bus (USB) connection to a passenger device, and the like). The vehicle processor 130 may have one or more associated memory devices for storing applications and data, and may be interconnected by various wired or wireless communication paths, such as a Controller Area Network (CAN) bus or various wireless technologies known in the art.

[0028] A vehicle may also be associated with one or more passenger devices, which may be computing devices associated with a vehicle occupant. A passenger device may include a smartphone, tablet, smart watch, wearable computer, portable computer, or any other type of computing device. In one embodiment, the vehicle processor 130 may access a list of passenger devices associated with the vehicle and may search the list of passenger devices to determine a particular passenger device that is within or in proximity to the vehicle.

[0029] In one embodiment, the vehicle may be associated with a fixed location. For example, the vehicle may be owned by an individual who lives at home at the fixed location. The vehicle processor 130 may transmit the current vehicle energy level 112 to the location processor 120 associated with the fixed location. In one embodiment, the current vehicle energy level 112 may be transmitted at regular intervals (e.g., hourly), when the vehicle is within a distance threshold (e.g., within 20 miles) of the fixed location, or upon a request (not shown) by the location processor 120 of the current vehicle energy level. The current vehicle energy level 112 may have a value between an uncharged or minimum energy level and a fully charged level. The location processor 120 may receive multiple current vehicle energy levels 112 from multiple vehicles associated with the fixed location, and each of the received current vehicle energy levels 112 may be different.

[0030] In one embodiment, the server 110 may determine an event related to energy or the power grid. The power grid distributes electrical energy to locations that need and use the energy. In one embodiment, the event may relate to planned maintenance of the power grid and may indicate a period of time when there is limited or no electrical energy available from the power grid. For example, a processor associated with the electric utility may provide a notification, e.g., an email notification to the server 110 regarding the expected start time, expected end time, and expected duration of the event. In another embodiment, the event may relate to a brownout or blackout of the power grid and may indicate a period of time when there is limited or no electrical energy or when the quality of electrical energy available from the power grid is lower. In another embodiment, the event may indicate the possibility or likelihood of losing power in the near future, but may not specify a start time and / or duration of losing power, such as in the case of extremely cold or hot temperatures.

[0031] In one embodiment, the event may be limited to a location, a neighborhood, a town / city / village, or an undefined area. In one embodiment, the server 110 may have a data structure stored in an accessible memory device that includes identification information of fixed locations associated with the server 110. The data structure may include an address, email address, neighborhood identification, zip code, GPS coordinates, and / or city identification information for all fixed locations associated with the server 110. For example, the server 110 may determine 116 fixed locations affected by the event (e.g., the server 110 receives notification from an electric utility server or processor that all fixed locations on a given street are affected by the event). In response to determining 116 that the location may lose power, the server 110 may send an event description 118 to the location processor 120 (or multiple location processors 120) as determined from the data structure.

[0032] The location processor 120 may be connected to an energy storage device at a fixed location. The location processor 120 may periodically (e.g., every 10 minutes) monitor the charge level of the energy storage device. In one embodiment, the energy storage device may send a notification to the location processor 120 if the charge level falls below a threshold level of charge stored in a memory device accessible to the location processor 120. The location processor 120 may also access a memory device connected to the location processor 120 to obtain a stored value of a maximum charge capacity for the energy storage device. In one embodiment, the location processor 120 may determine the amount of charge needed by the energy storage device by subtracting the current charge level of the energy storage device from the maximum charge capacity of the energy storage device.

[0033] In one embodiment, the location processor 120 may throttle 124 energy consumption at the fixed location in response to the event description 118 and the energy storage device charge level being less than the energy storage device charge threshold level 122. The throttle 124 energy consumption refers to reducing or preventing energy consumption at the fixed location for a period of time. For example, the throttle 124 energy consumption may include disabling lights in rooms of unoccupied buildings, turning off appliances, and turning off heating, air conditioning, or other climate control devices associated with the fixed location. In one embodiment, the throttle 124 energy consumption may include modifying heating and / or cooling thresholds so that the heating or cooling equipment, respectively, operates less frequently. In one embodiment, the amount of the throttle 124 energy consumption may be related to the amount of charge required by the energy storage device. In another embodiment, the amount of the throttle 124 energy consumption may be related to the difference between the current amount of energy consumption at the fixed location and the amount of charge required by the energy storage device. In one embodiment, the energy consumption throttling 124 may be performed by the location processor 120 when the current amount of energy consumption at a fixed location is greater than the amount of charge required by the energy storage device. In another embodiment, the amount of energy consumption throttling 124 may be based on the length of the event in the event description 118.

[0034] In one embodiment, the electric utility may throttle energy consumption for the fixed locations (124). The location processor 120 may detect reduced received energy levels by reading power meters at the fixed locations and storing 126 the reduced retained energy in an energy storage device. In one embodiment, the electric utility may throttle energy consumption based on a fixed percentage (124). In another embodiment, the electric utility may throttle energy consumption based on a percentage of energy consumption by the fixed locations in a recent time period (124). In another embodiment, the electric utility may throttle energy consumption based on recent energy consumption by the fixed locations and other fixed locations in a common area (124).

[0035] After the location processor 120 throttles energy consumption 124, the location processor 120 may store the retained energy in an energy storage device 126. In one embodiment, the amount of energy 126 stored in the energy storage device may be equal to the amount of throttled energy consumption 124 (i.e., the energy that would have been consumed is instead sent to the energy storage device).

[0036] In one embodiment, the server 110 determines (128) that an event has started. In one embodiment, the server 110 may detect an alarm or lack of response from an electricity detection device connected to the server 110. In another embodiment, the server 110 may receive a notification from the electric utility indicating that the power will be turned off. In response to determining (128) that an event has started, the server 110 may send an event notification to the location processor 120. In one embodiment, the event notification 132 may be received by the same location processor 120 that also received the event description 118. In another embodiment, the event notification 132 may be received by fewer or more location processors 120 that also received the event description 118. In one embodiment, the receipt of the event notification 132 by the location processor 120 may coincide with a loss of power at a fixed location. In response to receiving the event notification 132, the location processor 120 may use (136) stored energy from the energy storage device. In one embodiment, the location processor 120 may use 136 the retained energy for devices that were not throttled 124. In another embodiment, the location processor 120 may use 136 the retained energy for all devices in the fixed location. In another embodiment, the location processor 120 may use 136 the retained energy for devices that are not throttled in the fixed location only while the event notification 132 indicates a loss of power for the fixed location.

[0037] In one embodiment, an energy storage device at a fixed location may transmit the stored energy 134 to the vehicle. The vehicle may also be at a fixed location and connected to a charging station. The location processor 120 may have received the vehicle energy level 112 from the vehicle processor 130 and may therefore already know the current amount of stored energy 134 that the vehicle can accept. The location processor 120 may even approve the vehicle energy level 112 provided to the vehicle. The vehicle processor 130 stores the retained energy in the vehicle (138).

[0038] In one embodiment, the energy storage device may be a vehicle, and may move the vehicle to another location having a demand greater than a threshold to provide the stored energy. The vehicle may include an energy storage device that stores energy to power the vehicle. Energy in the energy storage device may be consumed as the vehicle moves and may require recharging for the vehicle to continue moving. The energy storage device may have a minimum energy level for moving, and the current energy level of the energy storage device may be between the minimum energy level and a fully charged level. Because the vehicle is mobile when charged, it has the ability to move to another location and transfer charge to another energy storage device in another fixed or mobile location, for example, another vehicle.

[0039] In one embodiment, the other location may have an associated processor that measures the current charge level of an energy storage device at the other location. The energy storage device at the other location may have an energy threshold stored in an accessible memory that indicates a level of demand for the other location. For example, the other threshold may reflect the ability of the energy storage device to operate basic necessary functions such as lighting or heating for a minimum period of time (e.g., 3 hours). A threshold greater than the other threshold may indicate a greater amount of demand at the other location, and thereby a greater urgency in providing additional charge to the energy storage device at the other location. The processor at the other location may send the current energy level and energy threshold of the energy storage device at the other location to the server 110, which may request the vehicle to proceed to the other location based on the threshold. For example, the server 110 may send a notification to the location processor 120 to transfer the stored energy to the energy storage device of the connected vehicle. The location processor 120 transmits the stored energy 134 to the vehicle, which stores the retained energy in the vehicle's energy storage device (138). In parallel with the stored energy 134, the location processor 120 may provide a notification to the vehicle processor 130 with an address or GPS coordinate of another fixed or mobile location. The vehicle processor 130 may transmit the address or GPS coordinate to the vehicle's navigation processor. The vehicle then travels to the other location and transmits a portion of the stored energy 134 to the other fixed or mobile energy storage device.

[0040] In one embodiment, the vehicle processor 130 may determine how much charge the vehicle has, the amount of charge in the energy storage device monitored by the location processor 120, and what energy needs may be at the current location before departure. The vehicle's energy management processor may send the current energy level stored in the vehicle energy storage device to the vehicle processor 130. For example, this may occur periodically, such as every 10 minutes, or when the vehicle arrives at a location and accesses a charging station at the location. When the vehicle connects to a charging station at the location, the location processor 120 may send a notification to the vehicle processor 130 that includes the current energy level and the maximum charge level of the energy storage device at the location. The vehicle processor 130 may subtract the current energy level from the maximum charge level to determine the amount of charge needed at the location.

[0041] In one embodiment, curtailing energy consumption 124 at the location may include determining a first device at the location that is needed to support habitation at the location, determining a second device at the location that is not needed to support habitation at the location, and not providing electricity to the second device during the event. It may be important to support habitation at the location during the event so that an occupant of the location can survive at the location for the duration of the event and reduce demand for auxiliary or emergency services. For example, habitation may require a fireplace that can maintain a minimum temperature, air conditioning that can maintain a maximum temperature, medical equipment (e.g., ventilators or infusion pumps) that are always powered, or some lights that remain on. Less important second devices may include televisions, kitchen appliances, washers / dryers, computers, and most lights at the location. The second devices may not be needed for human survival at the location.

[0042] In one embodiment, the location processor 120 may determine which devices at the location are the first and second devices by reading a data structure in an accessible memory device. For example, the server 110 may provide a list of the first and second devices to the location processor 120, which may store the list in a memory device. When the location processor 120 receives an event description 118 from the server 110, the location processor 120 may read the memory device to find the list of the first and second devices. The location may include an actionable switch between an energy storage device or a utility grid (i.e., an energy source) and each of the second energy devices. The location processor 120 may throttle energy consumption for the second device by sending a control to the actionable switch to disable the flow of energy to the second device (124).

[0043] In one embodiment, the location processor 120 may determine that storing the stored energy in the energy storage device from the current time until the predicted start time of the event is insufficient to fully charge the energy storage device. The location processor 120 may identify a means of transportation having a charge sufficient to fully charge the energy storage device and request the means of transportation to fully charge the energy storage device. Storing may not be sufficient to fully charge the energy storage device. The event description 118 from the server 110 may include the predicted start time of the event and, in some embodiments, may include the predicted event duration. The location processor 120 reads the current level of energy in the energy storage device and may determine that even if the stored energy is stored in the energy storage device (126), the energy storage device may not be fully charged before the event starts. For example, the location may be the critical care portion of a hospital, and if the event has a long or unpredictable duration for the survival of a patient, it may be important to fully charge the energy storage device before the event starts. The location processor 120 may obtain the full charge amount from an accessible memory device and may determine the charge percentage of the stored energy by reading a charge controller connected to the energy storage device. Considering the charge percentage and the event time specified in the event description 118, the location processor 120 may determine that the time between the current time and the event time is insufficient to fully charge the energy storage device. The location processor 120 may determine the predicted amount of charge in the energy storage device at the event time and may subtract this amount from the full charge amount to determine the amount of charge required for full charge. In one embodiment, the location processor 120 may send a notification to the server 110 to obtain additional charge for the energy storage device. The notification may include the amount of charge required to fully charge the energy storage device at the location.

[0044] The server 110 may send notifications (either individually to vehicles in a list in a memory device accessible to the server 110 or broadcast to all vehicles within range) in response to an indication of the amount of charge available in each responding vehicle. The vehicle processor 130 in each responding vehicle may determine the amount of charge available by subtracting the amount of charge needed to reach a charging station from the current level of charge in the responding vehicle and send this amount to the server 110. The server 110 may compare each of the amounts of charge provided from the responding vehicles to select a vehicle with the most appropriate level of charge to proceed to the location corresponding to the location processor 120. In one embodiment, the most appropriate level of charge may be the lowest amount of charge that is equal to or greater than the amount of charge needed for a full charge. In another embodiment, the most appropriate level of charge may be the amount of charge that is equal to or greater than the amount of charge needed for a full charge, and the responding vehicle is the closest distance to the location corresponding to the location processor 120. For example, the GPS coordinates of the responding vehicle may be compared to the GPS coordinates of the location to determine the closest responding vehicle. The server 110 may send a request to the responding vehicle with the most appropriate level of charge to proceed to the location corresponding to the location processor 120 and transfer the amount of charge needed for a full charge to an energy storage device at that location.

[0045] In one embodiment, using the stored energy at the location when the event occurs may include determining the energy consumption at the location prior to the event and using less than the determined energy consumption at the location during the event. For example, if the energy at the location is shut down, e.g., if the location is part of a blackout, the stored energy in the energy storage device and / or connected vehicle may be used to power devices at the location, which may be at a reduced consumption level equal to the previous consumption level, or may be at an even reduced level (most likely).

[0046] In one embodiment, the location processor 120 may continuously determine energy consumption at the location for one or more past time periods (e.g., the most recent day, week, or month, or daily, weekly, or monthly, etc.) and store the past energy consumption in an accessible memory device. In one embodiment, the location processor 120 may obtain past energy consumption from a power meter at the location corresponding to the location processor 120. In one embodiment, the location processor 120 may consume less energy than the past amount of energy by slowing (or reducing) the rate of energy use at the location. The location processor 120 may slow down energy use at the location by requesting that individuals at the location turn off lights, appliances, or other devices that may use stored energy. The location processor 120 may initiate this lower energy consumption rate in response to receiving an event notification 132 from the server 110. The request may include sending a notification to a display associated with the location processor 120, where the content of the notification is displayed.

[0047] In another embodiment, the event description 118 may not include an event duration or may indicate a varying event duration. The location processor 120 may interpret this as an unreliable event duration and may accordingly initiate additional reduced energy consumption from the memory device below historical levels. For example, the location processor 120 may determine that energy consumption needs to be reduced by 50% from historical energy consumption and may turn off one or more devices in the location to achieve the 50% savings (i.e., throttle energy consumption (124)).

[0048] In another embodiment, the location processor 120 may determine that the stored energy is sufficient to fully charge the energy storage device, determine an excess amount of stored energy, and provide the excess amount of stored energy to charge the vehicle. The location processor 120 may determine that the energy storage device is fully charged before the event start time specified in the event description 118. In one embodiment, the location processor 120 may determine an amount of excess charge that may be available before the event start time, where the excess amount is not needed to charge the energy storage device at the location. The location processor 120 may instead transmit the excess energy as stored energy 134 to the connected vehicle and provide a notification to the vehicle processor 130 regarding the amount of excess energy transmitted to the energy storage device of the vehicle. The location processor 120 may also provide a location for the vehicle to travel to and deposit the excess energy. For example, the travel location may include a fixed or mobile location associated with a family or business entity associated with a location corresponding to the location processor 120.

[0049] In one embodiment, a vehicle may not be able to accept the excess energy because the vehicle may already be fully charged. The vehicle processor 130 may provide a response to the location processor 120 that it cannot accept the excess charge. The location processor 120 may then send a notification to the server 110 that it has an amount of excess charge available. The server 110 may query a group of vehicles in a list in a memory device accessible to the server 110 to determine one or more other vehicles that may use the excess charge at the location. One or more vehicle processors 130 associated with the one or more other vehicles may respond to the offer, and the server 110 may provide directions to the one or more other vehicles to proceed to the location associated with the location processor 120 to receive the excess charge.

[0050] In one embodiment, the location processor 120 may determine that the event will begin before the energy storage device is charged to a threshold, prevent energy consumption at the location, and transfer the retained energy from the energy storage device to the vehicle. In one embodiment, the event description 118 may not include a start time for the event because in some cases, an exact start time may not be available. In another embodiment, the event description 118 may include a start time for the event, but for many reasons, the event may begin before that time. The location processor 120 may be storing retained energy in the energy storage device (126) when the event begins, and the energy storage device may not be fully charged. In one embodiment, the energy storage device may not include a useful energy level when the event begins because a minimum level of useful energy for the energy storage device may not yet be achieved. For example, the event may be three days in expected duration, but the stored energy in the energy storage device may only have one day of retained energy stored (126). Rather than utilizing the limited amount of stored energy in the energy storage device, it may be more sensible to not consume any more energy at the location and to transfer the stored energy to a connected vehicle that empties the location.

[0051] In one embodiment, the location processor 120 may maintain charge level thresholds in an accessible memory device. The charge level thresholds may correspond to the expected duration of the event if the energy storage device is fully charged. For example, 3x level for a 1 day event, 2x level for a 2 day event, and 3x level for a 3 day event. If the event description 118 indicates that the expected event duration is 2 days, the energy storage device is charged to reflect a 1 day supply of energy, and an event notification 132 has been received by the location processor 120, the location processor 120 may throttle 124 energy consumption at the location and provide a notification to the vehicle processor 130 indicating that the charge in the energy storage device is being transferred to the vehicle. The energy storage device transfers the 1 day supply of energy to the vehicle, and the location processor 120 may send a notification to the vehicle occupant's device or the vehicle processor when the energy transfer is complete.

[0052] The flow diagrams depicted herein, such as Figures 1, 2C, 2D, 2E, 3A, 3B, and 3C, are separate examples that may be of 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.

[0053] FIG. 2A illustrates a vehicle network diagram 200, 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'. The vehicles 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between the 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. Although depicted as a single vehicle and processor, there may be multiple vehicles and processors. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the present elements.

[0054] 2B illustrates 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'. The vehicles 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between the 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. The processors 204, 204' may further communicate with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a vehicle 222, a computer 224, an I / O device 226, and a voice application 228. The processor 204, 204' may be in communication with further elements comprising one or more of a processor, memory, and software.

[0055] 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 the processors 204, 204' and elements 230. For example, the mobile phone 220 may provide information to the processor 204, which may cause the vehicle 202 to initiate an action, which may further provide information or additional information to the processor 204', which may cause the vehicle 202' to initiate an action, which may further provide information or additional information to the mobile phone 220, the vehicle 222, and / or the 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 present elements.

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

[0057] The processor 204 performs one or more of determining 244C locations within the area that may lose electricity during a grid-related event, conserving 246C energy through curtailment of energy consumption at the locations, storing 248C the retained energy in an energy storage device at the locations, and using 250C the retained energy at the locations when an event occurs.

[0058] 2D illustrates a further vehicle network diagram 250 according to an exemplary embodiment. The network comprises elements including a vehicle 202 including 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 including a processor and memory.

[0059] The processor 204 determines whether the energy storage device is a vehicle, and whether the vehicle is moved to another location having a demand greater than a threshold to provide the stored energy 244D, where curtailing energy consumption at the location includes determining a first device at the location that is needed to support occupancy at the location, determining a second device at the location that is not needed to support occupancy at the location, and not providing electricity to the second device during the event 245D, determines that storing retained energy in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device, and identifies a vehicle having sufficient charge to fully charge the energy storage device. and, separately, one or more of: requiring the vehicle to fully charge the energy storage device 246D, where using the stored energy at the location when the event occurs includes determining an energy consumption at the location prior to the event and using less than the determined energy consumption at the location during the event 247D; determining that the stored energy is sufficient to fully charge the energy storage device, determining an excess amount of the stored energy, and providing the excess amount of the stored energy to charge the vehicle 248D; and determining that the event begins before the energy storage device is charged to a threshold, preventing energy consumption at the location, and transferring the stored energy from the energy storage device to the vehicle 249D.

[0060] 2E illustrates yet another vehicle network diagram 260 according to an example 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 validation data and sources of validation 207 for future use (e.g., in audits).

[0061] In this example, only one vehicle 202 is described in detail, but multiple such nodes may be connected to the blockchain 206. It should be understood that the 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. The vehicle 202 may have 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. Although a single processor 204 is depicted, it should be understood that the vehicle 202 may include multiple processors, multiple cores, or the like, without departing from the scope of the present application. The vehicle 202 may be a vehicle, a server, or any device that includes a processor and memory.

[0062] The processor 204 performs one or more of: receiving 244E an acknowledgment of an event from one or more elements described or depicted herein, the acknowledgment comprising a blockchain consensus between peers represented by any of the elements; and executing 246E a smart contract to record the acknowledgment in the blockchain based on the blockchain consensus. The consensus is formed between any of the elements 230 and / or one or more of any 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 any of the elements described or depicted herein, including a server, a wireless device, etc.

[0063] The processor and / or computer readable medium 242E may be fully or partially internal or external to the vehicle. The steps or functions stored in the computer readable medium 242E may be performed fully 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.

[0064] FIG. 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, WiFi, and the like. The vehicle 266 may also communicate with the other vehicles 268, charging stations 270, and / or electrical grid 272 in a wireless and / or wired manner. In one example, the vehicle 266 is routed (or routes itself) to the 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, the 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, the safety and efficiency of the vehicle may be increased, and may have a positive impact on the environment as described and / or depicted herein.

[0065] The term "energy" may be used to refer to any form of energy that is received, stored, used, shared, and / or lost by a vehicle. Energy may be referenced along with a voltage source of charge and / or current supply provided from an entity to a vehicle during a charging / use operation. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or from alternative sources of power, 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.

[0066] In one example, the charging station 270 manages the amount of energy transferred from the vehicle 266 so that the vehicle 266 has enough charge remaining to reach the destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transfer between the vehicles 268, both of which may be moving. In one example, an unused vehicle, such as the vehicle 266 (which may be autonomous), is directed to provide an amount of energy to the charging station 270 and return to its original location (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 268 and transfer the stored excess energy to the charging station 270. In one example, factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (weight, etc.), the schedule of the occupant while using the vehicle, and the expected schedule of the occupant waiting for the vehicle determine the amount of energy to transfer to the charging station 270. In one example, vehicle 268 , charging station 270 , and / or electrical grid 272 may provide energy to vehicle 266 .

[0067] In one embodiment, a location, such as a building, home, 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 at which electricity flows to the location, vehicle 266, other vehicle 268, or one or more of the locations is modified in response to external conditions, such as weather. For example, if 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.

[0068] In one example, the solutions described and depicted herein may be utilized to determine the impact of loads 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 energy stored in the vehicle's battery. In one example, the solutions may also be utilized 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 utilized to manage the amount of energy remaining in the vehicle after a portion of the charge has been transferred to a charging station. In one example, the solutions may also be utilized to notify a vehicle to provide an amount of energy in the battery in the vehicle, the amount of energy to transfer being based on the distance of the vehicle to the module receiving the energy.

[0069] In one example, the solution may also be utilized to use a mobile energy storage unit that uses the determined route to travel to a vehicle that has excess energy and deposits the stored energy to the electric grid. In one example, the solution may also be utilized to determine the priority of the vehicle's decision regarding 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 the vehicle's decision to maneuver to a location to discharge excess energy to the energy grid and then return to the previous location when the vehicle is not in use. In one example, the solution may also be utilized to determine the amount of energy required by the vehicle to provide needed energy to another vehicle via energy transfer between vehicles based on one or more conditions, such as weather, traffic, road conditions, vehicle conditions, and passengers and / or goods in the other vehicle, and to instruct the vehicle to route and provide energy to the other vehicle. 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 utilized 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 utilized to provide a remaining distance required to a charging station, which determines the amount of energy to be extracted from the vehicle, and the amount of remaining charge is based on the remaining distance. In one example, the solution may also be utilized to manage a vehicle being charged at more than one point simultaneously, such as 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.

[0070] In one embodiment, vehicles 266 and 268 may be utilized as bidirectional vehicles. Bidirectional vehicles may assist in providing power to grid 272 and / or function as a mobile microgrid that can 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 may take 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 being charged, alternating current (AC) electricity from grid 272 is converted to direct current (DC). This may be done by one or more of the 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 and other networks and / or systems.

[0071] FIG. 2G is a diagram 275 showing the interconnections between the 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 and all communicatively connected to communicate with a network 286. A database 287 is communicatively connected to the network and allows for the storage and retrieval of data. 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 infrastructures 282, one or more residential housing units 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 interface with the solution. The smartphone 278, laptop 280, 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'. The one or more public buildings 281 may include various institutions. The one or more public buildings 281 may utilize computing devices 281'. The one or more service providers 279 may include a dealership, a tow truck service, a collision center, or other repair shop. The 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, such as 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 infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. The one or more traffic infrastructures 282 may utilize a computing device 282'.

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

[0073] In one example, the solution described and depicted herein may be utilized to determine access to a vehicle via blockchain consensus. In one example, the solution may also be utilized to perform profile verification before allowing a vehicle occupant to use the vehicle. In one example, the solution may also be utilized to have the vehicle indicate (visually, but also in another example verbally, etc.) on or from the vehicle what actions (which may be pre-recorded) the user needs to take and verify that the actions are correct actions. In one example, the solution may also be utilized to provide the vehicle with the ability to decide based on the risk level associated with the data and the driving environment how to distribute to the occupant a portion of the bifurcated data with a lower risk level in a safe driving environment and later distribute the remaining portion of the bifurcated data with a higher risk level to the occupant after the occupant has left the vehicle. In one example, the solution 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.

[0074] In one example, the solution may also be utilized to allow a vehicle to continue operating outside of the boundary if a consensus is reached by the vehicle based on the vehicle's operation 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, the size of the file, 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 the subject vehicle and other nearby vehicles to perform a normally dangerous maneuver in a safe manner 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 suitable for an 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.

[0075] In one example, the solution may also be utilized to detect lane usage at a location and time and inform or instruct the vehicle occupant to recommend or not recommend a lane change. In one example, the solution may also be utilized to eliminate the need to send information via email and the driver / occupant to respond by making a payment via email or in person. In one example, the solution may also be utilized to provide services to the vehicle occupant, 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 utilized to record changes in the state of rented objects. In one example, the solution may also be utilized to seek blockchain consensus from other vehicles in the vicinity of the damaged vehicle. In one example, the solution may also be utilized to receive media from a server, such as an insurance entity server, or a vehicle computer that may be related to the accident. The server accesses one or more media files to access the damage to the vehicle and stores the 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 multiple devices at various times prior to a vehicle-related event.

[0076] In one example, the solution may also be utilized to solve the problem of a lack of video evidence for accidents involving vehicles. The solution details inquiries by vehicles involved in the accident regarding media related to the accident from 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 vehicles and other devices (e.g., pedestrian cell phones, street light cameras, etc.).

[0077] In one example, the solution may also be utilized to alert the occupants if the vehicle is maneuvering towards a dangerous area and / or event, allowing the vehicle to notify the 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 the vehicle is traveling at a high speed, at least one other vehicle is used to assist in slowing the vehicle so that the impact on traffic is minimal. 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 the vehicle that the vehicle is approaching a traffic control sign on a road, and then receive an indication from other nearby vehicles that the vehicle is driving poorly if the vehicle goes beyond the sign. In one example, the solution may also be utilized to render a vehicle partially inoperable 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 per time period.

[0078] In one example, the solution may also be utilized to overcome the need for reliance on software updates to correct issues with the vehicle when it is not operating properly. Through observations of other vehicles on the route, the 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 if the data suggests unsafe or erroneous operation. In one example, the solution may also be utilized to provide notification 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, either by a device associated with a vehicle accident or by a device near the accident. Based on the severity of the accident or near the accident, 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 analysis of the data. 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 and proposed future states 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 vehicle rental entity.

[0079] In one example, the solution may also be utilized to move the vehicle to another location based on the user's event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user based on the outcome of the original event or the modified event. In one example, the solution may also be utilized to enable verification of available locations in the area through vehicles present in the area. The approximate time that 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 the vehicle to a closer parking space if a parking space becomes available and the elapsed time from the initial parking is less than the average time of the event. Furthermore, the vehicle is moved to a final parking space when the event is completed 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 approaching congestion. The system interacts with the vehicle to provide some service below the regular rate and / or guide the vehicle to alternative parking locations based on the vehicle's priority, thereby improving optimization of the parking situation before arrival.

[0080] In one example, the solution may also be utilized to sell fractional ownership of a vehicle or determine pricing and availability for ride-sharing applications. In one example, the solution may also be utilized to provide accurate and timely reporting of dealership sales activity, much better than what is currently available. In one example, the solution may also be utilized to enable dealerships to request assets in the blockchain. By using the blockchain, consensus is obtained before any assets are moved. Furthermore, the process may be automated and payments may be initiated in the blockchain. In one example, the solution may also be utilized 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 utilized 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 utilized to determine services required at the destination of the vehicle. One or more service locations capable of providing the required service are located within an area on the route to the destination and available for performance of the service. Navigation of the vehicle is updated with the determined service locations. A smart contract including a compensation value for the service is identified and a blockchain transaction is stored on the distributed ledger for the transaction.

[0081] In one example, the solution may also be utilized to link the service provider's vehicle with the vehicle's 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 and, in another example, meets with the vehicle to provide the service / goods. In one example, the solution may also be utilized to detect vehicles 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 utilized to assign one or more vehicles as road managers, who help regulate traffic. Road managers may generate road indicators (such as signal lights, displays, sounds, etc.) to assist with traffic flow. In one example, the solution may also be utilized to alert the vehicle's driver by a device, which may be a traffic light or near an intersection. An alert is sent upon events such as when a traffic light turns green and the vehicle ahead of it in the list of vehicles does not move.

[0082] FIG. 2H is another block diagram 290 showing the interconnections between different elements in one example. A vehicle 276 is depicted, including 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 in the vehicle. The 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 controller area network (CAN) bus 294. The ECUs may also communicate with the vehicle's computer 298 via the CAN bus 294. The vehicle's processor / sensors 298 (such as the vehicle's computer) may communicate with external elements such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296 and head unit 297 may include its own security policy. The security policy defines the permissible processes that are executable in the appropriate context. In one example, the security policy may be provided partially or completely in the vehicle's computer 298.

[0083] Each of the ECUs 295, 296 and head unit 297 may include custom security function elements 299 that define approved processes and the contexts in which the processes are allowed to operate. Context-based authorization, which determines the validity of 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 permitted boundaries, such as proximity contexts such as nearby objects, distance to approaching objects, speed, 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.

[0084] In one example, the solutions described and depicted herein may be utilized to partially disable a vehicle by (in certain embodiments) limiting speed, limiting ability to approach another vehicle, limiting 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 an exchange of ownership of a vehicle using blockchain, where data is sent to a server by either a device associated with an incident with the vehicle or a device near the incident. Based on the severity of the incident or near the 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 near the incident. The server attempts to obtain data from the other vehicles, allowing the server to gain an understanding of 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 send data related to the sound and the location of the possible source to the 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 unfolding of the accident. In one example, the solution may also be utilized to associate a vehicle with an accident and then capture media captured by devices near the location of the accident. 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 will assist in understanding further details surrounding the accident.

[0085] In one example, the solution may also be utilized to record areas where possible events have occurred, such as when a vehicle comes into or may come into contact with another vehicle (whether moving or parked), utilizing sensors to record audio, video, motion, etc., and the system captures data from sensors that may be present on one or more of the vehicles and / or on 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 a new condition of the vehicle during a vehicle event and comparing the condition to a vehicle condition profile, thereby allowing for safe and secure capture of critical data from a vehicle about to be involved in a harmful event.

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

[0087] In one example, the solution may also be utilized to increase or decrease a vehicle's 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 are used to determine a status of the vehicle. Fractional ownership of the vehicle is determined based on the status and new responsibilities of the vehicle are established. In one example, the solution may also be utilized to provide data to a replacement / upfitting part, the data attempting to destroy an approved functionality of the replacement / upfitting part and allowing the part to use an approved functionality of the replacement / upfitting part depending on the approved functionality not being destroyed.

[0088] In one example, the solution may also be utilized to allow a passenger to individually ensure that they are in the vehicle and that they should reach a particular destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authorized to interact with the passenger. Pick-up, drop-off, and location are also mentioned. All of the above are stored in an immutable manner on the blockchain. In one example, the solution may also be utilized to determine driver characteristics through analysis of driving style and other factors to take action in the event that the driver is not driving as they normally do, such as when the driver has previously driven in certain conditions, e.g., during the day, at night, in the rain, in the snow, etc. Additionally, vehicle attributes are also considered. Attributes consist of weather, whether headlights are on, whether navigation is being used, whether HUD is being used, whether media at a certain volume is being played, etc. In one example, the solution may also be utilized to notify passengers in the vehicle of a dangerous situation when items in the vehicle indicate that the passenger may not be aware of the dangerous situation.

[0089] In one example, the solution may also be utilized to mount a calibration device on a fixed fixture on 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 sends malfunction information, and consensus is required from other service centers as to what the severity threshold is for the data. Once consensus is received, the service center may send a malfunction security level to the blockchain where it is stored. In one example, the solution may also be utilized to determine the difference between sensor data outside the vehicle and the vehicle's own sensor data. The vehicle requests software from the 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.

[0090] Referring to FIG. 2I, a connected vehicle operating environment 290A is shown, according to some embodiments. As depicted, the vehicle 276 includes a controller area network (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, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0091] The 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 the display unit 299A. The 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. The 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 solution.

[0092] The memory 297A is a non-transitory memory that stores instructions or data that can be accessed and executed by the processor 296A. The instructions and / or data can include code for performing the techniques described herein. The memory 297A can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory, or some other memory device. In some embodiments, the memory 297A can also include non-volatile memory or similar permanent storage devices and media, which can 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 the memory 297A can be reserved for use as a buffer or virtual random access memory (virtual RAM). The vehicle 276 can include one or more memories 297A without departing from the present solution.

[0093] 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.

[0094] The navigation system 295A may represent at least one navigation route including a start point and an end point. In some embodiments, the navigation system 295A of the vehicle 276 receives a request from a user for a navigation route, the request including a start point and an end point. The 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. The real-time data server 293 transmits the navigation route data to the vehicle 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the vehicle 276.

[0095] 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 activated or enabled so that ADAS system 294A may operate on a given navigation route.

[0096] 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: camera, LiDAR sensor, ultrasonic sensor, vehicle engine sensor, radar sensor, laser altimeter, manifold absolute pressure sensor, infrared detector, motion detector, thermostat, sound detector, carbon monoxide sensor, carbon dioxide sensor, oxygen sensor, mass airflow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air fuel ratio meter, blind spot meter, curb feeler, fault detector, Hall effect sensor, parking sensor, speed gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission fluid temperature sensor, turbine speed sensor (TSS), variable reluctance sensor, vehicle speed sensor (VSS), moisture sensor, wheel speed sensor, GPS sensor, mapping function, and any other type of automotive sensor. The navigation system 295A may store the sensor data in memory 297A.

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

[0098] 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 based on the detected radar information as an area where other vehicles 277 are located, calculating a probability that the GPS information of a target vehicle is located in the set area, and identifying a vehicle and / or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

[0099] In one example, the solutions described and depicted herein may be utilized to manage emergency deployment and functionality of a vehicle when it is determined that the vehicle is entering an area without network access. In one example, the solutions may also be utilized to manage and provide functionality (such as audio, 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 the vicinity of 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.

[0100] 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 taking place. In one example, the solution may also be utilized to determine two threat levels for obstacles in the 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 remove sensitive data from the vehicle if it is damaged in a way that renders it unusable.

[0101] In one example, the solution may also be utilized to ensure that customer data to be removed is truly removed from all required locations within an enterprise demonstrating GDPR compliance. In one example, the solution may also be utilized to provide compensation from one vehicle to another in exchange for safety related data, important notifications, etc., to increase the autonomous capabilities of a lower level autonomous vehicle. 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 a continuum of the first biometric. The vehicle provides the decrypted data to the occupant only if the occupant is able to receive the decrypted data, 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 steering wheel of the vehicle. In one example, the solution may also be utilized to provide existing but currently not enabled features to a passenger vehicle to present vehicle occupants with features that reflect their characteristics.

[0102] In one example, the solution may also be utilized to enable the reflection of modifications on 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, recreation of a occupant's work environment and / or home environment is disclosed. The system may attempt to "recreate" the user's work / home environment while the user is in the vehicle if the vehicle determines that the user is in "work mode" or "home mode". All data related to the interior and exterior of the vehicle, as well as the various occupants utilizing the vehicle, is stored on the blockchain and executed via smart contracts. In one example, the solution may also be utilized to detect occupant gestures to assist in communication with nearby vehicles, which may 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 the user's gait and 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 dangerous activities before allowing a gesture.

[0103] In one example, the solution may also be utilized to assign a status to each occupant in the 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 the system details of sounds associated with the collision (where, what direction, whether it is getting louder or quieter, from which device, data associated with the device such as type, manufacturer, owner, and number of sounds occurring simultaneously and time of day the sounds were emitted, etc.) if analysis of the data assists in determining details regarding the collision. In one example, the solution may also be utilized to provide a determination that operation of the vehicle is unsafe. The vehicle includes multiple components that operate together to control the vehicle, each component associated with a separate component key. An encryption key is transmitted to the vehicle to reduce 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.

[0104] In one example, the solution may also be utilized to provide an indication from one particular vehicle (trying to vacate a location) to another particular vehicle (trying to occupy a location), with the 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 the use of the vehicle may change over a period of time, used to update fractional ownership by the system. Other embodiments are included in applications that include minimum ownership of vehicles based on vehicle availability and vehicle driver determination rather than vehicle use, as well as other things.

[0105] In one example, the solution may also be utilized within a vehicle for users to authorize their subscriptions with respect to a closed group of people, such as family or friends. For example, a user may want to share a 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 vehicle) may verify that the person requesting the service is an approved person with whom the subscriber shared their profile. In one example, the solution may also be utilized to allow a person to utilize secondary transportation to reach an intended destination. Functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining what type of alternative transportation should be utilized) are used in determining secondary transportation. In one example, the solution may also be utilized to allow a passenger who is involved in an accident to access other transportation to proceed to their original destination.

[0106] In one example, the solution may also be utilized to convey software / firmware uploads to a first subset of transport means. This first set of transport means tests the update and, if the test is successful, the update is conveyed to a further set of transport means. In one example, the solution may also be utilized to convey software / firmware updates from a master transport means to a vehicle, and the updates are conveyed through the vehicle's network from a first subset, then a larger subset, etc. A portion of the update may be sent first and then the remaining portion may be sent from the same vehicle or a different vehicle. In one example, the solution may also be utilized to provide updates for the computers of the transport means to the transport means and the devices of the operator / occupants of the transport means. The updates may be approved by all drivers and / or all occupants. Software updates are provided to the vehicle and the devices. The user need do nothing other than go near the vehicle and the functionality occurs automatically. A notification indicating that the software update is complete is sent to the device. In one example, the solution may also be utilized to verify that an OTA software update is being performed by an authorized technician and that the circumstances related to the originator of the verification code, the procedure for wirelessly receiving the software update, the information included in the software update, and the result of the verification are being generated by components of one or more transport means.

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

[0108] To make a vehicle sufficiently secure, it needs to 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.

[0109] 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 each other through a central network in the vehicle that may be referred to as a Controller Area Network (CAN). Cutting edge features such as autonomous driving are highly dependent on the implementation of new and complex ECUs such as advanced driver assistance systems (ADAS), sensors, and the like. While these new technologies are helping to improve the safety and driving experience of the vehicle, they also increase the number of external communication units within the vehicle, making them more vulnerable to attacks. Below are some examples of securing a vehicle from physical and remote intrusions:

[0110] 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 a CPU 2922B and 2913B, respectively, that controls the respective device, where there is memory in (or accessible to) the CPU 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 device.

[0111] When a user presses a button 293B on the key fob 292B (or otherwise activates the fob, etc.), a CPU 2922B runs in the key fob 292B and transmits a data stream to the transmitter 2921B, which is output via an antenna. In other embodiments, the user's intent is recognized in the key fob 292B via other means, such as a microphone to accept audio, a camera to capture images and / or video, or other sensors commonly used in the art to detect intent from a user, including receiving gestures, movements, eye movements, and the like. The data stream can be a 64-bit to 128-bit long signal that includes one or more of a preamble, a command code, and a rolling code. The signal can be transmitted at a rate between 2KHz and 20KHz, 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.

[0112] If the key fob 292B and the vehicle 291B use a fixed code between them, a replay attack can be performed. In this case, if an attacker can capture / find the fixed code during short-range communication, he / she can replay this code to gain access to the vehicle 291B. To improve security, the key fob and the vehicle 291B can 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 number, a pseudo-random number, etc.). 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.

[0113] In addition to rolling codes, the 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 the transmitter 2921B and the receiver 2911B may be used to establish a secure session. As another example, the code may have a limited expiration or timeout. Additionally, 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.

[0114] FIG. 2K illustrates a controller area network (CAN) 290C in a vehicle according to an exemplary embodiment. Referring to FIG. 2K, the CAN 290C includes a CAN bus 297C having high and low terminals, and multiple electronic control units (ECUs) 291C, 292C, 293C, etc., connected to the CAN bus 297C via wired connections. The CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without using a host computer. The CAN bus 297C implements a message-based protocol (i.e., ISO 11898 standard) that allows the ECUs 291C-293C to send commands to each other at the root level. Meanwhile, the ECUs 291C-293C represent controllers that control electrical systems or subsystems in the vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other functions.

[0115] In this example, the ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver may be used to send and receive messages to and from the CAN bus 297C. For example, the transceiver 2911C may convert data from the microcontroller 2912C into a format for the CAN bus 297C and convert data from the CAN bus 297C into a format for the microcontroller 2912C. Meanwhile, in one example, the microcontroller 2912C interprets messages and determines which messages to send using ECU software installed on the microcontroller 2912C.

[0116] To protect the CAN290C from cyber threats, various security protocols can be implemented. For example, sub-networks (such as sub-network A and B, etc.) can be used to divide the CAN290C into smaller sub-CANs to limit the ability of attackers to remotely access the transportation means. In the example of Figure 2K, the ECUs 291C and 292C can be part of the same sub-network, while the ECU 293C is part of an independent sub-network. Further, a firewall 294C (or a gateway, etc.) can be added to prevent messages from crossing the CAN bus 297C across sub-networks. If an attacker achieves access to a certain sub-network, the attacker does not have access to the entire network. In one example, to make the sub-network even more secure, the most important ECUs are not placed in the same sub-network.

[0117] Although not shown in Figure 2K, other examples of security control within the CAN include intrusion detection systems (IDSs), which can be added to each sub-network to read all passing data and detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle user. Other possible security protocols can include encryption / security keys that can be used to obfuscate messages. As another example, in one example, an authentication protocol is implemented that allows messages to authenticate themselves.

[0118] In addition to protecting the 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 connected 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. These communication systems are often referred to as telematics because they involve a combination of telecommunications and informatics. Additionally, the present solutions as 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.

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

[0120] 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, trip data, passenger information, diagnostic data, fuel data, speed data, and the like. However, the device 296D may only communicate collected information back to the host server 295D upon the vehicle being ignited and the trip being completed. Furthermore, communications may only be initiated by the device 296D, and not by the host server 295D. Thus, in one example, the device 296D does not accept communications initiated by external sources.

[0121] To communicate, the device 296D may establish a secure private network between the device 296D and the host server 295D, where the device 296D may include a tamper-proof SIM card that provides secure access to the carrier network 294D via the 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 firewall 293D of the host server 295D. As another example, the carrier network 294D may use data encryption (e.g., AES encryption, etc.) 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.

[0122] 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. Wireless networks may include one or more Wi-Fi networks, cellular networks, Dedicated Short Range Communications (DSRC) networks, 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 greatly reducing collisions. Additionally, the present solutions 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.

[0123] FIG. 2M illustrates an example 290E of vehicles 293E and 292E using security certificates for secure V2V communication, according to an exemplary embodiment. With reference to FIG. 2M, vehicles 293E and 292E may communicate with each other 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.

[0124] Upon receiving communications from each other, the transport vehicles may verify the signature with a certificate authority 291E or the like. For example, the transport vehicle 292E may verify with the certificate authority 291E that the public key certificate 294E used by the transport vehicle 293E to sign the V2V communication is authentic. If the transport vehicle 292E successfully verifies the public key certificate 294E, the transport vehicle knows that the data is from a legitimate source. Similarly, the transport vehicle 293E may verify with the certificate authority 291E that the public key certificate 295E used by the transport vehicle 292E to sign the V2V communication is authentic. Additionally, the present 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.

[0125] Figure 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 Figure 2B may include a security processor 292F as shown in example process 290F of Figure 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.

[0126] 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's computer and may communicate with other elements of the vehicle, such as ECU / CAN network 296F, and 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 to devices attached or connected via wires to the vehicle's computer are also secure.

[0127] For example, the authorization module 293F may store passwords, usernames, PIN codes, biometric scans, and the like for various users of the vehicle. The authorization module 293F may determine whether a user (or technician) has permission to access a particular setting, 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, via a console or GUI within the vehicle or via an attached / connected device, the authorization module 293F may require the user to identify themselves in some way before the setting is changed. For example, the authorization module 293F may require a username, password, PIN code, biometric scan, 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) that is being requested.

[0128] 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 for authenticating communications between ECUs. As an example, the authentication module 294F may send a bit signature algorithm to the ECUs of the CAN network. The ECUs may use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. Each time a new CAN frame is generated by one of the ECUs, the bit signature algorithm may dynamically change the position, amount, etc. of the authentication bits. The authentication module 294F may also provide a list of ECUs that are exempt (safe list) and do not need to use the authentication bits. The authentication module 294F may communicate with a remote server to retrieve updates to the bit signature algorithm and the like.

[0129] 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 the other devices to decrypt / encrypt the 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.

[0130] 3A illustrates a flow diagram 300 according to an example embodiment. Referring to FIG. 3, the flow diagram includes one or more of determining 302 locations within an area that may lose electricity during a grid-related event, conserving energy through curtailment of energy consumption at the locations 304, storing 306 the retained energy in an energy storage device at the locations, and using 308 the retained energy at the locations when an event occurs.

[0131] 3B illustrates another flow diagram 320 according to an exemplary embodiment. Referring to FIG. 3B, the flow diagram includes: an energy storage device is a vehicle, and the vehicle is moved to another location having a demand greater than a threshold to provide stored energy 322, where curtailing energy consumption at the location includes determining a first device at the location that is needed to support occupancy at the location, determining a second device at the location that is not needed to support occupancy at the location, and not providing electricity to the second device during the event 323; determining that storing retained energy in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device, and moving the vehicle to another location having a demand greater than a threshold to provide stored energy 324, where curtailing energy consumption at the location includes determining a first device at the location that is needed to support occupancy at the location, determining a second device at the location that is not needed to support occupancy at the location, and not providing electricity to the second device during the event 325; determining that storing retained energy in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device, and and requesting the vehicle to fully charge the energy storage device 324, where using the stored energy at the location when the event occurs includes determining an energy consumption at the location before the event and using less than the determined energy consumption at the location during the event 325; determining that the stored energy is sufficient to fully charge the energy storage device, determining an excess amount of the stored energy, and providing the excess amount of the stored energy to charge the vehicle 326; and determining that the event begins before the energy storage device is charged to a threshold, preventing energy consumption at the location and transferring the stored energy from the energy storage device to the vehicle 327.

[0132] 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.

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

[0134] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created 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 outside of the vehicle 402.

[0135] 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.

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

[0137] FIG. 5A illustrates an example vehicle configuration 500 that manages database transactions associated with a vehicle, according to an example embodiment. With reference 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 move (512) assets in accordance with the transaction. A vehicle processor 526 resides in the vehicle 525, and communication exists between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The transaction module 520 may record information such as assets, parties, credits, service description, date, time, location, outcome, notices, unexpected events, etc. The transaction in the transaction module 520 may be replicated in the database 530. The database 530 may be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, may be on-board the vehicle, may be off-board the vehicle, may be accessible directly and / or through a network, or may be accessible to the vehicle.

[0138] FIG. 5B illustrates an exemplary vehicle configuration 550 that manages database transactions between various vehicles, according to an exemplary embodiment. If a vehicle reaches a situation where a service needs to be shared with another vehicle, the vehicle 525 may engage with another vehicle 508 to perform various operations such as sharing, transmitting, obtaining a service request, etc. 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 package for delivery. A vehicle processor 528 resides in the vehicle 508 and there is communication between the vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 may notify another vehicle 525 that is in its network and operating on its blockchain member services. A vehicle processor 526 resides in the vehicle 525 and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The 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 can be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, can be on-board the vehicle, can be off-board the vehicle, and can be accessible directly and / or through a network.

[0139] FIG. 6A illustrates a blockchain architecture configuration 600, according to an example embodiment. With reference 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 those members who have permission to access the blockchain data, rather than all parties. Blockchain nodes are involved in a number of 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 (such as authentication) and attempt to write to the blockchain immutable ledger that is stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

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

[0141] FIG. 6B illustrates a shared ledger configuration, according to an exemplary embodiment. Referring to FIG. 6B, an 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 an 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 required by participants, maintain their state, control their assets, and receive external information. This may be deployed and installed as an entry by appending to the distributed ledger on all blockchain nodes.

[0142] 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 generation 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 to store transactions and smart contracts in the blockchain.

[0143] A blockchain platform may include various layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.) and an underlying physical computer infrastructure that may 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.

[0144] The blockchain architecture configuration 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 that are subject to changes, updates, etc. The smart contract itself may be used to identify authorization and access requirements and rules associated with the 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.

[0145] In smart contract executable code, smart contracts may be created via high-level application and programming languages ​​and then written into blocks in the blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated with the 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 the smart contract may trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of the smart contract may be automatically replicated throughout the decentralized network of blockchain peers via one or more consensus protocols.

[0146] 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 the 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 execution environment provided and then deleted once the data needed for the blockchain is identified.

[0147] The smart contract executable code may include a code interpretation of the smart contract along with additional functionality. As described herein, the smart contract executable code may be program code deployed on a computation network, which together are executed and verified by a chain validator during a consensus process. The smart contract executable code receives the hash and retrieves from the blockchain a hash associated with a data template created 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 sends an authorization key to the requested service. The smart contract executable code may write data associated with the cryptographic details to the blockchain.

[0148] FIG. 6C illustrates a blockchain configuration that stores blockchain transaction data, according to an exemplary embodiment. With reference 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., 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 the 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, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, collection of sensor information, etc., that may be used to invoke a vehicle service event. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the vehicle's service status, event updates, etc. A transaction may include the parties involved, 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 services, rights / permissions, sensor data retrieved during vehicle event operations 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.

[0149] FIG. 6D shows the content of blockchain block 680 that can be added to the distributed ledger and block structures 682A-682n according to an exemplary embodiment. Referring to FIG. 6D, a client (not shown) can submit an entry to a blockchain node to perform activities on the blockchain. As an example, the client can be an application that functions on behalf of a requester such as a device, person, or entity to propose an entry to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. Various types of blockchain nodes / peers can exist within a blockchain network, including an approval peer that simulates and approves an entry proposed by a client, and a commit peer that verifies an endorsement, validates an entry, and commits the entry to the distributed ledger. In this example, a blockchain node can perform the role of an endorser node, a committer node, or both.

[0150] 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, and each peer maintains its own copy of the distributed ledger for each channel of which it is a member. The blockchain is an entry log structured as hash-linked blocks, with each block containing a sequence of N entries. Blocks may include various components, such as those shown in FIG. 6D. Block combinations may be generated by appending a hash of the previous block's header in the block header of the current block. In this way, all entries in the blockchain are ordered and cryptographically combined, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because they are combined, 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) that supports append-only blockchain workloads.

[0151] The current state of the blockchain and distributed ledger may be stored in a state database, where the current state data represents the latest values ​​for all keys ever included 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 the smart contract executable code's interactions highly efficient, the latest values ​​of all keys are stored in the state database. The state database may contain an indexed view into the blockchain's entry log, so that 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.

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

[0153] The ordering service accepts approved entries, orders the entries into a block, and distributes the block to the committing peers. For example, the ordering service may start a new block when a threshold 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, smart contracts, or 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 such that a specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

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

[0155] With reference to FIG. 6D, a block 682A (also referred to as a data block) stored on a blockchain and / or distributed ledger may include multiple data segments, such as block headers 684A-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 exemplary embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction specific data 686A that 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 header of the previous block. The block header 684A may also include a unique block number, a hash of the block data 690A of the current block 682A, and the like. The block numbers of the blocks 682A are unique and may be assigned in increasing / consecutive order starting from zero. The first block in a blockchain may be referred to as a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0156] 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: type of entry, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, path of the smart contract executable code (deployment transmission), name of the smart contract executable code, version of the smart contract executable code, inputs (smart contract executable code and functions), client (creator) identity such as public key and certificate, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code events, 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.

[0157] In some embodiments, the block data 690A may also store transaction-specific data 686A that adds additional information to the hash link chain of the block in the blockchain. Thus, the data 686A may be stored in an immutable log of the block in the distributed ledger. Some of the advantages of storing such data 686A are reflected in various embodiments disclosed and depicted herein. The 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. Meanwhile, the committer of the block (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.

[0158] 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 header of the previous block, or 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 file), as shown by arrow 692, to establish an auditable and immutable chain of custody.

[0159] 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 be present in a random access memory ("RAM"), a flash memory, a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM"), an electrically erasable programmable read-only memory ("EEPROM"), a register, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0160] 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 illustrates an exemplary computer system architecture 700 that may represent or be integrated into any of the components described above.

[0161] 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 computing node 700 may still implement and / or perform any of the functions described herein above.

[0162] Within computing node 700 is a computer system / server 702 that 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.

[0163] The computer system / server 702 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 702 may be executed 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.

[0164] 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.

[0165] 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 without limitation, an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0166] 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 to read from and write to a non-removable, non-volatile magnetic medium (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 and writes to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such a case, 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) of program modules configured to perform the functions of various embodiments of the present application.

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

[0168] As will be appreciated by one of ordinary skill 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.

[0169] 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, pointing device, display, 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., network card, modem, etc.) that allows the computer system / server 702 to communicate with one or more other computing devices. Such communication may occur through an I / O interface of the device 712. Furthermore, the computer system / server 702 may communicate with one or more networks, such as a local area network (LAN), a general wide network (WAN), and / or a public network (e.g., the Internet), via a network adapter. As depicted, the device 712 communicates with other components of the computer system / server 702 via a bus. It is understood that other hardware and / or software components, not shown, may be used with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0170] Preferred embodiments of at least one of a system, a method, and a non-transitory computer-readable medium are shown in the accompanying drawings and described in the foregoing detailed description, but the present application is not limited to the disclosed embodiments, and it will be understood that many rearrangements, modifications, and substitutions are possible as defined by the following claims. For example, the functions of the systems of the various figures may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include a transmitter, a receiver, or a pair thereof. For example, all or part of the functions performed by individual modules may be performed by one or more of these modules. Further, the functions described herein may be performed at various times in connection with various events internal or external to the modules or components. Also, the 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 a plurality of protocols. Also, messages transmitted or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0171] Those skilled in the art will understand that "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 a combination of devices. Presenting the functions described above as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide an example of one of a number of embodiments. Indeed, the methods, systems, and devices disclosed herein may be implemented in a local and distributed form consistent with computing technology.

[0172] 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, or 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.

[0173] 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 as, for example, 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, a module 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.

[0174] 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 in different locations, including different storage devices, and may exist at least in part as merely electronic signals over a system or network.

[0175] 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, and 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.

[0176] Those skilled in the art will readily appreciate that the above 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.

[0177] 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 to the appended claims (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. determining locations within the area that may lose electricity during a grid-related event; conserving energy through reduced energy consumption at said location; storing the retained energy in an energy storage device at the location; using the stored energy at the location when the event occurs; and A method comprising:

2. 10. The method of claim 1, wherein the energy storage device is a vehicle, and the vehicle is moved to another location having a demand greater than a threshold to provide the stored energy.

3. Reducing energy consumption at the location includes: determining a first device at the location that is needed to support residence at the location; determining a second device at the location that is not required to support residence at the location; and not providing electricity to the second device during the event; and The method of claim 1 , comprising:

4. determining that storing the retained energy in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device; identifying a vehicle having sufficient charge to fully charge the energy storage device; requesting the vehicle to fully charge the energy storage device; The method of claim 1 , comprising:

5. Using the stored energy at the location when the event occurs determining energy consumption at the location prior to the event; using less than the determined energy consumption at the location during the event; and The method of claim 1 , comprising:

6. determining that the retained energy is sufficient to fully charge the energy storage device; determining a retained excess of energy; providing a surplus of said stored energy for charging a vehicle; and The method of claim 1 , comprising:

7. determining that the event begins before the energy storage device is charged to a threshold; and preventing energy consumption at said location; transmitting the stored energy from the energy storage device to a vehicle; and The method of claim 1 , comprising:

8. A processor; a memory, coupled to the processor, comprising instructions; the instructions, when executed by the processor, determining locations within the area that may lose electricity during a grid-related event; conserving energy through reduced energy consumption at said location; storing the retained energy in an energy storage device at the location; using the stored energy at the location when the event occurs; The system is configured as follows:

9. 10. The system of claim 8, wherein the energy storage device is a vehicle, and the vehicle is moved to another location having a demand greater than a threshold to provide the stored energy.

10. The reduction in energy consumption at the location includes: determining a first device at the location that is required to support residence at the location; determining a second device at the location that is not required to support residence at the location; not providing electricity to the second device while the event occurs; The system of claim 8 , comprising the instructions configured to:

11. The instruction: determining that the retained energy stored in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device; identifying a vehicle having sufficient charge to fully charge the energy storage device; requesting the vehicle to fully charge the energy storage device; The system of claim 8 , configured to:

12. The processor configured to use the stored energy at the location when the event occurs, determining energy consumption at the location prior to the event; using less than the determined energy consumption at the location while the event occurs. The system of claim 8 , comprising the instructions configured to:

13. The instruction: determining that the retained energy is sufficient to fully charge the energy storage device; determining the amount of excess energy retained; providing a surplus of said stored energy for charging a vehicle; The system of claim 8 , configured to:

14. The instruction: determining that the event begins before the energy storage device is charged to a threshold; Preventing energy consumption at said location; transmitting the stored energy from the energy storage device to a vehicle; The system of claim 8 , configured to:

15. 1. A computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to: determining locations within the area that may lose electricity during a grid-related event; conserving energy through reduced energy consumption at said location; storing the retained energy in an energy storage device at the location; using the stored energy at the location when the event occurs; and A computer-readable storage medium for causing a computer to perform the above steps.

16. 20. The computer-readable storage medium of claim 15, wherein the energy storage device is a vehicle, and the vehicle is moved to another location having a demand greater than a threshold to provide the stored energy.

17. The instructions direct the processor to: determining a first device at the location that is needed to support residence at the location; determining a second device at the location that is not required to support residence at the location; and not providing electricity to the second device during the event; and The computer-readable storage medium of claim 15 , further comprising:

18. The instructions direct the processor to: determining that storing the retained energy in the energy storage device from a current time to a predicted start time of the event is insufficient to fully charge the energy storage device; identifying a vehicle having sufficient charge to fully charge the energy storage device; requesting the vehicle to fully charge the energy storage device; The computer-readable storage medium of claim 15 .

19. The instructions direct the processor to: determining energy consumption at the location prior to the event; using less than the determined energy consumption at the location during the event; and 20. The computer-readable storage medium of claim 15, further comprising:

20. The instructions direct the processor to: determining that the retained energy is sufficient to fully charge the energy storage device; determining a retained excess of energy; providing a surplus of said stored energy for charging a vehicle; and The computer-readable storage medium of claim 15 .

Images