CN114103641A

CN114103641A - Dynamic vehicle energy control

Info

Publication number: CN114103641A
Application number: CN202110994861.6A
Authority: CN
Inventors: N·卢; M·帕内斯
Original assignee: Toyota Motor North America Inc
Current assignee: Toyota Motor North America Inc
Priority date: 2020-08-28
Filing date: 2021-08-27
Publication date: 2022-03-01
Also published as: US20220067848A1; JP2022040076A

Abstract

The present disclosure relates to dynamic vehicle energy control. Example operations include one or more of: determining, by the vehicle, that the characteristic associated with the passenger is at a level below a threshold; performing an energy saving action by the vehicle to reduce the characteristic level; and in response to the characteristic level rising above the level but below the threshold, performing, by the vehicle, an energy usage action to reduce the characteristic level; the energy saving action is performed while the energy usage action is performed.

Description

Dynamic vehicle energy control

Cross reference to related applications

This application is related TO co-pending U.S. non-provisional patent application entitled "vehicle energy ALLOCATION TO transportation" and U.S. provisional patent application entitled "wireless energy transfer TO vehicle BASED ON ROUTE DATA (WIRELESS ENERGY TRANSFER TO transportation BASED ROUTE DATA"), all filed ON the same day and the entire contents of each of which are incorporated herein by reference.

Background

Vehicles or vehicles (e.g., automobiles, motorcycles, trucks, airplanes, trains, etc.) often provide transportation needs to passengers and/or cargo in a variety of ways. Vehicle-related functions may be identified and used by various computing devices (e.g., smart phones or computers on and/or off the vehicle).

Disclosure of Invention

An example embodiment provides a method comprising one or more of: determining, by the vehicle, that the characteristic associated with the passenger is at a level below a threshold; performing, by the vehicle, an energy saving action to reduce a characteristic level; and in response to the characteristic level rising above the level but below the threshold, performing, by the vehicle, an energy usage action to reduce the characteristic level; wherein the energy saving action is performed while the energy usage action is performed.

Another example embodiment provides a vehicle comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of the following: determining that a characteristic associated with the passenger is at a level below a threshold; performing an energy saving action to reduce the feature level; and in response to the characteristic level rising above the level but below the threshold, performing an energy usage action to reduce the characteristic level; wherein the energy saving action is performed while the energy usage action is performed.

Yet another example embodiment provides a non-transitory computer readable storage medium containing instructions that, when read by a processor, cause the processor to perform one or more of the following: determining that a characteristic associated with the passenger is at a level below a threshold; performing an energy saving action to reduce the feature level; and in response to the characteristic level rising above the level but below the threshold, performing an energy usage action to reduce the characteristic level; wherein the energy saving action is performed while the energy usage action is performed.

Drawings

FIG. 1A shows an example system diagram of vehicle operation according to an example embodiment.

FIG. 1B illustrates an example of controlling vehicle operation by performing various actions, according to an example embodiment.

FIG. 2A illustrates another vehicle network diagram of vehicle operation sensors according to an example embodiment.

FIG. 2B illustrates another vehicle network diagram according to an example embodiment.

FIG. 2C illustrates yet another vehicle network diagram according to an example embodiment.

FIG. 2D illustrates yet another vehicle network diagram according to an example embodiment.

FIG. 2E illustrates yet another vehicle network diagram in accordance with an example embodiment.

Fig. 2F shows a diagram depicting one or more elements electrified, according to an example embodiment.

Fig. 2G shows a diagram depicting interconnections between different elements, according to an example embodiment.

Fig. 2H illustrates yet another diagram depicting interconnections between different elements, according to an example embodiment.

Fig. 2I shows yet another diagram depicting interconnections between different elements according to an example embodiment.

Fig. 3A shows a flow diagram according to an example embodiment.

Fig. 3B illustrates another flow diagram according to an example embodiment.

Fig. 3C shows yet another flow diagram according to an example embodiment.

Fig. 4 illustrates a machine learning vehicle network diagram according to an example embodiment.

FIG. 5A illustrates an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

FIG. 5B illustrates another example vehicle configuration for managing database transactions between various vehicles, according to an example embodiment.

Fig. 6A illustrates a blockchain architecture configuration according to an example embodiment.

Fig. 6B illustrates another blockchain configuration according to an example embodiment.

Fig. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment.

FIG. 6D illustrates an example data block, according to an example embodiment.

FIG. 7 illustrates an example system that supports one or more example embodiments.

Detailed Description

It will be readily understood that the present components, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of at least one of the methods, apparatus, non-transitory computer readable media and systems, as illustrated in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

Communications between the vehicle and certain entities, such as remote servers and local computing devices (e.g., smart phones, personal computers, vehicle-embedded computers, etc.), may be received and processed by one or more "components," which may be hardware, firmware, software, or a combination thereof. The components may be part of any of these entities or computing devices, or other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by a computing device or component associated with a vehicle and one or more components located outside or remotely from the vehicle. Consensus decisions or agreements are processes agreed upon between one or more nodes or peers in a network with respect to values, states, results, inputs, outputs, conditions, etc.

The features, structures, or characteristics as described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, use of the phrases "example embodiment," "some embodiments," or other similar expressions throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment. Thus, appearances of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar expressions throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, characteristics may be combined in any suitable manner in one or more embodiments. Any connections between elements in the figures may be uni-directional and/or bi-directional communications, even though the connections shown in the figures are uni-directional or bi-directional arrows. In the current solution, the vehicle may include one or more of an automobile, a truck, a walk-by-electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that may be used to transport people and/or cargo from one location to another.

Additionally, although the term "message" may have been used in the description of the embodiments, other types of network data (e.g., messages, frames, datagrams, etc.) may also be used. Further, while certain types of messages and signaling may be described in example embodiments, they are not limited to a certain type of messages and signaling.

Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and/or networks that provide for at least one of: a vehicle (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, an authentication system, an authorization system, and a vehicle data distribution system. Vehicle state condition data received in the form of communication messages, such as wireless data network communications and/or wired communication messages, may be processed to identify vehicle/vehicle state conditions and provide feedback related to vehicle state and/or changes. In one example, the user profile may be applied to a particular vehicle/vehicle to authorize a current vehicle event, a service point of a service stop, to authorize subsequent vehicle rental services, and to enable vehicle-to-vehicle communication.

Within the communication infrastructure, a decentralized database is a distributed storage system that includes a plurality of nodes in communication with each other. Blockchains are examples of decentralized databases, including simply appended immutable data structures (i.e., distributed ledgers), which enable records to be maintained between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record and in the event of no consensus among the distributed peers, no single peer can modify the database record. For example, a peer may perform a consensus protocol to validate blockchain store entries, group store entries into chunks, and build hash chains from chunks. According to the requirement, the process forms the account book by sequencing the storage items, and the consistency is realized. In a public or unlicensed blockchain, anyone can participate without a specific identity. The common blockchain may involve cryptocurrency and use a consensus of various protocols based on, for example, workload attestation (PoW). In contrast, a licensed blockchain database may secure transactions between a group of entities that do not trust or do not trust completely with each other but have a common goal, such as the exchange of funds, goods, information, etc. The present scheme may be used in licensed and/or unlicensed blockchain settings.

Smart contracts are trusted distributed applications that take advantage of the tamper-resistant nature of a shared or distributed ledger (which may be in the form of a blockchain) and the underlying protocol between member nodes, known as an endorsement or endorsement policy. In general, block chain entries are "endorsed" prior to being committed to the block chain, and entries that are not endorsed are ignored. Typical endorsement policies allow intelligent contract executables to specify an endorser for an entry in the form of a set of peer nodes necessary for endorsement. When the client sends an entry to the peer specified in the endorsement policy, the entry is executed to validate the entry. After verification, the entries enter a sort stage in which a consensus protocol is used to generate a sorted sequence of endorsed entries that make up a block.

A node is a communication entity of the blockchain system. In this sense, a "node" may perform a logical function. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. The nodes may comprise different types, such as clients or submitting client nodes that submit an entry call to an endorser (e.g., a peer) and broadcast an entry proposal to a ranking service (e.g., a ranking node). Another type of node is a peer node that can receive client submitted entries, submit entries, and maintain a state and copy of the block chain ledger. Peers may also have the role of endorsers. A sequencing service node or sequencer is a node running a communication service for all nodes that performs delivery guarantees, such as broadcasting to each peer node in the system when submitting entries and modifying the world state of the blockchain. World states may constitute initial blockchain entries, which typically include control and setting information.

The ledger is an ordered and tamper-resistant record of all state transitions of the blockchain. State transitions may result from intelligent contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, sequencing nodes, endorsement nodes, peer nodes, etc.). An entry may cause a set of asset key-value pairs to be submitted to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a block chain (also referred to as a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database for maintaining the current state of the blockchain. There is typically one book per lane. Each peer maintains a copy of the account for each channel for which it is a member.

A chain is a log of entries structured as hash-linked chunks, each chunk containing a sequence of N entries, where N is equal to or greater than 1. The chunk header includes a hash of the entry for the chunk and a hash of the previous chunk header. In this way, all items on the ledger can be ordered and linked together in an encrypted manner. Thus, it is not possible to tamper with the ledger data without destroying the hash link. The hash of the recently added blockchain chunk represents each entry on the chain that occurred before it, so that it can be ensured that all peers are in a consistent and trusted state. The chains may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.) to efficiently support the append-only nature of the blockchain workload.

The current state of the immutable ledger represents the latest value of all keys included in the chain entry log. The current state is sometimes referred to as the world state because it represents the latest key value known to the channel. The smart contract executable calls the current state data execution entry for the ledger. To make these intelligent contract executable code interactions efficient, the latest values of the keys may be stored in a state database. The state database may simply be an indexed view of the entry log for the chain, and thus may be regenerated from the chain at any time. The state database may be automatically restored (or generated when needed) upon startup of the peer node and before the entry is accepted.

Blockchains differ from traditional databases in that blockchains are not centrally stored but decentralized, immutable and secure storage, where nodes must share changes to records in the storage. Some attributes inherent to blockchains that help implement blockchains include, but are not limited to: immutable ledgers, intelligent contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

Example embodiments provide services to a particular vehicle and/or user profile applied to the vehicle. For example, the user may be an operator of a vehicle owned by the vehicle owner or another party. The vehicle may need to be serviced at intervals and authorization for service requirements may be required before service is allowed. Further, the service center may provide services to vehicles in the vicinity based on the vehicle's current route plan and the relative level of service requirements (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand may be monitored by one or more vehicle and/or road sensors or cameras that report sensed data to a central controller computer device within the vehicle and/or remote from the vehicle. The data is forwarded to the management server for auditing and action. The sensors may be located in one or more of the following: the interior of a vehicle, the exterior of a vehicle, a stationary object remote from a vehicle, and another vehicle proximate to a vehicle. The sensors may also be associated with the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the amount of fuel, service requirements, gear shifting of the vehicle, steering of the vehicle, and the like. As described herein, a sensor may also be a device, such as a wireless device in and/or near a vehicle. Furthermore, the sensor information may be used to identify whether the vehicle is operating safely and whether the occupant is in any unexpected vehicle state, such as during vehicle entry and/or use. Vehicle information collected before, during, and/or after operation of the vehicle may be identified and stored in transactions on the shared/distributed ledger, which may be generated and submitted to the immutable ledger determined by the permission granting federation, and thus in a "decentralized" manner, such as by blockchain member groups.

