Situation-specific vehicle energy allocation

Abstract

The present disclosure relates to situation-specific vehicle energy allocation. Example operations include one or more of: detecting an environment by a vehicle using a first sensor; determining by the vehicle that an event related to the environment is about to occur; providing power by the vehicle to a second sensor associated with the upcoming event; and detecting, by the vehicle using the second sensor, the event while the event is occurring.

Description

Background Art

[0001] Vehicles or conveyances (e.g., cars, motorcycles, trucks, airplanes, trains, etc.) typically provide transportation needs for passengers and / or cargo in various ways. Functions associated with the conveyances can be recognized and accessed through various computing devices (e.g., smartphones or computers on and / or off the conveyance). Summary of the Invention

[0002] An example embodiment provides a method comprising one or more of the following operations: detecting an environment by a vehicle via a first sensor; determining by the vehicle that an event related to the environment is about to occur; providing energy by the vehicle to a second sensor associated with the upcoming event; and detecting the event by the vehicle via the second sensor while the event is occurring.

[0003] Another example embodiment provides a vehicle comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of the following operations: detecting an environment via a first sensor; determining that an event related to the environment is about to occur; providing energy to a second sensor associated with the impending event; and detecting the event via the second sensor when the event occurs.

[0004] 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 operations: detecting an environment by a vehicle via a first sensor; determining by the vehicle that an event related to the environment is about to occur; providing energy by the vehicle to a second sensor associated with the upcoming event; and detecting, by the vehicle via the second sensor, the event while the event is occurring. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1A An example system diagram of vehicle operation according to an example embodiment is shown.

[0006] Figure 1B An example of a vehicle operating sensor according to an example embodiment is shown.

[0007] Figure 1C Yet another example of a vehicle operation sensor according to an example embodiment is shown.

[0008] Figure 2A Another vehicle network diagram of vehicle operating sensors is shown according to an example embodiment.

[0009] Figure 2BAnother vehicle network diagram is shown according to an example embodiment.

[0010] Figure 2C Yet another vehicle network diagram is shown according to an example embodiment.

[0011] Figure 2D Yet another vehicle network diagram is shown according to an example embodiment.

[0012] Figure 2E Yet another vehicle network diagram is shown in accordance with an example embodiment.

[0013] Figure 2F A diagram depicting electrification of one or more components is shown according to an example embodiment.

[0014] Figure 2G A diagram depicting the interconnection between different elements is shown according to an example embodiment.

[0015] Figure 2H Still another diagram depicting the interconnection between different elements is shown according to an example embodiment.

[0016] Figure 2I Still another diagram is shown depicting the interconnection between different elements according to an example embodiment.

[0017] Figure 3A A flow chart according to an example embodiment is shown.

[0018] Figure 3B Another flow chart according to an example embodiment is shown.

[0019] Figure 3C Yet another flow chart according to an example embodiment is shown.

[0020] Figure 4 A machine learning vehicle network diagram is shown according to an example embodiment.

[0021] Figure 5A An example vehicle configuration for managing database transactions associated with a vehicle is shown according to an example embodiment.

[0022] Figure 5B Another example vehicle configuration for managing database transactions between various vehicles is shown according to an example embodiment.

[0023] Figure 6A A blockchain architecture configuration according to an example embodiment is shown.

[0024] Figure 6B Another blockchain configuration according to an example embodiment is shown.

[0025] Figure 6CA blockchain configuration for storing blockchain transaction data according to an example embodiment is shown.

[0026] Figure 6D An example data block is shown according to an example embodiment.

[0027] Figure 7 An example system is shown that supports one or more example embodiments. DETAILED DESCRIPTION

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

[0029] Communications between a vehicle and certain entities (e.g., remote servers and local computing devices (e.g., smartphones, personal computers, computers embedded in the vehicle, etc.)) can be received and processed by one or more "components," which can be hardware, firmware, software, or a combination thereof. A component can be part of any of these entities or computing devices, or other computing devices. In one example, consensus decisions related to blockchain transactions can be performed by computing devices or components associated with the vehicle and one or more components located externally or remotely from the vehicle. Consensus decisions or agreements are the process by which one or more nodes or peers in a network reach agreement on a value, state, outcome, input, output, condition, etc.

[0030] The features, structures, or characteristics 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 an embodiment may be included in at least one embodiment. Thus, the phrases "example embodiment," "in some embodiments," "in other embodiments," or other similar expressions that appear throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, and characteristics may be combined in any suitable manner in one or more embodiments. Any connection between elements in the figures may be unidirectional and / or bidirectional communication, even if the connection shown in the figure is a unidirectional or bidirectional arrow. In the current solution, a vehicle may include one or more of a car, a truck, a pedestrian electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that can be used to transport people and / or goods from one location to another.

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

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

[0033] Within a communications infrastructure, a decentralized database is a distributed storage system comprised of multiple nodes communicating with each other. A blockchain is an example of a decentralized database, comprising an append-only, immutable data structure (i.e., a distributed ledger) that can maintain records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peers. Each peer maintains a copy of the database records, and no single peer can modify them without consensus among the distributed peers. For example, peers can execute a consensus protocol to validate blockchain entries, group them into blocks, and construct a hash chain from the blocks. This process achieves consensus by sorting the entries as needed to form a ledger. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols, such as proof-of-work (PoW). In contrast, a permissioned blockchain database can secure transactions between a group of entities that do not trust each other or cannot fully trust each other but share a common purpose, such as exchanging funds, goods, or information. This scheme can be used in permissioned and / or permissionless blockchain settings.

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

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

[0036] The ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions may be generated by smart contract executable code invocations (i.e., entries) submitted by participating parties (e.g., client nodes, ordering nodes, endorsing nodes, peer nodes, etc.). Entries can result in a set of asset key-value pairs being submitted to the ledger as one or more operations (e.g., create, update, delete, etc.). The ledger consists of a blockchain (also called a chain), which stores immutable, ordered records in blocks. The ledger also includes a state database, which maintains the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for each channel of which it is a member.

[0037] A chain is a log of entries structured as hash-linked blocks, with each block containing a sequence of N entries, where N is equal to or greater than 1. A block header consists of the hash of the block's entries and the hash of the previous block's header. In this way, all entries in the ledger are sequentially arranged and cryptographically linked together. Therefore, tampering with the ledger data is impossible without breaking the hash links. The hash of the most recently added blockchain block represents every entry that came before it in the chain, ensuring a consistent and trusted state across all peers. The chain can be stored on the peer node file system (i.e., locally, on attached storage, in the cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0038] The current state of the immutable ledger represents the latest values ​​for all keys included in the chain's entry log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes referred to as the world state. Smart contract executable code calls execute entries against the current state of the ledger. To make these smart contract executable code interactions efficient, the latest values ​​for keys can be stored in a state database. The state database can simply be an indexed view of the chain's entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) upon peer node startup and before entries are accepted.

[0039] Blockchain differs from traditional databases in that it is decentralized, immutable, and secure storage, rather than a central repository, where nodes must share any changes to the stored records. Intrinsic blockchain properties that contribute to their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsements, and accessibility.

[0040] Example embodiments provide services tailored to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the vehicle owner or the operator of a vehicle owned by another party. Vehicles may require service at regular intervals, and authorization of service requests may be required before receiving service. Furthermore, a service center can provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requests (e.g., immediate, severe, moderate, minor, etc.). Vehicle needs may be monitored by one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer located within and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located in one or more of the following: the interior of the vehicle, the exterior of the vehicle, a fixed object remote from the vehicle, or another vehicle near the vehicle. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service needs, vehicle gear shifting, vehicle steering, and the like. As described herein, sensors may also be devices, such as wireless devices located within and / or near the vehicle. Additionally, sensor information can be used to identify whether the vehicle is operating safely and whether passengers are in any unexpected vehicle states, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger determined by a permissioned consortium and therefore in a "decentralized" manner, such as by a blockchain member group.

[0041] Each stakeholder (i.e., owner, user, company, institution, etc.) may wish to limit the exposure of private information, so blockchain and its immutable nature can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify crash and / or degradation events, identify safety incidents, identify the parties involved in the event, and provide distribution to registered entities requesting access to such vehicle event data. Furthermore, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on a consensus method associated with the blockchain. This approach is not feasible with traditional centralized databases.

[0042] Various driving systems of this solution can utilize software, sensor arrays, and machine learning capabilities, Light Detection and Ranging (LIDAR) projectors, radar, ultrasonic sensors, and more to create terrain and road maps for vehicles to use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, and more can also be used in place of LIDAR in autonomous vehicles.

[0043] In certain embodiments, the present solution includes authorizing a vehicle for service through an automated and rapid authentication scheme. For example, driving to a charging station or gas pump can be performed by the vehicle operator or an autonomous vehicle, and upon receipt of authorization by the service station and / or charging station, authorization to receive electricity or gas can be performed without delay. The vehicle can provide a communication signal with a vehicle identifier having a current activity profile linked to an account authorized to receive service, which can subsequently be corrected through compensation. Additional measures can be used to achieve further authentication, such as wirelessly transmitting another identifier from the user's device to the service center, thereby replacing or supplementing the initial authorization effort between the vehicle and the service center with an additional authorization effort.

