Power storage management anticipated to peak usage time

Abstract

Example operations include one or more of the following: estimating a power peak time at a location; and preparing for peak use prior to the time, wherein the preparing comprises: charging the battery at the location to a level associated with an end time of peak use; and notifying the location to maintain the charge level.

Description

Background Art

[0001] Vehicles or conveyances, such as cars, motorcycles, trucks, airplanes, trains, etc., generally provide transportation needs for passengers and / or cargo in various ways. Functions associated with the conveyance can be recognized and used by various computing devices such as smart phones or computers located on and / or outside the conveyance. Summary of the invention

[0002] An example embodiment provides a method comprising one or more of: estimating a peak time of electricity usage at a location; and preparing for peak usage prior to the time, wherein the preparation comprises: charging a battery at the location to a level associated with an end time of peak usage; and notifying the location to maintain the charge level.

[0003] Yet another example embodiment provides a system comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of: estimating a peak time of electricity usage at a location; and preparing for peak usage prior to the time, wherein the preparation comprises: charging a battery at the location to a level associated with an end time of peak usage; and notifying the location to maintain the charge level.

[0004] Yet another example embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: estimating a peak time of electricity usage at a location; and preparing for peak usage prior to the time, wherein the preparation comprises: charging a battery at the location to a level associated with an end time of peak usage; and notifying the location to maintain the charge level. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1A According to an example embodiment, an example flow chart is illustrated.

[0006] Figure 1B According to an example embodiment, a power management network diagram is illustrated.

[0007] Figure 2A According to an example embodiment, a transportation network diagram is illustrated.

[0008] Figure 2B According to an illustrative embodiment, yet another transportation network diagram is illustrated.

[0009] Figure 2C According to an example embodiment, a power management network diagram is illustrated.

[0010] Figure 2DYet another power management network diagram is illustrated, according to an example embodiment.

[0011] Figure 2E According to an example embodiment, yet another transportation network diagram is illustrated.

[0012] Figure 2F According to an example embodiment, a diagram depicting electrification of one or more components is illustrated.

[0013] Figure 2G According to an example embodiment, diagrams depicting the interconnections between various elements are illustrated.

[0014] Figure 2H Yet another diagram depicting the interconnections between various elements is illustrated, according to an example embodiment.

[0015] Fig.2I Yet another diagram depicting interconnections between elements is illustrated, according to an example embodiment.

[0016] Figure 2J Another diagram depicting a keyless entry system is illustrated, according to an example embodiment.

[0017] Figure 2K Another diagram depicting a CAN within a vehicle is illustrated, according to an example embodiment.

[0018] Figure 2L According to an example embodiment, another diagram depicting an end-to-end communication channel is illustrated.

[0019] Figure 2M Another diagram depicting an example of a vehicle using security credentials for secure V2V communications is illustrated, according to an example embodiment.

[0020] Figure 2N Another diagram depicting an example of a vehicle interacting with a secure processor and a wireless device is illustrated according to an example embodiment.

[0021] Figure 3A According to an example embodiment, a flow chart is illustrated.

[0022] Figure 3B Yet another flow chart is illustrated according to an example embodiment.

[0023] Figure 3C Yet another flow chart is illustrated, according to an example embodiment.

[0024] Figure 4 According to an example embodiment, a machine learning transportation network graph is illustrated.

[0025] Figure 5AAccording to an example embodiment, an example vehicle configuration for managing database transactions associated with a vehicle is illustrated.

[0026] Figure 5B According to an example embodiment, another example vehicle configuration for managing database transactions between various vehicles is illustrated.

[0027] Fig. 6A According to an example embodiment, a blockchain architecture configuration is illustrated.

[0028] Figure 6B According to an example embodiment, another blockchain configuration is illustrated.

[0029] Figure 6C According to an example embodiment, a blockchain configuration for storing blockchain transaction data is illustrated.

[0030] Fig.6D According to an example embodiment, example data blocks are illustrated.

[0031] Figure 7 An example system is illustrated to support one or more example embodiments. DETAILED DESCRIPTION

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

[0033] Communications between a vehicle and certain entities, such as remote servers, other vehicles, and local computing devices (e.g., smartphones, personal computers, vehicle embedded computers, etc.) may be sent and / or received and processed by one or more "components", which may be hardware, firmware, software, or a combination thereof. The component may be part of any of these entities or computing devices or certain other computing devices. In one example, consensus decisions related to blockchain transactions may be made by one or more computing devices or components associated with the vehicle (which may be any of the elements described and / or depicted herein), as well as one or more components external to the vehicle or at a location remote from the vehicle.

[0034] The features, structures or characteristics of the present invention as described in this specification may be combined in any appropriate manner in one or more embodiments. For example, the use of the phrase "exemplary embodiment", "some embodiments" or other similar language throughout this specification refers to the fact that a specific feature, structure or characteristic described about the embodiment may be included in at least one example. Therefore, the appearance of the phrase "exemplary embodiment", "in some embodiments", "in other embodiments" or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures or characteristics may be combined in any appropriate manner in one or more embodiments. In the diagram, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. In the current solution, the means of transport may include one or more of a car, a truck, a pedestrian zone battery electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that can be used to transport people and / or goods from one place to another.

[0035] In addition, although the term "message" may be used in the description of the embodiments, other types of network data may also be used, such as packets, frames, datagrams, etc. In addition, although certain types of messages and signaling may be described in exemplary embodiments, they are not limited to a certain type of message or signaling.

[0036] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of: a vehicle (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status status data received in the form of communication messages (such as wireless data network communications and / or wired communication messages) can be processed to identify vehicle / vehicle status status and provide feedback on the status and / or changes of the vehicle. In one example, a user profile can be applied to a specific vehicle / vehicle to authorize a current vehicle event, a service stop at a service station, authorize subsequent vehicle rental services, and enable inter-vehicle communications.

[0037] Within the communication infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an immutable data structure (i.e., a distributed ledger) that can only be appended, which is able to keep records between mutually untrusting parties. Mutually untrusting parties are referred to as peers, nodes, or peer nodes in this article. Each peer keeps a copy of the database record, and no single peer can change the database record without reaching a consensus between the decentralized peers. For example, peers can execute a consensus protocol to verify blockchain storage entries, group storage entries into blocks, and build a hash chain through blocks. The process forms a ledger by sorting storage entries as needed, taking into account consistency. In a public or non-permissioned blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). In contrast, a permissioned blockchain database can protect interactions between a group of entities that have a common goal but do not trust or cannot fully trust each other, such as businesses that exchange funds, goods, information, etc. The solution can operate in permissioned and / or permissionless blockchain environments.

[0038] Smart contracts are trusted distributed applications that take advantage of the tamper-proof nature of a shared or distributed ledger (which can be in the form of a blockchain) and the underlying protocol between member nodes (called endorsements or endorsement policies). Typically, blockchain entries are "endorsed" before being submitted to the blockchain, and unendorsed entries are ignored. A typical endorsement policy allows the smart contract executable code to specify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to the peers specified in the endorsement policy, the entry is executed to verify the entry. After verification, the entry enters the sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed entries grouped into blocks.

[0039] A node is a communication entity of a blockchain system. A "node" can perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submit client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit entries, and maintain the state and copy of the ledger of blockchain entries. Peers can also play the role of endorsers. Ordering service nodes or orderers are nodes that run communication services for all nodes, which implement delivery guarantees, such as broadcasts to every peer node in the system when submitting entries and changing the world state of the blockchain. The world state can constitute the initial blockchain entry that typically includes control and setup information.

[0040] The ledger is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can originate from smart contract executable code calls (i.e., entries) submitted by participating parties (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for each channel of which they are a member.

[0041] A chain is a log of entries made up of hash-linked blocks, with each block containing a series of N entries, where N is equal to or greater than 1. The block header includes the hash of the block's entries, as well as the hash of the previous block's block header. In this way, all entries on the ledger can be arranged in sequence and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every entry on the chain that appeared before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage device, cloud, etc.), effectively supporting append-only nature of blockchain workloads.

[0042] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain's entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Smart contract executable code calls execute entries against the current state data of the ledger. In order to make the interaction of these smart contract executable code efficient, the latest values ​​of the keys can be stored in the state database. The state database can be just an indexed view of the chain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when a peer node starts and before an entry is accepted.

[0043] Blockchain differs from traditional databases in that blockchain is not a central storage, but a decentralized, immutable, secure storage where nodes must share changes to records in the storage. Some properties inherent in blockchain and that contribute to the implementation of blockchain include but are not limited to immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc.

[0044] Example embodiments provide services to a specific vehicle and / or a user profile applied to the vehicle. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. A vehicle may need service at intervals, and service requirements may require authorization before being allowed to receive service. In addition, a service center may provide services to vehicles in a nearby area based on the current route plan and relative level of service requirements of the vehicle (e.g., immediate, severe, medium, slight, etc.). Vehicle requirements may be monitored via one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer device in the vehicle and / or away from the vehicle. The data is forwarded to a management server for review and action. The sensor may be located at one or more of the following: the interior of a transport, the exterior of a transport, a fixed object separated from the transport, and other transports near the transport. The sensor may also be associated with the speed of the transport, the braking of the transport, the acceleration of the transport, the fuel level, the service requirement, the shifting of the transport, the steering of the transport, etc. The sensor as described herein may also be a device, such as a wireless device in and / or near a transport. Additionally, sensor information may be used to identify whether the vehicle is operating safely and whether the occupants encounter any unexpected vehicle conditions, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be generated and submitted to an immutable ledger determined by a permissioned consortium, thereby in a "decentralized" manner, such as via a blockchain member group.

[0045] Each stakeholder (i.e., owner, user, company, institution, etc.) may wish to limit exposure of private information, so the blockchain and its immutability can be used to manage permissions for each specific user vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify collision and / or degradation events, identify safety concern events, identify parties to events, and provide distribution to registered entities seeking access to such vehicle event data. In addition, results can be identified and necessary information can be shared among registered companies and / or individuals based on consensus laws associated with the blockchain. This approach cannot be implemented on traditional centralized databases.

[0046] Various drive systems of the present solution can utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (LIDAR) projectors, radars, ultrasonic sensors, etc. to create terrain and road maps that vehicles can use for navigation and other purposes. In some embodiments, instead of LIDAR, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles.

[0047] In certain embodiments, the present solution includes authorizing a vehicle for a service via an automatic and rapid authentication scheme. For example, travel to a charging station or fuel pump can be performed by a vehicle operator or an autonomous vehicle, and authorization to receive charge or fuel can be performed without any delay as long as the service and / or charging station receives the authorization. The vehicle can provide a communication signal that provides an identification of the vehicle, which has a profile of current activity linked to an account authorized to receive service, which can be corrected later by compensation. Additional measures can be used to provide further authentication, such as other identifiers that can be wirelessly sent from the user's device to the service center to replace or supplement the first authorization work between the vehicle and the service center with additional authorization work.

[0048] The shared and received data may be stored in a database that is in a single database (e.g., a database server) and typically maintains data in one specific location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is generally accessible from multiple different points. Due to its single location, a centralized database is easy to manage, maintain, and control, especially for security. Within a centralized database, data redundancy is minimized because a single storage location for all data also means that there is only one master record for a given set of data. Blockchain can be used to store data and transactions related to transportation vehicles.

[0049] Any actions described herein may be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), host units, etc.) that may be located on or off a vehicle. The one or more processors may communicate with other processors located on other vehicles or off other vehicles to utilize data sent by the vehicle. The one or more processors and the other processors may send data, receive data, and utilize the data to perform one or more actions described or depicted herein.

[0050] Figure 1A According to an example embodiment, an example flow chart 100 is illustrated. Figure 1A As shown in the example flow chart 100, in certain embodiments, the present solution includes a power management system 102 that estimates peak electricity usage times at a location, such as a residence or commercial enterprise, and prepares the location for peak electricity usage before the peak electricity usage times occur. In one embodiment, the power management system 102 and the location may be part of an electric power transmission and distribution network. In other embodiments, the power management system 102 may be used in other contexts to prepare a location for peak electricity usage times before the peak electricity usage times, where the location relies on electricity to support various types of operations at the location. In one embodiment, the power management system 102 includes a processor 104 and a transceiver 106. In one embodiment, the location may include one or more fixed and / or mobile charge storage devices and / or charge generating devices.