Each interested party (i.e., owner, user, company, organization, etc.) may wish to limit the exposure of private information, so the blockchain and its inflexibility may be used to manage the permissions of each particular user's vehicle profile. Smart contracts may be used to provide compensation, quantify user profile scoring/rating/auditing, apply vehicle event permissions, determine when services are needed, identify collision and/or degradation events, identify security issue events, identify participants to events, and provide distribution to registered entities applying for access to such vehicle event data. Further, the results may be identified and necessary information may be shared between registered companies and/or individuals based on the consensus method associated with the blockchain. This approach cannot be implemented on a traditional centralized database.

The various drive systems of the present solution may utilize software, sensor arrays, and machine learning functions, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, etc. to create topographical and road maps for use by the vehicle for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. may also be used in autonomous vehicles in place of LIDAR.

In certain embodiments, the present solution includes authorizing a vehicle for service through an automatic and quick authentication scheme. For example, traveling to a charging station or a refueling pump may be performed by a vehicle operator or an autonomous vehicle, and in the event that authorization is received at a service station and/or charging station, authorization to receive electricity or oil may be performed without delay. The vehicle may provide a communication signal with a vehicle identification, the vehicle having a current activity profile linked to an account authorized to receive service, which may be subsequently corrected by compensation. Further authentication may be achieved using additional measures, for example another identifier may be wirelessly transmitted from the user's device to the service center, replacing or supplementing the initial authorization effort between the vehicle and the service center by an additional authorization effort.

The shared and received data may be stored in a database that maintains the data in a single database (e.g., a database server) and is typically located at a particular 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 central database can often be accessed from a number of different points. Centralized databases are easy to manage, maintain and control, as their single location is particularly advantageous for data security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data means that there is only one primary record for a given data set. The blockchain may be used to store data and transactions related to the vehicle.

FIG. 1A shows an example system diagram 100 of vehicle operation, according to an example embodiment. Referring to fig. 1A, the vehicle 120 may receive capabilities from itself or data through a separate entity a 110, which entity 110 may be a server or other vehicle, or alternatively may be through a sub-component of the vehicle, such as a mobile computing device, vehicle computing system, or sensor operated by a vehicle occupant. Further, the data may be shared with another entity B130, which entity B130 may be one or more vehicle control devices operating within the vehicle and controlled by the vehicle 120. In this example, vehicle 120 receives characteristic data, which may include sensor data provided by sensors, and uses the data to detect environmental characteristics associated with one or more passengers. Powering of sensors that collect data (e.g., characteristic data) may be controlled by processing entities associated with the vehicle, such as on-board computing devices, passenger-controlled mobile devices that control certain vehicle functions, remote servers in mobile communication with the vehicle, and so forth.

In operation, the vehicle identifies received characteristic data (112) via its internal computing platform, which may include an in-vehicle computing device and/or a peripheral device, such as a user mobile device. This characteristic data may include internal temperature, audio volume, air flow rate, etc. and at a particular location in the vehicle. The identified characteristic level may be determined to be below a threshold (114), however, the level may be within a certain range (e.g., X units), such as four degrees or 3 decibels, which still requires some type of action to reduce the likelihood of the level rising further, and/or to mitigate the passenger area by reducing the characteristic level in an attempt to provide the passenger with an operational result that is satisfactory to them.

The initial action may be to perform an energy saving action (116), such as activating a local fan when the characteristic is temperature and the characteristic level is within a range (i.e., 3 to 4 degrees of threshold) necessary to perform the action. The initial action may be an energy saving action performed in place of the more energy consuming action. For example, while turning on a fan at one location of a vehicle may consume some energy, this energy saving action may consume less of a certain amount of energy than activating an air conditioner, which requires significantly more energy and may be denoted as an energy usage action. The vehicle 120 may actively monitor the characteristic data, as indicated by the additional new characteristic state information (118), which arrives at the vehicle 120 and is processed by the vehicle 120 through its corresponding computing device. The characteristic data may be shared by sensor control units associated with onboard vehicle sensors that acquire environmental data and share the data with the vehicle 120 at predefined time intervals (e.g., every 60 seconds), the vehicle 120 receiving and processing the data via an onboard computing device to compare the data to established ranges and thresholds that may trigger an action to occur.

Continuing with the same example, when the new characteristic data 118 reaches the vehicle computing platform, an indication may be triggered if the characteristic level rises again and this time above the range of acceptable energy saving actions (e.g., low energy remedial measures to mitigate the current state of the vehicle). Furthermore, the level range that has been exceeded may be a degree range (i.e. 3 to 4), and the characteristic level now requires additional actions, such as additional energy saving actions and/or energy usage actions. Another term for energy saving actions may be reduced energy usage actions to make clear that such actions do use energy but reduce usage compared to energy usage actions. In such a case, the vehicle 120 may then be configured to perform the energy usage action (122) when a set level is exceeded, which may be a higher level of the range. In one example, the lower level of the range may be exceeded when the characteristic level first enters the particular level range; the characteristic level may then exceed the upper level of the range beyond the range but may still be below the threshold level, however when the characteristic level is identified a second time as being above an acceptable level, this result may require an energy usage action to reduce the characteristic level back to an acceptable value. The vehicle may perform the energy saving action, the energy usage action, or a combination of both actions by forwarding a command to engage a particular entity, such as entity B130, which may also be performed simultaneously (124). Entity B may represent a controller or device that performs a vehicle function. In other examples, the plurality of actions may be performed by one or more of entity a 110, entity B130, and/or vehicle 120, e.g., in the case of temperature control, a window may be swung down a portion of the entire distance, a local fan may engage a first level or a second level, etc., an air conditioner may be turned on at a first output level, re-turned up to a second output level, or turned off, etc.

According to example embodiments, using energy saving actions before and during a vehicle trip may allow the vehicle to travel greater distances by saving energy. Prior to travel, the vehicle may determine an estimated travel distance and travel time based on the particular battery charge level at the current time and any travel plan data known in advance. Various input data may be used to further identify the distance traveled based on the destination, expected speed, load, etc. There are a number of limitations that may affect vehicle energy consumption, such as road grade or condition, traffic conditions, driving characteristics (aggressive versus gentle), specific weather patterns (including downwind/crosswind), unplanned stops, and so forth. The system application may be run via an onboard and/or offboard computing platform associated with the vehicle. In an example embodiment, a server, vehicle, and/or related device may communicate with a database to provide and/or receive route and/or battery level information related to a current state of the vehicle and an available power level in a particular area for a period of time. The system applications may provide actions, suggestions, and recommendations that seek to reduce energy consumption, and they may also be displayed on at least one device, such as a display associated with the vehicle, which may be the main display of the vehicle and/or other displays in the vehicle (such as on the seat back), and one or more mobile devices associated with passengers of the vehicle.

In one embodiment, the system application may determine which factors may be modified to reduce energy usage, such as unnecessary energy consumption actions, which may include unnecessary parking, unnecessary energy usage of the vehicle, and the like, depending on the travel objective. Setting the action to reduce energy usage may cause the vehicle to travel a greater distance before needing to recharge the vehicle. The system application may calculate the weight of the vehicle load, the type of load, and the intended use of the load and provide suggested changes/changes to change/reduce the load, such as dropping a package, box, luggage, passengers, etc. The system application may inform the occupants of the vehicle of the difference in expected distance the vehicle will travel based on the changed/reduced load. During travel, the vehicle may determine possible additional travel distances based on the current level of battery charge and energy savings associated with reduced energy consumption. For example, temperature control, driving style, etc. may be modified to provide a greater range of travel distances. The passenger(s) may be prompted to decelerate to a particular speed that uses the optimal amount of energy for a particular time based on the road conditions and the measured energy usage over the last period of time. Such data can be periodically measured and compiled to generate new build and commands to be executed by the vehicle.

In another example, by dynamically controlling multiple functions of a vehicle, modifications may be used during travel to a particular destination. Air conditioning functions onboard a vehicle, including a compressor for cooling a vehicle cabin, consume a significant amount of energy compared to other on-board energy consuming vehicle functions, so limiting the time of use of the compressor can provide improved energy efficiency. The battery charge of a given vehicle may also increase the total distance traveled. For example, depending on the temperature inside and outside the vehicle cabin, it may be recommended to make the cabin interior more comfortable while using the least amount of power for the vehicle. The vehicle-initiated changes may be presented in increments. For example, via one or more on-board and/or off-board processors/sensors associated with entity a 110 and/or entity B130, the vehicle may keep the temperature control function closed for a particular length of time, automatically open and/or close one or more windows, open and/or close particular vents, and/or engage temperature control to a particular temperature for a particular length of time, which limits overuse. The commands to perform these operations may be continuously recognized, processed, and used by an onboard computing platform associated with the vehicle.

The system application may also determine the amount of temperature modification that should be used in the cabin of the vehicle based on the current and/or future outside temperature of the vehicle, the current and/or future inside temperature of the vehicle, the current and/or future temperature of one or more spaces associated with each passenger currently in the vehicle, etc. By using one or more devices in the vehicle (e.g., pressure sensitive seat sensors, cameras, voice recognition modules, motion detection sensors, etc.), the number of passengers and the load of the vehicle may be accurately determined. Based on the one or more devices, modifications to the temperature control may be made for individual passengers. For example, if a passenger is seated with sunlight shining on them, air from the vent and against the passenger may be implemented and their fan speed may be increased. Further, if it is determined that the occupant is uncomfortable, such as sweating, wiping the face/forehead, blowing himself with the hands or other objects, etc., the vehicle may increase the fan speed, gradually turn on the air conditioning unit, etc., in the area of the occupant while maintaining less or no operation in other areas of the vehicle. If the sun is no longer shining on the passenger and the sensor detects that the amount of sunlight at a particular location is low, and/or if the passenger is no longer presenting an uncomfortable condition, the vehicle may automatically revert to its initial state by reducing the amount of simultaneous energy saving and/or energy usage operations.

In an example embodiment, the vehicle's air conditioners and/or heaters are automatically engaged and/or disengaged by the system application. In an embodiment, the system application determines an estimated time based on the amount of remaining power and the distance to the charging station to wait to engage the air conditioning compressor in order to time for an event to one or more of a charging station that is further away, a better charging station (e.g., a charging station that is close to a restaurant or other attraction that a passenger may like), and/or a destination. In an embodiment, a recommendation is presented to a device associated with a passenger of a vehicle, the recommendation including a trip start time, a stop to be made, and a trip end time to ensure that the vehicle achieves optimal energy usage. Changes may be made because trips are only one suggested strategy to reduce energy usage in an optimal manner during that particular time period.

FIG. 1B illustrates an example of controlling vehicle operation by performing various actions, according to an example embodiment. Referring to FIG. 1B, the vehicle 150 includes various vehicle modules 160 and 178 (which may be controlled by a central controller node), such as an onboard computing platform, a peripheral computing device, or a remote computing device. Any one or more of the

modules

160 and 178 may control devices in various vehicles. For example, certain control modules may include a seat 160/170 (e.g., temperature control, position movement, weight detection, etc.), a frontal area 162/172 (e.g., display, fan, air conditioning vent, speaker, etc.), a door panel 164/174 (e.g., fan, display, speaker, etc.), a window 166/176 (e.g., head-up display, window control, etc.), and a roof 168/178 (e.g., sunroof, speaker, display, fan, etc.). The

control module