[0044] Shared and received data can be stored in a database, which stores data in a single database (e.g., a database server) and is typically located in a single, specific location. This location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a central database can typically be accessed from multiple different locations. Centralized databases are easy to manage, maintain, and control, and their single location is particularly beneficial for data security. Data redundancy is minimized in a centralized database, as a single storage location for all data means there is only one master record for a given data set. Blockchain can be used to store vehicle-related data and transactions.

[0045] Figure 1A An example system diagram 100 of vehicle operation according to an example embodiment is shown. Figure 1A, the vehicle 120 may receive data from its own receiving capabilities or through a separate entity 110, which may be a server or other vehicle, or alternatively may be a subcomponent of the vehicle, such as a mobile computing device or vehicle computing system operated by a vehicle passenger. In addition, data may be shared with another entity 130, which may be a server or other vehicle, or alternatively may be a subcomponent of the vehicle, such as a vehicle computing system or a mobile computing device operated by a vehicle passenger. In this example, the vehicle 120 receives sensor data (112) through a first sensor and uses this data to detect the environment through sensor feedback. The sensor may be any type of sensor, processor, device including memory, etc. The environment may be a road driving environment with other vehicles and objects that can be easily detected by one or more sensors disposed on or in communication with the vehicle 120. Assuming that another vehicle is approaching vehicle 120, and sensor data identifies the approaching vehicle as an object that is identified as a vehicle at a particular distance D1 at a particular time T1, vehicle 120 may determine that an "event" related to the environment is about to occur (114), such as a potential collision due to the distance, speed, and / or angle of the approaching vehicle relative to vehicle 120. A collision may be designated as an imminent event when the vehicle is identified at a first distance at a first time and at a second distance at a second time, and these distances and times exceed safety threshold levels (e.g., thresholds for position change over time) that must be observed by other vehicles on the road. Thus, when these thresholds are exceeded, an imminent event may be designated, and the vehicle may take necessary precautions to prepare for the impending event.

[0046] In this event scenario, vehicle 120 can determine the amount of time before an approaching vehicle can affect it based on sensor data received from one or more first sensors. Furthermore, the identified location information can provide vehicle 120 with information about which sensors to activate and begin capturing information about the environment, such as the location on the vehicle where the event may occur. For example, if a vehicle is equipped with multiple sensors on its bumper and / or other locations, a first sensor can identify an impending event and enable one or more other sensors to participate in a monitoring and detection cycle, as well as initiate a detection cycle. This can include capturing data at fixed time intervals T1, T2, T3, ..., Tn, without maintaining a constant sensor usage scenario, as the total amount of energy available to power each sensor may be limited. In one example, to conserve energy, most sensors can be paused, while sensors near the location of the vehicle that may be affected by the impending event can participate and initiate a detection cycle in response to a processor command from the vehicle, mobile device, or other control device. By limiting monitoring to sensors located where they can detect information relevant to the event, other sensors can be paused, eliminating the need for additional energy from the vehicle's battery or other energy source. In this example, a location on the vehicle where an event may occur is determined (116), and energy is supplied to the sensors for a required time period to detect the event (118). The time period is derived from sensor data that provides estimates of the location and distance between the vehicle 120 and approaching vehicles and / or other objects.

[0047] The provision of energy to the sensors can be controlled by a processing entity associated with the vehicle, such as an onboard computing device, a passenger's mobile device that controls certain vehicle functions, a remote server in mobile communication with the vehicle, or the like. Once the location and time of an impending event are determined, energy can be provided to secondary sensors associated with the impending event, and other actions can be performed to prepare for the event. For example, upon determining the location of the vehicle where an impending event is expected to occur, energy can be provided to one or more additional sensors located at the location of the vehicle where the event is expected to occur for a predefined period of time (e.g., "X" seconds), until the event is expected to occur and / or a specified period of time after the event occurs, regardless of whether the event occurs in a manner consistent with the expected occurrence (e.g., a collision, exceeding a threshold distance between vehicles, etc.). In another example, the location of the vehicle where the impending event is expected to occur (e.g., the front, side, rear, front side, rear side, top, bottom, etc.) can be determined based on initial sensor data and initial sensor positions, and a majority or all sensors associated with the identified location of the vehicle can participate in monitoring for a first period of time, while secondary sensors can participate in monitoring for a second period of time that is longer than the first period. All sensor actions can be performed by a processor associated with the vehicle. In this example, the processing entity may request sensor data from all sensors to capture information from the exterior surroundings of the vehicle, and once the data is captured, it may only need to continue capturing data for an additional time period (e.g., a second time period compared to the first time period) and from only certain sensors rather than all sensors. The determination of which sensors to provide energy to may be based on location information, distance information, driver and / or passenger information, weather information, road information, vehicle information, impact information, and / or motion, light, sound, or other sensor-detected events.

[0048] Other operations may include: determining, by the processor, that the front of the vehicle is the location of the vehicle where an imminent event is expected to occur, such as another vehicle approaching the front end of the vehicle. In this case, the processor may provide energy to the vehicle to change operation (122), such as reducing the vehicle's speed for a predefined time period to reduce the severity of the imminent collision or avoid contact with other objects / vehicles. Alternatively, the processor may include: determining that the rear of the vehicle is the location of the vehicle where an imminent event is expected to occur; in this case, the processor may provide energy to the vehicle to increase the vehicle's speed for a predefined time period to mitigate the impact of the expected collision. Other optional operations may include steering the vehicle in a specific direction, deploying airbags, activating seatbelt functions, changing wheel angles to mitigate impact, etc. Once the event is over, specific notification information may be created and shared with relevant third-party entities (124).

[0049] The processor may also include: verification of an event received by the vehicle from at least one component, wherein the verification includes blockchain consensus among a peer group consisting of the vehicle and the at least one component, and execution of a smart contract by the vehicle to record the impending event and the at least one component on the blockchain based on the blockchain consensus. Blockchain transactions can be executed during any event detection cycle or through certain sensor data detection procedures. In one example, when a relevant event is about to occur, the component or sensor will record external and internal audio. For example, if a 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 related to the anticipated event. In addition, the audio components / sensors will remain off until the processor senses the impending event to save energy by not operating features deemed unnecessary at a given time.

[0050] To further conserve energy, if applicable, components / sensors associated with the vehicle will be turned off when auxiliary components / sensors are turned on. In the event of a rear-end collision, front-end components / sensors will be turned off while rear-end components / sensors will be turned on, making the vehicle energy neutral. A component in this example can be any sensor or powered feature of the vehicle. If the primary battery source is low and / or unable to power a component / sensor, a secondary power source (e.g., portable charger, solar power, phone battery, etc.) can be used for the vehicle. When needed, the source wirelessly connects to the secondary component and provides power to it. Not powering certain components on the vehicle can help conserve energy. However, in certain situations (e.g., emergency situations, accident avoidance, etc.), it may be necessary to power such components. In such scenarios, power is provided to the component in advance (i.e., milliseconds, microseconds, nanoseconds, etc.) of the emergency, accident, near-accident, etc. The associated processor and / or sensors on the vehicle will indicate when such an impending event has occurred (or has passed) and provide power to such components that can provide additional data related to the situation (e.g., to a server, another vehicle, etc.). After providing the additional data, the processor and / or sensors are turned off until they are likely needed again. For example, when a vehicle is about to crash, the zoom and / or pan features of cameras and / or other cameras located on and / or outside the vehicle can be enabled. Before, during, and / or after such a crash, the additional data from the enabled cameras (and / or any other components) is collected, stored, analyzed, and / or processed to produce a specific result.

[0051] In some embodiments, components / sensors can be powered based on factors other than event types such as emergencies, accidents, and near-accidents. These factors may include weather, road conditions, driver status, traffic conditions, and so on. For example, during adverse weather conditions, components / sensors may be powered to provide data including video, images, audio, and so on until weather conditions improve. This additional data is received from a server, another vehicle, or the like and correlated with other data normally received and / or generated by the vehicle. This "combined" data provides a detailed summary of any situation and ensures that this combined data is provided with minimal energy usage. In one embodiment, a small amount of energy (e.g., energy generated by the vehicle) is transmitted (via the vehicle, a charging station, the road, etc.) to power specific vehicle sensors / devices. In one example, an object approaches the vehicle from behind. Sensors (e.g., rear-view cameras) are enabled and powered by one or more onboard processors, and specific sensor functions are activated to provide additional capabilities. For example, these capabilities may include zoom features provided by the sensors / cameras, or other similar functions that may be used / needed in specific situations (e.g., safety or emergency situations). In the current embodiment, the sensor / camera lens is pre-programmed for zoom operation. This functionality is enabled only when an object (e.g., another vehicle) approaches from behind and reaches a certain threshold distance (and / or speed) from the vehicle in front. The speed and / or distance of the approaching event are determined by one or more sensors on the vehicle. When the speed / distance of the object exceeds one or more thresholds, the zoom functionality is enabled. The zoom functionality allows for the recording of additional data (e.g., a zoomed image / video). In one embodiment, the same camera is used to initiate the recording. In an alternative embodiment, a separate camera is used to perform the data capture. A camera may only require a few seconds of energy, or a fraction of a second, to capture the relevant image / video, so this functionality requires minimal energy in this case. Therefore, the total energy usage of the vehicle can be determined on a component / sensor basis based on the probability of each component being used, the number of times each component is used, and the duration of each component's use.