[0051] See also Figure 1A, each charge storage device 108, 110 at the location may have a known or discoverable charge storage capacity and may store a detectable charge level. In addition, each charge generating device at the location may have a known or discoverable charge generating potential. In one embodiment, a location may have one or more vehicle charge storage devices 108 associated therewith, and one or more other charge storage devices and / or charge generating devices 110 associated therewith. The vehicle charge storage device 108 may include a battery associated with a vehicle such as a car. The other charge storage devices and / or charge generating devices 110 may include fixed batteries, such as wall-mounted batteries, and batteries associated with appliances at the location. In addition, it may include solar panels and wind generators (e.g., wind turbines). In one embodiment, a processor of the vehicle charge storage device 108, directed by software executed thereon, may access data 112 from a charge level sensor and / or memory associated with the vehicle charge storage device 108, such as the charge level and / or charge storage capacity stored by the charge storage device 108, and provide access to the data 112. In one embodiment, a processor of the other charge storage device and / or charge generating device 110 directed by software executed thereon can access data 114 from charge level sensors and / or memories associated with the other charge storage devices, and / or memories associated with the charge generating devices, such as the charge levels and / or charge storage capabilities and / or charge generating capabilities respectively stored by the other charge storage devices and / or charge generating devices 110, and provide access to the data 114.

[0052] In one embodiment, data 112 may be accessed via a communication component of a vehicle associated with vehicle charge storage device 108, and data 114 may be accessed via a communication component of other charge storage devices and / or charge generating device 110 for transmission from processors associated with such devices to power management system 102 or otherwise providing access to power management system 102.

[0053] In one embodiment, the power management system 102 may receive transmissions of the data 112 and 114 provided from the processors of the vehicle charge storage device 108 and other charge storage devices and / or the charge generating device 110. In other embodiments, the power management system 102 may obtain the data 112 and 114 by retrieving data provided from the processors of the vehicle charge storage device 108 and other charge storage devices and / or the charge generating device 110.

[0054] In one embodiment, based on analysis of data 112 and 114 and other data that may be maintained by power management system 102, which may include but is not limited to the expected duration of an upcoming event, power usage patterns, and power usage during similar past events, processor 104 may estimate peak power usage times for a region and locations within the region, such as Figure 1A As shown in 116. In one embodiment, the other data can be obtained by the processor 104 from a memory component of a server that serves as a host for the power management system 102. In other embodiments, the other data can be obtained by the processor 104 from a processor associated with a server that does not serve as a host for the power management system 102, or from a processor associated with a remote server that stores relevant data, such as weather-related data, electrical equipment / grid-related data, etc. that can be transmitted over a network, in an associated memory component. During peak electricity usage times, locations within the area that are experiencing peak usage are at risk of losing power supply. Therefore, it is useful to understand the amount of charge that a location in the area should maintain to ensure that its power needs are met during peak usage times.

[0055] In one embodiment, the processor 104 can estimate the peak usage time using software that identifies past events with similar characteristics to the expected upcoming event (using data from a database or other data repository associated with previous similar events) to estimate the peak usage time of the upcoming event. In one embodiment, the database or other repository can be located in a memory associated with one or more servers or other computer systems that serve as a host for the power management system 102, or in a memory associated with a server that does not host the power management system 102, but stores weather-related data, electrical equipment / grid-related data, etc. The processor 104 associated with the power management system 102 can access the database under the guidance of software for accessing data stored in the database to obtain information to be used as part of the estimation of the peak usage time. Similarly, in one embodiment, the processor 104 can determine the amount of charge that a location in the area should maintain in order to ensure that its power needs are met by executing software to identify data in the database, the database including but not limited to data related to power usage at the location during previous similar events. In other embodiments, other ways of estimating peak usage times and / or determining the amount of charge that a location should maintain can be used. For example, other ways to estimate peak usage times and / or determine the amount of charge that a location should maintain may include, but are not limited to, determining power usage and stored charge at other similar locations during similar past events, or using a computer simulated location with similar characteristics to the location to estimate power usage and stored charge.

[0056] In one embodiment, after estimating the peak usage time, the processor 104 can prepare the location for the peak usage time before the peak usage time, such as Figure 1A As shown in 118. The processor 104 can prepare the location for the peak usage time before the peak usage time by prompting the battery at the location to be charged to a level associated with the end time of peak usage, as shown in 118a. In one embodiment, the charging of the battery can be prompted by the processor 104 to send a communication to the transceiver of the user device and / or one or more battery chargers, such as the charge level associated with the end time of peak usage. In an embodiment, the software of the user device can direct the processor of the user device to (in conjunction with the display processing circuit) cause the received charge level to be presented to the end user via the display. The user can then set the battery charger control to charge the battery to the indicated charge level. In addition, in an embodiment, the software of the battery charger can direct the processor of the battery charger to (in conjunction with the display processing circuit) cause the received charge level to be presented to the end user via the display of the battery charger, and / or when the battery charger is configured and has been granted (such as granted by the owner / user) permission in response to a command received from the power management system 102, start charging the battery to the received charge level. In one embodiment, the level associated with the end of peak usage time may be a charge level that has been determined to be sufficient to last for the duration of the peak usage time, and in particular, sufficient to last until the end of the peak usage time.

[0057] Additionally, as part of preparing the location for peak usage, the processor 104 may notify the location to maintain a charge level stored by one or more charge storage systems at the location, as shown at 118b. In one embodiment, the processor 104 may notify the location to maintain the charge level by sending information or providing access to information 120 and 122. In one embodiment, the processor 104 may notify the location to maintain the charge level by sending a notification to one or more user devices and / or one or more battery chargers associated with the location, which notification may be presented on a display associated with the one or more user devices and / or one or more battery chargers.

[0058] In one embodiment, the estimation includes identifying other locations with energy storage and / or energy generation capabilities within the region including the location, and the corresponding types and quantities of energy storage and energy generation capabilities. In one embodiment, other locations within the region including the location may have known or discoverable charge storage capabilities in a manner similar to the location itself, and may store a determinable level of charge. In addition, these locations may have known or discoverable charge generation potentials. In one embodiment, the power management system 102 may obtain this information by sending a request to a user device of a user associated with the other location to provide this information or information related to the brand and model of the charge storage and charge generation system at the location (the power management system 102 may use this information to determine the appliance specifications, such as from a lookup table stored in a memory associated with the power management system 102). If the appliance at the location is networked, the processor 104 of the power management system 102 may send a request for the information to the appliance network, and based on the request, a processor associated with the appliance network and directed by software executed thereon may access the requested information from the memory associated with the appliance network and provide it to the processor 104 of the power management system 102. This information, which can be collected from each location in a region, can be used to accurately determine the overall electricity usage of the region, and enable accurate estimation of the charge level that should be stored at various locations in the region.

[0059] In one embodiment, each location may be a residential location. In other embodiments, each location may be a commercial or business location. In one embodiment, the energy storage capability may include, but is not limited to, energy storage capability provided by one or more batteries. In one embodiment, the energy generation capability may include, but is not limited to, energy generation capability provided by one or more wind turbines or one or more solar panels.

[0060] In one embodiment, the estimation may include identifying other locations in the region including the location that may need power during peak usage times and determining when the other locations may need power during peak usage times. For example, in one embodiment, the power management system 102 may develop a profile for each location in the region that indicates when the location uses power, the amount of power the location uses during those times, and when the location does not use power. In one embodiment, based on this and other information, the power management system 102 may determine the charge level that batteries associated with vehicles and other appliances at the location need to maintain.

[0061] In one embodiment, charging the battery at the location to a level associated with the end time of peak usage may include determining a charge storage capacity at the location and a likely power usage at the location. In embodiments, determining the charge storage capacity at the location may include determining a charge storage capacity of a battery and / or a charge storage capacity of another charge storage device at the location. Additionally, determining the charge storage capacity at the location may include accessing charge storage capacity data from the location. In other embodiments, determining the charge storage capacity at the location may include accessing charge storage capacity data stored in a database or other repository associated with the power management system 102.

[0062] In one embodiment, determining the possible power usage at the location may include determining the possible power usage of each power-consuming load at the location. In one embodiment, the power-consuming loads at the location may include, but are not limited to, electrical devices that consume electricity at the location, such as appliances and lights. In one embodiment, appliances may include, but are not limited to, refrigerators, stoves, air conditioning systems, computer systems, and the like. In one embodiment, determining the possible power usage of each power-consuming load at the location may include analyzing the power usage of each power-consuming load relative to past time periods, events, and the like. For example, the power usage of each power-consuming load during past power outages associated with peak usage times affecting the location. In particular, past peak usage times that are similar in one or more aspects to expected upcoming peak usage times. For example, peak usage times that are expected to have a duration similar to upcoming peak usage times.

[0063] In one embodiment, the charge associated with each battery at the location can be transferred to or shared with one or more other batteries at the location. In one embodiment, a wired or wireless power transmission system can be used to transfer or share the charge associated with each battery at the location. For example, the power transmission system can be a system for transmitting electrical energy from one battery to another with or without a wire as a physical link between the batteries. In one embodiment, the batteries can be networked, and the charge stored in one battery can be transferred from the battery to another battery, or shared by the battery with one or more other batteries under the guidance of software associated with the power transmission system, and the software controls the power transmission circuit, which enables the flow of power through the wired or wireless link. In one embodiment, the power management system can control the operation of the power transmission system by directing the processor 104 to send instructions to the power transmission system to guide the battery to share the charge with one or more other batteries or transfer the charge to one or more other batteries. In other embodiments, the user can control the operation of the power transmission system by setting controls at the location. In one embodiment, the user can set the control based on a message received from the power management system 102 or independent of the communication from the power management system.

[0064] In one embodiment, a change in the estimate of the end time of peak usage may result in a change in the charge level associated with the end time of peak usage (e.g., the charge level to which the battery will be charged). In one embodiment, a change in the estimate of the end time of peak usage may result in a change in the charge level associated with the end time of peak usage (e.g., a charge level in a lookup table assigned based on the estimated duration of the peak usage time) when the conditions upon which the charge level determination is based change. For example, when the estimate of the duration of the peak usage time changes, the charge level associated with the end time of peak usage may change so that the battery at the location can be charged to a level sufficient to support the power needs of the location for the duration of the peak usage time.

[0065] In one embodiment, preparing for peak usage prior to the peak usage time further comprises controlling the electrical loads at the location by prioritizing the consumption of power by one or more electrical loads. In one embodiment, controlling the electrical loads at the location comprises controlling the amount of power delivered to the one or more electrical loads through the outlets. In other embodiments, automatically controlling the electrical loads at the location may comprise directly controlling the operation of one or more electrical loads, for example, by controlling the “on”, “off” or other setting of the electrical appliances that comprise the loads.

