Outage-aware electric vehicle battery charging

Abstract

To charge the optimal charge to a vehicle when an outage is predicted.SOLUTION: An example operation includes one or more of: determining, by a vehicle, a severity and a length related to a predicted outage at a certain location; determining, by the vehicle, an optimal charge of a battery of the vehicle prior to the predicted outage, in which the optimal charge is based on the severity and the length; comparing, by the vehicle, a current charge of the vehicle to the optimal charge; and charging, by the vehicle, the battery to the optimal charge when the current charge is below the optimal charge.SELECTED DRAWING: Figure 1A

Description

Background Art

[0001] Generally, vehicles and conveyances such as cars, motorcycles, trucks, airplanes, trains, etc. satisfy the transportation needs of passengers and / or goods in various ways. Various computing devices such as smartphones and computers installed inside or outside the vehicle can identify and utilize vehicle-related functions.

Summary of the Invention

Means for Solving the Problems

[0002] One exemplary embodiment comprises a method including one or more of the following: determining, by a vehicle, the severity and duration associated with a predicted power outage at a location; determining, by the vehicle, an optimal charge level of a battery of the vehicle, determined by the severity and duration, prior to the predicted power outage; comparing, by the vehicle, a current charge level of the vehicle with the optimal charge level; and charging, by the vehicle, the battery to the optimal charge level when the current charge level is below the optimal charge level.

[0003] Another exemplary embodiment comprises a system comprising a memory communicatively connected to a processor, the processor executing one or more of the following: determining, by a vehicle, the severity and duration associated with a predicted power outage at a location; determining, by the vehicle, an optimal charge level of a battery of the vehicle, determined by the severity and duration, prior to the predicted power outage; comparing, by the vehicle, a current charge level of the vehicle's battery with the optimal charge level; and charging, by the vehicle, the battery to the optimal charge level when the current charge level is below the optimal charge level.

[0004] Further exemplary embodiments include a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following processes: determining, by a vehicle, a severity and a length associated with a predicted power outage at a location; determining, by the vehicle, an optimal charge level of a battery of the vehicle based on the severity and the length before the predicted power outage; comparing, by the vehicle, a current charge level of the battery with the optimal charge level; and charging, by the vehicle, the battery to the optimal charge level when the current charge level is lower than the optimal charge level. BRIEF DESCRIPTION OF THE DRAWINGS

[0005]

Figure 1A

[0006]

Figure 1B

[0007]

Figure 2A

[0008]

Figure 2B

[0009]

Figure 2C

[0010]

Figure 2D

[0011]

Figure 2E

[0012]

Figure 2F

[0013]

Figure 3A

[0014]

Figure 3B

[0015]

Figure 3C

[0016]

Figure 3D

[0017]

Figure 3E

[0018]

Figure 4A

[0019]

Figure 4B

[0020]

Figure 4C

[0021]

Figure 4D

[0022]

Figure 4E

[0023]

Figure 5A

[0024]

Figure 5B

[0025]

Figure 5C

[0026]

Figure 5D

[0027]

Figure 5E

[0028]

Figure 5F

[0029]

Figure 6

DETAILED DESCRIPTION OF THE INVENTION

[0030] As will be readily understood, as shown throughout the drawings of the present application, the present component may be arranged and designed in various configurations. Therefore, it is not intended to limit the claims of the present application by the following detailed description of at least one embodiment of a method, apparatus, computer-readable storage medium, and system as shown in the accompanying drawings. This description is merely representative of the selected embodiments. It is not intended to limit the scope of the solutions by the multiple embodiments shown herein. The computer-readable storage medium may be either a non-transitory computer-readable medium or a non-transitory computer-readable storage medium.

[0031] Communication between a vehicle and certain entities such as a remote server, other vehicles, and local computing devices (such as smartphones, personal computers, in-vehicle computers, etc.) may be transmitted and processed by one or more "components". The component may be hardware, firmware, software, or a combination thereof, and may be part of the above entities or computing devices, or some other computing device. In one example, a consensus decision related to a blockchain transaction may be made by one or more computing devices or components (which may be any of the elements described and / or shown herein) associated with the vehicle, and one or more components located outside or away from the vehicle.

[0032] In one or more embodiments, the functions, structures, or characteristics described herein may be combined in any suitable manner. For example, throughout this specification, the use of "exemplary embodiments", "an embodiment", or other similar expressions indicates that the specific functions, structures, or characteristics described in connection with the embodiments may be included in one or more examples. Thus, throughout this specification, when expressions such as "exemplary embodiments", "in an embodiment", "in other embodiments", or other similar expressions appear, they may all refer to the same embodiment. Therefore, these embodiments can function in relation to other embodiments, cannot be functionally separated, and in one or more embodiments, the described functions, structures, or characteristics may be combined in any suitable manner. In the figures, whether illustrated by single-headed or double-headed arrows, one-way and / or two-way communication is possible through element connections. In this solution, the vehicle may include one or more of the following: cars, trucks, internal combustion engine (ICE) vehicles, battery electric vehicles (BEV), e-pallets, fuel cell buses, motorcycles, scooters, bicycles, boats, campers, airplanes, drones, unmanned aerial vehicles (UAV), and anything that can be used to transport people and / or goods from one place to another.

[0033] Also, in the description of the embodiments, other types of network data such as packets, frames, datagrams, etc. may be used, where the term "message" may sometimes be used. Further, in the exemplary embodiments, certain types of messages and signaling methods may be shown, but are not limited to these certain types of messages and signaling methods.

[0034] An exemplary embodiment provides a method, system, component, non-transitory computer-readable medium, device, and / or network that includes at least one of a transporter (also referred to herein as a vehicle or car), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. By processing vehicle status data received in the form of communication messages such as wireless data network communications and / or wired communication messages, the vehicle status can be identified and feedback regarding the conditions and / or changes of the vehicle can be provided. In one example, by applying a user profile to a particular vehicle, current vehicle events can be authorized, service at a service station can be stopped and subsequent vehicle rental services can be authorized, and vehicle-to-vehicle communication can be enabled.

[0035] Within a communication infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. A blockchain is an example of a decentralized database and includes an append-only and immutable data structure (i.e., a distributed ledger) that enables the maintenance of records among untrusted parties. Here, untrusted parties are referred to as peers, nodes, or peer nodes. Since each peer maintains a copy of the database records, a single peer cannot change the database records without reaching an agreement among the distributed peers. For example, a peer can verify blockchain storage inputs by executing a consensus protocol, group these storage inputs into blocks, and construct a hash chain through the blocks. Through this process, a ledger is formed by ordering the storage inputs for consistency as needed. Public or permissionless blockchains are, in particular, unauthenticated and can be participated in by anyone. Public blockchains can be involved in cryptocurrencies and can use consensus based on various protocols such as proof-of-work (PoW). In contrast, in a permissioned blockchain database, interactions among groups of entities that have the same goals but do not fully trust or cannot fully trust each other, such as businesses that exchange funds, goods, information, etc., can be protected. This solution can function in a permissioned and / or permissionless blockchain setting.

[0036] A smart contract is a reliable distributed application that leverages the immutability of a shared or distributed ledger (which may be in the form of a blockchain) and the basic agreement among member nodes called an endorsement or endorsement policy. Generally, blockchain inputs are endorsed before being committed to the blockchain, while unendorsed inputs are ignored. A typical endorsement policy enables the specification, in the form of a set of peer nodes, required for an endorser to endorse an input by smart contract executable code. When a client sends an input to a peer specified by the endorsement policy, the input is executed and verified. After verification, the input enters the ordering stage. At this stage, an ordered sequence of endorsed inputs grouped into blocks is generated by a consensus protocol.

[0037] A node is a communication entity in a blockchain system. A "node" is capable of performing a logical function in the sense that multiple different types of nodes can be executed on the same physical server. Nodes are grouped within a trust domain and associated with logical entities that control them in various ways. There may be various types of nodes. For example, a client or presenting client node that presents an input call to an endorser (such as a peer) and broadcasts an input proposal to an ordering service (such as an ordering node). Another type of node is a peer node. A peer node can receive and commit an input submitted by a client and maintain the state and replication of the blockchain input ledger. A peer can also act as an endorser. An ordering service node or orderer is a node that executes a communication service for all nodes and implements delivery guarantees such as broadcasting to each peer node in the system when committing a blockchain input and changing its world state. The world state can typically constitute the initial blockchain input including control and setup information.

[0038] A ledger is a tamper-resistant record in which all state transactions of a blockchain are arranged. State transactions may result from smart contract executable code calls (i.e., inputs) presented by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). The input may be a set of asset key / value pairs committed to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a blockchain (also called a chain) that stores immutable records arranged in blocks within the blocks, and a state database that maintains the current state of the blockchain. Typically, there is one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which it is a member.

[0039] The chain is an input log composed of hash-linked blocks, and each block contains an array of N inputs (N is 1 or more). The block header contains the hash of the block's inputs and the hash of the header of the previous block. In this way, it is possible to arrange all the inputs on the ledger and cryptographically link them to each other. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents all the previous inputs on the chain, making it possible to ensure that all peer nodes are in a consistent and reliable state. The chain may be stored in a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the additional dedicated nature of the blockchain workload.

[0040] The current state of the immutable ledger represents the latest values of all keys included in the chain input log. Since the current state represents the latest values of keys known to the channel, it may be referred to as the world state. Inputs are executed against the current state data of the ledger by smart contract executable code calls. To efficiently facilitate the interaction of this smart contract executable code, the latest values of keys may be stored in a state database. The state database may simply be an indexed view into the chain's input log and can thus be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) when a peer node starts up or before an input is received.

[0041] A blockchain differs from traditional databases in the following ways: it is a decentralized and immutable secure storage rather than a central storage, where changes to records must be shared among nodes. Characteristics unique to the blockchain and facilitating its implementation include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc.

[0042] Exemplary embodiments provide services to a particular vehicle and / or a user profile applicable to this vehicle. For example, the user may be the owner of the vehicle or an operator of a vehicle owned by another party. The vehicle may request services at certain intervals, and the service demand side may request authorization before permitting the receipt of services. Also, the service center can provide services to nearby vehicles based on the vehicle's current route plan and the relative level of service requirements (e.g., urgent, critical, normal, minor, etc.). Vehicle demand may be monitored via one or more vehicle and / or road sensors or cameras that report data sensed within and / or away from the vehicle to a central control computer device. This data is transferred to a management server for review and action. The sensors may be disposed on one or more of the inside of the vehicle, the outside of the vehicle, on a fixture away from the vehicle, or on another vehicle proximate to the vehicle. Also, the sensors may be associated with the vehicle's speed, brakes and acceleration, fuel level, service demand, gear shifting and steering of the vehicle, etc. As described herein, the sensors may be devices such as wireless devices within and / or proximate to the vehicle. Also, for example, sensor information may be used to identify whether the vehicle is operating safely and whether the occupants are involved in any unexpected vehicle situations during vehicle access and / or during the usage period. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in a transaction on a shared / distributed ledger. This may be committed to an immutable ledger determined by a consortium that grants permissions, such as in the case of being generated and passed through a blockchain membership group, and thus in a "decentralized" format.

[0043] Each party (i.e., owner, user, company, agency, etc.) may wish to limit the exposure of private information, and for that reason, the blockchain and its immutability can be used to manage permissions for each specific user vehicle profile. Smart contracts may be used for providing compensation, quantifying user profile scores / ratings / reviews, applying vehicle event permissions, determining when services are needed, identifying collision and / or degradation events, identifying safety concern events, identifying event participants, and providing distribution to registered entities requesting access to such vehicle event data. Also, results may be identified and the necessary information can be shared among registered companies and / or individuals based on a consensus method associated with the blockchain. Such a method is not implemented in a conventional centralized database.

[0044] The various driving systems of this solution can create maps of the terrain and roads that a vehicle can use for navigation and other purposes, using machine learning functionality, optical sensing / ranging (lidar) projectors, radar, ultrasonic sensors, etc., as well as software and sensor arrays. In one embodiment, in an autonomous vehicle, GPS, maps, cameras, sensors, etc. may be used instead of lidar.

[0045] In certain embodiments, the solution includes authorizing a vehicle for a service via an automated and fast authentication scheme. For example, driving to a charging station or fuel pump may be performed by a vehicle operator or an autonomous vehicle, and authorization to receive charging or fuel can be done without delay if received by the service and / or the charging station. The vehicle can provide a communication signal that provides an identification of the vehicle having an active profile linked to an account authorized to receive the service, which can be corrected later by compensation. Additional means can be used to provide further authentication. For example, another identifier can be wirelessly sent 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).

[0046] Shared and received data may be stored in a database (e.g., a database server) where data is generally maintained in one specific location within a single database. This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Typically, the information stored in a centralized database is accessible from multiple other points. Since a centralized database is in one location, it is easy to manage, maintain, and control, especially for security purposes. Within a centralized database, the fact that all data is stored in a single location also means that data redundancy is minimized because a particular dataset has only one primary record. A blockchain may be used to store data and transactions associated with the vehicle.