[0052] In another embodiment, there are components / sensors on a vehicle that are typically not used except under specific circumstances. These components / sensors use minimal energy, and if energy is provided to them, the drivable distance during the journey will be reduced due to energy loss. For example, the zoom function on the backup camera or the windshield wipers on the headlights may not be considered in determining the vehicle's total energy usage on a component / sensor basis. However, in certain situations, such features are more likely to occur. For example, in stop-and-go traffic, the vehicle may accelerate and decelerate rapidly, necessitating the use of the rear and / or front cameras. In a further example, the vehicle may be traveling on a road with impending rain, poor visibility, and / or fading sunlight, necessitating the use of the windshield wipers on the headlights. In such cases, additional energy, not initially accounted for, may be required and obtained from various sources (e.g., rolling charging networks, vehicle-to-vehicle (V2V) wireless power transfer, etc.). This allows for faster and safer arrival at the destination, and allows for accurate and updated pre-trip energy usage estimates for each component / sensor based on current / future driving conditions.

[0053] In one embodiment, additional functionality of vehicle components / sensors is enabled in specific scenarios. For example, the zoom function of a vehicle camera is enabled when an impending collision is determined, and the headlight wipers are only used when needed, such as when an obstruction is visible in the headlight lens. Energy conservation can also be achieved through operational changes, regenerative braking, economical operating modes, driving during times of low energy consumption, speed limits, and energy conservation or generation through the execution of certain functions (e.g., turning sensors on and off)—particularly acceleration and deceleration operations.

[0054] Figure 1B An example of a vehicle operating sensor according to an example embodiment is shown. Figure 1B , example 150 includes a vehicle 120 that actively monitors its environment. In this example, various sensors and data capture components can be arranged throughout the interior and exterior of the vehicle. The example shows sensors 152-166 around the vehicle. The first sensor 152 can be enabled at a first time T1 due to motion detection or other triggering event that causes the sensor 152 to be enabled. The field of view 160 is a defined area in which a particular sensor (e.g., sensor 152) can capture information (e.g., video, images, audio, etc.) at a particular time. At the current time T1, the approaching vehicle 140 may be a particular distance D1 from the vehicle 120. The other sensors 154-166 may not be enabled, may also be enabled, or may be enabled for a short time before or after time T1.

[0055] Figure 1CAnother example of a vehicle operation sensor according to an example embodiment is shown. Figure 1C Example 170 illustrates a later time, T2, where approaching vehicle 140 is moving at a different angle relative to vehicle 120. In this example, distance D2 at time T2 is less than distance D1. The new distance measurement, detected by sensor 152 or other sensors, can trigger other sensors to activate and / or deactivate. For example, because approaching vehicle 140 is approaching the side of vehicle 120, side sensors 152, 154, 156, and so on, may be activated for a period of time. In this example, sensors 152 and 154 are both activated at time T2. However, any combination of sensors on that side of vehicle 120 can be activated at specific times or sequentially, such as enabling sensors one after another if an approaching vehicle is detected moving toward different sensors at different times. The processor can use an operating program to activate two sensors at a time for redundancy, but deactivate the last sensor each time a new sensor is activated. Alternatively, an activated sensor can trigger all sensors to activate and capture data for a period of time, then limit the number of sensors activated for a longer period to one or two.

[0056] In one example, a sensor on a first side of a vehicle can trigger the activation of sensors on that side and other sensors within the area of ​​the vehicle. In response to a detected impending event, all sensors can be activated for a short period before and after the expected event time. In another example, a first sensor can trigger a second sensor to capture image data at a rear-facing camera sensor, which then signals the activation of corner camera sensors near the corners of the vehicle in anticipation of an approaching vehicle approaching at an angle. Furthermore, when a sensor does not provide a specific type of feedback, another sensor can be activated, and the previous sensor can be disabled until the next time. Certain sensors may remain activated for a second threshold period on the side of the vehicle where an event is expected, but not on the other side of the vehicle where the event is not expected. However, it may be prudent to maintain at least one sensor on the other side of the vehicle not affected by the event to capture data if a collision occurs on the other side of the vehicle involving another vehicle.

[0057] In another example, a vehicle can determine the amount of energy required to power a second sensor on the vehicle based on an upcoming event / specific situation and by integrating the recorded event into the recorded environment (since the environment can be continuously recorded before, during, and after the event), and then turning off the second sensor after the event. Furthermore, the first and second sensors can be related (e.g., the first sensor can be a front-facing camera and the second sensor can be a rear-facing camera). When the upcoming event is expected to occur at a location different from the location recorded by the first sensor, the first sensor can be turned off while the second sensor is turned on, creating an energy-neutral scenario. For example, the first sensor (i.e., the front-facing camera) can be turned off while the second sensor (i.e., the rear-facing camera) is turned on. Furthermore, a wireless energy source independent of the vehicle can be used to power the second sensor, creating an energy-neutral scenario.

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

[0059] Figure 2BAnother vehicle network diagram 210 is shown 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′. Vehicle nodes 202 and 202′ communicate with each other via processors 204 and 204′ and other elements (not shown), including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of communication. Vehicle nodes 202 and 202′ can communicate directly with each other via private and / or public networks (not shown) or through other vehicle nodes and elements that include one or more of a processor, memory, and software. Processors 204 and 204′ can further communicate 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. Processors 204 and 204' may further be in communication with elements including one or more of a processor, memory, and software.

[0060] Although a single vehicle node, processor, and element are shown, multiple vehicle nodes, processors, and elements may be present. Information may be sent to, received from, or communicated with any of the processors 204, 204', and element 230. For example, the mobile phone 220 may provide information to the processor 204, which may activate the vehicle node 202 to take action, which may further provide the information or additional information to the processor 204', which may activate the vehicle node 202' to take action, which 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, solutions, etc. described and / or depicted herein may be used and / or provided by these elements.

[0061] Figure 2C 240 is shown in accordance with 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 elements 230 (e.g., Figure 2B ).

[0062] The processor 204 performs one or more of the following operations: detecting an environment via a first sensor (244C), determining that an event related to the environment is about to occur (246C), providing energy to a second sensor associated with the upcoming event (248C), and detecting the event via the second sensor while the event is occurring (250C).

[0063] Figure 2D 2 shows 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. The processor 204 is communicatively coupled to the computer readable medium 242D and the element 230 (e.g., Figure 2B ).

[0064] The processor 204 performs one or more of the following operations: determining a location of the vehicle where an upcoming event is expected to occur and providing energy to one or more additional sensors disposed in the location of the vehicle where the event is expected to occur (244D); determining a location of the vehicle where an upcoming event is expected to occur, providing energy to all sensors associated with the location for a first time period, and providing energy to a second sensor for a second time period that is longer than the first time period (246D); determining that a front portion of the vehicle is the location of the vehicle where an upcoming event is expected to occur, and providing energy to the vehicle to reduce the vehicle speed for a predefined time period (248D); determining that a rear portion of the vehicle is the location of the vehicle where an upcoming event is expected to occur, and providing energy to the vehicle to increase the vehicle speed for a predefined time period (250D).

[0065] Figure 2E Yet another vehicle network diagram 260 is shown according to an example embodiment. Figure 2E , the network diagram 260 includes a vehicle node 202 connected to other vehicle nodes 202' and an update server node 203 via a blockchain network 206. Vehicle nodes 202 and 202' can represent vehicles. The blockchain network 206 can have a ledger 208 for storing software update verification data and verification sources for future use (e.g., for auditing).

[0066] While this example describes only one vehicle node 202 in detail, multiple 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 this application. The vehicle node 202 may comprise a computing device or server computer, etc., and may include a processor 204, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other hardware 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 this application.

[0067] The processor 204 performs one or more of the following operations: receiving verification of an event from at least one component, the verification including blockchain consensus between a peer group consisting of a vehicle and the at least one component (244E); and executing a smart contract to record the upcoming event and the at least one component on a blockchain based on the blockchain consensus (246E).

[0068] The processor and / or computer-readable medium may be located, in whole or in part, within or outside the vehicle node. The steps or features stored in the computer-readable medium may be executed, in whole or in part, by any processor and / or element in any order. Furthermore, one or more steps or features may be added, omitted, combined, or performed at a later time.