[0066] Figure 1B According to an example embodiment, a power management network diagram is illustrated. Figure 1B Location 150 is shown, which includes a vehicle 152, a vehicle storage device 154, a fixed storage device 156, other location storage devices 158, and a charge generating device 160. Sensors (not shown) associated with the vehicle 152, the vehicle storage device 154, the fixed storage device 156, the other location storage devices 158, and the charge generating device 160 capture data, which is provided to the processor 104 ( Figure 1A In the processor 104 ( Figure 1A ) can receive the data and pass the data and the power management system 102 ( Figure 1A ) may be maintained to estimate peak usage times at location 150 and prepare location 150 for such peak usage times, as described in reference to Figure 1A described.

[0067] The current application may prompt the battery at location 150 to be charged to a battery provided by power management system 102 ( Figure 1A ) and notifies location 150 to maintain the charge level so that location 150 can prepare for the peak power consumption before the peak power consumption occurs. The current application can send a message to one or more processors associated with the battery charging action at location 150 to charge the battery at location 150 to the level determined by power management system 102 ( Figure 1A ) level determined.

[0068] In embodiments, the charge level stored by the battery can be determined by various methods. In one embodiment, the charge level can be determined by coulomb counting. In other embodiments, the charge level can be determined using methods including but not limited to chemical, voltage, current, filtering, and pressure methods. In other embodiments, other methods for determining charge level can be used.

[0069] In one embodiment, the charge level of each battery associated with a particular device / appliance at location 150 may be determined in order to determine the required charge level for location 150. Furthermore, the charge level associated with each battery may be shared / given / exchanged based on actual usage.

[0070] For example, in a residence that presents a refrigerator with a battery associated therewith having a first charge level, an HVAC with a battery associated therewith having a second charge level, and an occupant who is not home when they should be, there may be an opportunity to set the temperature to 78 degrees instead of 76 degrees. The energy saved by adjusting the temperature in this manner may be stored (rather than used), or may be applied to running other appliances, such as a refrigerator in a garage that may require more power than expected due to the temperature / humidity in the garage.

[0071] In one embodiment, as part of preparing location 150 for an upcoming peak electricity usage period, power management system 102 ( Figure 1A ) can take action to ensure that the battery associated with the electric vehicle is charged to full capacity at location 150. This can serve as a means of offsetting the power used during peak usage times, as charging of the battery associated with the electric vehicle during these times can be avoided. Similarly, in one embodiment, the local storage at location 150 can also be fully charged in advance of the expected peak usage time. In one embodiment, charging the electric vehicle to full capacity at location 150 can involve charging the electric vehicle to a level higher than the level to which the electric vehicle is normally charged.

[0072] In one embodiment, as part of preparing location 150 for an upcoming peak electricity usage period, power management system 102 ( Figure 1A ) can identify the electric transportation vehicle and the local storage unit at the location 150. In addition, the power management system 102 ( Figure 1A ) can identify other locations with power generation capabilities in the area including location 150, such as locations with solar devices, wind turbines, and / or other power generation devices. In embodiments, knowledge of the charge storage system and power generation system informs the charging portion and the notification portion to prepare the location for upcoming peak power usage times. In embodiments, this can be done per household in the area.

[0073] In one embodiment, as part of preparing location 150 for an upcoming peak hour, the power management system may notify the user not to use power stored at location 150. This guidance may differ from what the user expects from power management system 102 ( Figure 1A ). For example, when a peak in electricity consumption is approaching, the user may not be aware of this and they may pay more for electricity during this period. In such cases, the user may be advised not to use the stored electricity but to store it for use during the peak period. In one embodiment, the user may receive a signal from the processor 104 ( Figure 1A ) advises the user not to use the stored power, and the notification message can be received by the user device and presented to the user on its display.

[0074] In one embodiment, as part of preparing location 150 for an upcoming peak electricity usage period, power management system 102 ( Figure 1A ) can notify the user not to use the electricity generated at location 150 (such as through solar or wind power), but to store the electricity. In one embodiment, as processor 104 ( Figure 1A) may be a part of a notification message sent by the user device, which may notify the user not to use the generated power. The notification message may be received by the user device and presented to the user on its display. Figure 1A ) can inform users that it may be wise to sell power back to the grid during peak usage times because of the increased revenue potential at this time if they wish to take advantage of this. Power management system 102 ( Figure 1A ) can provide details including the potential income that can be generated.

[0075] In one embodiment, a distribution system operator (DSO) may be used to allocate and manage the transmission of electricity from generation sources to end consumers. The DSO may use smart meters that allow bidirectional reading of power flow and real-time communication. In one embodiment, the DSO may be used where there are electric vehicles associated with a location such as a home.

[0076] The flowcharts depicted in this article, such as Figure 1A , Figure 2C , Figure 2D , Figure 2E , Figure 3A , Figure 3B and Figure 3C are separate examples, but may be the same or different embodiments. Any operation in one flowchart may be adopted and shared with other flowcharts. No example operation is intended to limit any embodiment or the subject matter of the corresponding claims.

[0077] Figure 2A According to example embodiment, the transportation means network diagram 200 is illustrated.This network comprises the element that comprises transportation means 202 and transportation means 202 ', and transportation means 202 comprises processor 204, and transportation means 202 ' comprises processor 204 '.Transportation means 202,202 ' communicate with each other via processor 204,204 ', and comprise transceiver, transmitter, receiver, storage device, sensor and other elements that can provide communication (not shown).Communication between transportation means 202,202 ' can directly occur, occurs via dedicated and / or public network (not shown), or occurs via other transportation means and comprises one or more elements in processor, memory and software.Although being depicted as single transportation means and processor, multiple transportation means and processor can exist.One or more applications, features, steps, solutions etc. described and / or depicted herein can be utilized and / or provided by element of the present invention.

[0078] Figure 2BAccording to example embodiment, another vehicle network diagram 210 is illustrated.This network comprises the element that comprises vehicle 202 and vehicle 202', and vehicle 202 comprises processor 204, and vehicle 202' comprises processor 204'.Vehicle 202,202' communicates with each other via processor 204,204', and comprises transceiver, transmitter, receiver, storage device, sensor and other elements that can provide communication (not shown).Communication between vehicle 202,202' can directly occur, occurs via dedicated and / or public network (not shown), or occurs via other vehicles and comprises one or more elements in processor, memory and software.Processor 204,204' can also communicate with one or more elements 230, comprises sensor 212, wired device 214, wireless device 216, database 218, mobile phone 220, vehicle 222, computer 224, I / O device 226 and voice application 228. The processors 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

[0079] Although depicted as a single vehicle, processor, and element, multiple vehicles, processors, and elements may exist. Information or communication may occur to and / or from any one of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204, which may initiate vehicle 202 to take action, which may further provide information or additional information to processor 204', which may initiate vehicle 202' to take action, which may further provide information or additional information to mobile phone 220, vehicle 222, and / or computer 224. One or more applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by elements of the present invention.

[0080] Figure 2C According to an example embodiment, a power management network diagram 240 is illustrated. The network includes elements including a power management system 202, which includes a processor 204 and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer readable medium 242C and ( Figure 2B ) element 230. The power management system 202 can be a computer system, a server, or any device including a processor and a memory.

[0081] The processor 204 performs one or more of the following: estimating a peak time of electricity usage at a location (244C) and preparing for peak usage prior to the time (246C), wherein the preparation includes: charging a battery at the location to a level associated with the end time of peak usage (248C), and notifying the location to maintain the charge level (250C).

[0082] Figure 2D According to an example embodiment, another power management network diagram 250 is illustrated. The network includes elements including a power management system 202, which includes a processor 204 and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and ( Figure 2B ) element 230. The power management system 202 can be a computer system, a server, or any device including a processor and a memory.

[0083] The processor 204 performs one or more of the following: the estimating includes identifying other locations with energy storage and / or energy generation capabilities within the area including the location, and the corresponding types and quantities of energy storage and energy generation capabilities (244D), the estimating includes identifying other locations within the area including the location that will require power during peak usage times, and determining when the other locations will require power during peak usage times (245D); charging the battery at the location to a level associated with the end time of peak usage includes determining the energy storage capacity at the location and the likely energy usage at the location (246D); and determining the energy storage capacity of the battery at the location and the likely energy usage of the battery at the location (247D); and determining the energy storage capacity of the battery at the location and the likely energy usage of the battery at the location (248D). The charge associated with the battery can be transferred to or shared with one or more other batteries at the location, wherein the battery at the location is fixed and movable, and wherein the other batteries at the location are fixed (247D); the notification provides an indication of the amount of charge to be maintained by each battery at the location, whether the one or more batteries at the location are to receive charge from the local energy generation system, and the amount of charge to be received by the one or more batteries from the local energy generation system (248D); and the preparation also includes automatically controlling electrical loads at the location by setting a level at which one or more electrical loads consume power (249D).

[0084] Figure 2E According to an exemplary embodiment, yet another transportation network diagram 260 is illustrated. Figure 2E, the network diagram 260 includes a vehicle 202 connected to other vehicles 202' and an update server node 203 through a blockchain network 206. Vehicles 202 and 202' may represent vehicles / vehicles. The blockchain network 206 may have a ledger 208 for storing software update verification data and a verification source 207 for future use (e.g., for auditing).

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

[0086] Processor 204 performs one or more of the following: receiving confirmation of the event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus between peers represented by any of the elements (244E), and executing a smart contract based on the blockchain consensus to record the confirmation on the blockchain (246E). Consensus is formed between any element 230 and / or any element described or depicted herein, including one or more of a transport, a server, a wireless device, etc. In another example, transport 202 can be any element 230 and / or any element described or depicted herein, including one or more of a server, a wireless device, etc.

[0087] The processor and / or computer readable medium 242E may be completely or partially present inside or outside the vehicle. The steps or features stored in the computer readable medium 242E may be performed in whole or in part by any processor and / or element in any order. In addition, one or more steps or features may be added, omitted, combined, performed later, etc.

[0088] Figure 2FThe diagram 265 depicting the electrification of one or more elements is illustrated. In one example, a vehicle 266 can provide power stored in its battery to one or more elements, including other vehicles 268, charging stations 270, and power grids 272. Power grids 272 are coupled to one or more charging stations 270, which can be coupled to one or more vehicles 268. This configuration allows for distribution of electricity / power received from the vehicle 266. The vehicle 266 can also interact with other vehicles 268, such as via vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. The vehicle 266 can also interact with other vehicles 268, charging stations 270, and / or power grids 272 wirelessly and / or in a wired manner. In one example, the vehicle 266 is routed to (or it routes itself to) power grids 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the present solution, the vehicle 266 can provide energy to one or more elements depicted herein in various advantageous ways as described and / or depicted herein. Additionally, transportation safety and efficiency may be improved, and the environment may be positively impacted as described and / or depicted herein.

[0089] The term "energy" may be used to refer to any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be referred to in conjunction with a source of charging voltage and / or current supplied from an entity to a vehicle during a charging / using operation. Energy may also be in the form of fossil fuels (e.g., for use with hybrid vehicles) or with the aid of alternative energy sources, including but not limited to lithium-based fuel cells, nickel-based fuel cells, hydrogen fuel cells, atomic / nuclear energy, fusion energy, and energy generated on-the-fly during energy sharing and / or using operations used to increase or decrease the energy level of one or more vehicles at a given time.