[0047] The actions described herein may be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), head units, etc.) that may be mounted on or not mounted on a vehicle, with or without memory (such as a server, computer, mobile / wireless device, etc.). The one or more processors may communicate with other memories and / or other processors that may be mounted on or not mounted on other vehicles and utilize data transmitted by and / or to the vehicle. The one or more processors and the other processors may transmit and receive data and utilize it to perform one or more of the actions described or shown herein.

[0048] Figure 1A shows a diagram of system 100 in some embodiments. In certain embodiments, the solution is executed in whole or in part within the memory of the server 103, the memory 110 of the processor 111 associated with the first vehicle 102, the memory 115 of the processor 116 associated with the second vehicle 106, or the memory of one or more other processors associated with the devices and / or entities mentioned herein. In certain embodiments, one or more of the server 103, the processor 111, and the processor 116 may comprise a microcontroller including one or more central processing unit (CPU) cores, program memory, and program-controllable input / output peripherals. The program memory may be provided, for example, in the form of flash memory.

[0049] In one embodiment, the processor 111 of the first vehicle 102 determines the severity and duration associated with a predicted power outage at a location. For example, the processor 111 may communicate with the weather condition server 134 via the network 104. Here, the server 134 is operably coupled to the weather database 135. Alternatively or additionally, the processor 111 may communicate with the power distribution network server 125 via the network 104. Here, the power distribution network server 125 is operably coupled to the power distribution network server database. The weather condition server 134 and / or the power distribution network server 125 can transmit information to the processor 111 related to an actual or predicted power outage of the power distribution network 123.

[0050] In one example, the predicted power outage may be a voltage drop with a partial loss of power to location 108, or a complete power outage with a total loss of power to location 108. The predicted power outage at location 108 can be predicted based on one or more of the predicted temperature at location 108, the predicted severe weather conditions at location 108, the current or predicted status of the power distribution network 123 covering location 108, and historical data regarding past power outages. In a further example, the power outage can be predicted based on disruptions in the flow of alternative energy sources such as natural gas, wind, solar energy, etc. In another example, the weather condition server 134 and the power distribution network server 125 may not have information regarding the severity and / or duration of the predicted power outage for transmission to the processor 111.

[0051] In one embodiment, the processor 111 of the first vehicle 102 determines the optimal state of charge (SoC) of the battery 113 of the first vehicle 102 prior to a predicted power outage. Here, the optimal SoC is based on the severity and duration of the predicted power outage. For example, the optimal SoC can be based on maximizing the amount of time that the first vehicle 102 can be used to supply power to location 108 if the predicted power outage occurs. Location 108 may be a residential, commercial, or other type of structure.

[0052] Conventional electric vehicles do not continuously monitor the possibility of power outages. Therefore, when a power outage occurs and the SoC of the electric vehicle is low, the amount of time the electric vehicle can supply power to location 108 will be shorter than the amount of time it could have supplied power to location 108 if the SoC of the electric vehicle were high.

[0053] In one embodiment, the processor 111 compares the current SoC of the battery 113 with the optimal SoC. For example, the processor 111 can monitor the battery management system 112 of the first vehicle 102 and determine the current SoC of the battery 113.

[0054] The processor 111 can determine the optimal SoC corresponding to the probability of a predicted power outage occurring, the severity of the predicted power outage, and the length of the predicted power outage. If the current SoC is less than the optimal value, the processor 111 can instruct the battery management system 112 of the first vehicle 102 to charge the battery 113 to the optimal SoC. For example, the battery 113 of the first vehicle 102 can be charged by the bi-directional charging station 119 located at location 108. The bi-directional charging station 119 may include an inverter circuit that converts the direct current from the battery 113 into alternating current for supplying to the smart electrical panel 131 at location 108.

[0055] In a further example, the processor 111 sends a notification to the infotainment system 151 of the first vehicle 102, instructing the operator of the first vehicle 102 to connect the first vehicle 102 to the bi-directional charging station 119. In another example, the processor 111 sends a notification via the network 104 to the mobile device 137 associated with the user of the first vehicle 102. This notification can instruct the user of the first vehicle 102 to connect the first vehicle 102 to the bi-directional charging station 119.

[0056] In one embodiment, the processor 111 updates the severity and duration associated with the predicted power outage and provides at least a portion of the optimal SoC of the battery 113 to location 108 based on the updated severity and duration. For example, the processor 111 can communicate with the weather condition server 134 via the network 104 to obtain updated information related to changing weather conditions. When the weather conditions deteriorate, the processor 111 can increase the optimal SoC of the battery 113. If the weather conditions are improving, the processor 111 can decrease the optimal SoC of the battery 113. Alternatively or additionally, the processor 111 can communicate with the power grid server 125 via the network 104 to obtain updated information related to the state of the power grid 123. If the state of the power grid 123 suggests that damage to the power grid is increasing, the processor 111 can increase the optimal SoC of the battery 113.

[0057] If the state of the power grid 123 suggests that the power grid 123 is recovering from damage and / or that repairs to the power grid 123 have been made, the processor 111 can decrease the optimal SoC of the battery 113.

[0058] In one embodiment, for a predicted power outage, the optimal SoC is provided from the battery 113 to location 108. For example, the processor 111 can monitor the power grid server 125 via the network 104 and determine that a predicted power outage has occurred at location 108.

[0059] Alternatively or additionally, when the first vehicle 102 is connected to the bi - directional charging station 119, the processor 111 may monitor the bi - directional charging station 119 and confirm whether the bi - directional charging station 119 is receiving power from the power distribution network 123. During a predicted power outage, the battery 113 may supply power to location 108 through the bi - directional charging station 119. As described above, the bi - directional charging station 119 may include a power conversion circuit that converts the direct current from the battery 113 into alternating current that can be used to supply power to the smart electrical panel 131 at location 108. The smart electrical panel 131 can supply power to at least one of the electrical consumption devices 133, including household appliances, lighting equipment, heating, ventilation, and air conditioning (HVAC) systems, entertainment devices, computing devices, and other power - consuming devices. In a further example, in response to a predicted power outage, the processor 111 may send a notification to the infotainment system 151 of the first vehicle 102. This notification can be used to instruct the operator of the first vehicle 102 to connect the first vehicle 102 to the bi - directional charging station 119. In another example, in response to a predicted power outage, the processor 111 may send a notification via the network 104 to the portable device 137 associated with the user of the first vehicle 102. This notification can be used to instruct the user of the first vehicle 102 to connect the first vehicle to the bi - directional charging station 119.

[0060] In certain embodiments, the processor 111 determines to change at least one of the severity and duration of a predicted power outage. For example, the processor 111 may receive information from the weather condition server 134 indicating that the severity and / or duration of a predicted power outage is increasing due to rapidly deteriorating weather conditions.

[0061] When at least one of the predicted severity and duration of the power outage increases, the processor 111 instructs the first vehicle 102 to increase the amount of charge from the battery 113 to the location 108 via the bi - directional charging station 119. Alternatively or in addition, the location 108 includes the second vehicle 106. For example, the processor 116 of the second vehicle 106 can receive information from the weather condition server 134 indicating that the predicted severity and / or duration of the power outage has increased due to rapidly deteriorating weather conditions. When at least one of the predicted severity and duration of the power outage increases, the processor 116 instructs the second vehicle 106 to increase the amount of charge from the battery 118 of the second vehicle 106 to the location 108 via the bi - directional charging station 119. The battery 118 is operably connected to the battery management system 117 of the second vehicle 106. Or, the location 108 includes the on - site energy storage device 107, the battery pack 109 managed by the battery management system 114, and the processor 129 operably connected to the battery management system 114 and the network 104. The processor 111 sends a command to the processor 129 via the network 104, instructing the on - site energy storage device 107 at the location 108 to increase the amount of charge to the smart electrical panel 131.

[0062] In one embodiment, the processor 111 determines the optimal SoC of the battery 113 based on the energy consumption at the location 108. This energy consumption may be based on, for example, the amount of energy required to operate one or more of the electrical consumption devices 133, such as a heating, ventilation, and air conditioning (HVAC) system, at the location 108, taking into account the predicted weather conditions during the power outage. Alternatively or in addition, the electrical consumption device 133 may include any of the lighting, household appliances, entertainment devices, security devices, computing devices, or medical devices at the location 108.

[0063] In one embodiment, in response to a location 108 that includes an energy storage device 107 within the site, the processor 111 transmits a command to the processor 129 of the energy storage device 107 within the site via the network 104. By this command, the energy storage device 107 within the site can be instructed to supply energy to the smart electrical panel 131 at the location 108 during a predicted power outage. While the energy storage device 107 within the site supplies energy to the location 108, the processor 111 can monitor the SoC of the energy storage device 107 within the site via the network 104 by communicating with the processor 129. When the SoC of the energy storage device 107 within the site approaches zero, the processor 111 instructs the first vehicle 102 to supply energy to the smart electrical panel 131 at the location 108.

[0064] In a further embodiment, while the first vehicle 102 supplies energy to the location 108, the processor 111 monitors the SoC of the first vehicle 102 using the battery management system 112. When the SoC of the first vehicle 102 approaches a threshold amount, the processor 111 transmits a command to the bi-directional charging station 119 and instructs the bi-directional charging station 119 to stop supplying energy from the first vehicle 102 to the smart electrical panel 131 at the location 108. The charging station 119 can respond to the above command by disabling its inverter circuit. Alternatively or additionally, the processor 111 can transmit a command to the smart electrical panel 131 and instruct the smart electrical panel 131 to stop supplying electricity to at least one of the electrical consumption devices 133 at the location 108. The threshold amount can be based on a first amount of energy required to drive one way from the location 108 to the nearest healthcare facility by vehicle, or can also be based on a second amount of energy required to drive to and from between the nearest healthcare facility and the location 108 by vehicle.

[0065] In one embodiment, in response to a location 108 that includes a second vehicle 106, the processor 111 sends a notification to the processor 116 via the network 104 and instructs the second vehicle 106 to supply energy to the bi-directional charging station 119 at the location 108 during a predicted power outage. While the second vehicle 106 supplies energy to the bi-directional charging station 119 at the location 108, the processor 111 can monitor the SoC of the second vehicle 106 by communicating with the processor 116 via the network 104. When the SoC of the second vehicle 106 approaches zero, the processor 111 can send a command to the processor 116 and instruct the second vehicle 106 to stop supplying energy to the bi-directional charging station 119. Alternatively or additionally, the processor 111 can send a command to the bi-directional charging station 119 and instruct the bi-directional charging station 119 to stop receiving electricity from the second vehicle 106. The processor 111 can instruct the first vehicle 102 to supply energy to the bi-directional charging station 119.

[0066] In a further embodiment, while the first vehicle 102 supplies energy to the location 108 through the bi-directional charging station 119 and the smart electrical panel 131, the processor 111 monitors the SoC of the first vehicle 102 using the battery management system 112. When the SoC of the first vehicle 102 approaches a threshold amount, the processor 111 issues a prompt asking for confirmation to stop supplying energy from the first vehicle 102 to the location 108. For example, this prompt can be displayed on the infotainment system 151, the mobile device 137, or both the mobile device 137 and the infotainment system 151.

[0067] The threshold amount can be based on a first amount of energy required to drive one-way from the location 108 to the nearest healthcare facility to the vehicle, or can be based on a second amount of energy required to drive round-trip between the nearest healthcare facility to the vehicle and the location 108.

[0068] In one embodiment, processor 111 updates the severity and duration associated with the predicted power outage during the predicted power outage. For example, processor 111 can communicate with weather condition server 134 via network 104 to obtain updated information related to the changing weather conditions. When the weather conditions deteriorate, processor 111 can send a command via network 104 and instruct smart electrical panel 131 to stop power supply to at least one of the electrical consumption devices 133 at location 108.

[0069] FIG. 1B shows a diagram of system 150 in some embodiments. In one embodiment, the solution is executed in whole or in part in the memory 105 of server 103 (FIG. 1A), the memory 110 of processor 111 associated with the first vehicle 102, the memory 115 of processor 116 associated with the second vehicle 106, or the memory of one or more other processors associated with the devices and / or entities mentioned herein. In one embodiment, one or more of server 103, processor 111, and processor 116 may comprise a microcontroller including one or more central processing unit (CPU) cores, program memory, and program controllable input / output peripheral devices. The program memory can be provided, for example, in the form of flash memory.

[0070] In block 152 of FIG. 1B, the processor functions as a monitor for critical weather conditions that could cause a power outage. For example, the processor can communicate with a weather condition server via a network to check if a critical weather event that could cause a power outage at a certain location is predicted. In block 154, a test is executed to check if the probability of a power outage is higher than a threshold. For example, the threshold can be expressed as a probability or a ratio and can represent the likelihood of a power outage occurring. If the probability of a power outage is not higher than the threshold, the program returns to block 152. The Yes branch exiting block 154 continues to block 156, where a test is performed to check if the first vehicle is parked. For example, the first vehicle can include a transmission lever sensor, a motion sensor, and / or a Global Positioning System (GPS) device that the processor can monitor to determine if the first vehicle is parked.