[0069] Figure 2F A diagram 265 depicting the electrification of one or more components is shown. In one embodiment, a vehicle 266 can provide energy stored in its battery to one or more components, including other vehicles 268, charging stations 270, and a power grid 272. Power grid 272 is connected to one or more charging stations 270, which can be connected to one or more vehicles 268. This configuration allows for the distribution of power / energy received from vehicle 266. Vehicle 266 can also interact with other vehicles 268, for example, via vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. Vehicle 266 can also interact with other vehicles 268, charging stations 270, and / or power grid 272 wirelessly and / or wiredly. In one embodiment, vehicle 266 is routed (or self-routed) to power grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. In one or more embodiments employing this solution, vehicle 266 can provide energy to one or more of the components depicted herein in a variety of advantageous ways described and / or depicted herein. Further, transportation safety and efficiency may be improved, and the environment may be positively impacted as described and / or depicted herein.

[0070] 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 provided by an entity to a vehicle during charging / using 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 energy, fusion energy, and energy dynamically generated during energy sharing and / or using operations to increase or decrease one or more vehicle energy levels at a given time.

[0071] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 so that vehicle 266 retains sufficient charge to reach its destination. In one embodiment, energy transfers are wirelessly directed between vehicles 268 using a wireless connection, which may all be in operation. In one embodiment, an idle vehicle, such as vehicle 266 (which may be autonomous), is directed to charge station 270 to provide a certain amount of energy and return to a starting location (e.g., its starting location or a different destination). In one 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 to charging station 270. In one embodiment, the amount of energy that can be transferred to charging station 270 is determined by factors such as distance, time, traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), passenger vehicle usage schedules, and expected passenger waiting schedules. In one embodiment, vehicle 266 can be provided with energy by vehicles 268, charging station 270, and / or power grid 272.

[0072] In one embodiment, the solution described and depicted herein can be used to determine the 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 a module and a vehicle, allowing a processor in the device to wirelessly communicate with the vehicle regarding the amount of energy stored in the vehicle's battery. In one embodiment, the solution can also be used to provide charging from a vehicle to a location based on factors such as the temperature, energy costs, and energy levels at that location. In one embodiment, the solution can also be used to manage the amount of energy remaining in a vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, the solution can also be used to notify a vehicle to provide a certain amount of energy from the vehicle's battery, where the amount of energy to be transferred is based on the distance between the vehicle and the module receiving the energy.

[0073] In one embodiment, the solution can also be used to utilize a mobile energy storage unit that uses a determined route to travel to a vehicle with excess energy and deposit the stored energy into the power grid. In one embodiment, the solution can also be used to prioritize the energy that a vehicle needs to provide to the power grid, as well as the priority of the vehicle's current needs, such as passengers, incoming passengers, current cargo, or incoming cargo. In one embodiment, the solution can also be used to determine when a vehicle is idle and decides to travel to a location to release excess energy to the power grid before returning to its previous location. In one embodiment, the solution can also be used to determine the energy required by a vehicle based on one or more conditions (e.g., weather, traffic, road conditions, vehicle 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 instruct the vehicle to route to the other vehicle and provide the energy. In one embodiment, the solution can also be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, the solution may also be used to retrieve energy from a vehicle based on an estimate of the energy consumed by the vehicle to reach a rendezvous point with another vehicle, provide service, and return to the original location. In one embodiment, the solution may also be used to provide the remaining distance required to reach a charging station, which determines the amount of energy to be taken from the vehicle, wherein the amount of energy remaining is based on the remaining distance. In one embodiment, the solution may also be used to manage vehicles that are charging at multiple points simultaneously, such as a charging station connected by a wire and another vehicle connected by a wireless connection. In one embodiment, the solution may also be used to assign energy application priorities to vehicles, wherein priority is given to those vehicles that will provide a portion of their stored energy to another entity (e.g., a power grid, a residence, etc.). Further, with respect to Figure 2F The solutions described and depicted may be used in this and other networks and / or systems.

[0074] Figure 2GA diagram 275 illustrates the interconnections between various elements. The solution may be stored, in whole or in part, on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277' associated with various entities, all of which are communicatively coupled to and in communication with a network 286. A database 287 is communicatively coupled to the network and allows for data storage and retrieval. In one embodiment, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructure 282, one or more 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 smartphones 278, laptops 280, and / or wearable devices, may also interoperate with the solution. Smartphone 278, laptop 280, microphone 285, and other devices can connect to one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various institutions. One or more public buildings 281 may utilize computing device 281'. One or more service providers 279 may include dealerships, towing services, collision centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computing devices may be directly and / or communicatively coupled to one another, for example, via a wired network, a wireless network, a blockchain network, or the like. In one embodiment, microphone 285 may function as a virtual assistant. In one embodiment, one or more traffic infrastructure 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 infrastructure. One or more traffic infrastructure 282 may utilize computing device 282'.

[0075] In one embodiment, vehicles 277 / 276 are capable of transporting people, goods, permanent or temporary devices, and the like. In one embodiment, vehicle 277 can communicate with vehicle 276 via V2V communication via computers 276' and 277' associated with each vehicle, and may be referred to as vehicles, cars, vehicles, automobiles, and the like. Vehicles 276 / 277 may be self-propelled wheeled vehicles, such as cars, sport utility vehicles, trucks, buses, vans, or other vehicles powered by motors, batteries, or hybrid electric vehicles. For example, vehicles 276 / 277 may be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicle with a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or boats, as well as any other form of transportation capable of transportation. Vehicles 276 / 277 may be semi-autonomous or fully autonomous. For example, vehicles 276 / 277 may be able to operate and navigate autonomously without human intervention. An autonomous vehicle may have and use one or more sensors and / or navigation units to enable autonomous driving.

[0076] In one embodiment, the solution described and depicted herein can be used to determine access to a vehicle through blockchain consensus. In one embodiment, the solution can also be used to perform profile verification before allowing a passenger to use the vehicle. In one embodiment, the solution can also be used to allow the vehicle to indicate (visually, or in another embodiment, verbally, etc.) the actions required by the user (which may be pre-recorded) on or from the vehicle and verify the correctness of the actions. In one embodiment, the solution can also be used to provide the vehicle with the ability to determine how to branch data based on the risk level associated with the data and the driving environment, distributing a portion of the branched data with a lower risk level to the passenger in a safe driving environment and later distributing the remaining portion of the branched data with a higher risk level to the passenger after the passenger leaves the vehicle. In one embodiment, the solution can also be used to handle vehicle transfers across borders (such as countries / states / etc.) using blockchain and / or smart contracts, and apply the rules of the new region to the vehicle.

[0077] In one embodiment, the solution can also be used to allow a vehicle to continue traveling outside the boundary when the vehicles reach a consensus based on the characteristics of the vehicle's operation and the vehicle's passengers. In one embodiment, the solution can also be used to analyze the vehicle's available data upload / download speed, the file size, and the vehicle's travel speed / direction to determine the distance required to complete the data upload / download and assign safe zone boundaries for performing the data upload / download. In one embodiment, the solution can also be used to safely perform normally dangerous maneuvers. For example, when the system determines that an exit is approaching and the vehicle appears unprepared for exiting (e.g., in the wrong lane or traveling at a speed that does not facilitate exiting), the solution can instruct the subject vehicle and other nearby vehicles to safely exit the exit. In one embodiment, the solution can also be used to verify the judgment of another vehicle using one or more vehicles, where both the one or more vehicles and the other vehicle are in motion.

[0078] In one embodiment, the solution can also be used to detect lane usage at a certain location and time to notify vehicle passengers or direct the vehicle to recommend or not recommend a lane change. In one embodiment, the solution can also be used to eliminate the need to send information via email and the need for drivers / passengers to respond via email or in person. In one embodiment, the solution can also be used to provide services to vehicle passengers, where the services are provided on a subscription basis and permissions are obtained from other vehicles connected to the passenger's profile. In one embodiment, the solution can also be used to record changes in the status of rental objects. In one embodiment, the solution can also be used to seek blockchain consensus from other vehicles in proximity to a damaged vehicle. In one embodiment, the solution can also be used to receive media from a server, such as an insurance entity's server, or from a vehicle computer, which may be related to an accident. The server accesses one or more media files to determine the damage to the vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also be used to obtain consensus from multiple devices at different times prior to an event related to the vehicle to determine the severity of the event.