[0090] In one example, the charging station 270 manages the amount of energy transferred from the vehicle 266 so that there is enough power remaining in the vehicle 266 to reach the destination. In one example, the wireless connection is used to wirelessly guide a certain amount of energy transfer between the vehicles 268, where the vehicles can all be in motion. In one example, an idle vehicle such as the vehicle 266 (which can be an autonomous vehicle) is guided to provide a certain amount of energy to the charging station 270 and return to the original location (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 268 and transfer the stored excess energy at the charging station 270. In one example, factors determine the amount of energy to be transferred to the charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (weight, etc.), occupant schedules when using the vehicle, potential occupant schedules waiting for the vehicle, etc. In one example, the vehicle 268, the charging station 270 and / or the power grid 272 can provide energy to the vehicle 266.

[0091] In one embodiment, a location such as a building, residence, or the like (not shown) may be communicatively coupled to one or more of the power grid 272, the vehicle 266, and / or the charging station 270. Based on external conditions such as weather, the rate at which electrical current flows to one or more of the location, the vehicle 266, the other vehicles 268 is modified. For example, when the outside temperature is extremely high or low, increasing the likelihood of a power outage, the current flowing to the connected vehicles 266 / 268 is slowed to help minimize the likelihood of a power outage.

[0092] In one example, the solutions described and depicted herein may be used to determine load impacts on a vehicle and / or system, provide energy to the vehicle and / or system based on future demand and / or priority, and provide intelligence between a device containing a module and a vehicle, allowing a processor of the device to wirelessly communicate the amount of energy stored in a battery on the vehicle. In one example, these solutions may also be used to provide charge from a vehicle to a location based on factors such as the temperature at the location, the cost of energy, and the power level at the location. In one example, these solutions may also be used to manage the amount of energy remaining in a vehicle after a portion of the charge is transferred to a charging station. In one example, these solutions may also be used to notify a vehicle to provide a certain amount of energy from a battery on the vehicle, where the amount of energy to be transferred is based on the distance of the vehicle to the module receiving the energy.

[0093] In one example, these solutions can also be used to use a mobile energy storage unit that uses a determined path to travel to a vehicle with excess energy and deposits the stored energy into the grid. In one example, these solutions can also be used to determine the priority of the vehicle's need to provide energy to the grid, as well as the priority of the vehicle's current needs, such as the priority of passengers, or upcoming passengers, or current cargo, or upcoming cargo. In one example, these solutions can also be used to determine that when the vehicle is idle, the vehicle decides to maneuver to a certain location, release excess energy to the energy grid, and then return to the previous location. In one example, these solutions can also be used to determine the amount of energy required by the vehicle based on one or more conditions, such as weather, traffic, road conditions, car conditions, and passengers and / or cargo in other vehicles, to provide the required energy to another vehicle via a vehicle-to-vehicle energy transfer, and instruct the vehicle to route to another vehicle and provide energy. In one example, these solutions can also be used to transfer energy from a moving vehicle to another moving vehicle. In one example, these solutions may also be used to obtain energy from a vehicle based on the energy consumed by the vehicle to reach a meeting location with another vehicle, provide the service, and the estimated energy consumed to return to the original location. In one example, these solutions may also be used to provide the remaining distance required to the charging station, and the charging station determines the amount of energy to be obtained from the vehicle, where the remaining power is based on the remaining distance. In one example, these solutions may also be used to manage vehicles that are simultaneously charged by more than one point (such as both a charging station via a wired connection and another vehicle via a wireless connection). In one example, these solutions may also be used to apply priority to the allocation of energy to vehicles, where priority is given to those vehicles that provide a portion of their stored charge to other entities such as power grids, residences, etc.

[0094] In one embodiment, vehicles 266 and 268 can be used as bidirectional vehicles. Bidirectional vehicles are those that can act as mobile microgrids that can assist in supplying power to the grid 272 and / or reducing power consumption when the grid is stressed. Bidirectional vehicles incorporate bidirectional charging, and in addition to receiving a charge to the vehicle, the vehicle can also take energy from the vehicle and "push" energy back to the grid 272, also known as "V2G." In bidirectional charging, the current flows in both directions; to the vehicle and out of the vehicle. When the vehicle is charged, alternating current (AC) from the grid 272 is converted to direct current (DC). This can be done by the vehicle's own converter or one or more of the converters on the charger 270. Energy stored in the vehicle's batteries can be sent back to the grid in the opposite direction. The energy is converted from DC to AC by a converter that is typically located in the charger 270 (also known as a bidirectional charger). In addition, as described with respect to Figure 2F The solution described and depicted may be used in this network and / or system and in other networks and / or systems.

[0095] Figure 2G275 is a diagram showing the interconnection between different elements 275. The present solution may be stored in whole or in part on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287' and 277' associated with various entities, all of which are communicatively coupled and communicate with the network 286. The database 287 is communicatively coupled to the network and allows 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 means of transport 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, a power grid / charging station 284, a microphone 285 and / or other means of transport 277. Other entities and / or devices, such as one or more private users using a smart phone 278, a laptop 280, an augmented reality (AR) device, a virtual reality (VR) device and / or any wearable device, may also interact with the present solution. Smartphone 278, laptop 280, microphone 285 and other devices can be connected to one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287' and 277'. One or more public buildings 281 can include various institutions. One or more public buildings 281 can utilize computing device 281'. One or more service providers 279 can include dealers, towing services, collision centers or other repair shops. One or more service providers 279 can utilize computing device 279'. These various computer devices can be directly and / or communicatively coupled to each other, such as via a wired network, a wireless network, a blockchain network, etc. In one example, microphone 285 can be used as a virtual assistant. In one example, one or more traffic infrastructure 282 can include one or more traffic lights, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructure 282 can utilize computing device 282'.

[0096] In one example, the transport 277 / 276 can transport personnel, objects, permanent or temporarily fixed devices, etc. In one example, the transport 277 can communicate with the transport 276 via V2V communication, through a computer associated with each transport 276' and 277', and can be referred to as a transport, a car, a vehicle, a motor vehicle, etc. The transport 276 / 277 can be a self-propelled wheeled vehicle, such as a car, a sports utility vehicle, a truck, a bus, a van, or other motor or battery-driven or fuel cell-driven transport. For example, the transport 276 / 277 can be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle with a fuel cell stack, a motor and / or a generator. Other examples of vehicles include bicycles, scooters, trains, airplanes or ships, and any other form of vehicle capable of transport. The transport 276 / 277 can be semi-autonomous or autonomous. For example, the transport 276 / 277 can automatically operate and navigate without manual input. An autonomous vehicle may have and use one or more sensors and / or navigation units to autonomously drive itself.

[0097] In one example, the solutions described and depicted herein can be used to determine access to a vehicle via a consensus of a blockchain. In one example, these solutions can also be used to perform profile verification before allowing an occupant to use a vehicle. In one example, these solutions can also be used to enable a vehicle to indicate (visually, but in another example, verbally, etc.) the action (the action can be pre-recorded) that a user needs to perform on or from the vehicle, and verify that it is the correct action. In one example, these solutions can also be used to provide a capability for the vehicle to determine how to fork the data based on the risk level associated with the data and the driving environment, and distribute a portion of the forked data with a lower risk level in a safe driving environment to the occupant, and then distribute the remaining portion of the forked data with a higher risk level to the occupant after the occupant leaves the vehicle. In one example, these solutions can also be used to process the transfer of vehicles across borders (such as countries / states / etc.) using blockchains and / or smart contracts, and apply the rules of the new area to the vehicle.

[0098] In one example, these solutions can also be used to allow the transport to continue to operate outside the boundary when the transport reaches a consensus based on the characteristics of the transport's operation and the transport's occupants. In one example, these solutions can also be used to analyze the available data upload / download speed of the transport, the size of the file, and the driving speed / direction of the transport to determine the distance required to complete the data upload / download, and specify the safe area boundary for the data upload / download to be performed. In one example, these solutions can also be used to perform usually dangerous maneuvers in a safe manner, such as when the system determines that an exit is coming, and when the transport does not seem to be ready to exit (for example, in an incorrect lane or at a speed that is not conducive to the upcoming exit), and instruct the object transport and other adjacent transports to allow the object transport to exit in a safe manner. In one example, these solutions can also be used to use the one or more vehicles to verify the diagnosis of the other transports when one or more vehicles and other transports are in motion.

[0099] In one example, these solutions may also be used to detect lane usage at a certain time of day at a certain location to notify the occupants of the transport or guide the transport to suggest or not suggest a lane change. In one example, these solutions may also be used to eliminate the need to send information by mail, and the need for the driver / occupant to respond by mail or in person to make a payment. In one example, these solutions may also be used to provide services to the occupants of the transport, wherein the services provided are subscription-based, and wherein permissions are obtained from other transports connected to the occupant's profile. In one example, these solutions may also be used to record changes in the condition of a rental object. In one example, these solutions may also be used to seek blockchain consensus from other transports close to the damaged transport. In one example, these solutions may also be used to receive media from a transport computer that may be related to an accident from a server such as an insurance entity server. The server accesses one or more media files to access the damage to the transport and stores the damage assessment on the blockchain. In one example, these solutions may also be used to obtain consensus from multiple devices at different times before an event related to the transport to determine the severity of the event.

[0100] In one example, these solutions can also be used to address the lack of video evidence for vehicle-related accidents. The current solution details the query of accident-related media by the vehicle involved in the accident from other vehicles that may be close to the accident. In one example, these solutions can also be used to record specific parts of a damaged vehicle using the vehicle and other equipment (e.g., pedestrians' cell phones, street light cameras, etc.).

[0101] In one example, these solutions can also be used to warn passengers when the transport is approaching a dangerous area and / or event, thereby allowing the transport to notify passengers or a central controller of potential dangerous areas on or near the current transport route. In one example, these solutions can also be used to detect when the transport is traveling at a high speed, using at least one other transport to help reduce the speed of the transport in a way that minimizes traffic. In one example, these solutions can also be used to identify dangerous driving situations, wherein the vehicles involved in the dangerous driving situation capture media. A geo-fence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geo-fence. In one example, these solutions can also be used to send a notification to one or more passengers of the transport that the transport is approaching a traffic control sign on the road, and then if the transport passes through the sign, then receive instructions for bad driving from other nearby transports. In one example, these solutions can also be used to make the transport partially inoperable by (in some embodiments) limiting speed, limiting the ability to approach other vehicles, limiting speed to a maximum value, and only allowing a given number of miles allowed per time period.

[0102] In one example, these solutions can also be used to overcome the need to rely on software updates to correct problems with a transport when the transport is not operating correctly. By observing other transports on the route, the server will receive data from possible multiple other transports that observe unsafe or incorrect operation of the transport. Through analysis, these observations may result in notifications to the transport when the data indicates that the operation is unsafe or incorrect. In one example, these solutions can also be used to provide notifications between a transport and a potential dangerous situation involving a person outside the transport. In one example, these solutions can also be used to send data to the server through a device associated with an accident of the transport, or a device near the accident. Based on the severity of the accident or attempted accident, the server notifies the sender of the data. In one example, these solutions can also be used to provide suggestions for operating the transport to the driver or occupant of the transport based on the analysis of the data. In one example, these solutions can also be used to establish a geographic fence associated with a physical structure and determine the payment responsibility for the transport. In one example, these solutions can also be used to use the current state at a certain location and the future state proposed by using the navigation destination of other vehicles to coordinate the ability to return the car at this location. In one example, these solutions may also be used to coordinate the ability to automatically schedule vehicle returns at locations such as transportation rental entities.

[0103] In one example, these solutions can also be used to move the transport to other locations based on the user's event. More specifically, the system tracks the user's device and modifies the transport to be moved near the user at the end of the original event or the modified event. In one example, these solutions can also be used to allow the existing transport in the area to verify the available locations in the area. The approximate time that a certain location may be vacated is also determined based on the verification from the existing transport. In one example, these solutions can also be used to move the transport to a closer parking space when a parking space becomes available and the time elapsed since the initial parking is less than the average time of the event. In addition, the transport is moved to the final parking space when the event is completed or according to the position of the device associated with at least one occupant of the transport. In one example, these solutions can also be used to plan parking before the upcoming crowd. The system interacts with the transport, provides some services at a price lower than the full price, and / or guides the transport to an alternative parking location based on the priority of the transport, thereby improving the optimization of the parking situation before arrival.

[0104] In one example, these solutions can also be used to sell fractional ownership of a vehicle, or to determine pricing and availability for ride-sharing applications. In one example, these solutions can also be used to provide accurate and timely dealer sales activity reports that go far beyond what is currently available. In one example, these solutions can also be used to allow dealers to request assets through blockchain. By using blockchain, consensus is obtained before any asset is moved. In addition, the process is automated and payments can be initiated through blockchain. In one example, these solutions can also be used to arrange agreements with multiple entities (such as service centers) where consensus is obtained and actions (such as diagnosis) are performed. In one example, these solutions can also be used to associate digital keys with multiple users. The first user can be the operator of the vehicle, and the second user is the responsible party of the vehicle. These keys are authorized by a server, where the proximity of the keys is verified against the location of the service provider. In one example, these solutions can also be used to determine the services required at the destination of the vehicle. Locate one or more service locations that can provide the required services, the service location services are both in the area on the route to the destination, and have the availability to perform the services. The navigation of the vehicle is updated using the determined service locations. Identify the smart contract containing the compensation value of the service, and store the blockchain transaction in the distributed ledger of the transaction.

[0105] In one example, these solutions can also be used to dock the service provider's transport with the profile of the transport occupant to determine the services and goods that the occupant in the transport may be interested in. These services and goods are determined by the occupant's history and / or preferences. Then, the transport receives the quotation from the service provider's transport, and in another example, meets with the transport to provide services / goods. In one example, these solutions can also be used to detect the transport within the range and send service quotations (such as maintenance quotations, product quotations, etc.) to the transport. An agreement is reached between the system and the transport, and the system selects a service provider to provide the agreement. In one example, these solutions can also be used to assign one or more transports as road managers, wherein the road managers assist in controlling traffic. Road managers can generate road indicators (such as lights, displays, sounds) to help traffic flow. In one example, these solutions can also be used to remind the driver of the transport through a device, wherein the device can be a traffic light or near an intersection. When an event occurs, such as when the green light is on, and the transport in front of a column of transports does not move, a reminder is sent.

[0106] Figure 2H 290 is another block diagram showing the interconnection between different elements in an example. A vehicle 276 is presented, which includes ECUs 295, 296 and a head unit (also called infotainment system) 297. An electrical control unit (ECU) is an embedded system in automotive electronics that controls one or more electrical systems or subsystems in a vehicle. ECUs may include, but are not limited to, management of the vehicle's engine, braking system, transmission system, door locks, instrument panel, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's controller area network (CAN) bus 294. The ECU can also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as a vehicle computer) 298 can communicate with external elements, such as a server 293, via a network 292 (such as the Internet). Each ECU 295, 296 and head unit 297 can contain its own security policy. The security policy defines the allowable processing that can be performed in the appropriate context. In one example, the security policy may be provided in part or in whole in the vehicle computer 298 .

[0107] ECU 295, 296 and head unit 297 may each include a custom security function element 299 that defines authorized processes and the contexts in which these processes are allowed to run. Context-based authorization for determining the validity of whether a process can be executed allows the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's controller area network (CAN bus). When the ECU encounters an unauthorized process, the ECU can prevent the process from running. The automotive ECU can use different contexts to determine whether a process is running within its allowed boundaries, such as proximity contexts such as nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects, operational contexts such as an indication of whether the vehicle is moving or parked, the current speed of the vehicle, the state of the transmission, user-related contexts such as devices connected to the vehicle via wireless protocols, use of the infotainment system, cruise control, parking assistance, driving assistance, location-based contexts, and / or other contexts.

[0108] In one example, the solutions described and depicted herein can be used to make a vehicle partially inoperable by (in some embodiments) limiting speed, limiting the ability to approach other vehicles, limiting speed to a maximum, and only allowing a given number of miles allowed per time period. In one example, these solutions can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent to a server by a device associated with an accident of the vehicle, or a device near the accident. Based on the severity of the accident or attempted accident, the server notifies the sender of the data. In one example, these solutions can also be used to help the vehicle avoid accidents by querying servers of other vehicles near the accident, such as when the vehicle is involved in an accident. The server attempts to obtain data from other vehicles, so that the server can understand the nature of the accident from multiple vantage points. In one example, these solutions can also be used to determine that the sound from the vehicle is atypical, and send data related to the sound and possible source locations to the server, where the server can determine possible causes and avoid potential dangerous situations. In one example, these solutions can also be used to establish a location boundary via the system when the vehicle is involved in an accident. The boundary is based on the decibels associated with the accident. Multimedia content of the devices within the boundary is obtained to help further understand the circumstances of the accident. In one example, these solutions can also be used to associate a vehicle with an accident and then capture media obtained by a device near the accident location. The captured media is saved as a media fragment. The media fragment is sent to other computing devices, which build a sound profile of the accident. The sound profile will help understand more details closely related to the accident.

[0109] In one example, these solutions can also be used to record audio, video, motion, etc. using sensors to record areas where potential events are occurring, such as if a vehicle is in contact or may come into contact with other vehicles (while moving or parked), the system captures data from sensors that may be located on one or more vehicles and / or located on fixed or moving objects. In one example, these solutions can also be used to identify a new condition of a vehicle during a vehicle event using sensor data and compare that condition to a vehicle condition profile to determine that the vehicle is compromised, thereby enabling safe and reliable capture of critical data from a vehicle that is about to be involved in an adverse event.

[0110] In one example, these solutions may also be used to warn occupants of a vehicle when the vehicle determines, via one or more sensors, that it is approaching or traveling down a one-way street the wrong way. The vehicle has sensors / cameras / maps that interact with the systems of the current solutions. The system knows the geographic location of the one-way street. For example, the system may audibly notify the occupants that "one-way street is approaching." In one example, these solutions may also be used to allow vehicles to be paid, thereby allowing owners of autonomous vehicles to monetize the data collected and stored by their vehicle sensors, thereby incentivizing owners to share their data and providing entities with additional data to improve the performance of future vehicles, provide services to owners, etc.

[0111] In one example, these solutions may also be used to increase or decrease features of a vehicle based on the vehicle's actions over a period of time. In one example, these solutions may also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and equipment proximate to the vehicle is used to determine a condition of the vehicle. Partial ownership of the vehicle is determined based on the condition, and new responsibilities for the vehicle are specified. In one example, these solutions may also be used to provide data to a replacement / modification component, wherein the data attempts to subvert an authorized function of the replacement / modification component, and in response to non-subversion of the authorized function, allow the component to use the authorized function of the replacement / modification component.

[0112] In one example, these solutions can also be used to provide individuals with the ability to ensure that an occupant should board a transport and that the occupant is taken to a specific destination. In addition, the system ensures that the driver (if it is a non-autonomous transport) and / or other occupants have the right to interact with the occupant. In addition, the boarding, disembarkation, and location are noted. All of the above is stored on the blockchain in an immutable manner. In one example, these solutions can also be used to determine the characteristics of the driver by analyzing driving style and other factors to take action if the driver does not drive in a normal manner (such as the way the driver has previously driven in specific conditions, such as during the day, at night, in the rain, in the snow, etc.). In addition, the attributes of the transport are also taken into account. The attributes consist of weather, whether the headlights are on, whether navigation is used, whether the HUD is used, the volume of the media being played, etc. In one example, these solutions can also be used to notify occupants in the transport of dangerous conditions when the items in the transport indicate that the occupants may not be aware of the dangerous situation.

[0113] In one example, these solutions can also be used to mount a calibration device on a bracket fixed to a vehicle, where various sensors on the vehicle can automatically adjust themselves based on what the calibration device should detect compared to what is actually detected. In one example, these solutions can also be used to use blockchain to require multiple service centers to reach a consensus when a vehicle in need of service sends fault information, thereby allowing remote diagnostic functions, where other service centers are required to reach a consensus on the severity threshold of the data. Once the consensus is received, the service center can send the fail-safe level to the blockchain for storage. In one example, these solutions can also be used to determine the difference between sensor data outside the vehicle and the sensor data of the vehicle itself. The vehicle requests software from the server to correct the problem. In one example, these solutions can also be used to allow messaging between nearby or in-area vehicles when an event (such as a collision) occurs.

[0114] See also Fig.2I , illustrates an operating environment 290A for a connected vehicle according to some embodiments. As shown, a vehicle 276 includes a controller area network (CAN) bus 291A connecting elements 292A-299A of the vehicle. Other elements can be connected to the CAN bus, which is not shown here. The elements shown connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

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

[0116] Memory 297A is a non-temporary memory for storing instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include codes for performing the technology described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory or some other storage device. In certain embodiments, memory 297A may also include a non-volatile memory or similar permanent storage device and medium, which may include a hard drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device or some other large-capacity storage device for permanent storage of information. A part of memory 297A may be reserved for use as a buffer or a virtual random access memory (virtual RAM). Without departing from current solutions, transport 276 may include one or more memory 297A.

[0117] The memory 297A of the vehicle 276 may store one or more of the following types of data: navigation route data 295A and autonomous feature data 294A. In some embodiments, the memory 297A stores data that may be required for the navigation application 295A to provide functionality.

[0118] The navigation system 295A can describe at least one navigation route including a starting point and an end point. In some embodiments, the navigation system 295A of the transport 276 receives a request for a navigation route from a user, wherein the request includes a starting point and an end point. The navigation system 295A can query (via the network 292) a real-time data server 293, such as a server providing driving directions, for navigation route data corresponding to the navigation route including a starting point and an end point. The real-time data server 293 sends the navigation route data to the transport 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the transport 276.

[0119] ECU 293A controls the operation of many systems of vehicle 276, including ADAS system 294A. ECU 293A can, in response to instructions received from navigation system 295A, deactivate any unsafe and / or unselected autonomous features for the duration of a trip controlled by ADAS system 294A. In this way, navigation system 295A can control whether ADAS systems 294A are activated or enabled so that they can be activated for a given navigation route.

[0120] The sensor group 292A may include any sensor in the vehicle 276 that generates sensor data. For example, the sensor group 292A may include short-range sensors and long-range sensors. In some embodiments, the sensor group 292A of the vehicle 276 may include one or more of the following vehicle sensors: cameras, LIDAR sensors, ultrasonic sensors, automotive engine sensors, radar sensors, laser altimeters, intake manifold absolute pressure sensors, infrared detectors, motion detectors, thermostats, sound detectors, carbon monoxide sensors, carbon dioxide sensors, oxygen sensors, mass air flow sensors, engine coolant temperature sensors, throttle position sensors, crankshaft position sensors, valve timers, air-fuel ratio meters, blind spot meters, curb detectors, defect detectors, Hall effect sensors, parking sensors, radar guns, speedometers, speed sensors, tire pressure monitoring sensors, torque sensors, transmission oil temperature sensors, turbine speed sensors (TSS), variable reluctance sensors, vehicle speed sensors (VSS), water sensors, wheel speed sensors, GPS sensors, mapping capabilities, and any other type of automotive sensors. The navigation system 295A may store sensor data in the memory 297A.

[0121] The communication unit 298A sends and receives data to and from the network 292 or other communication channels. In some embodiments, the communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software required to make the vehicle 276 a DSRC-equipped device.

[0122] The vehicle 276 may interact with other vehicles 277 via V2V technology. In one example, V2V communication includes sensing radar information corresponding to a relative distance to an external object, receiving GPS information of the vehicle, setting an area as an area where other vehicles 277 are located based on the sensed radar information, calculating a probability that the GPS information of the target vehicle will be located in the set area, and identifying the vehicle and / or object corresponding to the radar information and the GPS information of the target vehicle based on the calculated probability.

[0123] In one example, the solutions described and depicted herein can be used to manage emergency situations and vehicle features when it is determined that the vehicle is about to enter an area without network access. In one example, these solutions can also be used to manage and provide features (such as audio, video, navigation, etc.) in the vehicle without a network connection. In one example, these solutions can also be used to determine when the profile of a person near the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0124] In one example, the solutions may also be used to analyze the availability of occupants in a respective vehicle for voice communications based on the amount of time remaining in the vehicle and the context of the communication to be conducted. In one example, the solutions may also be used to determine a two-level threat of a road congestion and receive a gesture that may indicate an alert that the congestion has not risen above a threshold, so that the vehicle continues along the road. In one example, the solutions may also be used to delete sensitive data from a vehicle when the vehicle has been damaged, rendering it unusable.