[0071] If the first vehicle is not parked, the program proceeds to block 160, where the processor determines that the first vehicle is in operation. Then, the program proceeds to at least one of blocks 162, 164, and 170. In block 162, the processor sends a notification to the infotainment system of the first vehicle. This notification proposes a more efficient route home to the first vehicle. In block 164, the processor sends a notification to the infotainment system of the first vehicle. This notification proposes one or more charging stations along the planned route of the first vehicle. In block 170, the processor sends a notification to the infotainment system associating each of a plurality of charging times with a corresponding predicted length of time during which the first vehicle can supply power to a location during a predicted power outage. In one example, the notifications in blocks 162, 164, and 170 may be provided to a mobile device associated with the user of the first vehicle in addition to or instead of providing the notification to the infotainment system.

[0072] The Yes branch that exits from block 156 indicating that the first vehicle is parked is followed by block 158. Here, a test is conducted to check whether the first vehicle is connected to the charging station. If not connected, the program proceeds to block 166 where the processor sends a notification to the mobile device associated with the user of the first vehicle. This notification proposes plugging in the first vehicle to the charging station. The Yes branch that exits from block 158 is followed by block 168 where the first vehicle is charged to a SoC corresponding to at least one of the severity and duration of the power outage at the location in order to supply power to at least one of the electrical consumption devices at the location during the power outage.

[0073] The flowcharts such as FIG. 1A, FIG. 1B, FIG. 2C, FIG. 2D, FIG. 2E, and FIG. 2F shown here are separate examples and may be of the same or different embodiments. Operations in one flowchart may be adopted and shared in another flowchart. There is no intention to limit the embodiments or the subject matter of the corresponding claims by the exemplary operations.

[0074] The flowcharts and corresponding processes derived from FIG. 1A, FIG. 1B, FIG. 2C, FIG. 2D, FIG. 2E, and FIG. 2F may all be part of the same process, may share sub - processes with each other, and thus, although this figure is not combined to require a specific operation, it is important to note that it is possible to consider them as a single preferred embodiment for performing certain operations based on the exemplary process and one or more additional processes. The exemplary processes are all related to the same physical system and can be used separately or interchangeably.

[0075] This solution can be used in connection with one or more of the following types of vehicles: battery - powered electric vehicles, hybrid vehicles, fuel - cell vehicles, internal - combustion engine vehicles, and / or vehicles that utilize renewable resources.

[0076] In one embodiment, the vehicle not only predicts power outages but also actively participates in stabilizing the power grid. When receiving the optimal charge amount, the vehicle can discharge surplus energy during peak demand back to the power grid to prevent power outages. This solution is executed in the processor of the vehicle and / or a remote server, using machine learning to analyze a number of factors including weather patterns, energy usage trends, and past power outage data to predict stress events in the power grid. If a predicted power outage is imminent, the vehicle drives to the nearest charging station capable of vehicle-to-grid (V2G) and charges or discharges the vehicle's battery as needed. The vehicle can communicate with the smart city infrastructure server to optimize energy distribution in the network. Real-time updates regarding the health of the power grid are provided on the vehicle's display, and actions such as deferring energy-intensive tasks until non-peak hours can be proposed.

[0077] In one embodiment, the vehicle is utilized as an emergency response vehicle. The vehicle can function as a mobile energy storage facility that can be deployed to critical areas such as hospitals and emergency shelters during a power outage. When predicting a major power outage, the emergency equipped vehicle calculates the optimal state of charge (SoC), automatically heads towards the designated emergency areas in need of power, and can cooperate with other emergency vehicles to ensure efficient energy distribution. This embodiment includes an advanced navigation system that proposes alternative routes to avoid areas affected by the power outage, such as through interaction with an external server (e.g., a server that provides information regarding routing, power outages, and traffic). Also, the vehicle can prompt the user to confirm or avoid changing the destination to an emergency area.

[0078] In one embodiment, the vehicle is integrated with a home energy management system and acts as a backup power source and an energy consumption optimization device. This solution can prepare for power outages by using predictive analytics to simultaneously manage home energy storage and vehicle battery charging. If a power outage is predicted, the vehicle adjusts its charging schedule to establish an optimal energy balance between the home and the vehicle. This solution is executed by the vehicle's processor and can initiate energy-saving measures within the home, such as lowering the thermostat setting or stopping household appliances that are not absolutely necessary, to extend the vehicle's power supply. This function may be remotely executed when the vehicle is connected to the home and / or when the vehicle communicates with a server within the home.

[0079] In one embodiment, referring to FIG. 1A, vehicle 102 is integrated with an advanced system that performs a series of operations and is considered to manage energy resources during a predicted power outage. This vehicle includes an advanced processor 111 that is accessible via network 104 to various data sources (including, but not limited to) weather condition server 134 and power distribution network server 125. By analyzing data on critical weather conditions and the integrity of the power distribution network, processor 111 calculates the severity and predicted duration of a predicted power outage at a specific location 108. This calculation is important to establish the preparation steps the vehicle needs to take.

[0080] Once the prediction is calculated, processor 111, in conjunction with battery management system 112, evaluates the optimal battery charge level required to maintain essential functions during the predicted power outage at location 108. This optimal charge level takes into account the predicted severity and duration of the power outage, along with the expected energy consumption demand at location 108, which may include energy demands related to residences, businesses, and other infrastructure.

[0081] The vehicle's processor 111 continuously monitors the current SoC of the vehicle's battery 113 to ensure readiness. If the current SoC falls below the calculated optimal level, the processor 111 initiates the charging protocol and instructs the battery management system 112 to charge the battery 113 to the optimal SoC. The charging process can be simplified through a bi-directional charging station 119 that can charge the vehicle in the event of a predicted power outage and supply power back to location 108.

[0082] The vehicle's system includes an infotainment system 151 and the user's mobile device 137 and is engaged in notifying the user of the vehicle's charge status and other necessary actions. Through the notification, the user is prompted to connect the vehicle to the charging station 119, which can ensure the vehicle's battery 113 reaches and maintains the optimal SoC in anticipation of a predicted power outage.

[0083] In one embodiment, referring to FIG. 1A, the solution continuously monitors various data sources, including real-time weather conditions obtained from a weather condition server 134 via a network 104 and information regarding the status of the power distribution network from a power distribution network server 125. This monitoring is performed by the vehicle's processor (e.g., processor 111). Based on the severity and expected length of the event, if the processor determines that a predicted power outage has transitioned into an actual power outage, this determination triggers a series of actions.

[0084] One of the important components in this process is the vehicle's battery 113. The processor calculates the optimal charge state for this battery. The State-of-Charge is an important parameter that determines how long the vehicle can supply power to location 108 during a predicted power outage. The optimal SoC is calculated based on the severity and expected duration of the predicted power outage.

[0085] Once the processor confirms that the predicted power outage has actually occurred, it can send a notification to a processor such as the vehicle's infotainment system 151. This notification functions as a warning to the vehicle operator and instructs the vehicle to connect to the bidirectional charging station 119 located at the designated location. At the same time, the processor communicates with the vehicle's battery management system 112 and begins to discharge an optimal amount of charge stored in the vehicle's battery. This process enables the vehicle's battery to supply power to the location when it is charged to the optimal level and needed.

[0086] To increase user involvement and communication redundancy, the processor also sends a notification to a device associated with the user, such as the user's mobile device 137, via the network 104. By repeating this second notification's command to connect the vehicle to the bidirectional charging station 119, it ensures that the user can quickly become aware of the situation and take the necessary actions.

[0087] In one embodiment, referring to FIG. 1A, the vehicle's processor (e.g., processor 111) acts as a central decision-making entity and continuously monitors important data sources. These data sources include real-time weather conditions obtained through the weather condition server 134 via the network 104 and the latest information regarding the status of the power distribution network from the power distribution network server 125.

[0088] The processor detects a change in the severity or duration of the expected power outage. This change can be indicated by new data received from the weather condition server or the power distribution network server. For example, if the weather condition server reports a rapidly deteriorating weather situation, the processor interprets this as an increase in the severity and expected duration of the predicted power outage.

[0089] When it is expected that the predicted severity or duration of a power outage is likely to increase, the processor begins to actively add charge from the vehicle's battery 113 to a location. By communicating with a bi-directional charging station 119 equipped with an inverter circuit, the direct current of the vehicle can be easily converted into an alternating current suitable for powering a smart electrical panel 131 at the location. This ensures that the electrical consumption device continues to function seamlessly despite an increase in the severity or duration of the power outage.

[0090] In one embodiment, referring to FIG. 1A, a vehicle processor 111 monitors a plurality of data sources related to the prediction and success of power outage handling. These sources include real-time weather conditions obtained from a weather condition server 134 via a network 104 and the latest status of the power distribution network obtained from a power distribution network server 125.

[0091] Based on the comprehensive understanding of the energy demand during a power outage at a location as described above, the processor proceeds to calculate the optimal SoC for the vehicle's battery 113. This optimal charge level is an accurate and dynamic value, and is intricately adjusted to ensure power supply to the electrical consumption devices of the battery for the entire expected duration of the predicted power outage. This calculation takes into account multiple variables such as the energy demand of the device, weather conditions that have a significant impact on power consumption, and the expected length of the predicted power outage. According to this embodiment, it is ensured that the vehicle's battery is maintained at the accurate charge level necessary to supply power continuously throughout the predicted power outage without being overcharged or undercharged.

[0092] In one embodiment, referring to FIG. 1A, a vehicle, a location equipped with an electric consumption device 133 and a smart electric panel 131, an energy storage device 107 within the site, a battery pack 109 managed by a battery management system 114, and a network infrastructure are integrated to support the storage devices within the site. The processor 111 of the vehicle monitors an array of data sources. This source includes real-time weather conditions obtained from a weather condition server 134 via a network 104 and the dynamic state of the power distribution network from a power distribution network server 125. This data source provides important inputs that enable the processor to predict the severity and expected duration of an impending power outage at location 108.

[0093] This solution not only anticipates an upcoming power outage but also detects the presence of an energy storage device within the site at the location. This device is efficiently managed by a battery management system 114, functions as a storage place for the stored energy, and becomes available for use during a power outage. This system instructs the energy storage device within the site to supply energy to the smart electric panel, ensuring continuous power reception for the power consumption device. This seamless energy transfer is coordinated via the communication channel of the network 104. The processor issues commands to the storage devices within the site to facilitate the flow of energy to essential systems at the location. While the location is kept in a state where it can be used by the energy storage device within the site, the processor monitors the SoC of this device. Through ongoing communication with the battery management system 114, the energy level of this on-site storage is continuously monitored. This real-time monitoring ensures that the system always reliably recognizes the available energy storage.

[0094] When the SoC approaches a lower limit indicating that the on-site energy storage is about to run out, the system initiates a secondary response. The system instructs the vehicle to supply additional energy to the location. This transition is facilitated through the bi-directional charging station 119, a central component in the system's architecture. The processor communicates with the charging station and instructs it to convert the vehicle's direct current into the alternating current necessary to power the smart electrical panel.

[0095] In one embodiment, referring to FIG. 1A, the solution utilizes energy from additional vehicles to further enhance the resilience of energy during a power outage. The processor 111 of the first vehicle monitors important data sources. These sources include real-time weather conditions obtained from the weather condition server 134 via the network 104 and the dynamic state of the power distribution network extracted from the power distribution network server 125. This data source provides essential inputs for predicting the severity and expected duration of a possible power outage at location 108.

[0096] The processor anticipates an impending power outage at a location and detects the presence of another vehicle 106. This second vehicle is equipped with a battery 118 and is managed by a battery management system 117. The system begins by instructing the second vehicle to supply energy during the power outage at the location. The processor communicates with the battery management system 117 of the second vehicle through the network 104 and issues a command to cause the second vehicle to supply energy to the smart electrical panel 131 at the location. This ensures that the electrical consumption devices continue to receive power and the functionality of the location is maintained. The processor maintains continuous monitoring of the state of charge (SoC) of the battery of the second vehicle. Through real-time communication with the battery management system 117, the processor remains aware of the energy level of the second vehicle. When the SoC approaches a lower limit indicating that the energy storage of the second vehicle is likely to be depleted, the system takes preemptive measures. This includes issuing a command to the second vehicle to stop supplying energy to the location. This decision is efficiently communicated through the network 104 to ensure immediate communication between components. The second vehicle follows the command while securing its own energy storage in preparation for potential mobility needs under the guidance of its battery management system.

[0097] In one embodiment, the ability of a system to respond to changing power outage situations by updating severity and duration information and optimizing power supply is described. Referring to FIG. 1A, the processor 111 actively monitors important data sources. This source includes real-time weather conditions obtained from a weather conditions server via the network 104 and the dynamic state of the power distribution network obtained from a power distribution network server. When the processor detects a deteriorating situation through continuous communication with the weather conditions server and the power distribution network server, it begins to update the predicted power outage information. For example, if the weather conditions server reports rapidly deteriorating weather conditions, or if the power distribution network server notifies that the damage to the power distribution network is expanding, the processor immediately increases the severity and duration of the power outage. This updated information serves as a basis for optimizing the power supply during the power outage to match the real-time situation. The processor calculates the optimal SoC of the vehicle's battery 113 based on the revised severity and duration of the power outage. This calculation ensures flexible and maximum energy utilization by the system while keeping up with the evolving situation.