160 and 178 may be controlled by the computing module to determine by the vehicle that the characteristic (i.e., temperature, noise level, etc.) associated with the occupant is at a level below a threshold, and that an action other than a high energy use action may be implemented below the threshold, which may be referred to as an energy saving action. Other operations may include performing an energy saving action by the vehicle to reduce the characteristic level, and in response to the characteristic level rising above that level (e.g., the measured temperature rising one more degree) but below a threshold (an action absolute level that invokes one or more energy usage actions and potentially other actions), performing an energy usage action by the vehicle to reduce the characteristic level. Further, the energy saving action may be performed before, after, or during a period of time during which the energy usage action is performed. In one example, the module 162 may be a fan that is engaged to cool the driver and passengers when the measured characteristic level is within the energy saving action range but before the energy use action is performed (which may be invoked when the characteristic level is above a certain level and has entered a range of operable control for one or more of the control modules 160 and 178).

Another method may include: the number of passengers and the location of the passengers within the vehicle are determined, which may be performed by motion detection, sound detection, weight detection or a combination of detection processes. The process further comprises: based on the number of passengers, one or more vehicle operations are selected to be performed in response to one or more of the energy saving actions and the energy usage actions. For example, if the occupant is at all four locations of a four-door vehicle (e.g., vehicle configuration 150), then actions (both energy saving actions and energy use actions) may be performed in one or more portions of the vehicle to mitigate the occupant's environment. The process may also include determining one or more locations of one or more passengers within the vehicle, determining which vehicle operations are available at the one or more locations through a controller function of the computing module, and selecting one or more vehicle operations available at the one or more locations to perform in response to one or more of the energy saving action and the energy usage action. This may include using a fan, increasing the fan speed, and activating an air conditioning compressor to push cooler air at the same location (assuming both actions are performed at the same location at the same time).