[0125] In one example, these solutions can also be used to verify whether the customer data to be eliminated has indeed been eliminated from all required locations within the enterprise to prove GDPR compliance. In one example, these solutions can also be used to provide compensation from one transport to other transports in exchange for data related to safety, important notifications, etc., thereby enhancing the autonomous capabilities of lower-level autonomous vehicles. In one example, these solutions can also be used to provide the transport with the ability to receive data based on a first biometric feature associated with an occupant. The transport then decrypts the encrypted data based on the verification of the second biometric feature, where the second biometric feature is a continuum of the first biometric feature. When only the occupant can receive unencrypted data, the transport provides the unencrypted data to the occupant, and deletes the sensitive portion of the unencrypted data when providing the sensitive portion, and deletes the non-sensitive portion after a period of time associated with the biometric feature has passed. In one example, these solutions can also be used to provide the transport with the ability to verify individuals based on the weight and grip pressure applied to the steering wheel of the transport. In one example, these solutions can also be used to provide a car with a feature that exists but is not currently enabled, thereby presenting a feature reflecting the characteristics of the occupant to the occupant of the motor vehicle.

[0126] In one example, these solutions can also be used to allow the modification of a transport, in particular the interior of the transport and the exterior of the transport, to reflect and assist at least one occupant. In another example, the reconstruction of the occupant's work and / or home environment is disclosed. If the system determines that the user is in "work mode" or "home mode", the system may try to "reconstruct" the user's work / home environment while the user is riding in the transport. All data related to the interior and exterior of the transport and the various occupants using the transport are stored on the blockchain and executed via smart contracts. In one example, these solutions can also be used to detect occupant gestures to assist in communicating with nearby transports, where the transport can maneuver accordingly. In one example, these solutions can also be used to provide a transport with the ability to detect expected gestures using a gesture definition data warehouse. In one example, these solutions can also be used to provide a transport with the ability to take various actions based on the user's gait and gestures. In one example, these solutions can also be used to ensure that the driver of a transport currently performing various operations (e.g., talking while driving with navigation turned on, etc.) does not exceed the number of unsafe operations before being allowed to make gestures.