[0098] The processor takes means to maintain the vehicle's battery at an optimal energy level in response to the updated severity and duration information. Since the processor can charge the vehicle's battery to the newly calculated optimal SoC, it ensures seamless power supply preparation by the system during the evolving power outage.

[0099] Figure 2A shows a vehicle network diagram 200 according to an exemplary embodiment. This network includes 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 devices, sensors, and other elements capable of providing communication. The communication between vehicles 202 and 202' can be performed directly, via a private and / or public network (not shown), or via other vehicles or elements including one or more of processors, memories, and software. Although each is illustrated as a single vehicle and processor, there may be multiple vehicles and processors. One or more of the uses, functions, processes, solutions, etc. described and / or shown herein may be utilized and / or provided by this element.

[0100] Figure 2B shows another vehicle network diagram 210 according to an exemplary embodiment. This network includes 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 devices, sensors, and other elements capable of providing communication. The communication between vehicles 202 and 202' can be performed directly, via a private and / or public network (not shown), or via other vehicles or elements including one or more of processors, memories, and software. The processors 204, 204' can further communicate with one or more elements 230 including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicles 222, computers 224, input / output (I / O) devices 226, and voice applications 228. The processors 204, 204' can further communicate with elements including one or more of processors, memories, and software.

[0101] Although each is illustrated as a single vehicle, processor, and element, there may be multiple vehicles, processors, and elements. Information or communication may occur from any of processors 204, 204', and element 230 to any other. For example, mobile phone 220 can provide information to processor 204, thereby causing vehicle 202 to initiate an action. Mobile phone 220 can further provide this information or additional information to processor 204', thereby causing vehicle 202' to initiate an action, and can further provide this information or additional information to mobile phone 220, vehicle 222, and / or computer 224. One or more of the uses, functions, processes, solutions, etc. described and / or shown herein may be utilized and / or provided by this element.

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

[0103] Processor 204 performs one or more of the following: determine by the vehicle the severity and duration associated with a predicted power outage at a location (244C); determine by the vehicle the optimal charge level of the vehicle's battery, based on the severity and duration, prior to the predicted power outage (246C); compare by the vehicle the current charge level of the vehicle's battery with the optimal charge level (248C); charge the battery to the optimal charge level by the vehicle when the current charge level is below the optimal charge level (250C).

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

[0105] Processor 204 performs one or more of the following: in response to a predicted power outage, provide an optimal charge amount from the battery to a location (244D); determine by the vehicle whether at least one of severity and duration changes, and in response to at least one of severity and duration increasing, provide an additional charge amount from the vehicle's battery to the location (245D); where determining the optimal charge amount of the vehicle's battery is associated with the energy consumption at the location (246D); if the location includes an in-site energy storage device, use the in-site energy storage device to supply energy to the location during the predicted power outage; monitor the charge state of the in-site energy storage device while the in-site energy storage device is supplying energy to the location; if the charge state of the in-site energy storage device is approaching zero, use the vehicle to supply energy to the location (247D); if the location includes another vehicle, use this other vehicle to supply energy to the location during the predicted power outage; monitor the charge state of this other vehicle while this other vehicle is supplying energy to the location; if the charge state of this other vehicle is approaching zero, use the vehicle to supply energy to the location (248D); update by the vehicle the severity and duration associated with the predicted power outage during the predicted power outage; if at least one of severity or duration is increasing, turn off the power of at least one device at the location (249D).

[0106] In this embodiment, only one vehicle 202 is described in detail, but a plurality of such nodes may be connected to the blockchain. It should be understood that the vehicle 202 may include additional components, and some of the components described here may be removed or modified without departing from the scope of this solution. The vehicle 202 may have a computing device or a server computer, etc., and may also 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 illustrated, it should be understood that the vehicle 202 may include a plurality of processors, a plurality of cores, etc. without departing from the scope of this solution. The vehicle 202 may be a vehicle, a server, or a device having a processor and a memory.

[0107] The processor 204 performs one or more of the following: receives confirmation of an event including a blockchain consensus between peers represented by any of the elements 230 from one or more of the elements described or shown herein; executes a smart contract to record the confirmation regarding the blockchain consensus. The consensus is formed between one or more of the elements 230 and / or any of the elements described or shown herein, including vehicles, servers, wireless devices, etc. In another example, the vehicle 202 may be one or more of the elements described or shown herein, including the element 230 and / or a server, a wireless device, etc.

[0108] The processor and / or the computer-readable medium 242D can be located entirely or partially inside or outside the vehicle. The steps or functions stored in the computer-readable medium 242D may be executed entirely or partially in any order by any processor and / or element. Further, one or more steps or functions may be, for example, added, omitted, combined, and executed later.

[0109] Figure 2E shows a flow diagram 260 according to an exemplary embodiment. Referring to Figure 2E, the flow includes the vehicle determining (244E) the severity and duration associated with a predicted power outage at a location, the vehicle determining (246E) the optimal charge level of the vehicle's battery based on the severity and duration before the predicted power outage, the vehicle comparing (248E) the current charge level of the vehicle with the optimal charge level, and the vehicle charging (250E) the battery to the optimal charge level when the current charge level is below the optimal charge level.

[0110] Figure 2F shows another flow diagram 270 according to an exemplary embodiment. Referring to Figure 2F, the flow includes: providing (244F) the optimal charge level from the battery to the location in response to the occurrence of a predicted power outage; the vehicle determining whether at least one of the severity and duration changes, and providing (245F) an additional charge level from the vehicle's battery to the location in response to at least one of the severity and duration increasing; where determining the optimal charge level of the vehicle's battery is associated with the energy consumption at the location (246F); when the location includes an in-site energy storage device, using the in-site energy storage device to supply energy to the location during the predicted power outage, monitoring the charge state of the in-site energy storage device while the in-site energy storage device is supplying energy to the location, and using the vehicle to supply energy to the location when the charge state of the in-site energy storage device approaches zero (247F); when the location includes another vehicle, using this other vehicle to supply energy to the location during the predicted power outage, monitoring the charge state of this other vehicle while this other vehicle is supplying energy to the location, and using the vehicle to supply energy to the location when the charge state of this other vehicle approaches zero (248F); during the predicted power outage, the vehicle updating (249F) the severity and duration associated with the predicted power outage, and turning off the power of at least one device at the location when at least one of the severity or duration is increasing.

[0111] Referring now to FIG. 3A, the figure shows a machine learning vehicle network diagram 300A. The machine learning subsystem 306A includes a learning model 308A which is an artifact created by a machine learning training system 310A that generates predictions by finding patterns within one or more training data sets. In certain embodiments, the machine learning subsystem 306A resides in the vehicle node 302A. Artifacts are used to describe outputs created by the training process such as checkpoints, files, models, etc. In other embodiments, the machine learning subsystem 306A resides outside of the vehicle node 302A.

[0112] The vehicle 302A transmits data from one or more sensors 304A to the machine learning subsystem 306A. The machine learning subsystem 306A provides the data from the one or more sensors 304A to the learning model 308A, which in turn returns one or more predictions. The machine learning subsystem 306A transmits one or more commands to the vehicle 302A based on the predictions from the learning model 308A.

[0113] In further embodiments, the vehicle 302A can transmit data from the one or more sensors 304A to the machine learning training system 310A. In yet another embodiment, the machine learning subsystem 306A can transmit the data from the sensor 304A to the machine learning subsystem 306A. One or more of the uses, functions, processes, solutions, etc. described and / or shown herein can utilize a machine learning network as described herein.

[0114] As shown in the examples of FIGS. 3B - 3E, an exemplary embodiment can communicate with a host platform 320. The host platform 320 shown in FIGS. 3B - 3E can be the host of system 300B or system 300B can communicate with the host platform 320. That is, the methods, systems, and processes described herein can interact with the processes and systems in the examples shown and described in FIGS. 3B - 3E.

[0115] For example, FIG. 3B shows a process 300B for executing a machine learning model via a host platform 320. The host platform 320 can serve as a host for a process 322 within a library runtime environment that is accessible to other software programs, applications, etc. via a network such as the Internet. Here, the host process 322 can have a uniform resource locator (URL), endpoint, application programming interface (API), etc. that are publicly available on the Internet.

[0116] In this example, the host process 322 can control access to and execution of the models stored in the model repository 323. For example, the models can include artificial intelligence (AI) models, machine learning (ML) models, neural networks, etc. The system 302 can trigger the execution of a model from the model repository 323 via a call to the application programming interface (API) 321 of the host process 322. The request can include identifiers of one or more models to be executed, a data payload (e.g., data input to the model during execution), etc. The host process 322 can receive the call from the system 302, search for the corresponding model from the model repository 323, deploy the model within the runtime environment, execute the model on the input data, and return the execution result to the system 302. The execution result can include the output result from the execution of the model.

[0117] In one embodiment, system 302 can provide feedback from the output provided by the model. For example, a user can input a confirmation that the prediction output by the model is correct or provide a notification that the model is inaccurate. This information can be added to the execution results and stored in log 324. The log data can include an identifier of the input, an identifier of the output, an identifier of the model used, and feedback from the recipient. This information can be used to continue retraining the model, for example, using the model development environment shown in the example of FIG. 3C.

[0118] Typically, technological progress is built on previous technologies, as is the case with artificial intelligence (AI). The AI classification system indicates the development stage of AI. The first classification is known as "reactive machine" and is followed by today's AI classification (also known as "narrow artificial intelligence") "limited memory machine", progresses to "theory of mind" (also known as "general artificial intelligence"), and reaches the AI classification "self-awareness" (also known as "artificial superintelligence"). Today's limited memory machines are a growing group of AI models built on their predecessor reactive machines. Reactive machines mimic human reactions to stimuli but usually have limited capabilities as they cannot learn from previous experiences. Since the learning ability of AI models emerged, the classification has been upgraded to limited memory machines. In today's classification, AI models perform learning from large amounts of data, pattern detection, problem solving, and data generation and prediction, etc., while inheriting all the capabilities of reactive machines.

[0119] Examples of AI models classified as limited memory machines include, but are not limited to, chatbots, virtual assistants, machine learning (ML), deep learning (DL), natural language processing (NLP), generative AI (GenAI) models, and future AI models yet to be developed that have the characteristics of limited memory machines. Generative AI models are a combination of limited memory machine technologies incorporating ML and DL, and in turn form the basic building blocks of future AI models. For example, theory of mind is the next advancement in AI, enabling perception, connection, and reaction by generating appropriate responses in reaction to entities with which the AI model is interacting, and this ability relies entirely on the basis of generative AI. Further, in the evolution towards self-awareness classification, the AI model can understand and induce the emotions of entities with which the AI model interacts, and also has its own emotions, beliefs, and needs. All of these rely on the basis of generative AI, which is learning from experience, to generate and draw conclusions regarding the AI model itself and its surroundings. Generative AI models are essential and core to future artificial intelligence models. As described herein, generative AI refers to today's generative AI models and future AI models.

[0120] FIG. 3C shows a process 300C for training a machine learning model 330 according to an exemplary embodiment. Referring to FIG. 3C, a host platform 320 can host an integrated development environment (IDE) 340 that can develop, train, and retrain machine learning models, AI models, and the like. In this example, IDE 340 may include a software application having a user interface accessible by a system 302. For example, IDE 340 can be implemented as a web application accessible by a device at a certain network address or URL, etc. In another example, IDE 340 may be locally or remotely installed on a computing device used by a user.

[0121] Process 300C may be used to design a model such as a machine learning model (via the user interface of the IDE). Thereafter, the model can be executed / trained based on the training data established via the user interface. For example, a new model can be constructed using the user interface. Training data for training such a new model can be provided from a training data storage unit 325 that includes training samples from the web or from customers, etc. Here, the model is executed on the training data via the host platform 320 to generate results. By executing this model, the model will learn based on the input training data. When fully trained, the model can be stored in the model repository 323 via the IDE 340 or the like.

[0122] In another example, the IDE 340 can be used to retrain an existing model. Here, to retrain the model 330, the training process can use the execution results (including any feedback, etc.) previously generated / output by the model 330. For example, predicted outputs identified as accurate, best, good, etc. may be distinguished from outputs that are inaccurate, in error, bad, etc. To retrain the model, one or more of these outputs can be identified and used to help the model provide better outputs.

[0123] Figure 3D shows a process 300D for designing a new machine learning model via a user interface 350 of a system according to an exemplary embodiment. In one example, the model may be output as part of a software application that interacts with the IDE 340 shown in Figure 3C, but the embodiment is not limited thereto. Referring to Figure 3D, the user can add pieces / components to the model being developed in the work area 354 of the user interface 350 using an input mechanism from the menu 352 of the user interface 350.

[0124] In the example of FIG. 3D, the menu 352 includes options of a plurality of graphical user interface (GUI) menus that can select and expand additional components that can be added to the model design shown in the work area 354. Here, the GUI menu includes options for adding functions such as neural networks, machine learning models, AI models, data sources, conversion processes (e.g., vector instructionization, encoding, etc.), analysis, etc. The user can continue to add functions to the model and generate a flow in the work area 354 by using edges or other means to connect. For example, the user can add a node 356 to the flow of a new model within the work area 354. For example, the user can connect the node 356 to another node in the flow via an edge 358 to create a dependency within the flow. Once completed, the user can save the model for subsequent training / testing.