[0079] In one embodiment, this solution can also be used to address the lack of video evidence for vehicle-related accidents. The current solution details how a vehicle involved in an accident can query accident-related media from other vehicles that may have been near the accident. In one embodiment, this solution can also be used to utilize vehicles and other devices (e.g., pedestrians' mobile phones, streetlight cameras, etc.) to record specific parts of a damaged vehicle.

[0080] In one embodiment, the solution can also be used to alert passengers when a vehicle is approaching a hazardous area and / or event, allowing the vehicle to notify passengers or a central controller of potential hazardous areas on or near the current route. In one embodiment, the solution can also be used to detect when a vehicle is traveling at high speed, enabling at least one other vehicle to assist the vehicle in slowing down with minimal impact on traffic. In one embodiment, the solution can also be used to identify hazardous driving situations, where media information is captured by the vehicle involved in the hazardous driving situation. A geofence is established based on the distance from the hazardous driving situation, and additional media information is captured by at least one other vehicle within the established geofence. In one embodiment, the solution can also be used to notify one or more passengers of the vehicle that the vehicle is approaching a traffic control marking on the road, and if the vehicle crosses the marking, receive instructions for poor driving from other nearby vehicles. In one embodiment, the solution can also be used to render a portion of the vehicle inoperable by limiting speed, restricting the ability to approach another vehicle, limiting maximum speed, and (in some embodiments) setting a set number of miles allowed per time period.

[0081] In one embodiment, this solution can also be used to overcome the need to rely on software updates to correct vehicle issues when a vehicle is not operating properly. By observing other vehicles on a route, a server receives data from potentially multiple other vehicles, observing for unsafe or incorrect vehicle operation. These observations can be analyzed to generate notifications to the vehicle when the data indicates unsafe or incorrect operation. In one embodiment, this solution can also be used to provide notifications between a vehicle and potentially dangerous situations involving people outside the vehicle. In one embodiment, this solution can also be used to send data to a server via a device associated with the vehicle or an accident, or a device near an accident. Based on the severity of the accident or impending accident, the server notifies the sender of the data. In one embodiment, this solution can also be used to provide vehicle operation recommendations to the driver or passengers of the vehicle based on data analysis. In one embodiment, this solution can also be used to establish geofences associated with physical structures and determine vehicle payment responsibility. In one embodiment, this solution can also be used to coordinate the ability to drop off a vehicle at a location based on the current state of the location and the future state of a destination using other vehicles for navigation. In one embodiment, the solution may also be used to coordinate capabilities to automatically schedule vehicle returns at locations such as vehicle rental entities.

[0082] In one embodiment, the solution can also be used to move a 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 or modified event. In one embodiment, the solution can also allow existing vehicles in the area to verify available parking spaces within the area. The approximate time a space will become available can also be determined based on verification of existing vehicles. In one embodiment, the solution can also be used to move a vehicle to a nearby parking space when one is available and the time elapsed since parking began is less than the average duration of the event. Furthermore, the vehicle can be moved to the final parking space upon completion of the event or based on the location of a device associated with at least one passenger of the vehicle. In one embodiment, the solution can also be used to plan parking before congestion occurs. The system interacts with vehicles to offer services at a lower price than full fare and / or direct them to alternative parking spaces based on their priority, thereby optimizing parking availability before arrival.

[0083] In one embodiment, the solution can also be used to sell fractional ownership in a vehicle or determine pricing and availability in ride-sharing applications. In one embodiment, the solution can also be used to provide accurate and timely reporting of dealer sales activity at a scale far beyond what is currently available. In one embodiment, the solution can also be used to allow dealers to request assets via blockchain. By using blockchain, consensus is reached before any asset is transferred. Furthermore, the process is automated, and payments can be initiated via the blockchain. In one embodiment, the solution can also be used to arrange agreements with multiple entities (such as service centers), where consensus is achieved and actions (such as diagnostics) are performed. In one embodiment, the solution can also be used to associate digital keys with multiple users. The first user can be the operator of the vehicle, and the second user can be the responsible party for the vehicle. These keys are authorized by a server, where the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be used to determine the services required by the vehicle at its destination. One or more service points are located that can provide the required services, both within the area along the route to the destination and available to perform the services. The vehicle's navigation is updated with the identified service points. A smart contract containing the compensation value for the services is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

[0084] In one embodiment, the solution can also be used to connect service provider vehicles with the profiles of vehicle passengers to identify services and goods that may be of interest to the vehicle's passengers. These services and goods are determined by the passenger's history and / or preferences. The vehicle then receives a quote from the service provider vehicle and, in another embodiment, fulfills the service / goods offer. In one embodiment, the solution can also be used to detect vehicles within range and send service quotes (e.g., maintenance quotes, product quotes, etc.) to the vehicle. Agreements are reached between the system and the vehicle, and the system selects a service provider to provide the offer. In one embodiment, the solution can also be used to assign one or more vehicles as road managers, where road managers assist in traffic control. Road managers can generate road signals (e.g., lights, displays, sounds) to help direct traffic. In one embodiment, the solution can also be used to issue alerts to vehicle drivers via a device, such as a traffic light or near an intersection. Alerts are issued when an event occurs, such as when a light turns green and a vehicle ahead of a column of vehicles does not move.

[0085] Figure 2H 2 is another block diagram illustrating the interconnections between various components in example 290. Vehicle 276 is shown and includes ECUs 295 and 296 and a head unit (also known as an infotainment system) 297. An electrical control unit (ECU) is an embedded automotive electronic system that controls one or more electrical systems or subsystems within the vehicle. ECUs may include, but are not limited to, those that manage the vehicle's engine, braking system, transmission system, door locks, instrument panel, airbag system, infotainment system, electronic differential, and active suspension. ECUs are connected to the vehicle's controller area network (CAN) bus 294. ECUs can also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (e.g., vehicle computer) 298 can communicate with external components, such as a server 293 via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 can contain its own security policy. The security policy defines the permitted processes that can be executed within the appropriate context. In one embodiment, the security policy may be partially or entirely implemented within the vehicle computer 298.

[0086] ECUs 295, 296, and head unit 297 can each include custom security features 299 that define authorized processes and the contexts in which such processes are allowed to run. Context-based authorization determines the validity of processes when they can be executed, maintaining secure ECU operation and preventing unauthorized access to components such as the vehicle's controller area network (CAN bus). When an ECU encounters an unauthorized process, it can block the process from running. Vehicle ECUs can use various contexts to determine whether a process is running within its permitted scope, such as proximity context (e.g., nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects), operational context (e.g., an indication of whether the vehicle is moving or parked, the vehicle's current speed, and transmission status), user-related context (e.g., devices connected to the vehicle via wireless protocols, usage of infotainment, cruise control, parking assistance, and driver assistance), location-based context, and / or other contexts.

[0087] In one embodiment, the solution described and depicted herein can be used to render a vehicle partially inoperable by limiting speed, restricting the ability to approach another vehicle, limiting maximum speed, and (in some embodiments) setting a specified number of miles allowed per time period. In one embodiment, the solution can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is transmitted to a server by devices associated with the vehicle or an accident, or devices in proximity to the accident. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one embodiment, the solution can also be used to help vehicles avoid accidents. For example, when a vehicle is involved in an accident, the server queries other vehicles in proximity to the accident. The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one embodiment, the solution can also be used to determine whether sounds emitted by the vehicle are atypical and transmit data related to the sounds and the possible source location to the server, where the server can determine the possible cause and avoid potentially dangerous situations. In one embodiment, the solution can also be used to establish a location boundary when a vehicle is involved in an accident. The boundary is determined based on the decibel level associated with the accident. Multimedia content from devices within the boundary is retrieved to further understand the accident scene. In one embodiment, the solution can also be used to associate a vehicle with an accident, then capture media captured by a device near the accident location. The captured media is saved as a media clip. The media clip is sent to another computing device, which creates an audio profile of the accident. This audio profile helps to understand more details about the accident.

[0088] In one embodiment, the solution can also be used to utilize sensors to record audio, video, motion, etc. to record areas where potential incidents are occurring. For example, if a vehicle (while moving or parked) contacts or may contact another vehicle, the system captures data from sensors that may be located on the vehicle and / or one or more fixed or moving objects. In one embodiment, the solution can also be used to identify a new condition of the vehicle during an incident by using sensor data and comparing that condition to a vehicle condition profile to determine if the vehicle has been compromised. This allows for the safe and reliable capture of critical data from a vehicle about to enter an adverse incident.

[0089] In one embodiment, the solution can also be used to warn passengers of a vehicle when the vehicle determines through one or more sensors that it is approaching or traveling along a one-way road in the wrong way. The vehicle has sensors / cameras / maps that interact with the system in the current solution. The system knows the geographic location of one-way roads. For example, the system can use an audible notification to passengers that they are "approaching a one-way road." In one embodiment, the solution can also be used to allow vehicles to be compensated, enabling autonomous vehicle owners to earn money using the data collected and stored by their vehicle sensors, encouraging vehicle owners to share their data and provide additional data to entities that can use this data to improve the performance of future vehicles, provide services to vehicle owners, and so on.

[0090] In one embodiment, the solution can also be used to increase or decrease vehicle features based on the vehicle's behavior over a period of time. In one embodiment, the solution can also be used to assign partial ownership of a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine the condition of the vehicle. Partial ownership of the vehicle is determined based on the condition and provides new vehicle responsibilities. In one embodiment, the solution can also be used to provide data to a replacement / upgrade component, where the data attempts to disrupt the authorized functionality of the replacement / upgrade component, and in response to the authorized functionality being unbreakable, the component allows the authorized functionality of the replacement / upgrade component to be used.

[0091] In one embodiment, the solution can also be used to provide individuals with the ability to ensure a passenger is in a vehicle and that the passenger arrives at a specific destination. Furthermore, the system ensures that the authorized driver (in the case of a non-autonomous vehicle) and / or other passengers interact with the passenger. Furthermore, boarding, exiting, and location are annotated. All of this is immutably stored on the blockchain. In one embodiment, the solution can also be used to determine a driver's characteristics by analyzing driving style and other factors, allowing for action if the driver is not driving in a typical manner, such as how the driver has previously driven in specific conditions, such as daytime, nighttime, rain, and snow. Furthermore, vehicle attributes are taken into consideration. These attributes include weather conditions, whether the headlights are on, whether navigation is being used, whether the head-up display is in use, the volume of media being played, and so on. In one embodiment, the solution can also be used to notify passengers in a vehicle of hazardous situations when objects within the vehicle indicate that the occupants may be unaware of the situation.