When performing an energy saving action (i.e., increasing fan speed), the process may further include: while performing the energy saving action, the initial energy usage level of the vehicle is reduced by performing an additional energy saving action, which may include pausing any operations by the vehicle and in response to the energy usage action being performed to save additional energy. The process may include: the reduced energy usage level of the vehicle is increased to create a modified energy usage level of the vehicle. In this case, the controller of the computing device may engage and disengage any vehicle control module (i.e., 160-. The process may also include identifying an initial energy usage level of the vehicle prior to performing the energy saving action and the energy usage action, and modifying the initial energy usage level of the vehicle to be less than the initial energy usage level of the vehicle during performance of the energy saving action and the energy usage action. This example shows that the vehicle can use the initial energy usage level as a basis to determine whether the new operation that was invoked should be counteracted by reducing the level of other vehicle operations or pausing those operations to a later time.

The process may also include receiving, by the vehicle, a verification of an energy saving action from at least one component (as described and/or depicted herein), wherein the verification may include a blockchain consensus between peer groups consisting of the vehicle (or one or more devices within the vehicle) and the at least one component. The process may further include: executing, by the vehicle, an intelligent contract to record the verification and the at least one component on a blockchain based on blockchain consensus. The decision to conduct a blockchain transaction may be based on determining that an energy usage operation is invoked and persists for a period of time and based on a particular level of energy usage of the vehicle. The transaction may be used to verify energy saving cycles that may be required by the local government or other authorities regulating the use of vehicles.

In addition to the measurable characteristics (e.g., temperature invoking an air conditioning event and noise level invoking an audio conditioning event), the characteristic of the occupant may be a general level of discomfort (e.g., the occupant may be excited, tired, restless, warm or hot, etc.), which may be detected by one or more sensors (e.g., in-vehicle sensors). Once the energy usage amount equals or exceeds the threshold level, the vehicle will automatically stop certain energy usage operations. At a future time, when energy savings reduce the energy usage level to a particular level, energy usage may be restored for certain vehicle operations at fixed time intervals. The type of energy usage may also depend on the amount of energy savings. For example, the vehicle may perform only certain actions (e.g., opening a window or opening a vent) if the energy savings is at a first level, but may perform other actions including a lower overall vehicle energy usage level (e.g., opening an air conditioning/cooling seat at an initial level) if the energy savings is at a second level.

The energy saving action and the energy usage action may be the same type of action, such as the fan operating at a first level and operating at a second level using more or less energy than the first level. In another example, energy savings may include rolling down the window, and increasing air flow to the vent as fan speed increases may continue to increase energy usage. In another example, the energy savings may be cooling the seat, and energy usage may continue to reduce air temperature and increase fan speed, and gradually attempt to alleviate discomfort levels without invoking particular modules or functions that use excessive energy. Sensors may be used to determine discomfort of one or more passengers, e.g., based on video/audio information, detect sweating, detect spoken words such as "hot," "warm," etc., a fanning gesture with a hand and/or other object, etc.

In another example, if the passenger shows signs of discomfort due to elevated temperatures, the vehicle may automatically increase the airflow rate by: using one or more vents near the occupant to push air and determine whether the level of discomfort persists, and/or changing the vent that blows and starting from the identified most uncomfortable area and determining whether the level of discomfort persists. Examples may include detecting sunlight on one side of the vehicle and directing airflow in that direction, increasing airflow through one or more vents and determining whether the level of discomfort is persistent. In the event that the level of discomfort is caused by the passenger being warm or hot, the system application may control the vehicle to shake the window closest to the passenger slightly or shake the window most likely to alleviate the passenger's discomfort, such as shaking the front window for the rear passenger, and determine whether the level of discomfort is persistent. Other options include turning on the seat cooler/heater at a minimum level and determining whether the level of discomfort persists, increasing the level of the seat cooler/heater and determining whether the level of discomfort persists, turning on the air conditioner at a first temperature/level and determining whether the level of discomfort persists, and/or increasing the effectiveness of the air conditioner temperature.

In each incremental operation, the previous operation may be retained or discarded. For example, if proceeding to the fourth operation, the third operation may be performed. In another example, if going to the fifth operation, operations four and three may be maintained or abandoned, or one or both in either event. When the air conditioner is opened, the window may be reversed, and a lower output of the vent may be performed. The vehicle may also be able to determine whether the passenger's device requires charging. For example, the vehicle may identify the charge level of the personal mobile device through the stationary and/or mobile device. If the device requires charging, but the energy usage on the vehicle will increase, the vehicle may attempt to provide charging through secondary operations. Such ancillary operations may include portable chargers, other passenger cellular devices, solar cells, and the like. With weather services and/or on-board equipment, the vehicle may recommend a stopping location that is most efficient during the weather event or during the time of day when energy usage is greatest. For example, on a hot summer day, the vehicle may determine the optimal time to not operate and when to operate. The vehicle will then make an identification and share recommendations with the passengers to stop at a charging station or wait until a later time to re-drive the vehicle, etc.

The processor may further include: receiving, by a vehicle, a verification of an event from at least one component, wherein the verification includes blockchain consensus between peer groups consisting of the vehicle and the at least one component; and executing, by the vehicle, the intelligent contract to record the upcoming event and the at least one component on the blockchain based on the blockchain consensus. Blockchain transactions may be performed at any event detection period or by some sensor data detection procedure. In one example, the component or sensor will record external and internal audio when a relevant event is imminent. For example, if another vehicle is about to collide with the vehicle, the vehicle will turn on the external and internal audio components/sensors to help provide more accurate data collection regarding the expected event. Furthermore, the audio components/sensors will remain off until the processor senses an impending event in order to conserve energy by not operating features that are deemed unnecessary at a given time.

To further save energy, the components/sensors associated with the vehicle will be turned off when the auxiliary components/sensors are turned on, if applicable. In the event of a rear-end collision, the front-end components/sensors are switched off and the rear-end components/sensors are switched on, so that the vehicle can achieve energy neutralization (energy neutral). The component in this example may be any sensor or energized feature of the vehicle. If the main battery source is low and/or cannot power the components/sensors, an auxiliary energy source (e.g., portable charger, solar, phone battery, etc.) is used for the vehicle. The source will wirelessly connect to and power the second component as needed. Not providing energy to certain components on the vehicle is advantageous for saving energy. However, it may be desirable to provide energy to such components in certain situations (e.g., emergency situations, accident avoidance, etc.). In such a scenario, energy would be provided to the components prior to the occurrence of an emergency, accident, proximity accident, etc. (i.e., milliseconds, microseconds, nanoseconds, etc.). An associated processor and/or sensor on the vehicle will indicate when such an impending event occurs (or has passed) and provide energy to such a component (e.g., a server, another vehicle, etc.) that may provide additional data related to the situation. After providing the additional data, the processor and/or sensors are turned off until they may be needed. For example, when a vehicle is about to collide, zoom and/or pan features on cameras and/or other cameras located on and/or off the vehicle may be turned on. Before, during, and/or after such a collision, additional data from the turned-on camera (and/or any other component) is collected, stored, analyzed, and/or processed to produce a particular result.

In an embodiment, a small amount of energy (e.g., energy generated by the vehicle) is transmitted (by the vehicle, charging station, road, etc.) to provide energy to a particular vehicle sensor/device. In one example, the object approaches the vehicle from behind. The sensor (e.g., rear camera) is enabled, powered on, and a particular function of the sensor is activated to provide additional capabilities. For example, the capability may include a zoom feature provided by the sensor/camera, or other similar functionality that may be used/needed in certain situations (e.g., situations involving safety or emergency). In the current embodiment, the lens of the sensor/camera is preset for zoom operation. This function is enabled only when an object (e.g., another vehicle) approaches from behind and reaches a certain threshold distance (and/or speed) from the preceding vehicle. The speed and/or distance of the approach event is determined by one or more sensors on the vehicle. When the speed/distance of the object exceeds a known threshold, the zoom function will be enabled. The zoom function allows additional data (e.g., zoomed images/video) to be recorded. In one embodiment, the same camera is used to initiate recording. In an alternative embodiment, a separate camera is used to perform the data capture. The camera may only require a few seconds of energy or a fraction of a second of energy to capture the relevant image/video, so in this case the least amount of energy is required for this function. Thus, the total energy usage of the vehicle on a component/sensor-by-component level basis may be determined based on the probability of use of each component, the number of uses of each component, and the length of use of the component.

In another example, the vehicle may be traveling along a route where heavy rain is imminent, visibility is poor, and/or sunlight is diminishing, thus requiring the use of wipers on the headlights. In such an example, additional energy that was not originally intended may be required and would be derived from various sources such as a rolling charging network, vehicle-to-vehicle (V2V) wireless energy transfer, and so forth. Thus, the destination can be reached faster and more safely, and the energy usage of each component/sensor estimated before travel can be determined appropriately and updated based on current/future driving conditions. Energy savings may also be achieved by: operational modifications, regenerative braking, economy mode of operation, driving during times of low energy consumption, driving speed limits, savings or generation by performing certain functions (e.g., turning sensors on and off, more specifically acceleration and deceleration operations).

Fig. 2A illustrates a vehicle network diagram 200 according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a vehicle node 202 'having a processor 204'. The vehicle nodes 202 and 202 'communicate with each other through the processors 204 and 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of communication. The vehicle nodes 202 and 202' may communicate directly with each other via a private and/or public network (not shown) or via other vehicle nodes and elements including one or more of a processor, memory, and software. Although a single vehicle node and processor are shown, there may be multiple vehicle nodes and processors. One or more of the applications, features, steps, schemes, etc. described and/or depicted herein may be used and/or provided by these elements.

Fig. 2B illustrates another vehicle network diagram 210 according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a vehicle node 202 'having a processor 204'. The vehicle nodes 202 and 202 'communicate with each other through the processors 204 and 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of communication. The vehicle nodes 202 and 202' may communicate directly with each other via a private and/or public network (not shown) or via other vehicle nodes and elements including one or more of a processor, memory, and software. The processors 204 and 204' may further be in communication with one or more elements 230, including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicle nodes 222, computers 224, I/O devices 226, and voice applications 228. The processors 204 and 204' may further be in communication with elements including one or more of processors, memory, and software.

Although shown as a single vehicle node, processor, and element, there may be multiple vehicle nodes, processors, and elements. May transceive or communicate information with any of the processors 204, 204' and the element 230. For example, the mobile phone 220 may provide information to the processor 204, the processor 204 may initiate the vehicle node 202 to take an action, may further provide the information or additional information to the processor 204', the processor 204' may initiate the vehicle node 202' to take an action, may further provide the information or additional information to the mobile phone 220, the vehicle node 222, and/or the computer 224. One or more of the applications, features, steps, approaches, etc. described and/or depicted herein may be used and/or provided by these elements.

Fig. 2C shows yet another vehicle network diagram 240, according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and the element 230 (as shown in fig. 2B).

The processor 204 performs one or more of the following: determining that a characteristic associated with the passenger is at a level below a threshold (244C); performing an energy saving action to lower the characteristic level (246C); in response to the characteristic level rising above the level but below a threshold, performing an energy usage action to decrease the characteristic level (248C); and performing an energy saving action (250C) while performing the energy usage action.

Fig. 2D illustrates yet another vehicle network diagram 250, according to an example embodiment. The network includes elements including a vehicle node 202 having a processor 204 and a non-transitory computer readable medium 242D. Processor 204 is communicatively coupled to computer-readable medium 242D and element 230 (as shown in fig. 2B).

The processor 204 performs one or more of the following: determining a number of passengers within the vehicle, selecting one or more vehicle operations to perform in response to one or more of the energy saving actions and the energy usage actions based on the number of passengers (244D); determining one or more locations of one or more passengers within the vehicle, determining vehicle operations available at the one or more locations, and selecting one or more vehicle operations available at the one or more locations to perform in response to one or more of the energy saving actions and the energy usage actions (246D); in response to the energy saving action, reducing an initial energy usage level of the vehicle, and in response to the energy usage action, increasing the reduced energy usage level of the vehicle to create a modified energy usage level (248D) of the vehicle; prior to performing the energy saving action and the energy usage action, an initial energy usage level of the vehicle is identified, and during the performing the energy saving action and the energy usage action, the initial energy usage level of the vehicle is modified to be less than the initial energy usage level of the vehicle (250D).

Fig. 2E shows yet another vehicle network diagram 260, according to an example embodiment. Referring to fig. 2E, the network map 260 includes the vehicle node 202 connected to other vehicle nodes 202' and the update server node 203 through the blockchain network 206. The vehicle nodes 202 and 202' may represent vehicles/vehicles. The blockchain network 206 may have an accounting 208 for storing software update validation data and validation sources for future use (e.g., for auditing).

Although this example only details one vehicle node 202, a plurality of such nodes may be connected to the blockchain 206. It should be understood that the vehicle node 202 may include additional components and that some of the components described herein may be removed and/or changed without departing from the scope of the present application. The vehicle node 202 may have a computing device or server computer, etc., and may include a processor 204, which may be a semiconductor-based microprocessor, Central Processing Unit (CPU), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or other hardware device. Although a single processor 204 is depicted, it should be understood that the vehicle node 202 may include multiple processors, multiple cores, etc., without departing from the scope of the present application.

The processor 204 performs one or more of the following: receiving a verification of an energy saving event from at least one component, the verification comprising blockchain consensus between peer groups consisting of a vehicle and the at least one component (244E); an intelligent contract is executed to record energy saving events and the at least one component on the blockchain based on the blockchain consensus (246E).

The processor and/or computer readable medium may be located wholly or partially inside or outside the vehicle node. Steps or features stored in a computer readable medium may be executed in whole or in part by any processor and/or element in any order. Further, one or more steps or features may be added, omitted, combined, or performed at a later time.

Fig. 2F shows a diagram 265 depicting electrification of one or more elements. In an embodiment, the vehicle 266 may provide the energy stored in its battery to one or more elements, including other vehicles 268, a charging station 270, and an electrical grid 272. The power grid 272 is connected to one or more charging stations 270, and the charging stations 270 may be connected to one or more vehicles 268. This configuration allows for distribution of electrical energy received from the vehicle 266. The vehicle 266 may also interact with other vehicles 268, such as through vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, and so forth. The vehicle 266 may also interact with other vehicles 268, charging stations 270, and/or the power grid 272 in a wireless and/or wired manner. In an embodiment, the vehicle 266 is routed (or self-routes) to the power grid 272, the charging station 270, or other vehicle 268 in a safe and efficient manner. In one or more embodiments employing the present solution, the vehicle 266 may provide energy to one or more of the elements depicted herein in a variety of advantageous ways as described and/or depicted herein. Further, the safety and efficiency of the vehicle may be improved and may positively impact the environment as described and/or depicted herein.

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 refer to a voltage source and/or current supply of charge provided to the vehicle from an entity during charging/use operations. Energy may also be in the form of fossil fuels (e.g., for hybrid vehicles) or through other alternative energy sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic/nuclear, fusion energy, and energy dynamically generated during energy sharing and/or use operations to increase or decrease one or more vehicle energy levels at a given time.

In one embodiment, the charging station 270 manages the amount of energy transferred from the vehicle 266 such that there is sufficient charge left in the vehicle 266 to reach the destination. In one embodiment, wireless connections are used to wirelessly guide the amount of energy transfer between vehicles 268, which may all be in operation. In one embodiment, an idle vehicle, such as vehicle 266 (which may be autonomous) is directed to provide a certain amount of energy to the charging station 270 and return to an initial location (e.g., its initial location or a different destination). In an embodiment, 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 a charging station 270. In one embodiment, factors determine the amount of energy that can be delivered to the charging station 270, such as distance, time, and traffic conditions, road conditions, environmental/weather conditions, vehicle conditions (weight, etc.), schedule of passenger usage of the vehicle, schedule of expected passengers of waiting vehicles, and the like. In an embodiment, the vehicle 268, the charging station 270, and/or the power grid 272 may provide energy to the vehicle 266.

In an embodiment, the solutions described and depicted herein may be used to determine load impact on a vehicle and/or system, provide energy to the vehicle and/or system based on future needs and/or priorities, and provide intelligence between a device containing the module and the vehicle, allowing a processor in the device to wirelessly communicate with the vehicle regarding the amount of energy storage in a battery on the vehicle. In an embodiment, the solution may also be used to provide charging from a vehicle to a location based on factors such as the temperature of the location, the cost of energy, and the energy level at the location. In an embodiment, the solution may also be used to manage the amount of energy remaining in the vehicle after a portion of the charge has been transferred to the charging station. In an embodiment, the solution may also be used to notify the vehicle to provide an amount of energy from a battery on the vehicle, where the amount of energy to transmit is based on the distance between the vehicle and the module to receive the energy.

In an embodiment, the solution may also be used to use a mobile energy storage unit that travels using the determined path to a vehicle that has excess energy and stores the stored energy in an electrical grid. In an embodiment, the solution may 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 demand, such as the priority of passengers, upcoming passengers, current cargo or upcoming cargo. In an embodiment, the solution may also be used to determine that when the vehicle is idle, the vehicle decides to travel to a location to release excess energy to the grid and return to the previous location. In an embodiment, the solution may also be used to determine the energy required by the vehicle based on one or more conditions (e.g., weather, traffic, road conditions, automobile conditions, and/or passengers and/or cargo in other vehicles) to provide the required energy to another vehicle through vehicle-to-vehicle energy transfer, and to instruct the vehicle to route to another vehicle and provide energy. In an embodiment, the solution can also be used to transfer energy from one moving vehicle to another. In an embodiment, the solution may also be used to retrieve energy from a vehicle based on the predicted energy consumption of the vehicle to reach a rendezvous point with another vehicle, provide service, and return to an original location. In an embodiment, the solution may also be used to provide a remaining distance required to reach a charging station, the charging station determining a size of energy to take away from the vehicle, wherein the amount of energy remaining is based on the remaining distance. In an embodiment, the solution can also be used to manage a vehicle that is charged at multiple points simultaneously, for example a charging station through a wired connection and another vehicle through a wireless connection. In an embodiment, the solution may also be used to assign energy application priorities to vehicles, where priority will provide a portion of their stored energy to those vehicles of another entity (e.g., a power grid, a residence, etc.). Further, the solution described and depicted with respect to fig. 2F may be used in this and other networks and/or systems.

Fig. 2G shows a diagram of the interconnections 275 between the different elements. 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 communicatively coupled to and in communication with the network 286. Database 287 is communicatively coupled to a network and allows data storage and retrieval. In one embodiment, the database is an immutable book. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, a power grid/charging station 284, a microphone 285, and/or another vehicle 277. Other entities and/or devices, such as one or more private users using smart phone 278, laptop 280, and/or wearable devices, may also interwork with the present solution. Smart phone 278, laptop 280, microphone 285, and other devices may be connected with one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various facilities. One or more public buildings 281 may use computing devices 281'. The one or more service providers 279 may include a dealer, a trailer service, a collision center, or other repair shop. One or more service providers 279 may use computing devices 279'. Such various computer devices may be directly and/or communicatively coupled to each other, e.g., through a wired network, a wireless network, a blockchain network, etc. In one embodiment, the microphone 285 may act as a virtual assistant. In an embodiment, the one or more traffic infrastructures 282 may 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 infrastructures. One or more traffic infrastructures 282 may utilize a computing device 282'.

In one embodiment, the vehicle 277/276 is capable of transporting people, things, permanently or temporarily affixed devices, and the like. In one embodiment, the vehicles 277 may communicate with the vehicles 276 via V2V communications through the computers 276 'and 277' associated with each vehicle, and may be referred to as vehicles, cars, vehicles, automobiles, and the like. The vehicle 276/277 may be a self-propelled wheeled vehicle such as an automobile, sport utility vehicle, truck, bus, van, or other motor or battery powered or hybrid electric vehicle. For example, the vehicle 276/277 may be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, an electric motor, and/or a generator. Other examples of vehicles include bicycles, scooters, trains, planes or boats, and any other form of transportation that can be used for transportation. The vehicle 276/277 may be semi-automatic or fully automatic. For example, the vehicle 276/277 may be automatically steered and navigated without manual operation. Automated vehicles may have and use one or more sensors and/or navigation units to enable autonomous driving.

In an embodiment, the solution described and depicted herein can be used to determine access to a vehicle through consensus of blockchains. In an embodiment, the solution may also be used to perform profile verification before allowing the passenger to use the vehicle. In an embodiment, the solution may also be used for having the vehicle indicate (visually, also in another embodiment verbally, etc.) on or from the vehicle the action (which may be pre-recorded) that the user needs to perform and verify the correctness of the action. In an embodiment, the solution may also be used to provide the vehicle with the ability to determine how to branch the data based on the risk level associated with the data and the driving environment, and to distribute to the passengers a portion of the branched data having a lower risk level in a safe driving environment, and to distribute to the passengers a remaining portion of the branched data having a higher risk level later after the passengers leave the vehicle. In one embodiment, the solution may also be used to handle vehicle transfers across boundaries (e.g., countries/states/etc.) by using blockchains and/or intelligent contracts, and apply rules for new regions to the vehicle.

In an embodiment, the solution may also be used to allow the vehicle to continue traveling outside the boundary when the vehicle reaches consensus based on the operation of the vehicle and the characteristics of the occupants of the vehicle. In an embodiment, the solution may also be used to analyze the available data upload/download speed of the vehicle, the size of the file, and the travel speed/direction of the vehicle to determine the distance required to complete the data upload/download and to assign a safe zone boundary to perform the data upload/download. In an embodiment, the solution may also be used to perform normally dangerous operations in a safe manner, such as instructing the subject vehicle and other nearby vehicles so that the subject vehicle safely exits the exit when the system determines that an exit location is being approached and when the vehicle does not appear to be ready to exit the exit (e.g., on a wrong-way lane or traveling at a speed that is not conducive to exiting the exit). In an embodiment, the solution may also be used for a determination to authenticate another vehicle using one or more vehicles, where the one or more vehicles and the other vehicle are both in motion.

In an embodiment, the solution may also be used to detect lane usage at a location at a time, to notify passengers of the vehicle or to guide the vehicle to recommend or not recommend changing lanes. In an embodiment, the solution may also be used to remove the need to send information by mail and to remove the need for the driver/passenger to respond by mail or in-person payment. In an embodiment, the solution may also be used to provide services to passengers of a vehicle, where the services are provided on a subscription basis, and where permissions are obtained from other vehicles connected to the passenger profiles. In one embodiment, the solution may also be used to record state changes for leased objects. In an embodiment, the solution may also be used to seek blockchain consensus from other vehicles that are close to the damaged vehicle. In an embodiment, the solution may also be used to receive media from a server, such as an insurance entity server, from a vehicle computer, which may be related to an accident. The server accesses one or more media files to access the damage status of the vehicle and stores the damage assessment onto the blockchain. In an embodiment, the solution can also be used to obtain consensus from multiple devices at different times prior to the vehicle-related event to determine the severity of the event.

In an embodiment, the solution may also be used to address the problem of insufficient video evidence of a vehicle-related accident. Current solutions detail querying, by a vehicle involved in an accident, for media related to the accident from other vehicles that may be proximate to the accident. In an embodiment, the solution may also be used to record specific parts of a damaged vehicle with vehicles and other devices (e.g., pedestrian's cell phone, street light camera, etc.).

In an embodiment, the solution may also be used to alert passengers when the vehicle is traveling to a dangerous area and/or event, allowing the vehicle to notify passengers or the central controller of a potentially dangerous area on or near the current travel route. In an embodiment, the solution may also be used to detect that at least another vehicle is used to help slow down the vehicle with minimal impact on the traffic when the vehicle is traveling at high speed. In an embodiment, the solution may also be used to identify a dangerous driving situation, wherein the media information is captured by a vehicle in a dangerous driving situation. A geofence is established based on distance from the hazardous driving condition, and additional media information is captured by at least one other vehicle within the established geofence. In an embodiment, the solution may also be used to send a notification to one or more passengers of a vehicle that the vehicle is approaching a traffic control marking on a road, and if the vehicle crosses this marking, receive an indication of bad driving from other nearby vehicles. In one embodiment, the solution may also be used to render the vehicle partially inoperable by limiting the speed, limiting the ability to approach another vehicle, limiting the maximum speed, and setting a given number of miles allowed per time period (in some embodiments).

In an embodiment, the solution may also be used to overcome the need to rely on software updates to correct vehicle problems when the vehicle is not operating properly. By observing other vehicles on the route, the server receives data from potentially many other vehicles, observing unsafe or incorrect operation of the vehicles. By analysis, these observations can produce notifications to the vehicle when the data indicates that unsafe or incorrect operation exists. In an embodiment, the solution may also be used to provide notification between the vehicle and a potentially dangerous situation involving people outside the vehicle. In an embodiment, the solution may also be used to send data to a server through a device associated with the vehicle or accident or a device proximate to the accident. Based on the severity of the accident or impending accident, the server notifies the sender of the data. In an embodiment, the solution may also be used to provide recommendations to a driver or passenger of the vehicle to operate the vehicle based on the data analysis. In an embodiment, the solution can also be used to establish a geofence associated with a physical structure and determine a payment responsibility for the vehicle. In one embodiment, the solution may also be used to coordinate the ability to return to a vehicle (drop off vehicle) at a location based on the current state of the location and the proposed future state using other vehicle navigation destinations. In one embodiment, the solution can also be used to coordinate the ability to automatically arrange for a return at a location such as a vehicle rental entity.

In an embodiment, the solution may also be used to move the vehicle to another location based on a user event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user at the end of the original event or the modified event. In an embodiment, the solution may also be used to allow verification of available locations within an area by existing vehicles within the area. The approximate time that the location may vacate may also be determined based on verification from existing vehicles. In an embodiment, the solution may also be used to move a vehicle to a nearby parking space when the parking space is available, and the time elapsed after the start of parking is less than the average time of the event. Further, the vehicle is moved to a final parking space upon completion of the event or depending on a location of a device associated with at least one passenger of the vehicle. In an embodiment, the solution may also be used to plan parking before congestion arrives. The system interacts with the vehicle to provide some services at a lower than full price and/or to direct the vehicle to an alternate parking space based on the priority of the vehicle, thereby promoting parking situation optimization prior to arrival.

In an embodiment, the solution may also be used to sell partial ownership in a vehicle or to determine pricing and availability in a ride share application. In one embodiment, the solution can also be used to provide accurate and timely reporting of dealer sales activity on a scale far beyond what is currently available. In one embodiment, the solution may also be used to allow dealers to request assets through a blockchain. By using blockchains, consensus is achieved before any assets are transferred. Further, the process is automated and payment can be initiated through the blockchain. In an embodiment, the solution may also be used to arrange agreements with multiple entities (e.g., service centers) where consensus is obtained and actions (e.g., diagnostics) are performed. In an embodiment, the solution may also be used to associate digital keys with multiple users. The first user may be an operator of the vehicle and the second user is a responsible party of the vehicle. These keys are authorized by the server, with the proximity of the keys being verified against the location of the service provider. In an embodiment, the solution may also be used to determine the services required by the vehicle at the destination. One or more service points are located that are capable of providing the required service, both within the area on the route to the destination and with availability to perform the service. Updating the navigation of the vehicle with the determined service point. Intelligent contracts that include compensation values for services are identified, and blockchain transactions are stored in a distributed ledger of transactions.

In one embodiment, the solution may also be used to interface a service provider vehicle with a vehicle occupant's profile to determine services and goods in the vehicle that may be of interest to the occupant. These services and goods are determined by the passenger's history and/or preferences. The vehicle then receives the quote from the service provider vehicle and, in another embodiment, satisfies the vehicle to provide the service/goods. In an embodiment, the solution may also be used to detect vehicles within range and send service offers (e.g., maintenance offers, product offers, etc.) to the vehicles. An agreement is made between the system and the vehicle, the system selecting a service provider to provide the agreement. In an embodiment, the solution may also be used to assign one or more vehicles as road managers, where the road managers assist in traffic management. Road managers may generate road indication signals (e.g., lights, displays, sounds) to help break traffic. In an embodiment, the solution may also be used to alert the driver of the vehicle through a device, which may be a traffic light or an approach to an intersection. An alarm is issued when an event occurs, such as a light turning green, a vehicle in front of a train of vehicles not moving.

Fig. 2H is another block diagram illustrating interconnections between different elements in example 290. The vehicle 276 is shown and includes

ECUs

295, 296 and an audio host (also referred to as infotainment system) 297. An Electrical Control Unit (ECU) is an automotive electronics embedded system for controlling one or more electrical systems or subsystems in a vehicle. The ECU may include, but is not limited to, an engine, a braking system, a transmission system, door locks, an instrument panel, an airbag system, an infotainment system, an electronic differential, and a mobile suspension that manage the vehicle. The ECU is connected to a Controller Area Network (CAN) bus 294 of the vehicle. The ECU may also communicate with a vehicle computer 298 via a CAN bus 294. The vehicle's processor/sensor (e.g., vehicle computer) 298 can communicate with external elements, such as the server 293 via the network 292 (e.g., the internet). Each ECU295, 296 and the sound host 297 may contain its own security policy. The security policy defines a licensing process that can be performed in the appropriate context. In an embodiment, the security policy may be provided partially or entirely in the vehicle computer 298.

The

ECUs

295, 296 and the sound host 297 may each include a custom security function 299 for defining authorized processes and contexts that allow such processes to operate. Context-based authorization to determine the validity of a process that CAN be performed, keeps the ECU running securely, and prevents unauthorized access to elements such as the vehicle's controller area network (CAN bus). When an ECU encounters an unauthorized process, the ECU may prevent the process from running. The car ECU may use different contexts to determine whether the process is running within its allowed range, such as proximity context (e.g., nearby objects, distance from proximate objects, speed, and trajectory relative to other moving objects), operational context (e.g., an indication of whether the vehicle is moving or parked, current speed of the vehicle, transmission status), user-related context (e.g., devices connected to the vehicle via a wireless protocol, infotainment usage, cruise control, parking assistance, driving assistance), location-based context, and/or other contexts.

In one embodiment, the solution described and depicted herein may be used to render a vehicle partially inoperable by limiting speed, limiting the ability to approach another vehicle, limiting the maximum speed, and setting a given number of miles allowed per time period (in some embodiments). In an embodiment, the solution may also be used to facilitate the exchange of vehicle ownership using blockchains, where data is sent to a server through a device associated with the vehicle or accident or a device proximate to the accident. Based on the severity of the accident or near accident, the server notifies the sender of the data. In an embodiment, the solution may also be used to help the vehicle avoid the accident, for example when the vehicle is involved in the accident, the server queries other vehicles that are close to the accident. The server attempts to obtain data from other vehicles, allowing the server to learn the nature of the incident from a number of vantage points. In one embodiment, the solution may also be used to determine whether a sound emitted by a vehicle is atypical and transmit data related to the sound and the likely source location to a server, where the server may determine the likely cause and avoid a potentially dangerous situation. In an embodiment, the solution may also be used to establish location boundaries by the system when the vehicle is involved in an accident. The boundary is determined based on decibels associated with the incident. Multimedia content of devices within the boundary is acquired to help further understand the incident scene. In one embodiment, the solution may also be used to associate a vehicle with an accident, and then capture media obtained by devices near the location of the accident. The captured media is saved as a media clip. The media segments are transmitted to another computing device, which creates a voice profile of the incident. This sound profile helps to learn more about the incident.

In an embodiment, the solution may also be used to record audio, video, motion, etc. with sensors to record areas where potential events occur, such as if the vehicle contacts (while moving or parked) or may contact another vehicle, the system captures data from sensors that may be located on one or more of the vehicle and/or a stationary or moving object. In an embodiment, the solution may also be used to determine that the vehicle has been damaged by identifying a new condition of the vehicle using sensor data during the event, comparing the condition to a vehicle condition profile, thereby enabling secure and reliable capture of critical data from a vehicle about to enter an adverse event.

In an embodiment, the solution may also be used to alert the occupants of the vehicle when the vehicle determines, through one or more sensors, that it is approaching or traveling along a one-way road in an incorrect manner. The vehicle has sensors/cameras/maps that interact with the system in the current solution. The system knows the geographical location of the one-way road. For example, the system may audibly notify the passenger that "a one-way road is being approached. In one embodiment, the solution may also be used to allow vehicle remuneration, enable automated vehicle owners to earn money using data collected and stored by their vehicle sensors, encourage vehicle owners to share their data and provide additional data to entities, improve future vehicle performance through such data, provide services to vehicle owners, and the like.

In an embodiment, the solution may also be used to increase or decrease vehicle characteristics depending on the motion of the vehicle over a period of time. In an embodiment, the solution may also be used to assign partial ownership of the vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine a condition of the vehicle. Partial ownership of the vehicle is determined based on conditions and provides new vehicle accountability. In an embodiment, the solution is further operable to provide data to the replacement/upgrade component, wherein the data attempts to destroy authorized functionality of the replacement/upgrade component, and in response to non-destructibility of the authorized functionality, the component allows use of the authorized functionality of the replacement/upgrade component.

In an embodiment, the solution may also be used to provide individuals with the ability to ensure that passengers are in a vehicle and that passengers arrive at a particular destination. Further, the system ensures that authorized drivers (if not autonomous vehicles) and/or other passengers interact with the passenger. In addition, getting on, getting off, and location are labeled. All of the above is stored in an immutable manner on the blockchain. In an embodiment, the solution may also be used to determine characteristics of the driver through analysis of driving style and other elements to take action if the driver is not driving in a normal manner, such as the driver's previous driving style under certain conditions, e.g., daytime, night, rain, snow, etc. Further, the properties of the vehicle are also taken into account. Attributes include weather, whether headlights are on, whether navigation is being used, whether the HUD is being used, the volume of the media being played, etc. In an embodiment, the solution may also be used to notify passengers in a vehicle of a hazardous situation when items within the vehicle indicate that the occupants may not be aware of the hazardous situation.

In an embodiment, the solution can also be used to install calibration devices on equipment (rig) fixed on the vehicle, where various sensors on the vehicle can automatically adjust themselves based on a comparison of what the calibration device should detect with the actual detection result. In an embodiment, the solution may also be used to request consensus of multiple service centers using blockchains when a vehicle requiring service sends fault information allowing remote diagnostic functionality, where other service centers need to agree on a severity threshold for the data. Upon receiving the consensus, the service center may send the fail-safe level to the blockchain for storage. In an embodiment, the solution may also be used to determine the difference between sensor data external to the vehicle and sensor data of the vehicle itself. The vehicle requests software from the server to correct the problem. In one embodiment, the solution may also be used to allow vehicles in the vicinity or in the area to deliver messages when an event occurs (e.g., a collision).

Referring to fig. 2I, an operating environment 290A of a connected vehicle is shown, in accordance with some embodiments. As shown, the vehicle 276 includes a Controller Area Network (CAN) bus 291A that connects the elements 292A-299A in the vehicle. Other components may be connected to the CAN bus, not shown here. The components shown connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous driving feature or Advanced Driving 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.

Processor 296A includes an arithmetic logic unit, a microprocessor, a general purpose controller, and/or similar processor array for performing computations and providing electronic display signals to 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 Computer (RISC) architecture, or an architecture implementing a combination of instruction sets. The vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) communicatively coupled to each other may be used together in the present solution.

The memory 297A is a non-transitory memory that stores instructions or data that are accessible and executable by the processor 296A. The instructions and/or data may include code for performing the techniques described herein. The memory 297A may be a Dynamic Random Access Memory (DRAM) device, a Static Random Access Memory (SRAM) device, flash memory, or some other memory device. In some embodiments, memory 297A may also include non-volatile memory or similar permanent storage devices and media, which may include a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for permanently storing information. A portion of the memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). The vehicle 276 may include one or more memories 297A without departing from the current solution.