[0125] In another example, the object name can be identified from within the web page, the user interface 350 in the browser where the object is visible, or within the work area 354 on the user device. A pop-up within the browser or the work area 354 can be placed so that the object is visible, and optionally, there is browsing to the identified web page corresponding to the alternative object via a rule set.

[0126] Figure 3E shows a process 300E of accessing an object 362 from an object storage 360 of a host platform 320 according to an exemplary embodiment. For example, the object storage 360 can store data used by an AI model and a machine learning (ML) model 330, as well as training data, predicted outputs for testing, training results, and the like. Other types of data can also be stored in the object storage 360. Each object can include a unique number identifier, a data section 363, and a metadata section 364 that provides a descriptive context associated with the data and includes data that can be extracted later for machine learning purposes. The unique number identifier can uniquely identify an object within the object storage 360 with respect to all other objects. The data section 363 can include unstructured data such as web pages, digital content, images, audio, and text.

[0127] Rather than splitting files into blocks stored on a file system disk, the object storage 360 processes objects as individual data units stored in a structurally flat data environment. Here, the object storage device may not need to use folders, directories, and complex hierarchies. Instead, each object can be a simple self - contained repository that includes data, metadata, and a unique number identifier, and client applications can use this to locate and access the object. In this case, the metadata is more descriptive than a file - based approach. It is possible to customize the metadata using additional context that can be extracted and utilized later for other purposes such as data analysis.

[0128] Objects stored in the object storage 360 can be accessed via the API 361. The API 361 can be a RESTful API (also known as a RESTful web service) based on the Hypertext Transfer Protocol (HTTP). Any device can use the API 361 via the Internet from anywhere to query the metadata of the object to find out where the desired object (data) is. The API 361 can use HTTP commands such as "PUT" or "POST" to upload an object, "GET" to search for an object, or "DELETE" to remove an object.

[0129] The object storage 360 includes a directory 365 that uses the metadata of the object and can find the appropriate data file. The directory 365 can include descriptive information about each object stored in the object storage 360, such as name, unique number identifier, creation timestamp, collection name, etc. To query an object in the object storage 360, the client application can submit a command such as an HTTP command, along with the identifier of the object 362, the payload, etc. The actions and results described herein, including associating this list with each other based on variables used by two or more lists of ranked assets with a correlation exceeding a predetermined threshold, can be stored in the object storage 360.

[0130] FIG. 4A shows a diagram 400A representing the electrical supply of one or more elements. In one example, a vehicle 402B can provide the power stored in its battery to one or more elements including another vehicle 408B, a charging station 406B, and a power grid 404B. The power grid 404B is connected to one or more of the charging stations 406B, and the charging station 406B can be connected to one or more of the vehicles 408B. This configuration enables the distribution of the electricity / power received from the vehicle 402B. The vehicle 402B can also interact with other vehicles 408B via communication such as vehicle-to-vehicle (V2V) technology, cellular, Wi-Fi, etc. The vehicle 402B can interact with other vehicles 408B, the charging station 406B, and / or the power grid 404B wirelessly and / or wired. In one example, the vehicle 402B takes a path (or travels along that path by itself) to the power grid 404B, the charging station 406B, or another vehicle 408B safely and efficiently. Using one or more embodiments of this solution, the vehicle 402B can provide energy to the one or more elements shown here in various advantageous ways as described and / or shown here. Furthermore, the safety and efficiency of the vehicle can be enhanced, and an environmentally friendly impact can be exerted as described and / or shown here.

[0131] Terms such as "energy", "electricity", "power", etc. can be used to represent any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be referred to in relation to a voltage source and / or a current source related to the charge provided to the vehicle from an entity during a charging / usage operation. Energy may be in the form of fossil fuels (for example, for use with hybrid vehicles), or may be via alternative power sources including lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, nuclear fusion-based energy sources, and energy generated during energy sharing and / or usage operations to increase or decrease the energy level of one or more vehicles at a given time, but is not limited thereto.

[0132] In one example, the charging station 406B manages the amount of energy transferred from the vehicle 402B such that sufficient charge remains in the vehicle 402B to reach the destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transfer between vehicles 408B, where both vehicles may be in motion. In one embodiment, wireless charging may occur via stationary chargers arranged in a line (such as a charging mat in a garage or parking space) and the vehicle's battery. In one example, an idling vehicle (which may be autonomous), such as vehicle 402B, is directed to provide an amount of energy to the charging station 406B 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 408B and send the excess energy stored at the charging station 406B. In one example, the amount of energy sent to the charging station 406B is determined by factors such as distance, time, as well as traffic conditions, road conditions, environmental / weather conditions, vehicle state (such as weight), the schedule of the occupants while using the vehicle, the schedule of people waiting for the vehicle, the schedule of potential passengers, etc. In one example, the vehicle 408B, the charging station 406B, and / or the power distribution network 404B can supply energy to the vehicle 402B.

[0133] In one embodiment, a location such as a building, a residence, etc. (not shown) is communicatively coupled to one or more of the power distribution network 404B, the vehicle 402B, and / or the charging station 406B. The electrical current flow to one or more of the location, the vehicle 402B, other vehicles 408B is modified according to external conditions such as weather. For example, if the external temperature is extremely high or extremely low and the likelihood of a power outage increases, the flow of electricity to the connected vehicles 402B / 408B is slowed, which helps minimize the likelihood of a power outage.

[0134] In one embodiment, vehicles 402B and 408B can be used as bi-directional vehicles. A bi-directional vehicle can be used as a mobile microgrid that can assist in supplying power to the power grid 404B and / or reduce power consumption when stress is applied to the power grid. A bi-directional vehicle has a bi-directional charging function. This is called "V2G", and in addition to receiving charging to the vehicle, the vehicle can send its energy to the power grid 404B. In bi-directional charging, electricity flows in both directions, to and from the vehicle. When the vehicle is charged, alternating current (AC) electricity from the power grid 404B is converted to direct current (DC). This may be performed by one or more of the vehicle's own converter or the converter of the charging station 406B. The energy stored in the vehicle's battery can be sent in the reverse direction and returned to the power grid. The energy is converted from DC to AC via a converter, also called a bi-directional charger, which is typically at the charging station 406B. Further, the solution described and illustrated with respect to FIG. 4B can be utilized in this network and / or system and in other networks and / or systems.

[0135] Figure 4B shows a diagram 400B illustrating the interconnections between different elements. This solution may be stored and / or executed, in whole or in part, on and / or by one or more computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C, all of which are communicatively coupled to and communicate with a network 402C. A database 438C is communicatively coupled to the network and enables 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 404C, one or more service providers 416C, one or more public buildings 422C, one or more transportation infrastructures 426C, one or more residences 430C, a power distribution network / charging station 434C, a microphone 440C, and / or another vehicle 408C. Other entities and / or devices such as a smartphone 412C, a laptop computer 420C, one or more individual users using an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device may also be integrated with this solution. The smartphone 412C, the laptop computer 420C, the microphone 440C, and other devices may be connected to one or more of the connected computer devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C. One or more public buildings 422C may include various agencies. One or more public buildings 422C may utilize a computing device 424C. One or more service providers 416C may include stores, tow truck services, accident vehicle repair centers, and other repair shops. One or more service providers 416C may utilize a computing device 418C. These various computing devices may be communicatively coupled to each other directly and / or via a wired network, a wireless network, a blockchain network, etc. The microphone 440C may be utilized as a virtual assistant in one example.In one example, the one or more transportation infrastructures 426C can include one or more traffic signals, one or more sensors including one or more cameras, a vehicle speed sensor or a traffic sensor, and / or other transportation infrastructure. The one or more transportation infrastructures 426C can utilize a computing device 428C.

[0136] In one embodiment, when a charging station and / or a power distribution network is being charged or discharging, the entity that permits such charging is always one or more of a vehicle, a charging station, a server, and a network communicably coupled to the vehicle, the charging station, and the power distribution network.

[0137] In one example, the vehicle 408C / 404C can carry a person, an object, a permanently or temporarily fixed device, etc. In one example, the vehicle 408C can communicate with the vehicle 404C via V2V communication through a computer associated with each of the vehicles 406C and 410C, and can be referred to as a car, a vehicle, an automobile, etc. The vehicle 404C / 408C can be a self-propelled wheeled carrier such as a car, a sports utility vehicle, a truck, a bus, a light van, or other motor or battery-driven or fuel cell-driven vehicle. For example, the vehicle 404C / 408C can be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or other types of vehicles equipped with a fuel cell stack, a motor, and / or a generator. Examples of vehicles also include bicycles, scooters, trains, airplanes, boats, and other forms of carriers that enable transportation. The vehicle 404C / 408C can be semi-autonomous or autonomous. For example, the vehicle 404C / 408C can drive itself without human input. An autonomous vehicle can have and utilize one or more sensors and / or a navigation unit to drive autonomously. All the data described or shown herein can be stored, analyzed, processed, and / or transferred by one or more of the elements of FIG. 4B.

[0138] Figure 4C is another block diagram 400C illustrating the interconnections between different elements in the example of 1. Vehicle 412D is presented, which includes ECUs 410D, 408D, and a head unit 406D (also known as an infotainment system). An electronic control unit (ECU) is an in-vehicle electronics built-in system that controls one or more of the vehicle's electrical systems or subsystems. The ECU includes, but is not limited to, the management of the vehicle's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's Controller Area Network (CAN) bus 416D. The ECU can also communicate with the vehicle computer 404D via the CAN bus 416D. The vehicle's processor / sensor 404D (such as a vehicle computer) can communicate with external elements such as a server 418D via a network 402D (such as the Internet). Each ECU 410D, 408D, and head unit 406D can include its own security policy. The security policy defines the acceptable processes that are executable within an appropriate context. In one example, the security policy may be provided partially or entirely within the vehicle computer 404D.

[0139] ECU 410D, 408D, and the head unit 406D can each include a custom security feature element 414D that defines an authorized process and a context that permits the execution of that process. By authorizing based on the context to determine the validity of whether a process is executable, the ECU can maintain a safe operation and prevent unauthorized access from elements such as the vehicle's controller area network (CAN) bus. When encountering an unauthorized process, the ECU can block the operation of that process. An automotive ECU can use the following different contexts to determine whether a process is operating within its allowable range: proximity context, nearby objects, distance to approaching objects, speed, trajectory regarding other moving objects; an indicator of whether the vehicle is moving or parked, the current speed of the vehicle, an operation context such as the transmission state; a user-related context such as a device connected to a transporter via a wireless protocol, the use of infotainment, cruise control, parking assistance, driving assistance; a location-based context; and / or other contexts.

[0140] Referring to FIG. 4D, an operating environment 400D for a connected vehicle according to an embodiment is illustrated. As shown, vehicle 410E includes a controller area network (CAN) bus 408E that connects vehicle elements 412E - 426E. Other elements may be connected to the CAN bus, but are not shown here. The illustrated elements connected to the CAN bus include a sensor set 412E, an electronic control unit 414E, an autonomous function or advanced driver assistance system (ADAS) 416E, and a navigation system 418E. In an embodiment, vehicle 410E includes a processor 420E, a memory 422E, a communication unit 424E, and an electronic display unit 426E.

[0141] The processor 420E includes an arithmetic unit, a microprocessor, a general-purpose controller, and / or a similar processor array, executes calculations, and provides an electronic display signal to the display unit 426E. The processor 420E processes data signals and can include various computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture of a few computers, or an architecture that implements a combination of instruction sets. The vehicle 410E can include one or more processors 420E. Other processors, operating systems, sensors, displays, and physical configurations (not shown) that are communicably coupled to each other may be used with this solution.

[0142] The memory 422E is a non-transitory memory that stores instructions or data that can be accessed and executed by the processor 420E. The instructions and / or data can include code for implementing the techniques described herein. The memory 422E can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory, or other memory devices. In some embodiments, the memory 422E can be a non-volatile memory or a similar permanent storage device and medium, which can include a hard disk drive, a floppy disk drive, a compact disc read-only memory (CD-ROM) device, a digital versatile disc read-only memory (DVD-ROM) device, a digital versatile disc random access memory (DVD-RAM) device, a digital versatile disc rewritable (DVD-RW) device, a flash memory device, or other mass storage devices for permanently storing information. A portion of the memory 422E can be reserved for use as a buffer or virtual random access memory (RAM). The vehicle 410E can include one or more memories 422E without departing from this solution.

[0143] The memory 422E of the vehicle 410E can store one or more of the following types of data: navigation route data 418E, and autonomous function data 416E. In certain embodiments, the memory 422E stores data that may be required for the navigation application 418E to provide functionality.

[0144] The navigation system 418E can represent at least one navigation route including a starting point and an ending point. In certain embodiments, the navigation system 418E of the vehicle 410E receives a request for a navigation route from a user. Here, this request includes a starting point and an ending point. The navigation system 418E can query (via the network 402E) a real-time data server 404E, such as a server that provides driving instructions, for navigation route data corresponding to a navigation route including the starting point and the ending point. The real-time data server 404E transmits the navigation route data to the vehicle 410E via the wireless network 402E, and the communication system 424E stores the navigation data 418E in the memory 422E of the vehicle 410E.