[0092] In one embodiment, this solution can also be used to install a calibration device on a vehicle-mounted rig, enabling the various sensors on the vehicle to automatically adjust based on a comparison of what the calibration device should detect with the actual detection results. In one embodiment, this solution can also be used to request consensus from multiple service centers using blockchain when a vehicle requiring service sends fault information enabling remote diagnostics. The other service centers must reach a consensus on the severity threshold of the data. Once consensus is reached, the service center can send the failsafe level to the blockchain for storage. In one embodiment, this solution can also be used to determine discrepancies between sensor data external to the vehicle and the vehicle's own sensor data. The vehicle can then request software from a server to correct the problem. In one embodiment, this solution can also be used to allow nearby or nearby vehicles to communicate when an event occurs, such as a collision.

[0093] refer to Figure 2I , shows an operating environment 290A of a connected vehicle according to some embodiments. As shown, vehicle 276 includes a controller area network (CAN) bus 291A that connects components 292A-299A in the vehicle. Other components can 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 driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

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

[0095] Memory 297A is a non-transitory memory that stores instructions or data that can be accessed and executed by processor 296A. The instructions and / or data may include code for executing the techniques described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory device. In some embodiments, memory 297A may also include non-volatile memory or similar permanent storage devices and media, and may include a hard drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or other large-capacity storage devices for permanent storage of information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Vehicle 276 may include one or more memories 297A without departing from the current solution.

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

[0097] Navigation system 295A can describe at least one navigation route including a starting point and a destination. In some embodiments, navigation system 295A of vehicle 276 receives a request from a user for a navigation route, the request including a starting point and a destination. Navigation system 295A can query a real-time data server 293 (e.g., a server providing driving directions) (via network 292) for navigation route data corresponding to the navigation route including a starting point and a destination. Real-time data server 293 transmits the navigation route data to vehicle 276 via wireless network 292, and communication system 298A stores navigation route data 295A in memory 297A of vehicle 276.

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

[0099] 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, sensor group 292A of vehicle 276 may include one or more of the following vehicle sensors: a camera, a LIDAR sensor, an ultrasonic sensor, a vehicle engine sensor, a radar sensor, a laser altimeter, an intake air pressure sensor, an infrared detector, a motion detector, a thermostat, an acoustic detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, a mass air flow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timing device, an air-fuel ratio meter, a blind spot meter, a curb detector, a defect detector, a Hall effect sensor, a parking sensor, a radar gun, a speedometer, a speed sensor, a tire-pressure monitoring sensor, a torque sensor, a transmission oil temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a water sensor, a wheel speed sensor, a GPS sensor, mapping capabilities, and any other type of vehicle sensor. Navigation system 295A may store sensor data in memory 297A.

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

[0101] Vehicle 276 can interact with other vehicles 277 using V2V technology. V2V communication includes sensing radar information corresponding to relative distances to external objects, receiving GPS information from a vehicle, setting an area as the area where other vehicles 277 are located based on the sensed radar information, calculating a probability that the GPS information of the target vehicle is 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.

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

[0103] In one embodiment, the solution can also be used to analyze the presence of passengers in each vehicle available for voice communication based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one embodiment, the solution can also be used to determine two risk levels of road congestion and receive a gesture that can indicate a warning that the congestion has not risen above a threshold, so that the vehicle can continue along the road. In one embodiment, the solution can also be used to delete sensitive data from a vehicle when the vehicle is damaged and cannot be used.

[0104] In one embodiment, the solution can also be used to verify that deleted customer data has indeed been deleted from all necessary locations within the enterprise, demonstrating GDPR compliance. In one embodiment, the solution can also be used to enhance the autonomous driving capabilities of lower-level autonomous vehicles by allowing vehicles to exchange data related to safety, important notifications, and the like. In one embodiment, the solution can also be used to provide vehicles with the ability to receive data based on a first biometric associated with a passenger. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuation of the first biometric. The vehicle provides the decrypted data to the passenger when only the passenger is capable of receiving it, deletes sensitive portions of the decrypted data when provided, and deletes non-sensitive portions after a time period associated with the biometric. In one embodiment, the solution can also be used to provide vehicles with the ability to authenticate a person based on weight and grip on the vehicle's steering wheel. In one embodiment, the solution can also be used to provide a vehicle with a feature that exists but is not currently enabled for presentation to vehicle passengers, reflecting the passenger's characteristics.

[0105] In one embodiment, the solution can also be used to allow modifications to a vehicle, particularly its interior, but also its exterior, to reflect or assist at least one passenger, in one embodiment. In another embodiment, recreating a passenger's work and / or home environment is disclosed. If the system determines that a user is in "work mode" or "home mode," the system can attempt to "recreate" the user's work / home environment while in the vehicle. All data related to the vehicle's interior and exterior, as well as the various passengers using the vehicle, is stored on the blockchain and executed via smart contracts. In one embodiment, the solution can also be used to detect passenger gestures to facilitate communication with nearby vehicles, which can then operate accordingly. In one embodiment, the solution can also be used to provide vehicles with the ability to detect intended gestures using a gesture definition data store. In one embodiment, the solution can also be used to provide vehicles with the ability to take various actions based on a passenger's gait and gestures. In one embodiment, the solution can also be used to ensure that a vehicle driver currently engaged in various operations (e.g., driving while using voice navigation, etc.) has not exceeded the number of unsafe maneuvers before being permitted to perform gesture operations.

[0106] In one embodiment, the solution can also be used to assign a status to each passenger in a vehicle and verify a passenger's gestures based on their status. In one embodiment, the solution can also be used to collect details of collision-related sounds (at what location, in what direction, raised or lowered, from what device, and device-related data such as type, manufacturer, owner, and the number of simultaneous sounds, timing of the sounds, etc.) and provide them to a system, where data analysis helps determine details related to the collision. In one embodiment, the solution can also be used to determine unsafe vehicle operation. A vehicle includes multiple components that interoperate to control the vehicle, and each component is associated with a separate component key. An 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 actions: limiting the vehicle to a given speed, limiting the vehicle to a certain distance from another vehicle, or limiting the vehicle to a threshold distance.

[0107] In one embodiment, the solution can also be used to provide instructions from a specific vehicle (about to vacate a spot) to another specific vehicle (seeking to take the spot), with blockchain used to perform authentication and coordination. In one embodiment, the solution can also be used to determine partial ownership of a vehicle. For example, in situations where multiple people own a single vehicle, the vehicle's usage (which may change over time) can be used by the system to update partial ownership. Other embodiments are included in the application, including minimum ownership of a vehicle based not on vehicle usage but on vehicle availability, identification of vehicle drivers, and other factors.

[0108] In one embodiment, this solution can also be used to allow users within a vehicle to share their subscription services with a small group, such as family or friends. For example, a user may wish to share a membership; if so, the associated transactions would be stored on the blockchain or in a traditional database. When a user who is not the primary subscriber requests subscription materials, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared their profile. In one embodiment, this solution can also be used to allow people to utilize secondary transportation to reach their intended destination. Secondary transportation is determined using a functional relationship value (e.g., a value representing various parameters and their importance in determining which type of transportation to use). In one embodiment, these solutions can also be used to allow passengers involved in an accident to continue to their original destination using alternative transportation.

[0109] In one embodiment, the solution can also be used to propagate software / firmware uploads to a first subset of vehicles. This first group of vehicles tests the update, and upon successful testing, the update is propagated to another group of vehicles. In one embodiment, the solution can also be used to propagate software / firmware updates from a primary vehicle to vehicles, where the update propagates across the network from the first subset of vehicles, followed by a larger subset, and so on. A portion of the update can be sent first, followed by the remainder from the same vehicle or another vehicle. In one embodiment, the solution can also be used to deliver vehicle computer updates to vehicles and devices belonging to vehicle operators / passengers. The update can be authorized by all drivers and / or all passengers. The software update is delivered to vehicles and devices. The user does not need to do anything; the function is automatically completed upon approaching the vehicle. A notification is sent to the device indicating that the software update has been completed. In one embodiment, the solution can also be used to verify that the OTA software update was performed by a qualified technician, with one or more vehicle components generating status related to: the originator of the verification code, the procedure for wirelessly receiving the software update, the information contained in the software update, and the verification results.

[0110] In one embodiment, the solution can also be used to provide the ability for a second component to parse software updates located in a first component. The critical update content in the first part and the non-critical update content in the second part are then verified, and the verified first part is assigned to a process in the vehicle. This process runs the verified first part for a period of time, responds to a positive result based on the period of time, and then runs the verified first part again with other processes after a period of time. In one embodiment, the solution can also be used to provide service selection to passengers, where the service is based on the vehicle's passenger profile and profiles shared with the passenger. In one embodiment, the solution can also be used to store user profile data on a blockchain and intelligently present offers and recommendations to users based on their automatically collected purchase history and preferences derived from the user profile on the blockchain.