The memory 297A of the vehicle 276 can store one or more of the following types of data: navigation routing data 295A and autopilot feature data 294A. In some embodiments, the memory 297A stores data that may be needed by the navigation application 295A to provide functionality.

The navigation system 295A can describe at least one navigation route that includes a start point and an end point. In some embodiments, the navigation system 295A of the vehicle 276 receives a request from a user to navigate a route, the request including a start point and an end point. The navigation system 295A may query a real-time data server 293, e.g., a server providing driving directions, for navigation route data corresponding to a navigation route including a start point and an end point (via the network 292). The real-time data server 293 transmits the navigation route data to the vehicle 276 via the wireless network 292 and the communication system 298A stores the navigation data 295A in the memory 297A of the vehicle 276.

The ECU 293A controls the operation of many systems of the vehicle 276, including the ADAS system 294A. The ECU 293A may disable any unsafe and/or unselected autopilot features during a trip controlled by the ADAS system 294A in response to instructions received from the navigation system 295A. In this way, the navigation system 295A can control whether the ADAS system 294A is activated or enabled such that the ADAS system 294A can be activated for a given navigation route.

Sensor group 292A may include any sensor in vehicle 276 for generating sensor data. For example, 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, automobile engine sensors, radar sensors, laser altimeters, intake air pressure sensors, infrared detectors, motion detectors, thermostats, acoustic 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 functions, and any other type of automotive sensor. The navigation system 295A may store the sensor data in the memory 297A.

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