[0145] The ECU 414E controls many operations of the systems of the vehicle 410E, including the ADAS system 416E. In response to a command received from the navigation system 418E, the ECU 414E can disable dangerous and / or unselected autonomous functions during the journey controlled by the ADAS system 416E. In this way, the navigation system 418E controls whether to activate or enable the ADAS system 416E and can cause it to be active for a given navigation route.

[0146] The sensor set 412E can include all sensors in the vehicle 410E that generates sensor data. For example, the sensor set 412E can include a short-range sensor and a long-range sensor. In certain embodiments, the sensor set 412E of the vehicle 410E can include one or more of the following vehicle sensors: cameras, optical detection and ranging (lidar) sensors, ultrasonic sensors, automotive engine sensors, radar sensors, laser altimeters, intake pressure gauges, infrared detectors, motion detectors, thermostats, sound detectors, carbon monoxide sensors, carbon dioxide sensors, oxygen sensors, mass flow sensors, engine coolant temperature sensors, throttle position sensors, crank position sensors, valve timers, air-fuel ratio meters, blind spot meters, curve feelers, defect detectors, Hall effect sensors, parking sensors, radar guns, speedometers, speed sensors, tire pressure monitoring sensors, torque sensors, transmission fluid temperature sensors, turbine speed sensors (TSS), variable reluctance sensors, vehicle speed sensors (VSS), water sensors, wheel speed sensors, global positioning system (GPS) sensors, mapping functions, and any other type of automotive sensor. The navigation system 418E can store the sensor data in the memory 422E.

[0147] The communication unit 424E transmits and receives data with the network 402E or another communication channel. In certain embodiments, the communication unit 424E can include a dedicated short range communication (DSRC) transceiver, a DSRC receiver, and any other hardware and software necessary to make the vehicle 410E a DSRC equipped device.

[0148] The vehicle 410E can interact with other vehicles 406E via V2V technology. V2V communication, in one example, includes sensing radar information corresponding to the relative distance to an external object, receiving GPS information of the vehicle, setting the area where other vehicles 406E are located based on the sensed radar information, calculating the probability that the GPS information of the object / vehicle is in the set area, and identifying the vehicle and / or object corresponding to the radar information and / or the GPS information of the object / vehicle based on the calculated probability.

[0149] For proper safeguarding, the vehicle must be protected from unauthorized physical access as well as unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, in one example, the vehicle is equipped with a secure access system such as keyless entry. On the other hand, in one example, security protocols are added to the vehicle's computer and computer network to facilitate secure remote communication with the vehicle.

[0150] The Electronic Control Unit (ECU) is a node within the vehicle that controls tasks ranging from activating the wipers to tasks such as the anti-lock braking system. ECUs are often connected to each other via a vehicle's central network, sometimes referred to as a Controller Area Network (CAN). State-of-the-art features such as autonomous driving strongly rely on the implementation of new and complex ECUs such as Advanced Driver Assistance Systems (ADAS), sensors, etc. While these new technologies help improve vehicle safety and the driving experience, they also increase the number of external communication units within the vehicle, making it more vulnerable to attacks. The following are some examples of protecting the vehicle from physical and remote intrusion.

[0151] In one embodiment, the CAN includes a CAN bus having high and low terminals, and a plurality of Electronic Control Units (ECUs) connected to the CAN bus via a wired connection. The CAN bus is designed within an application to enable the microcontroller and the device to communicate with each other without a host computer. The CAN bus implements a message-based protocol (ISO standard 11898) that enables ECUs to send commands to each other at the root level. On the other hand, an ECU is representative of a controller for controlling an electrical system or subsystem within the vehicle. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and many other functions.

[0152] In this example, the ECU includes a transmitter and a microcontroller. The transmitter can be used to send and receive messages with the CAN bus. For example, the transmitter can convert data from the microcontroller into the format of the CAN bus, or convert data from the CAN bus into the format of the microcontroller. On the other hand, in one example, the microcontroller interprets the message and determines the message to be sent using the installed ECU software.

[0153] To protect the CAN from cyber threats, various security protocols can be implemented. For example, sub-networks (such as sub-network A, B, etc.) can be used to divide the CAN into smaller sub-CANs, limiting the ability of attackers to remotely access the vehicle. In one embodiment, a firewall (or gateway, etc.) can be added to prevent messages from crossing the CAN bus via the sub-network. Even if an attacker accesses a certain sub-network, they do not have access rights to the entire network. To further enhance the security of the sub-network, in one example, a plurality of the most important ECUs are not placed in the same sub-network.

[0154] In addition to protecting its internal network, the vehicle may also be protected when communicating with an external network such as the Internet. One of the advantages of connecting the vehicle to a data source such as the Internet is that, for analysis, information from the vehicle can be transmitted to a remote location via the network. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often called telematics because they involve a combination of telecommunications and information science. Furthermore, the described and shown solution can be used in this network and / or system, and other networks and / or systems including those described and shown herein.

[0155] Figure 4E shows an example 400E of vehicles 402I and 408I performing secure V2V communication using security certificates according to an exemplary embodiment. Referring to Figure 4E, vehicles 402I and 408I can communicate via V2V communication in a short-range network, a cellular network, etc. Vehicles 402I and 408I can sign messages using their respective public key certificates before transmitting the messages. For example, vehicle 402I can sign a V2V message using public key certificate 404I. Similarly, vehicle 408I can sign a V2V message using public key certificate 410I. In one example, public key certificates 404I and 410I are associated with vehicles 402I and 408I respectively.

[0156] Upon receiving communication from each other, the vehicles can inspect the signature using a certificate authority 406I etc. For example, vehicle 408I can use certificate authority 406I to inspect the reliability of public key certificate 404I used by vehicle 402I to sign V2V communication. When vehicle 408I successfully inspects public key certificate 404I, it can be understood on the vehicle side that the data is from a legitimate source. Similarly, vehicle 402I can use certificate authority 406I to inspect the reliability of public key certificate 410I used by vehicle 408I to sign V2V communication. Further, the solution as described and illustrated with respect to Figure 4E can be utilized in this network and / or system, and other networks and / or systems including those described and shown herein.

[0157] In one embodiment, the computer may include a security processor. In particular, the security processor can perform authorization, authentication, cryptography (e.g., encryption), etc. for data transmissions that are transmissions between ECUs and other devices on the vehicle's CAN bus, and for data messages transmitted between different vehicles. The security processor may include an authorization module, an authentication module, and a cryptographic module. The security processor may be implemented within the vehicle's computer and may communicate with other vehicle elements, such as wired and wireless devices like ECU / CAN networks, wireless network interfaces, or input ports. The security processor can ensure that data frames (e.g., CAN frames, etc.) transmitted within the vehicle (e.g., via the ECU / CAN network) are secure. Similarly, the security processor can ensure that messages transmitted between different vehicles and devices attached to or connected to the vehicle's computer by wire are also secure.

[0158] For example, the authorization module can store passwords, usernames, PIN codes, biometric scans, etc. for different vehicle users. The authorization module can determine whether a user (or technician) has permission to access a certain setting, such as the vehicle's computer. In one embodiment, the authorization module can communicate with the network interface and download the necessary authorization information from an external server. When a user wishes to change vehicle settings or modify technical details of the vehicle via a console or GUI within the vehicle, or via an attached / connected device, the authorization module can require the user to verify themselves in some way before such a setting change. For example, the authorization module may request a username, password, PIN code, biometric scan, predefined line drawing, or gesture, etc. In response, the authorization module can determine whether the user has the required permission (such as access).

[0159] The authentication module can be used to authenticate the internal communication between ECUs on the vehicle's CAN network. As an example, the authentication module can provide information for authenticating the communication between ECUs. As an example, the authentication module may send a bit signature algorithm to the ECUs of the CAN network. The ECU can use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. Usually, all ECUs on the CAN network receive each CAN frame. The bit signature algorithm may dynamically change the position, amount, etc. of the authentication bits each time an ECU generates a new CAN frame. The authentication module may provide a list of ECUs that are excluded (in the safe list) and do not need to use the authentication bits. The authentication module can communicate with a remote server to retrieve updates such as the bit signature algorithm.

[0160] The encryption module can store an asymmetric key pair used by the vehicle to communicate with other external user devices and the vehicle. For example, the encryption module can provide a private key used by the vehicle to encrypt / decrypt communication, while the corresponding public key may be provided to other user devices and the vehicle to enable other devices to decrypt / encrypt the communication. The encryption module can communicate with a remote server to receive new keys, key updates, keys for new vehicles or users, etc. Also, the encryption module may send an update of the local private key / public key pair to the remote server.

[0161] FIG. 5A shows an exemplary vehicle configuration 500A for managing database transactions associated with a vehicle, according to an exemplary embodiment. Referring to FIG. 5A, a particular vehicle 525 can receive an asset 510 and / or evict / transfer an asset 512 according to a transaction when participating in a transaction (such as vehicle maintenance, dealership transactions, shipping, transportation services, etc.). A vehicle processor 526 exists within the vehicle 525, and there is communication between the vehicle processor 526, the database 530, and the transaction module 520. The transaction module 520 can record information such as assets, parties, credits, service details, dates, times, locations, results, notifications, unexpected events, etc. These transactions within the transaction module 520 can be replicated to the database 530. The database 530 can be one of a structured query language (SQL) database, a relational database management system (RDBMS), a relational database, a non-relational database, a blockchain, a distributed ledger, and may or may not be installed in the vehicle, may be accessed directly and / or via a network, or may be accessible to the vehicle.

[0162] In one embodiment, when a vehicle reaches a situation where it needs to share services with other vehicles, the vehicle can perform various actions such as sharing, transferring, and obtaining dispatch requests in relation to other vehicles. For example, the vehicle may be scheduled for battery charging and / or have problems with its tires and / or be on a collection route for delivery. A vehicle processor exists within the vehicle, and there is communication between the vehicle processor, a first database, and a transaction module. The vehicle is within its network and can notify another vehicle operating in its blockchain member service. A vehicle processor exists within the other vehicle, and there is communication between the vehicle processor, a second database, the vehicle processor, and a transaction module. Then, the other vehicle can receive information via a wireless communication request to perform collection from the vehicle and / or a server (not shown). The transaction is recorded in the transaction modules of both vehicles. Credits are transferred from one vehicle to another, and the record of the transferred service is recorded in the first database if the blockchains are different from each other, or in the same blockchain used by all members. The first database can be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, and a distributed ledger, and may or may not be installed in the vehicle and may be directly and / or accessible via a network.

[0163] Figure 5B shows a blockchain architecture configuration 500B according to an exemplary embodiment. Referring to Figure 5B, the blockchain architecture 500B can include a set of blockchain member nodes 502-505 as part of a particular blockchain element, such as a blockchain group 510. In one exemplary embodiment, a permissioned blockchain is accessible only to members who are permitted access to the blockchain data, rather than all parties. Blockchain nodes participate in many activities such as the blockchain input addition and verification process (consensus). One or more of the blockchain nodes can endorse an input based on an endorsement policy and can provide an ordering service to all blockchain nodes. A blockchain node can initiate a blockchain action (such as authentication) and request a write to the blockchain immutable ledger stored on the blockchain, and its replica can also be stored on the underlying physical infrastructure.

[0164] When a blockchain transaction 520 is received and approved by a consensus model commanded by a member node, it is stored in the computer's memory. An approved transaction 526 is stored in the current block of the blockchain and committed to the blockchain via a commit procedure. This commit procedure includes executing a hash of the data content of the transactions within the current block and referencing the previous hash of the previous block. Within the blockchain, there can be one or more smart contracts 530 that define the conditions for transaction consent and actions included in the smart contract executable application code 532, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The code may be configured to identify whether the requesting entity is registered to receive vehicle maintenance, what service functions the requesting entity is entitled to receive / requested to receive considering its profile status, and whether to monitor the actions of the requesting entity in subsequent events. For example, a service event occurs, the sensor data is monitored when the user is in the vehicle as a trigger, certain parameters such as the vehicle charge level are identified as exceeding / falling below a certain threshold at a certain time, and as a result, a change to the current state occurs, which may require sending a warning to an administrator (i.e., vehicle owner, vehicle operator, server, etc.), and the service can be identified and stored for reference. The vehicle sensor data collected may be based on the types of sensor data used to collect information about the state of the vehicle. This sensor data may be the basis for vehicle event data 534 such as where to drive, average speed, maximum speed, acceleration rate, whether there was a collision, whether the expected route was taken, where the next destination is, whether safety measures are being implemented, whether the vehicle is fully charged / has fuel, etc. All such information can be the basis for the smart contract conditions 530 stored in the blockchain at that time.For example, the sensor thresholds stored in the smart contract can be used as criteria for determining whether the detected service is required and when and where the service should be executed.

[0165] In one embodiment, the blockchain logic example includes a blockchain application interface as an API or a plug-in application that links to a computing device and an execution platform for a specific transaction. The blockchain configuration can include one or more applications. This application is linked to an application programming interface (API) and accesses and executes the stored program / application code (such as smart contract executable code, smart contracts, etc.). This application code can be created according to the customized configuration required by the participants, maintain the state of the application itself, control the assets of the application itself, and receive external information. By leveraging this as input and adding it to the distributed ledger, it can be installed on all blockchain nodes.