[0111] Figure 3A Flowchart 300 is shown according to an example embodiment. Figure 3A , the processor may perform one or more of the following operations: detecting an environment via a first sensor ( 302 ), determining that an event associated with the environment is about to occur ( 304 ), providing energy to a second sensor associated with the upcoming event ( 306 ), and detecting an event via the second sensor while the event is occurring ( 308 ).

[0112] Figure 3B Another flow chart 320 is shown according to an example embodiment. Figure 3B , the processor may perform one or more of the following operations: determining a portion of the vehicle where an upcoming event is expected to occur and providing energy to one or more additional sensors disposed in the portion of the vehicle where the event is expected to occur (322); determining a portion of the vehicle where an upcoming event is expected to occur, providing energy to all sensors associated with the portion for a first time period, and providing energy to a second sensor for a second time period that is longer than the first time period (324); determining that a front portion of the vehicle is the portion of the vehicle where an upcoming event is expected to occur, and providing energy to the vehicle to reduce the vehicle speed for a predefined time period (326); determining that a rear portion of the vehicle is the portion of the vehicle where an upcoming event is expected to occur, and providing energy to the vehicle to increase the vehicle speed for a predefined time period (step 328).

[0113] Figure 3C Yet another flow chart 340 according to an example embodiment is shown. Figure 3C, the processor may perform one or more of the following operations: receiving verification of an event from at least one component, wherein the verification includes a blockchain consensus between a peer group consisting of the vehicle and the at least one component (342), and executing a smart contract to record the upcoming event and the at least one component on a blockchain based on the blockchain consensus (344).

[0114] Figure 4 A machine learning vehicle network diagram 400 is shown 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.

[0115] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by the 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.

[0116] The vehicle node 402 sends data from one or more sensors 404 to a machine learning subsystem 406. The machine learning subsystem 406 provides the one or more sensor 404 data to a learning model 408, which 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.

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

[0118] Figure 5A An example vehicle configuration 500 is shown for managing database transactions associated with a vehicle according to an example embodiment. Figure 5AWhen a particular vehicle / vehicle 525 engages in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle may receive assets 510 and / or write off / transfer assets 512 in accordance with the transaction. Vehicle processor 526 is located within vehicle 525, and communication occurs between vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Transaction module 520 may record information such as assets, parties, points, service descriptions, dates, times, locations, results, notifications, incidents, etc. Transactions in transaction module 520 may be replicated to database 530. Database 530 may be a SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and may be located on or off the vehicle, accessible directly and / or via a network, or accessible by the vehicle.

[0119] Figure 5B An example vehicle configuration 550 for managing database transactions between vehicles, according to an example embodiment, is shown. When a vehicle enters a state requiring sharing of services with another vehicle, vehicle 525 can engage with another vehicle 508 to perform various actions, such as sharing, transferring, or placing a service call. For example, vehicle 508 may need to charge its battery and / or have tire issues, and may be en route to pick up a package for delivery. Vehicle processor 528 is located within vehicle 508, and communication occurs between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle 525 that it is in its network and operating on its blockchain membership service. Vehicle processor 526 is located within vehicle 525, and communication occurs between vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Vehicle 525 can then request information from vehicle 508 and / or a server (not shown) via wireless communication to perform package pickup. The transaction is recorded in transaction modules 552 and 520 of both vehicles, respectively. Points are transferred from vehicle 508 to vehicle 525, and a record of the transfer service is recorded in database 530 / 554, if the blockchains are different from each other, otherwise it is recorded in the same blockchain shared by all members. Database 554 can be a SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be on or off the vehicle, directly accessible, and / or accessible via a network.

[0120] Figure 6A A blockchain architecture configuration 600 is shown according to an example embodiment. Figure 6ABlockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, a permissioned blockchain is not accessible to all parties, but only to those members who are permitted to access blockchain data. Blockchain nodes participate in various activities, such as blockchain entry addition and the verification process (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (e.g., authentication) and seek writes to the blockchain's immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0121] Blockchain transactions 620 are stored in the computer's memory as transactions received and approved by the consensus model specified by the member nodes. Approved transactions 626 are stored in the current block of the blockchain and submitted to the blockchain via a commit procedure that includes hashing the data content of the transaction in the current block and referencing the previous hash of the previous block. Within the blockchain, there may be one or more smart contracts 630 that define the terms of the transaction agreement and actions contained in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, what service capabilities they are entitled to / need based on their profile, and whether to monitor their behavior during subsequent events. For example, when a service event occurs while a user is in the vehicle, sensor data monitoring can be triggered. A parameter (e.g., vehicle charge level) can be identified as being above or below a specific threshold for a specific period of time. This may result in a change in the current state, which may require an alert to be sent to a management entity (i.e., vehicle owner, vehicle operator, server, etc.) so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's status. Sensor data can also form the basis for vehicle event data 634, such as the location of travel, average speed, maximum speed, acceleration, whether there were any collisions, whether the intended route was taken, the next destination, whether safety measures were in place, and whether the vehicle had sufficient power / fuel. All of this information can serve as the basis for smart contract 630 clauses and be stored on the blockchain. For example, sensor thresholds stored in a smart contract can be used as the basis for determining whether a detected service is necessary, when, and where to perform the service.

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

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

[0124] A blockchain platform can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that can be used to receive and store new entries and be accessible to auditors seeking access to data entries. The blockchain can expose interfaces that provide access to the virtual execution environment necessary to process program code and utilize the physical infrastructure. Cryptographic trust services can be used to verify entries (e.g., asset exchange entries) and keep information private.

[0125] Figure 6A and 6B The blockchain architecture configuration can process and execute program / application code through one or more interfaces exposed by the blockchain platform and the services it provides. As a non-limiting example, smart contracts can be created to implement reminders, updates, and / or other notifications of modifications or updates. The smart contracts themselves can be used to identify rules associated with authorization and access requirements and ledger usage. For example, this information can include a new entry, which can be processed by one or more processing entities included in the blockchain layer (e.g., processors, virtual machines, etc.). The results may include rejecting or approving the new entry based on criteria defined in the smart contract and / or a consensus decision among peers. Physical infrastructure can be used to retrieve any data or information described herein.

[0126] Smart contracts can be created using high-level applications and programming languages ​​and then written to blocks within a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated with a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of the smart contract code, which can be executed in response to the satisfaction of conditions associated with the smart contract. The execution of a smart contract can trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0127] Smart contracts can write data to the blockchain in the form of key-value pairs. Furthermore, smart contract code can read values ​​stored on the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. This code can be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be public and / or encrypted and maintained as private information. Temporary data used or generated by smart contracts is stored in memory by the provided execution environment and deleted once the required data for the blockchain is identified.

[0128] The smart contract executable code may include a code interpretation of the smart contract with additional features. As described herein, the smart contract executable code may be program code deployed on a computing network, executed and verified by chain validators during a consensus process. The smart contract executable code receives the hash and retrieves from the blockchain a hash value associated with a data template created using a previously stored feature extractor. If the hash value of the hashed identifier matches the hash value created from the stored identifier template data, the smart contract executable code sends an authorization key to the requesting service. The smart contract executable code may write data associated with encryption details to the blockchain.

[0129] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown. Figure 6CExample configuration 660 provides for a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server, on behalf of a service provider entity, can query a vehicle service provider to share user profile rating information when a known user profile attempts to rent a vehicle with an established rating profile. Server 666 may be receiving and processing data related to service requirements for a vehicle. When a service event occurs, such as vehicle sensor data indicating a need for refueling / charging, maintenance service, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke a vehicle service event. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the vehicle's service status, event updates, etc. Transactions may include the parties involved, requirements (e.g., age 18 or older, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients allowed access to the event and managed vehicle services, rights / permissions, sensor data retrieved during vehicle event operations to record details of the next service event and identify vehicle status, and thresholds used to determine whether the service event is completed and whether the vehicle status has changed.

[0130] Figure 6D 680, and the contents of block structures 682A through 682n, that may be added to a distributed ledger according to an example embodiment. Figure 6D Clients (not shown) can submit entries to blockchain nodes to perform activities on the blockchain. For example, a client can be an application that proposes entries to the blockchain on behalf of a requester (e.g., a device, person, or entity). Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. Different types of blockchain nodes / peers may exist in a blockchain network, including endorsing peers that simulate and endorse entries proposed by clients, and committing peers that verify endorsements, validate entries, and commit entries to the distributed ledger. In this example, a blockchain node can act as an endorsing node, a committing node, or both.

[0131] The live system consists of a blockchain that stores immutable, ordered records in blocks, and a state database that maintains the current state of the blockchain (the current world state). Each channel may have a distributed ledger, and each peer maintains its own copy of the distributed ledger for each channel it belongs to. The live blockchain is a log of entries, structured as hash-linked blocks, with each block containing a sequence of N entries. Blocks can include various components, such as Figure 6DThe components shown in . Block links are generated by adding the hash of the previous block header to the current block's header. This keeps all entries on the blockchain sequentially and cryptographically linked, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the linked structure, the latest block in the blockchain represents every entry that came before it. The live blockchain can be stored on a peer-to-peer file system (local or attached storage), supporting append-only blockchain workloads.

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