Vehicle 276 may interact with other vehicles 277 via V2V technology. The V2V communication includes sensing radar information corresponding to relative distance to external objects, receiving GPS information of the vehicle, setting an area to be 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 in one embodiment, identifying the vehicle and/or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

In an embodiment, the solution described and depicted herein may be used to manage emergency and vehicle features when it is determined that a vehicle enters an area without network access. In an embodiment, the solution may also be used to manage and provide features (e.g., audio, video, navigation, etc.) in a vehicle without a network connection. In an embodiment, the solution may also be used to determine when a profile of a person in proximity to the vehicle matches a profile attribute of a profile of at least one passenger in the vehicle. A notification is sent from the vehicle to establish communication.

In an embodiment, the solution can also be used to analyze whether a passenger is present in each vehicle available for voice communications based on the amount of time remaining in the vehicle and the context of the communication to be performed. In an embodiment, the solution may also be used to determine two risk levels that a road is congested and receive a gesture that may indicate that the congestion does not rise above a threshold in order for the vehicle to continue along the road. In one embodiment, the solution may also be used to delete sensitive data from the vehicle when the vehicle has been damaged and is not in use.

In one embodiment, the solution may also be used to verify that customer data to be deleted has indeed been deleted from all necessary locations within the enterprise, proving GDPR compliance. In an embodiment, the solution may also be used to consider one vehicle exchanging data related to safety, important notifications, etc. with another vehicle to enhance the autopilot capabilities of lower level autopilot vehicles. In an embodiment, the solution may also be used to provide the vehicle with the ability to receive data based on a first biometric associated with the passenger. The vehicle then decrypts the encrypted data based on verification of a second biometric, wherein the second biometric is a continuum of the first biometric. The vehicle provides the decrypted data to the passenger when only the passenger is able to receive the decrypted data, deletes the sensitive portion of the decrypted data when the sensitive portion is provided, and deletes the non-sensitive portion after a period of time associated with the biometric has elapsed. In an embodiment, the solution may also be used to provide the vehicle with the ability to authenticate personnel based on the weight and grip on the vehicle steering wheel. In an embodiment, the solution may also be used to provide the car with features that are present but not currently enabled for presentation to the car occupants, which reflect the characteristics of the occupants.

In an embodiment, the solution may also be used to allow modification of the vehicle, particularly inside the vehicle, as well as outside the vehicle, to reflect or assist at least one passenger in an embodiment. In another embodiment, a work and/or home environment is disclosed that reproduces passengers. If the system determines that the user is in "work mode" or "home mode," the system may attempt to "render" the user's work/home environment while the user is in the vehicle. All data relating to the inside and outside of the vehicle and the various passengers using the vehicle are stored on the blockchain and executed by the smart contracts. In an embodiment, the solution may also be used to detect passenger gestures to facilitate communication with nearby vehicles, where the vehicles may operate accordingly. In an embodiment, the solution may also be used to provide a vehicle with the ability to detect an expected gesture using the gesture definition data store. In an embodiment, the solution may also be used to provide the vehicle with the ability to take various actions based on the gait and gestures of the occupant. In an embodiment, the solution may also be used to ensure that the driver of a vehicle currently engaged in various operations (e.g., driving while voice navigating, etc.) does not exceed the number of unsafe operations before being allowed gesture operations.

In an embodiment, the solution may also be used to assign a status to each passenger in the vehicle and verify the passenger's gesture based on the passenger's status. In an embodiment, the solution can also be used to collect and provide crash related sound details (where, in what direction, up or down, from what equipment, device related data, such as type, manufacturer, owner, and number of sounds emitted simultaneously, time of sound emitted, etc.) to the system, where data analysis helps to determine details about the crash. In an embodiment, the solution may also be used to determine that the vehicle operation is unsafe. The vehicle includes a plurality of components that interoperate to control the vehicle, and each component is associated with a separate component key. The encryption key is sent to the vehicle to reduce vehicle functionality. In response to receiving the encryption key, the vehicle disables one or more component keys. Disabling one or more component keys results in one or more of the following operations: the method includes limiting the vehicle from moving no more than a given speed, limiting the vehicle from moving no less than a certain distance from another vehicle, and limiting the vehicle from traveling no more than a threshold distance.

In an embodiment, the solution may also be used to provide an indication from one particular vehicle (that a position is to be vacated) to another particular vehicle (that a position is to be occupied), and the blockchain is used to perform authentication and coordination. In an embodiment, the solution may also be used to determine part of the responsibilities of the vehicle. For example, where multiple people own a single vehicle, the use of the vehicle (which may change over time) is used by the system to update partial ownership. Other embodiments would be included in the application, including not based on vehicle use but on the minimum ownership of the vehicle, i.e., availability of the vehicle, determination of the driver of the vehicle, and others.