[0166] The smart contract application code provides the basis for blockchain transactions by establishing the application code, whereby the transaction conditions become active when executed. The smart contract, when executed, causes a certain specific approved transaction to be generated. This transaction is then transferred to the blockchain platform. The platform includes a computing device that executes security / authorization and transaction management, and a storage unit as a memory for storing transactions and smart contracts on the blockchain.

[0167] A blockchain platform may include underlying physical computer infrastructure that can be used to receive, store, and provide access to blockchain data at various layers, services (such as cryptographic trust services, virtual execution environments, etc.), and auditors who seek access to new inputs and access the data inputs. The blockchain can expose an interface that processes program code and provides access to the virtual execution environment necessary to relate to the physical infrastructure. Cryptographic trust services can be used to inspect inputs such as asset exchange inputs and keep information secret.

[0168] The blockchain architecture configurations of FIGS. 5A and 5B can process and execute program / application code via one or more interfaces exposed by the blockchain platform and the provided services. As a non-limiting example, smart contracts can be created to issue notifications regarding reminders, updates, and / or other changes, updates, etc. The smart contract itself can be used to identify authorization and access requirements and the rules associated with the use of the ledger. For example, the information can include new inputs that can be processed by one or more processing entities (such as processors, virtual machines, etc.) included in the blockchain layer. The result can include a determination to reject or approve the new input based on criteria defined by the smart contract and / or peer consensus. The data or information described herein can be retrieved using the physical infrastructure.

[0169] Within the smart contract executable code, a smart contract can be created via a high-level application and programming language and then written to a block within a blockchain. A smart contract can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). The input is the execution of the smart contract code, which can be executed in response to the conditions associated with the smart contract being satisfied. Execution of the smart contract can cause a reliable modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0170] A smart contract can write data to the blockchain in the form of key / value pairs. Further, the smart contract code can read values stored in the blockchain and use them in application operations. The smart contract code can write the outputs of various logical operations to the blockchain. This code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public or encrypted and maintained as a secret. Temporary data used / generated by the smart contract is held in memory by the provided execution environment and deleted when the data required by the blockchain is identified.

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

[0172] Figure 5C shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment. Referring to Figure 5C, an exemplary configuration 500C includes a vehicle 562, a user device 564, and a server 566 that share information with a distributed ledger (i.e., a blockchain) 568. The server may represent a service provider entity that queries a vehicle service provider to share user profile evaluation information when attempting to rent a vehicle that has an evaluation profile with a known established user profile. The server 566 can receive and process data related to the service requirements of the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charging or maintenance services, smart contracts can be used to invoke rules, thresholds, sensor information collection, etc. that can be used to call a vehicle service event. For each transaction, such as an access event, subsequent updates to the vehicle's service status, event updates, etc., blockchain transaction data 570 is stored. The transaction can include the parties, requirements (e.g., being 18 years old, service eligible candidate, valid driver's license, etc.), compensation level, distance traveled during the event, registered recipient who was granted access to the event and served as the host of the vehicle service, rights / permissions, details of the next service event, sensor data retrieved during the vehicle event operation to identify the vehicle situation, and thresholds used to determine whether the service event was completed and whether the vehicle situation changed.

[0173] FIG. 5D shows a blockchain block that can be added to a distributed ledger according to an exemplary embodiment, and the contents of block structures 582A to 582n. Referring to FIG. 5D, a client (not shown) can present an input to a blockchain node to perform activities on the blockchain. As an example, the client can be an application that operates on behalf of a requester, such as a device, person, or entity, to propose an input to the blockchain. A plurality of blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a replica of the distributed ledger. There may be different types of blockchain nodes / peers in a blockchain network that includes an endorser peer that simulates and endorses the input proposed by the client, an endorser that examines the endorsement, a validator that validates the input, and a commit peer that commits the input to the distributed ledger. In this example, a blockchain node can perform the role of an endorser node, a commit node, or both.

[0174] This system includes a blockchain that stores records arranged in a non-modifiable manner within blocks, and a state database (current world state) that maintains the current state of the blockchain. There may be one distributed ledger per channel, and each peer maintains a copy of that distributed ledger for each channel of which it is a member. This blockchain is an input log configured as hash-linked blocks, and each block contains an array of N inputs. A block can include various components as shown in FIG. 5D. The link of a block can be generated by adding the hash of the header of the previous block into the block header of the current block. In this way, all inputs on the blockchain are arranged and cryptographically linked together, preventing the blockchain data from being tampered with without breaking the hash link. Further, for the link, the latest block in the blockchain represents all inputs added prior to it. This blockchain may be stored in a peer file system (local or connected storage) that supports an append-only blockchain workload.

[0175] The current state of the blockchain and the distributed ledger can be stored in the state database. Here, the current state data represents the latest values of all keys that have been included in the input log of the blockchain. Inputs that counter the current state in the state database are executed by smart contract executable code calls. To make the interaction of this smart contract executable code as efficient as possible, the latest values of all keys are stored in the state database. The state database may include an indexed view into the input log of the blockchain and can thus be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) when the peer starts up, before inputs are accepted.

[0176] The endorser node receives an input from a client and endorses the input based on the result of the simulation. The endorser node holds a smart contract that simulates input proposals. When the endorser node endorses an input, the endorser node creates an input endorsement, which is a signed response from the endorser node to the client application indicating the endorsement of the simulated input. The method of endorsing an input depends on an endorsement policy that can be specified within the smart contract executable code. An example of an endorsement policy is that "a majority of the endorsing peers must endorse the input". If the channel is different, the endorsement policy may also be different. The endorsed input is transferred by the client application to the ordering service.

[0177] The ordering service receives the endorsed input, orders it within a block, and delivers the block to the commit peers. For example, the ordering service can start a new block when the threshold of the input is reached, when the timer times out, or under other conditions. In this example, the blockchain node is the commit peer that received the data block 582A for storage on the blockchain. The ordering service can be composed of a cluster of orderers. The ordering service does not process inputs or smart contracts or maintain a shared ledger. Rather, the ordering service can receive the endorsed input and specify the order in which the input is committed to the distributed ledger. The architecture of the blockchain network can be designed such that a particular "ordering" implementation is a detachable component.

[0178] Entries are written into the distributed ledger in a consistent order. When the order of the entries is established and committed to the network, it is ensured that the update to the state database is effective. Different from the cryptocurrency blockchain system where the order is assigned by decrypting cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism most suitable for their network.

[0179] Referring to FIG. 5D, the block 582A (also referred to as a data block) stored in the blockchain and / or the distributed ledger can include a plurality of data segments such as a block header 584n, transaction-specific data 586A to 586n, and block metadata 588A to 588n. It should be understood that the various blocks and their contents shown, such as block 582A and its contents, are for illustrative purposes only and do not mean to limit the scope of the exemplary embodiments. In some cases, both the block header 584A and the block metadata 588A may be smaller than the transaction-specific data 586A that stores the input data, but this is not a requirement. Block 582A can store the transaction information of N inputs (for example, 100, 500, 1000, 2000, 3000, etc.) in block data 590A to 590n. Block 582A can also include a link to the previous block (for example, on the blockchain) in block header 584A. In particular, block header 584A can include the hash of the header of the previous block. Block header 584A may also include a unique block number, the hash of the block data 590A of the current block 582A, and the like. The block number of block 582A is unique and can be assigned in ascending / sequential order starting from zero. The first block in the blockchain is sometimes called the genesis block and contains information about the blockchain, its members, the data stored therein, and the like.