[0127] In one example, these solutions can also be used to assign a state to each occupant in a transport and verify the occupant's gesture based on the occupant's state. In one example, these solutions can also be used to collect sound details related to the collision (at what position, in what direction, rising or falling, from what device, data related to the device, such as type, manufacturer, owner, and the number of sounds in the same period and the time when the sound is emitted, etc.), and provide them to the system, in which the analysis of the data helps to determine the details about the collision. In one example, these solutions can also be used to determine that the operation of the transport is unsafe. The transport includes a plurality of components that operate mutually to control the transport, and each component is associated with a separate component key. Send an encryption key to the transport to reduce the function of the transport. In response to receiving the encryption key, the transport disables one or more component keys. Disabling one or more component keys leads to one or more of the following: limiting the moving speed of the transport to no more than a given speed, limiting the transport to no more than a certain distance closer to other transports, and limiting the distance traveled by the transport to no more than a threshold distance.

[0128] In one example, these solutions can also be used to provide instructions from a specific vehicle (about to vacate a certain location) to another specific vehicle (seeking to occupy a certain location), and blockchain is used to perform authentication and coordination. In one example, these solutions can also be used to determine partial responsibility of a vehicle. For example, multiple people own a single vehicle, and the system uses the use of the vehicle that may change over a period of time to update partial ownership. Other embodiments will be included in this application, including minimum ownership of a vehicle that is not based on the use of the vehicle, but based on the availability of the vehicle, the determination of the driver of the vehicle, and other factors.

[0129] In one example, these solutions can also be used to allow a user in a transport to share his / her subscription with a closed group of people such as family members or friends. For example, a user may want to share a membership, and if so, the associated transaction will be stored in a blockchain or traditional database. When a user who is not a primary subscriber requests subscribed material, the blockchain node (i.e., the transport) can verify that the person requesting the service is an authorized person with whom the subscriber has shared a profile. In one example, these solutions can also be used to allow people to use auxiliary transport to reach their intended destination. When determining auxiliary transport, functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining what type of alternative transport to utilize) are used. In one example, these solutions can also be used to allow occupants in an accident to continue to their initial destination using other transport.

[0130] In one example, these solutions can also be used to propagate software / firmware uploads to a first subset of transport vehicles. The first group of transport vehicles tests the update, and when the test is successful, the update is propagated to another group of transport vehicles. In one example, these solutions can also be used to propagate software / firmware updates from the main transport vehicle to the vehicle, where the update is propagated from the first subset through the vehicle network, and then from a larger subset, and so on. A portion of the update can be sent first, and then the rest can be sent from the same vehicle or other vehicles. In one example, these solutions can also be used to provide updates to the transport computer to the devices of the transport vehicle and the transport operator / occupant. The update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicle and the device. The user does not have to do anything, just approach the vehicle and the function will happen automatically. A notification will be sent to the device indicating that the software update has been completed. In one example, these solutions can also be used to verify that the OTA software update is performed by a qualified technician, and that one or more transport components generate status related to the following: the initiator of the verification code, the process for wirelessly receiving the software update, the information contained in the software update, and the result of the verification.

[0131] In one example, these solutions may also be used to provide the ability for a software update located in a first component to be parsed by a second component. A first portion of a critical update and a second portion of a non-critical update are then verified, the verified first portion is assigned to a process in a vehicle, the verified first portion is run using the one process for a period of time, and in response to a positive result based on the period of time, the verified first portion is run using other processes after the period of time. In one example, these solutions may also be used to provide a selection of services to occupants, wherein the services are based on the profiles of occupants of the vehicle and shared profiles shared with the occupants' profiles. In one example, these solutions may also be used to store user profile data in a blockchain and intelligently present special offers and recommendations to users based on the user's automatically collected purchase history and preferences obtained from the user's profile on the blockchain.

[0132] In order for a vehicle to be adequately protected, the vehicle must be protected from both unauthorized physical access and 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. In another example, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications to and from the vehicle.

[0133] Electronic Control Units (ECUs) are nodes within a vehicle that control tasks such as activating windshield wipers to tasks such as anti-lock brakes. ECUs are usually connected to each other through a central network of the vehicle, which can be called a Controller Area Network (CAN). State-of-the-art features such as autonomous driving strongly rely on the implementation of new complex ECUs, such as advanced driver assistance systems (ADAS), sensors, etc. While these new technologies help improve vehicle safety and driving experience, they also increase the number of external communication units inside the vehicle, making them more vulnerable to attacks. The following are some examples of protecting vehicles from physical and remote intrusions.

[0134] Figure 2J According to an exemplary embodiment, a keyless entry system 290B is illustrated for preventing unauthorized physical access to a vehicle 291B. Figure 2JIn one example, the remote control key 292B sends a command to the vehicle 291B using a radio frequency signal. In this example, the remote control key 292B includes a transmitter 2921B having an antenna capable of sending a short-range wireless signal. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving a short-range wireless signal sent from the transmitter 2921B. The remote control key 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, for controlling the corresponding devices. Here, the memory (or CPU-accessible memory) of the CPUs 2922B and 2913B. In one example, the remote control key 292B and the vehicle 291B include power supplies 2924B and 2915B, respectively, for powering the corresponding devices.

[0135] When the user presses the button 293B on the remote control key 292B (or otherwise activates the remote control key, etc.), the CPU 2922B wakes up in the remote control key 292B and sends a data stream to the transmitter 2921B, which is output via the antenna. In other embodiments, the user's intention is confirmed on the remote control key 292B via other means, such as via a microphone that receives audio, a camera that captures images and / or video, or other sensors commonly used in the art to detect the user's intention, including receiving gestures, actions, eye movements, etc. The data stream can be a 64-bit to 128-bit long signal, which includes one or more of a preamble, a command code, and a rolling code. The signal can be sent at a rate between 2KHz and 20KHz, but the embodiment is not limited to this. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends a data stream to CPU 2913B, which decodes the signal and sends a command (e.g., lock door, open door, etc.) to command module 2912B.

[0136] If the remote control key 292B and the vehicle 291B use fixed codes between them, a replay attack can be performed. In this case, if the attacker is able to capture / sniff the fixed code during short-range communication, the attacker can replay this code to enter the vehicle 291B. To improve security, the remote control key and the vehicle 291B can use a rolling code that changes after each use. Here, the remote control key 292B and the vehicle 291B are synchronized with the initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. The remote control key 292B and the vehicle 291B also include a shared algorithm for modifying the initial seed 2914B each time the button 293B is pressed. The next key will take the result of the previous key press as input and transform it into the next number in the sequence. In some cases, the vehicle 291B can store multiple following codes (e.g., 255 following codes) in case the vehicle 291B does not detect the key on the remote control key 292B. Therefore, multiple key presses on the fob 292B that are not heard by the vehicle 291B do not prevent the vehicle from becoming out of sync.

[0137] In addition to the rolling code, the key fob 292B and the vehicle 291B may employ other methods to make the attack more difficult. For example, different frequencies may be used to transmit the rolling code. As another example, two-way communication between the transmitter 2921B and the receiver 2911B may be used to establish a secure session. As another example, the code may have a limited expiration time or timeout. In addition, as described with respect to Figure 2J The present solution described and depicted may be used in the present network and / or system and other networks and / or systems, including those described and depicted herein.

[0138] Figure 2K According to an exemplary embodiment, a controller area network (CAN) 290C within a vehicle is illustrated. Figure 2K , CAN 290C includes a CAN bus 297C having a high-level terminal and a low-level terminal, and a plurality of electronic control units (ECUs) 291C, 292C, 293C, etc. connected to the CAN bus 297C via a wired connection. The CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. The CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard) that allows ECUs 291C-293C to send commands to each other at the root level. At the same time, ECU 291C-293C represents a controller for controlling an electrical system or subsystem within a transport. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and many other features.

[0139] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send and receive messages to and from the CAN bus 297C. For example, the transceiver 2911C can convert data from the microcontroller 2912C to the format of the CAN bus 297C, and can also convert data from the CAN bus 297C to a format for the microcontroller 2912C. At the same time, in one example, the microcontroller 2912C interprets the message and also uses the ECU software installed therein to decide what message to send.

[0140] To protect the CAN 290C from cyber threats, various security protocols can be implemented. For example, subnetworks (e.g., subnetworks A and B, etc.) can be used to divide the CAN 290C into smaller sub-CANs, thereby limiting the ability of an attacker to remotely access the vehicle. Figure 2K In the example, ECU 291C and 292C can be part of the same subnet, while ECU 293C is part of a separate subnet. In addition, a firewall 294C (or gateway, etc.) can be added to prevent messages from traversing the CAN bus 297C across subnets. If an attacker gains access to one subnet, the attacker will not be able to access the entire network. In one example, to make the subnets more secure, the most critical ECUs are not placed on the same subnet.

[0141] although Figure 2K Not shown, but other examples of security controls within the CAN include an intrusion detection system (IDS) that can be added to each subnet and read all data transfers to detect malicious messages. If a malicious message is detected, the IDS can notify the car user. Other possible security protocols include encryption / security keys that can be used to hide messages. As another example, in one example, an authentication protocol is implemented that enables messages to authenticate themselves.

[0142] In addition to protecting the internal network of a vehicle, the vehicle may also be protected when communicating with external networks such as the Internet. One of the benefits of connecting a vehicle to a data source such as the Internet is that information from the vehicle can be sent over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve the combination of telecommunications and informatics. In addition, as discussed in Figure 2K The present solution described and depicted may be used in the present network and / or system and other networks and / or systems, including those described and depicted herein.

[0143] Figure 2LAccording to an example embodiment, a secure end-to-end transport communication channel is illustrated. Figure 2L , the telematics network 290D includes a vehicle 291D and a host server 295D arranged at a remote location (e.g., a network server, a cloud platform, a database, etc.) and connected to the vehicle 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D can be installed in a network within the vehicle 291D. In addition, although not shown, the device 296D can be connected to other elements of the vehicle 291D, such as a CAN bus, an on-board diagnostic (ODBII) port, a GPS system, a SIM card, a modem, etc. The device 296D can collect data from any of these systems and transmit the data to the server 295D via the network.

[0144] The secure management of data begins with the vehicle 291D. In some embodiments, the device 296D can collect information before, during, and after a trip. The data may include GPS data, driving data, occupant information, diagnostic data, fuel data, speed data, etc. However, the device 296D may only transmit the collected information back to the host server 295D in response to the vehicle ignition and the trip completion. In addition, the communication may be initiated only by the device 296D, rather than by the host server 295D. Therefore, in one example, the device 296D will not accept communications initiated by an external source.

[0145] In order to communicate, device 296D can establish a secure private network between device 296D and host server 295D. Here, device 296D can include a tamper-proof SIM card, which provides secure access to operator network 294D via radio tower 292D. When preparing to send data to host server 295D, device 296D can establish a one-way secure connection with host server 295D. Operator network 294D can communicate with host server 295D using one or more security protocols. As a non-limiting example, operator network 294D can communicate with host server 295D via a VPN tunnel, which allows access through firewall 293D of host server 295D. As another example, operator network 294D can use data encryption (e.g., AES encryption, etc.) when sending data to host server 295D. In some cases, the system can use multiple security measures such as VPN and encryption to further protect data.

[0146] In addition to communicating with external servers, vehicles can also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other, roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.), and the like via wireless networks. Wireless networks may include one or more of Wi-Fi networks, cellular networks, dedicated short-range communications (DSRC) networks, and the like. Vehicles can use V2V communications to provide other vehicles with information about the speed, acceleration, braking, and direction of the vehicles, to name a few. Thus, vehicles can be aware of conditions ahead before such conditions become visible, thereby greatly reducing collisions. In addition, as discussed with respect to Figure 2L The present solution described and depicted may be used in the present network and / or system and other networks and / or systems, including those described and depicted herein.