In an embodiment, the solution may also be used to allow in-vehicle users to share their subscription services with a small group such as family or friends. For example, a user may want to share membership, and if so, the associated transaction will be stored in a blockchain or traditional database. When a user that is not a primary subscriber requests subscription to material, the blockchain node (i.e., vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber shares a profile. In an embodiment, the solution may also be used to allow people to reach predetermined destinations with an auxiliary vehicle. The auxiliary vehicle is determined using a functional relationship value (e.g., a value representing various parameters and their importance in determining which type of vehicle to use). In an embodiment, these solutions may also be used to allow the passengers of an accident to continue to their original destinations using other vehicles.

In an embodiment, the solution may also be used to propagate software/firmware uploads to a first subset of vehicles. The first group of vehicles tests the update and, when the test is successful, propagates the update to another group of vehicles. In an embodiment, the solution may also be used to propagate software/firmware updates from the host vehicle to the vehicles, where the updates are propagated through a network from a first subset of vehicles, followed by a larger subset, and so on. A portion of the updated content may be sent first and then the remaining portion sent from the same vehicle or another vehicle. In an embodiment, the solution may also be used to provide vehicle computer updates to the vehicle and vehicle operator/passenger's devices. The updated content may be authorized by all drivers and/or all passengers. The software update content is provided to the vehicle and the device. The user does not need to do anything, and the function can be automatically completed as long as the user approaches the vehicle. A notification is sent to the device indicating that the software update is complete. In an embodiment, the solution may also be used to verify that OTA software updates are performed by qualified technicians and that the status is generated by one or more vehicle components in relation to: an initiator of the authentication code, a program to wirelessly receive the software update, information contained in the software update, and an authentication result.

In an embodiment, the solution may also be used to provide the ability to parse a software update located in a first component through a second component. The method then includes verifying the critical update content of the first portion and the non-critical update content of the second portion, assigning the verified first portion to a process in the vehicle, which runs the verified first portion for a period of time, and responding to a positive result based on the period of time, which runs the verified first portion with other processes after a period of time. In an embodiment, the solution may also be used to provide passengers with service choices, where the service is based on the passenger profile of the vehicle and the profile shared with the passenger profile. In an embodiment, the solution may also be used to store user profile data in a blockchain and intelligently present offers and recommended content to the user based on the purchase history automatically collected by the user and preferences obtained from the user profile on the blockchain.

Fig. 3A shows a flow diagram 300 according to an example embodiment. Referring to fig. 3A, processor 300 may perform one or more of the following: determining that a characteristic associated with a passenger is at a level below a threshold (302); performing an energy saving action to reduce the characteristic level (304); in response to the characteristic level rising above the level but below a threshold, performing an energy usage action to reduce the characteristic level (306); and performing an energy saving action (308) while performing the energy usage action.

Fig. 3B shows another flowchart 320 according to an example embodiment. Referring to fig. 3B, the processor may perform one or more of the following: determining a number of passengers within the vehicle, and based on the number of passengers, selecting one or more vehicle operations to perform in response to one or more of the energy saving actions and the energy usage actions (322); determining one or more locations of one or more passengers within the vehicle, determining vehicle operations available at the one or more locations, and selecting one or more vehicle operations available at the one or more locations to perform in response to one or more of the energy saving action and the energy usage action (324); in response to the energy saving action, reducing an initial energy usage level of the vehicle, and in response to the energy usage action, increasing the reduced energy usage level of the vehicle to create a modified energy usage level of the vehicle (326); prior to performing the energy saving action and the energy usage action, an initial energy usage level of the vehicle is identified, and during the performance of the energy saving action and the energy usage action, the initial energy usage level of the vehicle is modified to be less than the initial energy usage level of the vehicle (328).

Fig. 3C shows yet another flowchart 340 according to an example embodiment. Referring to fig. 3C, the processor may perform one or more of the following: receiving a verification of an energy saving event from at least one component, wherein the verification includes blockchain consensus between peer groups consisting of vehicles and the at least one component (342), and executing an intelligent contract to record the energy saving event and the at least one component on the blockchain based on the blockchain consensus (344).

Fig. 4 illustrates a machine-learning vehicle network diagram 400 according to an example embodiment. The network 400 includes a vehicle node 402 that interfaces with a machine learning subsystem 406. The vehicle node includes one or more sensors 404.

The machine learning subsystem 406 contains a learning model 408, which is a mathematical artifact created by a machine learning training system 410 that generates predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 is in the vehicle node 402. In other embodiments, the machine learning subsystem 406 is external to the vehicle node 402.

The vehicle node 402 sends data from one or more sensors 404 to a machine learning subsystem 406. Machine learning subsystem 406 provides one or more sensor 404 data to learning model 408, and learning model 408 returns one or more predictions. The machine learning subsystem 406 sends one or more instructions to the vehicle node 402 based on the predictions from the learning model 408.

In yet another embodiment, the vehicle node 402 may send one or more sensor 404 data to the machine learning training system 410. In yet another embodiment, the machine learning subsystem 406 may send the sensor 404 data to the machine learning training system 410. One or more of the applications, features, steps, solutions, etc., described and/or depicted herein may utilize the machine learning network 400 described herein.

Fig. 5A illustrates an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Referring to fig. 5A, when a particular vehicle/vehicle 525 engages in a transaction (e.g., vehicle service, dealer transaction, delivery/pickup, transportation service, etc.), the vehicle may receive the asset 510 and/or log off/transfer the asset 512 according to the transaction. The vehicle processor 526 is 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 may record information such as assets, parties, points, service descriptions, dates, times, locations, results, notifications, incidents, and the like. Those transactions in the transaction module 520 may be copied into the database 530. Database 530 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and may be on-board or off-board the vehicle, or may be directly accessible and/or accessible over a network, or may be accessible by the vehicle.

Fig. 5B illustrates an example vehicle configuration 550 for managing database transactions conducted between vehicles, according to an example embodiment. When the vehicle enters a state requiring sharing of services with another vehicle, the vehicle 525 may engage with another vehicle 508 to perform various actions, such as sharing, transferring, obtaining a service call, and the like. For example, the vehicle 508 may need to charge a battery and/or may have tire problems, and may be en route to pick up a package for delivery. The vehicle processor 528 is in the vehicle 508 and there is communication between the vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 can notify another vehicle 525 that the vehicle 525 is running in its network and on its blockchain member service. The vehicle processor 526 is in the vehicle 525 and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The vehicle 525 may then receive information via a wireless communication request to perform package pickup from the vehicle 508 and/or a server (not shown). The transactions are recorded in the

transaction modules

552 and 520 of the two vehicles, respectively. Credits are transferred from vehicle 508 to vehicle 525 and records of the transfer service are recorded in database 530/554 assuming the blockchains are different from each other, otherwise in the same blockchain common to all members. The database 554 may be one of a SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and may be onboard the vehicle, may be off-board the vehicle, may be directly accessible and/or accessible over a network.

Fig. 6A illustrates a blockchain architecture configuration 600, according to an example embodiment. Referring to fig. 6A, a blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602 as part of a

blockchain set

610 and 606. In an example embodiment, the permitted blockchain is not accessible by all parties, only those members that are allowed to access the blockchain data. The block link points participate in a number of activities, such as block chain entry addition and verification processes (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. A blockchain link point may initiate a blockchain action (e.g., authentication) and seek to write into a blockchain immutable ledger stored in the blockchain, a ledger copy of which may also be stored on the underlying physical infrastructure.

Blockchain transactions 620 are stored in the memory of the computer as transactions received and audited by the consensus model specified by the member node. The approved transaction 626 is stored in the current block of the chain of blocks and is submitted to the chain of blocks by a commit procedure that includes performing a hash operation on the data content of the transaction in the current block and performing a previous hash reference of the previous block. Within the blockchain, there may be one or more intelligent contracts 630 that define terms of the transaction protocols and actions contained in the intelligent contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, and the like. The code may be configured to identify whether the requesting entity is registered to receive vehicle services, what service functions they have rights/need to obtain based on the requesting entity's profile, and whether to monitor their behavior in subsequent events. For example, when a service event occurs and a user is riding in a vehicle, sensor data monitoring may be triggered, a certain parameter (e.g., vehicle charge level) may be identified as above/below a certain threshold for a certain period of time, such that the result may be a change in current status, which requires an alert to be sent to an administrative party (i.e., vehicle owner, vehicle operator, server, etc.) in order to identify and store the service for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle's state. Sensor data may also be the basis for vehicle event data 634, such as the location of the trip, average speed, top speed, acceleration, whether there is a collision, whether an expected route is taken, where the next destination is, whether safety measures are in place, whether the vehicle has sufficient electricity/fuel, etc. All of this information may be used as a basis for the terms of the intelligent contracts 630 and stored in the blockchain. For example, sensor thresholds stored in the smart contracts may be used as a basis for determining whether and where detected services are necessary to perform the services.

FIG. 6B illustrates a shared book configuration, according to an example embodiment. Referring to fig. 6B, the blockchain logic example 640 includes a blockchain application program interface 642, which is an API or plug-in application, that links to the computing device and execution platform for a particular transaction. Blockchain configuration 640 may include one or more applications linked to Application Programming Interfaces (APIs) to access and execute stored program/application code (e.g., smart contract executable code, smart contracts, etc.), which may be created according to custom configurations sought by participants, may maintain their own state, control their own assets, and receive external information. This may be deployed as an entry and installed on all blockchain nodes by attaching to the distributed ledger.

The 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. The smart contracts 630, when executed, cause certain audited passed transactions 626 to be generated and then forwarded to the blockchain platform 652. The platform includes security/authorization 658, a computing device 656 that performs transaction management, and a storage portion 654 that is memory that stores transactions and intelligent contracts in a blockchain.

The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure that may be used to receive and store new entries and for access by auditors seeking access to the data entries. The blockchain may expose interfaces that provide access to the handler code and virtual execution environment necessary to use the physical infrastructure. Cryptographic trust services may be used to verify entries (e.g., asset exchange entries) and keep information private.

The blockchain architecture configuration of fig. 6A and 6B can process and execute program/application code through one or more interfaces exposed by the blockchain platform and the services it provides. By way of non-limiting example, intelligent contracts may be created to perform reminders, updates, and/or other notifications subject to modification or update, and the like. The smart contracts themselves may be used to identify rules associated with authorization and access requirements and accounting usage. For example, the information may include a new entry that may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The result may include a decision to reject or approve the new entry based on criteria defined in the smart contract and/or consensus of the peers. The physical infrastructure may be used to retrieve any of the data or information described herein.

In the intelligent contract executable code, an intelligent contract may be created by a high-level application and programming language and then written to a block in a block chain. The smart contract may include executable code that is registered, stored, and/or replicated with a blockchain (e.g., a distributed network of blockchain peers). An entry is an execution of intelligent contract code that may be executed in response to a condition associated with an intelligent contract being satisfied. Execution of the intelligent contract may trigger a trusted modification of the digital blockchain ledger state. Modifications to the blockchain ledger resulting from execution of the smart contract may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

The intelligent contract may write data to the blockchain in a key-value pair format. In addition, the intelligent contract code may read values stored in the blockchain and used in application operations. The intelligent contract code may write the output of various logical operations to the block chain. The code may be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain may be public and/or may be encrypted and maintained as private information. Temporary data used/generated by the smart contracts is saved in memory by the provided execution environment and is deleted once the data needed by the blockchain is identified.

The intelligent contract executable code may include a code interpretation of an intelligent contract having additional features. As described herein, smart contract executable code may be program code deployed on a computing network that is executed and validated together by a chain validator during a consensus process. The smart contract executable code receives the hash and retrieves hash values associated with data templates created using previously stored feature extractors from the blockchain. The smart contract executable code sends an authorization key to the requested service if the hash value of the hash identifier matches a hash value created from the stored identifier template data. The smart contract executable code may write data associated with the encryption details into the blockchain.

Fig. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. Referring to fig. 6C, an example configuration 660 provides for a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., a blockchain) 668. The server may query the vehicle service provider on behalf of the service provider entity to share user profile rating information in the event that an established known user profile attempts to lease a vehicle with an existing rating profile. The server 666 may be receiving and processing data related to the service requirements of the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for refueling/charging, maintenance services, etc., intelligent contracts may be used to invoke rules, thresholds, sensor information collection, etc., which may be used to invoke the vehicle service event. Blockchain transaction data 670 is maintained for each transaction, such as access events, subsequent updates to vehicle service status, event updates, and the like. The transaction may include various parties, requirements (e.g., age 18, service qualified candidates, valid driver's license, etc.), compensation levels, distances traveled during the event, registered recipients who are allowed to access the event and host vehicle services, rights/permissions, sensor data retrieved during vehicle event operations to record detailed information for the next service event and identify vehicle status, and thresholds for determining whether the service event is complete and whether the vehicle status has changed.

Fig. 6D shows a blockchain block 680 that may be added to a distributed ledger, and the contents of the blockchain structures 682A through 682n, according to an example embodiment. Referring to fig. 6D, a client (not shown) may submit an entry to a block link point to perform an activity on the block chain. For example, the client may be an application that proposes an entry for the blockchain on behalf of a requestor (e.g., a device, person, or entity). Multiple blockchain peers (e.g., blockchain nodes) may maintain a copy of the distributed ledger and the state of the blockchain network. There may be different types of blockchain nodes/peers in a blockchain network, including endorsement peers that simulate and endorse entries made by clients, and submission peers that validate endorsements, validate entries, and submit entries to a distributed ledger. In this example, the block link points may serve the roles of an endorsement node, a commit node, or both.

The instant 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. There may be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel to which it belongs. I.e., time zone blockchains are a log of entries structured as hash-linked chunks, each chunk containing a sequence of N entries. A block may include various components, such as those shown in fig. 6D. The linking of the blocks may be generated by adding a hash of a previous block header in the block header of the current block. In this way, all entries on the blockchain can be ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Furthermore, due to the linked structure, the newest block in the block chain represents each entry that appears before it. I.e., the time zone blockchain may be stored on a peer-to-peer file system (local or attached storage), which supports only additional blockchain workloads.

The current state of the blockchain and the distributed ledger may be stored in a state database. Here, the current state data represents the latest values of all keys contained in the chain entry log of the block chain. The smart contract executable code calls an execution entry for the current state in the state database. To make these intelligent 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 in the log of entries for the blockchain so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated when needed) at peer start-up before accepting the entry.

The endorsement node receives an entry from the client and endorses the entry based on the simulation results. The endorsement node holds an intelligent contract that simulates an item proposal. When an endorsement node endorses an entry, the endorsement node creates an entry endorsement, which is a signed response of the endorsement node to the client application indicating an endorsement for the simulated entry. The method of endorsement entry depends on the endorsement policy specified in the intelligent contract executable code. An example of an endorsement policy is "most endorsement nodes must endorse entries". Different channels may have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

The sorting service accepts the endorsed entries, sorts them into blocks, and transfers the blocks to the submitting peer. For example, the ordering service may initiate a new tile when an entry threshold is reached, a timer times out, or other condition. In this example, a chunk chain link point is a commit peer that has received a data chunk 682A to be stored on the chunk chain. The ranking service may consist of a cluster of ranking nodes. The ranking service does not process items, smart contracts, or maintain shared accounts. Instead, the ranking service may accept the entries after endorsement and specify the order in which the entries are submitted to the distributed ledger. The architecture of the blockchain network may be designed to "order" (e.g., Solo, Kafka, BFT, etc.) to be implemented as pluggable components.

Entries are written to the distributed ledger in a consistent order. The order in which the entries are made is to ensure that updates to the state database are valid at the time of submission to the network. Rather than ordering by solving cryptographic puzzles or mining encrypted currency blockchain systems (e.g., bitcoins, etc.), in this example, each participant of the distributed ledger may select the ordering mechanism that best fits the network.

Referring to fig. 6D, a tile 682A (also referred to as a data block) stored on a blockchain and/or distributed ledger may include multiple data segments, such as tile headers 684A through 684n, transaction-specific data 686A through 686n, and tile metadata 688A through 688 n. It should be understood that the various blocks and their contents, e.g., block 682A and its contents, are depicted for exemplary purposes only and are not meant to limit the scope of the exemplary embodiments. In some cases, both chunk header 684A and chunk metadata 688A may be smaller than transaction-specific data 686A that stores the entry data; however, this is not essential. 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 chain of blocks) within block header 684A. In particular, chunk header 684A may include a hash value of a previous chunk header. The chunk header 684A may also include a unique chunk number, a hash value of the chunk data 690A of the current chunk 682A, and the like. The tile number for tile 682A may be unique and assigned in ascending/sequential order starting from zero. The first chunk in the blockchain may be referred to as a starting chunk, including information related to the blockchain, blockchain members, data stored therein, and the like.