[0133] An endorsing peer receives an entry from a client and endorses it based on the simulation results. Endorsing peers host smart contracts that simulate entry proposals. When an endorsing peer endorses an entry, it creates an entry endorsement, a signed response from the endorsing peer to the client application indicating its endorsement of the simulated entry. The method for endorsing an entry depends on the endorsement policy specified in the smart contract's executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry." Different channels can have different endorsement policies. The client application forwards the endorsed entry to the ordering service.

[0134] An ordering service accepts endorsed entries, orders them into blocks, and delivers these blocks to committing peers. For example, an ordering service can initiate a new block when a threshold of entries is reached, a timer expires, or other conditions occur. In this example, a blockchain node is a committing peer that has received data block 682A to be stored on the blockchain. An ordering service may consist of a cluster of ordering nodes. An ordering service does not process entries, smart contracts, or maintain a shared ledger. Instead, an ordering service accepts endorsed entries and specifies the order in which they are committed to the distributed ledger. Blockchain network architectures can be designed so that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0135] Entries are written to the distributed ledger in a consistent order. This order is established to ensure that updates to the state database are valid when submitted to the network. Unlike cryptocurrency blockchain systems, where ordering is achieved by solving cryptographic puzzles, in this example, each participant in the distributed ledger can choose the ordering mechanism that best suits the network.

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

[0137] Block data 690A may store entry information for each entry recorded within the block. For example, the entry data may include one or more of the following: entry type, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, smart contract executable code path (deploy 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 key and certificate, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code events, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkle tree query digest, etc. Entry data may be stored for each of the N entries.

[0138] In some embodiments, block data 690A may also store transaction-specific data 686A, which adds additional information to the chain of hash links of blocks in the blockchain. Thus, data 686A may be stored in an immutable log of blocks on the distributed ledger. Some benefits of storing this data 686A are reflected in various embodiments disclosed and described herein. Block metadata 688A may store multiple fields of metadata (e.g., as byte arrays, etc.). Metadata fields may include a signature at block creation, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, and the last offset of the ordering service that sorts the block. The signature, last configured block, and ordering node metadata may be added by the ordering service. Furthermore, the block submitter (e.g., a blockchain node) may add validity / invalidity information based on endorsement policies, read / write set verification, and the like. The entry filter may include a byte array equal in size to the number of entries in block data 610A and a verification code identifying whether an entry is valid / invalid.

[0139] The remaining blocks 682B through 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the block headers 684A through 684n in the remaining blocks includes a hash of the immediately preceding block. The hash of the immediately preceding block may be just the hash of the preceding block's header, or it may be the hash of the entire preceding block. By including the hash of the preceding block in each remaining block, the Nth block can be traced back to the genesis block (and associated original files), block by block, as indicated by arrow 692, to establish an auditable and immutable chain of custody.

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

[0141] An exemplary storage medium may be coupled to the processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral with the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may exist as discrete components. For example, Figure 7 An example computer system architecture 700 is shown, which may be representative of or integrated in any of the above components, etc.

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

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

[0144] Computer system / server 702 can be described in the general context of computer system-executable instructions (e.g., program modules) executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 can be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located in local and remote computer system storage media, including memory storage devices.

[0145] like Figure 7 As shown, 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, system memory 706, and a bus that couples various system components including system memory 706 to processor 704.

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

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

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

[0149] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as systems, methods, or computer program products. Accordingly, aspects of the present application may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which may be generally referred to herein as "circuits," "modules," or "systems." 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.

[0150] Computer system / server 702 can also communicate with one or more external devices via I / O devices 712 (e.g., I / O adapters). These I / O devices may include keyboards, pointing devices, displays, voice recognition modules, and the like, as well as one or more devices that enable a user to interact with computer system / server 702, and / or any device that enables computer system / server 702 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Communication can be achieved via the I / O interfaces of device 712. Furthermore, computer system / server 702 can communicate with one or more networks, such as a local area network (LAN), a general-purpose wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter. As shown, device 712 communicates with other components of computer system / server 702 via a bus. It should be understood 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, and data archiving storage systems.

[0151] Although example embodiments of at least one of the systems, methods, and non-transitory computer-readable media have been shown in the accompanying drawings and described in detail above, it should be understood that the present application is not limited to the various embodiments disclosed, but is capable of various rearrangements, modifications, and substitutions as described and defined in the appended claims. For example, the functions of the systems of the various figures can be performed by one or more modules or components described herein, or can be performed in a distributed architecture and can include transmitters, receivers, or pairs of both. For example, all or part of the functions performed by a single module can be performed by one or more of these modules. Further, the functions described herein can be performed at different times and in relation to various events inside or outside the modules or components. In addition, the information sent between the modules can be transmitted between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Moreover, messages sent or received by any module can be sent or received directly and / or sent or received via one or more other modules.

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

[0153] It should be noted that some system features described in this specification have been presented as modules to more specifically highlight their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom very large-scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented as a programmable hardware device, such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, or the like.

[0154] 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 example, comprise one or more physical or logical blocks of computer instructions, which may, for example, be assembled into an object, procedure, or function. However, the executable files for an identified module need not be physically located together, but may instead comprise different instructions stored in different locations; when logically connected together, these instructions comprise the module and achieve the stated purpose of the module. Furthermore, a module may be stored on a computer-readable medium, such as a hard drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0155] In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across multiple storage devices. Similarly, operational data can be identified and described herein within a module and can be embodied in any suitable form and organized in any suitable type of data structure. The operational data can be collected as a single data set or can be distributed in different locations, including across different storage devices, and can exist, at least in part, solely as electronic signals on a system or network.

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

[0157] Those skilled in the art will readily appreciate that the above content may be practiced with steps in a different order and / or with hardware elements having configurations different from those disclosed. Therefore, although the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative configurations will be apparent to those skilled in the art.

[0158] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and the scope of the present application should 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: detecting, by a first sensor of a vehicle, an impending event associated with an environment of the vehicle; identifying, by the vehicle, a portion of the vehicle where the impending event is expected to occur; In response to identifying a location, providing power, by the vehicle, to an additional sensor disposed in the location of the vehicle where the impending event is expected to occur; providing power, by the vehicle, to a second sensor associated with the impending event and suspending other sensors; as well as The vehicle is maneuvered to avoid the impending event based on input to the vehicle from the second sensor.

2. The method according to claim 1, comprising: providing energy to all sensors associated with the site during a first time period; as well as Energy is provided to the second sensor for a second time period that is longer than the first time period.

3. The method according to claim 1, comprising: identifying that the portion of the vehicle is the front portion of the vehicle; as well as Wherein, operating the vehicle further comprises: The speed of the vehicle is reduced for a predefined time period.

4. The method according to claim 1, comprising: identifying that the portion of the vehicle is the rear portion of the vehicle; as well as Wherein, operating the vehicle further comprises: The speed of the vehicle is increased for a predefined time period.

5. The method according to claim 1, comprising: Verification of the upcoming event is received by the vehicle from at least one component, wherein the verification comprises a blockchain consensus among a peer group consisting of the vehicle and the at least one component.

6. The method according to claim 5, comprising: A smart contract is executed by the vehicle to record the upcoming event and the at least one component on a blockchain based on the blockchain consensus.

7. A means of transport comprising: A processor configured to: detecting an impending event related to an environment of the vehicle based on an output of a first sensor of the vehicle; identifying a portion of the vehicle where the impending event is expected to occur; responsive to identifying a location, causing the vehicle to provide power to an additional sensor disposed in the location of the vehicle where the impending event is expected to occur; providing power to a second sensor associated with the impending event and suspending the other sensors; as well as The vehicle is maneuvered to avoid the impending event based on input to the vehicle from the second sensor.

8. The vehicle of claim 7, wherein the processor is further configured to: providing energy to all sensors associated with the site during a first time period; and Energy is provided to the second sensor for a second time period that is longer than the first time period.

9. The vehicle of claim 7, wherein the processor is further configured to: identifying that the portion of the vehicle is the front of the vehicle; and in, When the processor is configured to operate the vehicle, the processor is further configured to: The speed of the vehicle is reduced for a predefined time period.

10. The vehicle of claim 7, wherein the processor is further configured to: identifying that the portion of the vehicle is the rear of the vehicle; and in, When the processor is configured to operate the vehicle, the processor is further configured to: The speed of the vehicle is increased for a predefined time period.

11. The vehicle of claim 7, wherein the processor is further configured to: Verification of the upcoming event is received from at least one component, wherein the verification comprises a blockchain consensus among a peer group consisting of the vehicle and the at least one component.

12. The vehicle of claim 11, wherein the processor is further configured to: A smart contract is executed to record the upcoming event and the at least one component on a blockchain based on the blockchain consensus.

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

Images