[0147] Figure 2M According to an example embodiment, an example 290E of vehicles 293E and 292E using security certificates for secure V2V communications is illustrated. Figure 2M , the transports 293E and 292E can communicate with each other via V2V communication on a short-range network, a cellular network, etc. Before sending a message, the transports 293E and 292E can sign the message using corresponding public key certificates. For example, the transport 293E can sign the V2V message using public key certificate 294E. Similarly, the transport 292E can sign the V2V message using public key certificate 295E. In one example, public key certificates 294E and 295E are associated with the transports 293E and 292E, respectively.

[0148] When receiving each other's communication, the transport can verify the signature with the certificate authority 291E or the like. For example, the transport 292E can verify with the certificate authority 291E that the public key certificate 294E used by the transport 293E to sign the V2V communication is authentic. If the transport 292E successfully verifies the public key certificate 294E, the transport knows that the data is from a legitimate source. Similarly, the transport 293E can verify with the certificate authority 291E that the public key certificate 295E used by the transport 292E to sign the V2V communication is authentic. In addition, as described in relation to Figure 2M The present solution described and depicted may be used in this network and / or system and other networks and / or systems, including those described and depicted herein.

[0149] Figure 2N According to an example embodiment, another diagram 290F depicting an example of a vehicle interacting with a secure processor and a wireless device is illustrated. In some embodiments, Figure 2BThe computer 224 shown in FIG. 1 may include a computer 224 as shown in FIG. Figure 2N The security processor 292F shown in the example of processing 290F. In particular, the security processor 292F can perform authorization, authentication, cryptography (e.g., encryption), etc. on data transmissions sent between ECUs and other devices on the vehicle's CAN bus, as well as data messages sent between different vehicles.

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

[0151] For example, the authorization module 293F can store passwords, user names, PIN codes, biometric scans, etc. for different users of the transport. The authorization module 293F can determine whether a user (or technician) has access to certain settings, such as the computer of the transport. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user desires to change the transport settings or modify the technical details of the transport via a console or GUI in the transport, or via an attached / connected device, the authorization module 293F may require the user to confirm themselves in some way before such settings are changed. For example, the authorization module 293F may require a user name, password, PIN code, biometric scan, predefined line drawing or gesture, etc. In response, the authorization module 293F can determine whether the user has the necessary permission (access, etc.) requested.

[0152] The authentication module 294F can be used to authenticate the internal communication between ECUs on the CAN network of the vehicle. For example, the authentication module 294F can provide information for authenticating the communication between ECUs. For example, the authentication module 294F can send a bit signature algorithm to the ECU of the CAN network. The ECU can insert the authentication bit into the CAN field of the CAN frame using the bit signature algorithm. All ECUs on the CAN network usually receive each CAN frame. Whenever one of the ECUs generates a new CAN frame, the bit signature algorithm can dynamically change the position, quantity, etc. of the authentication bit. The authentication module 294F can also provide a list of ECUs that are exempted and do not need to use the authentication bit (security list). The authentication module 294F can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

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

[0154] Figure 3A According to an example embodiment, a flow chart 300 is illustrated. Figure 3A , the solution includes one or more of: estimating a peak time of electricity usage at a location (302); and preparing for peak usage prior to the time (304), wherein the preparation includes: charging a battery at the location to a level associated with an end time of peak usage (306); and notifying the location to maintain the charge level (308).

[0155] Figure 3B According to an example embodiment, yet another flow chart 320 is illustrated. Figure 3BThe solution includes one or more of the following: estimating including identifying other locations having energy storage and / or energy generation capabilities and corresponding types and amounts of energy storage and energy generation capabilities within an area that includes the location (322), estimating including identifying other locations within the area that includes the location that will require power during peak usage times and determining when the other locations will require power during peak usage times (323), charging a battery at the location to a level associated with an end time of peak usage including determining an energy storage capacity at the location and a likely energy usage at the location (324), and determining a battery at each battery at the location. The connected charge can be transferred to or shared with one or more other batteries at the location, wherein the batteries at the location are fixed and movable, and wherein the other batteries at the location are fixed (325), and notification is performed by providing an indication of the amount of charge to be maintained by each battery at the location, whether one or more batteries at the location are to receive charge from the local energy generation system, and the amount of charge to be received by the one or more batteries from the local energy generation system (326), and the preparation also includes automatically controlling electrical loads at the location by setting a level at which one or more electrical loads consume power (327).

[0156] Figure 3C According to an example embodiment, yet another flow chart 340 is illustrated. Figure 3C , the flow chart includes receiving a confirmation of an event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus between peers represented by any of the elements (342), and executing a smart contract based on the blockchain consensus to record the confirmation on a blockchain (344).

[0157] Figure 4 According to an example embodiment, a machine learning vehicle network diagram 400 is illustrated. The network 400 includes a vehicle 402 interfaced with a machine learning subsystem 406. The vehicle includes one or more sensors 404.

[0158] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by a machine learning training system 410, which generates predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 resides in the vehicle 402. In other embodiments, the machine learning subsystem 406 resides outside the vehicle 402.

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

[0160] In yet another embodiment, vehicle 402 may send data from one or more sensors 404 to machine learning training system 410. In another example, machine learning subsystem 406 may send data from sensor 404 to machine learning subsystem 410. One or more applications, features, steps, solutions, etc. described and / or depicted herein may utilize machine learning network 400 as described herein.

[0161] Figure 5A According to an example embodiment, an example vehicle configuration 500 for managing database transactions associated with a vehicle is illustrated. Figure 5A , when a particular vehicle / vehicle 525 participates in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or release / transfer assets 512 in accordance with the transaction. A vehicle processor 526 resides in the vehicle 525, and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The transaction module 520 can record information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, incidents, etc. These transactions in the transaction module 520 can be replicated in the database 530. The database 530 can be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and can be on the vehicle, can be off the vehicle, can be directly accessed and / or accessed through a network, or can be accessed by the vehicle.

[0162] Figure 5BAccording to an example embodiment, an example vehicle configuration 550 for managing database transactions conducted between various vehicles is illustrated. When a vehicle reaches a state where it is necessary to share services with other vehicles, the vehicle 525 can engage with other vehicles 508 to perform various actions such as sharing, transferring, and obtaining service calls. For example, the vehicle 508 may need to be charged and / or may have a problem with the tire, and may be on the way to pick up a package for delivery. The transport processor 528 resides in the vehicle 508, and there is communication between the transport processor 528, the database 554, and the transaction module 552. The vehicle 508 can notify other vehicles 525 in its network and running on its blockchain member service. The transport processor 526 resides in the vehicle 525, and there is communication between the transport processor 526, the database 530, the transport processor 526, and the transaction module 520. The vehicle 525 can then request to receive information via wireless communication to pick up a package from the vehicle 508 and / or from a server (not shown). The transaction is recorded in the transaction modules 552 and 520 of the two vehicles. Points are transferred from vehicle 508 to vehicle 525, and the transfer service record is recorded in database 530 / 554, assuming that the blockchains are different from each other, or recorded in the same blockchain used by all members. Database 554 can be one of a SQL database, RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and can be on the vehicle, can be off the vehicle, can be directly accessed and / or accessed through a network.

[0163] Fig. 6A According to an example embodiment, a blockchain architecture configuration 600 is illustrated. Fig. 6A , the blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, a permissioned blockchain is not accessible to all parties, but only to those members who are permitted to access blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processing (consensus). One or more of the blockchain nodes can endorse entries based on an endorsement policy and can provide ordering services for all blockchain nodes. Blockchain nodes can initiate blockchain actions (such as authentication) and attempt to write to the blockchain immutable ledger stored in the blockchain, a copy of which can also be stored on the supporting physical infrastructure.

[0164] When a transaction is received and approved by the consensus model specified by the member's nodes, the blockchain transaction 620 is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and is submitted to the blockchain through a submission process, which includes hashing the data content of the transaction in the current block and referencing the previous hash value of the previous block. Within the blockchain, there may be one or more smart contracts 630 that define the terms of the transaction protocol and behavior contained in the smart contract executable application code 632, such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, which service features they are entitled / needed to receive based on their profile status, and whether to monitor their behavior in subsequent events. For example, when a service event occurs and the user is riding in a vehicle, sensor data monitoring may be triggered, and a parameter such as the vehicle charge level may be identified as being above or below a certain threshold for a certain period of time, and the result may be a change to the current state, which requires an alert to be sent to the management party (i.e., the owner, the vehicle operator, the server, etc.), so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information related to the state of the vehicle. The sensor data can also be the basis of vehicle event data 634, such as the location to be traveled, the average speed, the maximum speed, the acceleration rate, whether there are any collisions, whether the expected route is taken, where the next destination is, whether the safety measures are in place, whether the vehicle is fully charged / fueled, etc. All of this information can be the basis for the smart contract terms 630 that are subsequently stored in the blockchain. For example, the sensor thresholds stored in the smart contract can be used as the basis for whether the detected service is necessary, and when and where the service should be performed.

[0165] Figure 6B According to an example embodiment, a shared ledger configuration is illustrated. Figure 6B , blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application, which is linked to the computing device and execution platform of a specific transaction. Blockchain configuration 640 can include one or more applications that are linked to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which can be created according to the customized configuration sought by the participants, can maintain their own state, control their own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via appending to the distributed ledger.

[0166] Smart contract application code 644 provides the basis for blockchain transactions by establishing application code that, when executed, validates the terms and conditions of the transaction. Smart contracts 630, when executed, cause certain approved transactions 626 to be generated, which are then forwarded to blockchain platform 652. The platform 652 includes security / authorization 658, a computing device 656 that performs transaction management, and a storage portion 654 that acts as a memory in the blockchain to store transactions and smart contracts.

[0167] The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that may be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain may expose interfaces that provide access to the virtual execution environment required to process program code and interface with the physical infrastructure. Cryptographic trust services may be used to verify entries such as asset exchange entries and keep the information private.

[0168] Fig. 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code through one or more interfaces exposed by the blockchain platform and the services provided. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications affected by changes, updates, etc. The smart contracts themselves can be used to identify rules associated with authorization and access requirements, and the use of the ledger. For example, information can include new entries that can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results may include a decision to reject or approve the new entry based on criteria defined in the smart contract and / or consensus of peers. The physical infrastructure can be used to retrieve any data or information described herein.

[0169] Smart contracts can be created through high-level applications and programming languages ​​and then written into blocks in a blockchain within smart contract executable code. Smart contracts may include executable code that is registered, stored, and / or replicated through a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of the smart contract code, which may be performed in response to the satisfaction of a condition associated with the smart contract. The execution of a smart contract may trigger a trusted change to the state of a digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may be automatically replicated throughout a distributed network of blockchain peers through one or more consensus protocols.

[0170] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The 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 and / or can be encrypted to remain private. The temporary data used / generated by the smart contract is saved in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

[0171] The smart contract executable code may include a code interpretation of the smart contract and have additional features. As described herein, the smart contract executable code may be a program code deployed on a computing network in which the smart contract executable code is executed and verified together by a chain validator in a consensus process. The smart contract executable code receives a hash value and retrieves a hash value associated with a data template created by utilizing a previously stored feature extractor from the blockchain. If the hash value of the hash identifier matches the hash value created from the stored identifier template data, the smart contract executable code sends the authorization key to the requesting service. The smart contract executable code may be written to the blockchain data associated with the encryption details.