The tile data 690A may store entry information of each entry recorded within a tile. For example, the entry data may include one or more of: entry type, version, timestamp, channel ID of distributed ledger, entry ID, epoch, payload visibility, smart contract executable code path (deployment transaction tx), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functions), client (creator) identity such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (key and version list of entry reads, etc.), write set (key and value list, etc.), start key, end key, key list, mercker tree query digest, etc. Entry data may be stored for each of the N entries.

In some embodiments, the chunk data 690A may also store transaction-specific data 686A, which adds additional information to the hash-linked chain of chunks in the blockchain. Thus, data 686A may be stored in an immutable log of the tile on the distributed ledger. Some of the benefits of storing such data 686A are manifested in the various embodiments disclosed and described herein. Chunk metadata 688A may store a plurality of fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of tile creation, a reference to the last configured tile, an entry filter that identifies valid and invalid entries within the tile, a last offset of the ordering service that orders the tiles, and the like. Signatures, last configuration chunk, and sort node metadata may be added by the sort service. At the same time, the submitter of the block (e.g., a blockchain node) may add validity/invalidity information based on endorsement policies, validation of read/write sets, and the like. The entry filter may include an array of bytes equal in size to the number of entries in block data 610A and a validation code that identifies whether the entry is valid/invalid.

The other blocks 682B through 682n in the block chain also have headers, files, and values. However, unlike the first chunk 682A, each of the chunk headers 684A-684 n in other chunks includes the hash value of the immediately preceding chunk. The hash value of the immediately preceding block may be the hash of the previous block header only, or may be the hash value of the entire previous block. By including the hash value of the previous block in each remaining block, the starting block (and associated original file) can be traced back from the nth block, block by block, as indicated by arrow 692, to establish an auditable and immutable chain of custody.

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

An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components. For example, fig. 7 illustrates an example computer system architecture 700 that may represent or be integrated within any of the above-described components and/or the like.

FIG. 7 is not intended to suggest any limitation as to the scope of use or functionality of the described embodiments of the application. In any event, computing node 700 is capable of implementing and/or performing any of the functions set forth above.

There is a computer system/server 702 in the computing node 700 that is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or notebook devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the above systems or devices, and the like.

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

As shown in fig. 7, computer system/server 702 in cloud computing node 700 is shown in the form of a general purpose computing device. Components of 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 processors 704.

The bus represents 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.

Computer system/server 702 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system/server 702 and includes both volatile and nonvolatile media, removable and non-removable media. In an embodiment, the system memory 706 implements the flow diagrams of the other figures. The system memory 706 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)708 and/or cache memory 710. Computer system/server 702 may also include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, the memory 706 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown, and commonly referred to as a "hard disk drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In which case each may be connected to the bus by one or more data media interfaces. As further depicted and described below, memory 706 can include at least one program product having a set (e.g., at least one) of program modules for performing the functions of embodiments of the present application.

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

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

Computer system/server 702 may also communicate with one or more external devices via I/O devices 712 (e.g., I/O adapters), which may include a keyboard, a pointing device, a display, a voice recognition module, etc., one or more devices that enable a user to interact with computer system/server 702, and/or any device (e.g., a network card, a modem, etc.) that enables computer system/server 702 to communicate with one or more other computing devices. Communication may be effected through an I/O interface of device 712. Moreover, computer system/server 702 may communicate with one or more networks, such as a Local Area Network (LAN), a general Wide Area Network (WAN), and/or a public network (e.g., the internet) through network adapters. As shown, device 712 communicates with the other components of computer system/server 702 over a bus. It should be appreciated that although not shown, other hardware and/or software components may be used with 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, data archival storage systems, and the like.

Although example embodiments of at least one of the systems, methods and non-transitory computer readable media have been illustrated in the accompanying drawings and described in the foregoing detailed description, it should be understood that the application is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions as set forth and defined by the following claims. For example, the functions of the systems of the various figures may be performed by one or more modules or components described herein, or may be performed in a distributed architecture, and may include transmitters, receivers, or both paired. For example, all or part of the functionality performed by a single module may be performed by one or more of those modules. Further, the functions described herein may be performed at different times and in relation to various events internal or external to the module or component. Further, information sent between modules may be transmitted between modules through at least one of: data networks, the internet, voice networks, internet protocol networks, wireless devices, wired devices, and/or via multiple protocols. Further, messages sent or received by any module may be sent or received directly and/or through one or more other modules.

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 cell phone, a tablet computing device, a smart phone, or any other suitable computing device or combination of devices. The presentation of the above-described 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 one example of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in a localized and distributed form consistent with computing technology.

It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly highlight their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

Modules may also be implemented, at least in part, in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be assembled into an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations; when logically connected together, these instructions comprise a module and achieve the stated purpose for the module. Further, the modules may be stored on a computer readable medium, which may be, for example, a hard disk drive, a flash memory device, a Random Access Memory (RAM), a magnetic tape, or any other such medium for storing data.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

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

Those of ordinary skill in the art will readily appreciate that the above may be practiced with steps in a different order and/or with hardware elements in configurations other than those disclosed. Thus, while the present application has been described based upon these preferred embodiments, certain modifications, variations and alternative constructions will be apparent to those skilled in the art.

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

Claims

1. A method, comprising:

determining, by the vehicle, that the characteristic associated with the passenger is at a level below a threshold;

performing, by the vehicle, an energy saving action to reduce the characteristic level; and

in response to the characteristic level rising above the level but below the threshold, performing, by the vehicle, an energy usage action to decrease the characteristic level;

wherein the energy saving action is performed while the energy usage action is performed.

2. The method of claim 1, comprising:

determining a number of passengers within the vehicle; and

selecting one or more vehicle operations to perform in response to one or more of the energy saving action and the energy usage action based on the number of passengers.

3. The method of claim 1, comprising:

determining one or more locations of one or more passengers within the vehicle;

determining which available vehicle operations are at the one or more locations; and

selecting one or more vehicle operations available at the one or more locations to perform in response to one or more of the energy saving actions and the energy usage actions.

4. The method of claim 1, comprising:

in response to the energy-saving action, reducing an initial energy usage level of the vehicle; and

in response to the energy usage action, increasing the reduced energy usage level of the vehicle to create a modified energy usage level of the vehicle.

5. The method of claim 1, comprising:

identifying an initial energy usage level of the vehicle prior to performing the energy saving action and the energy usage action; and

modifying the initial energy usage level of the vehicle to be less than the initial energy usage level of the vehicle during performance of the energy saving action and the energy usage action.

6. The method of claim 1, comprising: receiving, by the vehicle, a verification of the energy saving action from at least one component, wherein the verification comprises blockchain consensus between peer groups consisting of the vehicle and the at least one component.

7. The method of claim 6, comprising: executing, by the vehicle, an intelligent contract to record the verification and the at least one component on a blockchain based on the blockchain consensus.

8. A vehicle, comprising:

a processor configured to:

determining that a characteristic associated with the passenger is at a level below a threshold;

performing an energy saving action to reduce the characteristic level; and

in response to the characteristic level rising above the level but below the threshold, performing an energy usage action to decrease the characteristic level;

9. The vehicle of claim 8, wherein the processor is further configured to:

determining a number of passengers within the vehicle; and

10. The vehicle of claim 8, wherein the processor is further configured to:

determining one or more locations of one or more passengers within the vehicle;

11. The vehicle of claim 8, wherein the processor is further configured to:

12. The vehicle of claim 8, wherein the processor is further configured to:

13. The vehicle of claim 8, wherein the processor is further configured to receive a verification of the energy saving action from at least one component, wherein the verification comprises a blockchain consensus between peer groups consisting of the vehicle and the at least one component.

14. The vehicle of claim 13, wherein the processor is further configured to execute an intelligent contract to record the validation and the at least one component on a blockchain based on the blockchain consensus.

15. A non-transitory computer-readable storage medium configured to store instructions that, when executed, cause a processor to perform operations of the method of any of claims 1-7.