[0180] The block data 590A can store the input information of each input recorded within the block. For example, the input data can include one or more of the following: type of input, version, timestamp, channel ID of the distributed ledger, input ID, epoch, payload visibility, smart contract executable code path (deploy tx), smart contract executable code name, version of the smart contract executable code, input (smart contract executable code and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (list of keys and versions read by the input, etc.), write set (list of keys and values, etc.), start key, end key, list of keys, Merkle tree query summary, etc. The input data may be stored for each of the N inputs.

[0181] In one embodiment, block data 590A may also store transaction-specific data 586A. This data adds additional information to the hash-linked chain of blocks in the blockchain. Thus, data 586A can be stored in an immutable log of changes to blocks on the distributed ledger. Some of the advantages of storing such data 586A are reflected in the various embodiments disclosed and shown herein. Block metadata 588A can store multiple fields of metadata (e.g., byte arrays, etc.). The metadata fields can include a signature regarding block creation, a reference to the latest configuration block, an input filter that identifies valid and invalid inputs within the block, the latest offset of the ordering service that ordered the block, and the like. The signature, the latest configuration block, and the ordering-side metadata may be added by the ordering service. On the other hand, a block committer (such as a blockchain node) can add valid / invalid information based on an endorsement policy, inspection of read / write sets, and the like. The input filter can include a byte array of a size equal to the number of inputs in the block data and an inspection code that specifies whether the input was valid / invalid.

[0182] Other blocks 582B - 582n in the blockchain also have headers, files, and values. However, unlike the first block 582A, the headers 584A - 584n in the other blocks each contain the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the header of the immediately preceding block or may be the hash value of the entire immediately preceding block. By including the hash value of the previous block in each of the remaining blocks, it is possible to trace from the Nth block to the genesis block (and the associated original file) for each block, as shown by arrow 592, and establish an inspectable and immutable evidence preservation.

[0183] Figure 5E shows the processing 500E of new blocks added to the distributed ledger 520E according to an exemplary embodiment, and Figure 5D shows the content of the new data block structure 530E of Figure 5E for the blockchain according to an exemplary embodiment. Referring to Figure 5E, a client (not shown) can present a transaction to the blockchain nodes 511E, 512E, and / or 513E. The client can be a command received from any source to perform activities on the blockchain 522E. As an example, the client can be an application that operates on behalf of a requester, such as a device, a person, or an entity, to propose a transaction to the blockchain. A blockchain network may have different types of blockchain nodes / peers, including endorser peers that simulate and endorse transactions proposed by the client, inspection peers that inspect the endorsements, verification peers that verify the transactions, and commit peers that commit the transactions to the distributed ledger 520E. In this example, the blockchain nodes 511E, 512E, and 513E can perform the role of endorser nodes, commit nodes, or both.

[0184] The distributed ledger 520E includes a blockchain that stores records arranged immutably within a block, and a state database 524E (current world state) that maintains the current state of the blockchain 522E. There may be one distributed ledger 520E per channel, and each peer maintains a copy of that distributed ledger 520E for each channel that it is a member of. The blockchain 522E is a transaction log configured as hash-linked blocks, and each block contains an array of N transactions. The link of the blocks (indicated by the arrows in Figure 5E) can be generated by adding the hash of the header of the previous block into the block header of the current block. In this way, all transactions on the blockchain 522E are arranged and cryptographically linked together, preventing the blockchain data from being tampered with without breaking the hash link. Further, for the purpose of linking, the latest block within the blockchain 522E represents all transactions added prior to it. The blockchain 522E may be stored in a peer file system (local or connected storage) that supports an append-only blockchain workload.

[0185] The current state of the blockchain 522E and the distributed ledger 520E can be stored in the state database 524E. Here, the current state data represents the latest values of all keys that have been included in the transaction log of the blockchain 522E so far. Transactions that counteract the current state within the state database 524E are executed by chaincode calls. To make the interaction of these chaincode calls as efficient as possible, the latest values of all keys are stored in the state database 524E. The state database 524E may include an indexed view into the transaction log of the blockchain 522E and can thus be regenerated from the chain at any time. The state database 524E may be automatically restored (or generated as needed) when the peer starts up, before transactions are accepted.

[0186] The endorsing node receives a transaction from the client and approves the transaction based on the result of the simulation. The endorsing node holds a smart contract that simulates the transaction proposal. When the endorsing node endorses a transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on an endorsement policy that can be specified within the chain code. An example of an endorsement policy is that "a majority of the endorsing peers must endorse the transaction". If the channel is different, the endorsement policy may also be different. The endorsed transaction is transferred by the client application to the ordering service 510E.

[0187] The ordering service 510E receives the endorsed transaction, orders it within a block, and delivers the block to the committing peer. For example, the ordering service 510E can start a new block when the threshold of transactions is reached, when the timer times out, or under other conditions. In the example of Figure 5E, the blockchain node 512E is the committing peer that has received a new data block 530E for storage on the blockchain 522E. The first block in the blockchain is sometimes called the genesis block and contains information about the blockchain, its members, the data stored therein, and so on.

[0188] The ordering service 510E can be composed of a cluster of orderers. The ordering service 510E does not process transactions or smart contracts, nor does it maintain a shared ledger. Rather, the ordering service 510E can accept endorsed transactions and specify the order in which those transactions are committed to the distributed ledger 520E. The blockchain network architecture can be designed such that a particular "ordering" implementation is a detachable component.

[0189] Transactions are written to the distributed ledger 520E in a consistent order. When the order of the transactions is established and committed to the network, it is ensured that the updates to the state database 524E are valid. Different from a cryptocurrency blockchain system where the order is given by decrypting a cryptographic puzzle or mining, in this example, the parties of the distributed ledger 520E can choose the ordering mechanism most suitable for the network.

[0190] When the ordering service 510E initializes a new data block 530E, the new data block 530E can be broadcast to commit peers (e.g., blockchain nodes 511E, 512E, and 513E). In response, each commit peer verifies the transactions within the new data block 530E by a check to confirm that the read set and write set still match the current world state of the state database 524E. Specifically, the commit peer can determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state of the state database 524E. Once the commit peer has verified the transaction, the transaction is written to the blockchain 522E on the distributed ledger 520E, and the state database 524E is updated with the write data from the read / write set. If the transaction fails, i.e., the commit peer detects that the read / write set does not match the current world state within the state database 524E, the transactions ordered in the block are still included in that block but are marked as invalid and the state database 524E is not updated.

[0191] Referring to 500F in FIG. 5F, the new data block 530 (also referred to as a data block) stored on the blockchain 522E of the distributed ledger 520E shown in FIG. 5E, the block 582A (also referred to as a data block) can include a plurality of data segments such as a block header 540, block data 550, block metadata 560, etc. It should be understood that the various illustrated blocks and their contents, such as the new data block 530 and its contents shown in FIG. 5F, are merely examples and do not mean to limit the scope of the exemplary embodiments. The new data block 530 can store transaction information of N transactions (for example, 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 550. The new data block 530 can also include a link to the previous block (for example, on the blockchain 522E of FIG. 5E) in the block header 540. In particular, the block header 540 can include the hash of the header of the previous block. The block header 540 can also include a unique block number, the hash of the block data 550 of the new data block 530, etc. The block number of the new data block 530 is unique and can be assigned in various orders, such as starting from zero and increasing / continuing in sequence.

[0192] The block data 550 can store the transaction information of each transaction recorded in the new data block 530. For example, the transaction data can include one or more of the following: the type of the transaction, version, timestamp, the channel ID of the distributed ledger 520E (shown in FIG. 5E), transaction ID, epoch, payload visibility, chain code path (deploy tx), chain code name, version of the chain code, input (chain code and function), client (creator) identifiers such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, chain code event, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkle tree query summary, etc. The transaction data can be stored for each of the N transactions.

[0193] In one embodiment, the blockchain data 563 includes predicted power outage data including the severity and duration associated with a predicted upcoming power outage at a location. In FIG. 5F, the blockchain data 563 is illustrated within the block data 550, but the blockchain data 563 may be placed within the block header 540 or the block metadata 560.

[0194] The block metadata 560 can store multiple fields of metadata (e.g., byte arrays, etc.). The metadata fields can include a signature related to block creation, a reference to the latest configuration block, a transaction filter for identifying valid and invalid transactions within the block, the latest offset of the ordering service that ordered the block, and so on. The signature, the latest configuration block, and the ordering-side metadata may be added by the ordering service 510E in FIG. 5E. On the other hand, a block committer (such as the blockchain node 512E in FIG. 5E) can add valid / invalid information based on an endorsement policy, inspection of read / write sets, and so on. The transaction filter can include a byte array of a size equal to the number of transactions in the block data and an inspection code for specifying whether the transaction was valid / invalid.

[0195] Other blocks 582B to 582n in the blockchain also have headers, files, and values. However, unlike the first block 582A, the headers 584A to 584n in the other blocks each include the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the header of the immediately preceding block or may be the hash value of the entire immediately preceding block. By including the hash value of the previous block in each of the remaining blocks, it is possible to trace from the Nth block to the genesis block (and the associated original file) for each block as shown by the arrow 592, establishing verifiable and immutable evidence preservation.

[0196] An exemplary memory medium may be coupled to a processor such that the processor can read from and write to the memory medium. Alternatively, the memory medium may be integral with the processor. The processor and the memory medium can be disposed within an application specific integrated circuit (ASIC). Alternatively, the processor and the memory medium may exist as separate components. For example, FIG. 6 shows an exemplary computer system architecture 600, which can represent the above-described components and the like and may be integrated with the above-described components and the like.

[0197] FIG. 6 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein. Nevertheless, the computing node 600 is implementable and / or capable of performing the above-described functions.

[0198] The computing node 600 includes a computer system / server 602 operable in a number of other general purpose or special purpose computing system environments and configurations. Examples of well-known computing systems, environments, and / or configurations that may be used in conjunction with the computer system / server 602 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, mobile or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including the above systems or devices.

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

[0200] As shown in FIG. 6, the computer system / server 602 of the cloud computing node 600 is shown in the form of a general-purpose computing device. The components of the computer system / server 602 may include, but are not limited to, one or more processors or processing units 604, a system memory 606, and a bus that couples various system components including the system memory 606 to the processor 604.

[0201] The bus represents 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. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0202] The computer system / server 602 typically includes various computer system-readable media. Such media can be any available media that can be accessed by the computer system / server 602 and includes both volatile and non-volatile media, as well as removable and non-removable media. System memory 606, in one example, implements the flow diagrams of other figures. System memory 606 can include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 608 and / or cache memory 610. The computer system / server 602 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, memory 606 can be provided for reading and writing to a non-removable non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading and writing to a removable non-volatile magnetic medium (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media can be provided. In such cases, each can be connected to the bus by one or more data media interfaces. As further shown and described below, memory 606 can include at least one program product having a set of program modules (e.g., at least 1) configured to execute the functions of the various embodiments of the present application.

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

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

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

[0206] At least one exemplary embodiment of a system, method, and non-transitory computer-readable medium is shown in the accompanying drawings and has been described in the foregoing detailed description, but the present application is not limited to the disclosed embodiments, and it will be understood that numerous arrangement substitutions, modifications, and replacements are possible as defined in the following claims. For example, one or more of the modules or components described herein, or in a distributed architecture, can perform the capabilities of the systems of the various figures and can include a transmitter, a receiver, or pairs of both. For example, all or part of the functions performed by an individual module may be performed by one or more of this module. Further, the functions described herein can be performed inside or outside of a module or component, at various times, and in connection with various events. Also, the information transmitted between various modules can be transmitted between 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, the messages transmitted and received by a module may be transmitted and received directly and / or via one or more of other modules.

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

[0208] Note that some of the system functions described in this specification are presented as modules to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit consisting of a custom very large scale integration (VLSI) circuit or gate array, off-the-shelf semiconductors such as logic chips and transistors, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, or graphics processing unit.

[0209] A module may be implemented, at least in part, in software for execution by various types of processors. A unit of the specified executable code can include one or more physical or logical blocks of computer instructions that can be configured, for example, as objects, procedures, or functions. Nevertheless, it is not necessary to physically place the identified executable modules together, but they can be included when logically connected together and can include entirely different instructions stored in different locations that achieve the purpose of the module description. Further, a module may be stored on a computer-readable medium that can be, for example, a hard disk drive, flash device, random access memory (RAM), tape, or other such medium used for storing data.

[0210] In fact, a module of executable code can be a single instruction or multiple instructions, and further, it can be distributed across several different code segments, in different programs, and across several memory devices. Similarly, the arithmetic data can be identified and shown within the module, can be embodied in any suitable form, and can be organized within any suitable type of data structure. The arithmetic data may be collected as a single data set or may be distributed in different locations including different storage devices and may exist, at least in part, simply as electronic signals on a system or network.

[0211] It will be readily understood that the components of the present application can be arranged and designed in a wide variety of different configurations, as generally described and illustrated in this drawing. Accordingly, the detailed description of the embodiments is not intended to limit the claims of the present application, but merely to represent selected embodiments of the present application.

[0212] Those skilled in the art will readily understand that the above can be implemented using different sequences of steps and / or hardware elements of different configurations than those disclosed. Accordingly, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations are apparent.

[0213] While preferred embodiments of the present application are described, the described embodiments are merely illustrative, and it should be understood that the scope of the present application should be defined only by the appended claims, taking into account both equivalents and modifications of all scopes to the appended claims (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method comprising the following steps: Determining, by a vehicle, the severity and duration associated with a predicted power outage at a location; Determining, by the vehicle, an optimal charge amount of the vehicle's battery, determined by the severity and duration, before the predicted power outage; Comparing, by the vehicle, the current charge amount of the vehicle with the optimal charge amount; Charging, by the vehicle, the battery to the optimal charge amount when the current charge amount is less than the optimal charge amount.

2. The method according to claim 1, comprising the following steps: Providing, by the vehicle, the optimal charge amount from the battery to the location in response to the occurrence of the predicted power outage.

3. The method according to claim 1, comprising the following steps: Determining, by the vehicle, whether at least one of the severity and the duration changes; Providing, by the vehicle, an additional charge amount from the vehicle's battery to the location in response to an increase in at least one of the severity and the duration.

4. The method according to claim 1, wherein the step of determining the optimal charge amount of the vehicle's battery is associated with the energy consumption at the location.

5. The method according to claim 1, comprising the following steps: When the location includes an energy storage device within the site, supplying energy to the location using the energy storage device within the site during the predicted power outage; Monitoring the state of charge of the energy storage device within the site while the energy storage device within the site is supplying energy to the location; and Supplying energy to the location using the vehicle when the state of charge of the energy storage device within the site approaches zero.

6. The method according to claim 1, comprising the following steps: When the location includes another vehicle, supplying energy to the location using the other vehicle during the predicted power outage; Monitoring the state of charge of the other vehicle while the other vehicle is supplying energy to the location; and Supplying energy to the location using the vehicle when the state of charge of the other vehicle approaches zero.

7. The method according to claim 1, comprising the following steps: Updating, by the vehicle, the severity and the duration associated with the predicted power outage during the predicted power outage. When at least one of the severity or length is increasing, a step of turning off the power supply of at least one device at the location. **Claim 8** A system comprising a processor and a memory, The processor and the memory are connected so as to be able to transmit information, The processor, Determines, by the vehicle, the severity and length associated with a predicted power outage at a location, Before the predicted power outage, determines, by the vehicle, the optimal charge amount of the battery of the vehicle determined by the severity and length, Compares, by the vehicle, the current charge amount of the battery of the vehicle with the optimal charge amount, A system in which when the current charge amount is less than the optimal charge amount, the vehicle charges the battery to the optimal charge amount. **Claim 9** In response to the occurrence of the predicted power outage, The system according to claim 8, wherein the processor provides the optimal charge amount from the battery to the location. **Claim 10** The system according to claim 8, The processor, Determines, by the vehicle, whether at least one of the severity and the length changes, In response to at least one of the severity and the length increasing, provides an additional charge amount from the battery of the vehicle to the location. **Claim 11** The system according to claim 8, wherein the processor determines the optimal charge amount of the battery of the vehicle related to the energy consumption at the location. **Claim 12** The system according to claim 8, The location includes an energy storage device within the site, The processor, Using the energy storage device within the site, instructs the supply of energy to the location in response to the predicted power outage, While the energy storage device within the site is supplying energy to the location, monitors the charge state of the energy storage device within the site, and, When the charge state of the energy storage device within the site approaches zero, instructs the supply of energy to the location using the vehicle. **Claim 13** The system according to claim 8, The location includes another vehicle, The processor, Using the other vehicle, instructs the supply of energy to the location in response to the predicted power outage, While the other vehicle is supplying energy to the location, monitors the charge state of the other vehicle, and, When the state of charge of the other vehicle approaches zero, instruct the vehicle to supply energy to the location.

14. The system according to claim 8, wherein the processor updates, by means of the vehicle, the severity and the length associated with the predicted power outage during the predicted power outage, and cuts off the power supply of at least one device at the location when at least one of the severity or the length is increasing.

15. A computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform the following processes: determine, by means of the vehicle, the severity and the length associated with a predicted power outage at a location, determine, by means of the vehicle, an optimal charge level of the battery of the vehicle, determined by the severity and the length, before the predicted power outage, compare, by means of the vehicle, the current charge level of the battery with the optimal charge level, and charge, by means of the vehicle, the battery to the optimal charge level when the current charge level is below the optimal charge level.

16. In response to the occurrence of the predicted power outage, The computer-readable storage medium according to claim 15, further comprising an instruction to provide the optimal charge level from the battery to the location.

17. The computer-readable storage medium according to claim 15, further comprising the following instructions: determine, by means of the vehicle, whether at least one of the severity and the length changes, and provide an additional charge amount from the battery of the vehicle to the location in response to an increase in at least one of the severity and the length.

18. The computer-readable storage medium according to claim 15, wherein the determination of the optimal charge level of the battery of the vehicle is associated with the energy consumption at the location.

19. The computer-readable storage medium according to claim 15, further comprising the following instructions: when the location includes another vehicle, supply energy to the location by means of the other vehicle during the predicted power outage, monitor the state of charge of the other vehicle while the other vehicle is supplying energy to the location, and supply energy to the location by means of the vehicle when the state of charge of the other vehicle approaches zero.

20. A computer-readable storage medium according to claim 15, further comprising the following instructions: During the predicted power outage, update the severity and the length associated with the predicted power outage by the vehicle, If at least one of the severity or the length is increasing, cut off the power of at least one device at the location.

Images