[0172] Figure 6C According to an example embodiment, a blockchain configuration for storing blockchain transaction data is illustrated. Figure 6C , an example configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., a blockchain) 668. The server may represent a service provider entity that queries a vehicle service provider to share user profile rating information in the event that a known and established user profile attempts to rent a vehicle with an established rating profile. The server 666 may be receiving and processing data related to service requirements for the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charging, maintenance service, etc., a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., which may be used to invoke a vehicle service event. For each transaction, such as an access event, a subsequent update to the service status of the vehicle, an event update, etc., blockchain transaction data 670 is saved. Transactions may include parties, requirements (e.g., 18 years of age or older, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients allowed access to the event and managed vehicle services, permissions / permissions, sensor data retrieved during vehicle event operations to record details of a service event and identify the vehicle's condition status, and thresholds used to determine whether the service event is completed and whether the vehicle's condition status has changed.

[0173] Fig.6D According to an example embodiment, a blockchain block 680 that may be added to a distributed ledger is illustrated, along with the contents of block structures 682A-682n. Fig.6D , a client (not shown) can submit entries to a blockchain node to perform activities on the blockchain. For example, a client can be an application that acts on behalf of a requester such as a device, person, or entity to propose an entry for the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. There may be different types of blockchain nodes / peers in the blockchain network, including endorsement peers that simulate and endorse entries proposed by the client, and commit peers that verify endorsements, validate entries, and submit entries to the distributed ledger. In this example, a blockchain node can play the role of an endorser node and / or a committer node.

[0174] The system includes a blockchain that stores immutable ordered records in blocks, and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger can exist for each channel, and each peer maintains its own copy of the distributed ledger for each channel they are a member of. The blockchain is a log of entries as hash-linked blocks, where each block contains a sequence of N entries. Blocks can include Fig.6D The various components shown in . Block links can be generated by adding the hash value of the block header of the previous block in the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically linked together, thereby preventing tampering of the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain represents every entry that came before it. The present blockchain can be stored on a peer-to-peer file system (local or attached storage device) that supports append-only blockchain workloads.

[0175] The current state of the blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest values ​​of all keys that have ever been contained in the chain entry log of the blockchain. Smart contract executable code calls execute entries against the current state in the state database. In order to make these smart contract executable code interactions extremely efficient, the latest values ​​of all keys are stored in the state database. The state database may include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored at peer startup (or generated when needed) before an entry is accepted.

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

[0177] The ordering service accepts endorsed entries, orders them into blocks, and delivers blocks to committing peers. For example, the ordering service can initiate a new block when a threshold of entries has been reached, a timer has timed out, or other conditions. In this example, the blockchain node is a committing peer that has received data block 682A for storage on the blockchain. The ordering service can be composed of a group of orderers. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, the ordering service can accept endorsed entries and specify the order in which these entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0178] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is performed by solving cryptographic puzzles, or mining, in this case, the parties to the distributed ledger can choose the ordering mechanism that best suits the network.

[0179] See also Fig.6D, a block 682A (also referred to as a data block) stored on a blockchain and / or distributed ledger may include multiple data segments such as block headers 684A-684n, transaction-specific data 686A-686n, and block metadata 688A-688n. It should be appreciated that the various described blocks and their contents, such as block 682A and its contents, are for example only and are not intended to limit the scope of the example embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A storing the entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on a blockchain) within the block header 684A. In particular, the block header 684A may include a hash value of the block header of the previous block. The block header 684A may also include a unique block number, a hash value of the block data 690A of the current block 682A, etc. The block number of the block 682A may be unique and assigned in an increasing / sequential order starting from zero. The first block in the blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, the data stored therein, etc.

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

[0181] In some embodiments, the block data 690A may also store transaction-specific data 686A that adds additional information to the hash link chain of the block in the blockchain. Thus, the data 686A may be stored in an immutable log of the block on the distributed ledger. Some benefits of storing such data 686A are reflected in the various embodiments disclosed and described herein. The block metadata 688A may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature when the block was created, a reference to the latest configuration block, an entry filter that identifies valid and invalid entries within the block, a persistent latest offset of the sorting service that sorts the block, etc. The signature, the latest configuration block, and the sorter metadata may be added by the sorting service. At the same time, the submitter of the block (such as a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write collections, etc. The entry filter may include a byte array of size equal to the number of entries in the block data 610A, and a verification code that identifies whether the entry is valid / invalid.

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

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

[0184] An exemplary storage medium may be coupled to a processor such that the processor can read information from and write information to the storage medium. In an alternative, the storage medium may be an integral part of the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium may exist as discrete components. For example, Figure 7Illustrated is an example computer system architecture 700 that may be representative of or integrated in any of the above components, among others.

[0185] Figure 7 It is not intended to imply any limitation on the scope of use or functionality of the embodiments of the present application described herein. Regardless, computing node 700 is capable of implementing and / or performing any of the functions set forth above.

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

[0187] Computer system / server 702 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may be practiced 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 local and remote computer system storage media including memory storage devices.

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

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

[0190] Computer system / server 702 generally includes various computer system readable media. Such media can be any available media accessible to computer system / server 702, and it includes volatile and non-volatile media, removable and non-removable media. In one example, system memory 706 implements the flow charts of other figures. System memory 706 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 can also include other removable / non-removable, volatile / non-volatile computer system storage media. Just as an example, memory 706 can be provided for reading and writing non-removable, non-volatile magnetic media (not shown, commonly referred to as "hard drive"). Although not shown, a disk drive for reading and writing removable, non-volatile disks (e.g., "floppy disks") can be provided, as well as a disk drive for reading or writing removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs or other optical media. In such cases, each can be connected to the bus through one or more data medium interfaces. As further depicted and described below, the memory 706 may include at least one program product having a set (eg, at least one) of program modules configured to implement the functions of various embodiments of the present application.

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

[0192] It will be appreciated by those skilled in the art that various aspects of the present application may be embodied as a system, method or computer program product. Thus, various aspects of the present application may take the form of a pure hardware embodiment, a pure software embodiment (including firmware, resident software, microcode, etc.) or an embodiment in combination with software and hardware, which embodiments may generally be referred to as "circuit", "module" or "system" in this article. In addition, various aspects of the present application may take the form of a computer program product contained in one or more computer-readable media, and the computer-readable medium has a computer-readable program code contained thereon.

[0193] The computer system / server 702 can also communicate with one or more external devices that may include a keyboard, an indicating device, a display, a voice recognition module, etc., via an I / O device 712 (such as an I / O adapter), one or more devices that enable a user to interact with the computer system / server 702, and / or any device (such as a network card, a modem, etc.) that enables the computer system / server 702 to communicate with one or more other computing devices. Such communication can be carried out via the I / O interface of the device 712. In addition, the computer system / server 702 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN) and / or a public network (such as the Internet) via a network adapter. As shown, the device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0194] Although exemplary embodiments of at least one of the systems, methods, and non-temporary computer-readable media are shown in the drawings and described in the detailed description above, it should be understood that the present application is not limited to the disclosed embodiments, but rather allows for numerous rearrangements, modifications, and substitutions as stated and defined by the following claims. For example, the capabilities of the systems of the various drawings can be accomplished by one or more modules or components described herein or in a distributed architecture, and can include a transmitter and / or a receiver. For example, all or part of the functions performed by a single module can be performed by one or more of these modules. In addition, the functions described herein can be performed at different times in relation to various events inside or outside the modules or components. In addition, the information sent between the modules can be sent between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or through a variety of protocols. In addition, messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0195] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cellular telephone, a tablet computing device, a smart phone, or any other suitable computing device, or a combination of devices. Representing 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 apparatus disclosed herein can be implemented in localized and distributed forms consistent with computing technology.

[0196] It should be noted that some of the system features described in this specification are introduced as modules in order to more particularly emphasize their implementation independence. For example, modules can be implemented as hardware circuits, including custom very large scale integrated circuit (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors or other discrete components. Modules can also be implemented using programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0197] Modules can also be implemented at least in part with software so that they can be executed by various types of processors. For example, the executable code unit identified can include one or more physical or logical blocks of computer instructions, which can be organized as objects, processes, or functions, for example. However, the executable code of the identified module does not need to be physically located together, but can include different instructions stored in different locations, which, when logically connected together, form the module and achieve the intended purpose of the module. In addition, the module can be stored on a computer-readable medium, which can be, for example, a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0198] In fact, an executable code module can be one instruction or multiple instructions, and can even be distributed across several different code segments, different programs, and several storage devices. Similarly, operational data can be identified and shown within a module herein, can be embodied in any appropriate form, and can be organized within any appropriate type of data structure. The operational data can be collected as a single data set, or can be distributed in different locations, including on different storage devices, and can exist at least partially only as electronic signals on a system or network.

[0199] It is easy to understand that the various components of the present application as described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the present application claimed, but is only a representative of the selected embodiments of the present application.

[0200] Those skilled in the art will readily appreciate that the above may be practiced with multiple steps in different orders, and / or with hardware elements having configurations different from those disclosed. Thus, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that some modifications, variations, and alternative configurations will be apparent.

[0201] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application is limited solely by the appended claims when considering its various equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method comprising: estimating peak electricity usage times at a location; as well as Prepare for peak usage prior to the time, wherein the preparation includes: charging the battery at said location to a level associated with the end time of peak usage; and The location is informed of the level of charge maintained.

2. A method according to claim 1, wherein the estimating includes identifying other locations having energy storage and / or energy generation capabilities within an area including the location, and the corresponding types and quantities of energy storage and energy generation capabilities.

3. The method of claim 1, wherein the estimating comprises identifying other locations within an area including the location that will require power during peak usage times, and determining when the other locations will require power during peak usage times.

4. The method of claim 1 wherein charging the battery at the location to a level associated with an end time of peak usage comprises determining an energy storage capacity at the location and a likely energy usage at the location.

5. The method of claim 1 , wherein the charge associated with each battery at the location is transferable to, or shared with, one or more other batteries at the location, wherein the batteries at the location are fixed and movable, and wherein the other batteries at the location are fixed.

6. A method according to claim 1, wherein the notification provides an indication of the amount of charge to be maintained by each battery at the location, whether one or more batteries at the location are to receive charge from a local energy generation system, and the amount of charge to be received by the one or more batteries from the local energy generation system.

7. The method of claim 1, wherein the preparing further comprises automatically controlling electrical loads at the location by setting a level at which one or more electrical loads consume electrical power.

8. A server, comprising: Storage device; and processor; wherein the storage device and the processor are communicatively coupled, The processor is configured to: estimating peak electricity usage times at a location; as well as Prepare for peak usage prior to the time, wherein the preparation includes: charging the battery at said location to a level associated with the end time of peak usage; and The location is informed of the level of charge maintained.

9. A server according to claim 8, wherein the estimation identifies other locations having energy storage and / or energy generation capabilities within an area including the location, and the corresponding types and amounts of energy storage and energy generation capabilities.

10. The server of claim 8, wherein the estimating identifies other locations within an area including the location that will require power during peak usage times and determines when the other locations will require power during peak usage times.

11. The server of claim 8, wherein charging the battery at the location to a level associated with an end time of peak usage comprises determining an energy storage capacity at the location and a likely energy usage at the location.

12. A server as described in claim 8, wherein the charge associated with each battery at the location can be transferred to or shared with one or more other batteries at the location, wherein the batteries at the location are fixed and movable, and wherein the other batteries at the location are fixed.

13. A server according to claim 8, wherein the notification provides an indication of the amount of charge to be maintained by each battery at the location, whether one or more batteries at the location are to receive charge from the local energy generation system, and the amount of charge to be received by the one or more batteries from the local energy generation system.

14. The server of claim 8, wherein the provision automatically controls electrical loads at the location by setting a level at which one or more electrical loads consume electrical power.

15. A non-transitory computer-readable storage medium comprising instructions which, when read by a processor, cause the processor to: estimating peak electricity usage times at a location; as well as Prepare for peak usage prior to the time, wherein the preparation includes: charging the battery at said location to a level associated with the end time of peak usage; and The location is informed of the level of charge maintained.

16. The non-transitory computer-readable storage medium of claim 15, wherein the estimating comprises identifying other locations having energy storage and / or energy generation capabilities within an area including the location, and corresponding types and quantities of energy storage and energy generation capabilities.

17. The non-transitory computer readable storage medium of claim 15, wherein the estimating comprises identifying other locations within an area including the location that will require power during peak usage times and determining when the other locations will require power during peak usage times.

18. The non-transitory computer readable storage medium of claim 15, wherein charging the battery at the location to a level associated with an end time of peak usage comprises determining an energy storage capacity at the location and a likely energy usage at the location.

19. The non-transitory computer readable storage medium of claim 15, wherein charging the battery at the location to a level associated with an end time of peak usage comprises determining an energy storage capacity at the location and a likely energy usage at the location.

20. The non-transitory computer-readable storage medium of claim 15, wherein the charge associated with each battery at the location is transferable to, or shared with, one or more other batteries at the location, wherein the batteries at the location are fixed and movable, and wherein the other batteries at the location are fixed.

Images