Provisioning of external functionality to transports

Abstract

To provision external functionality to transports.SOLUTION: An example operation includes one or more of: receiving, at a transport, a key and data associated with an upcoming event from a server; verifying, by the transport, the data associated with the upcoming event based on current data acquired by the transport; in response to verification of the data associated with the upcoming event, receiving, at the transport, functionality configured to address the upcoming event; and unlocking the functionality on the transport by the key.SELECTED DRAWING: Figure 1B

Description

[Background technology]

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

[0002] One exemplary embodiment provides a method that includes one or more of receiving, at a vehicle, a key and data related to an upcoming event from a server; verifying, by the vehicle, the data related to the upcoming event based on current data acquired by the vehicle; receiving, at the vehicle, a function configured to address the upcoming event in response to verifying the data related to the upcoming event; and unlocking the function at the vehicle with the key.

[0003] Another exemplary embodiment provides a system including a memory communicatively coupled to a processor, the processor performing one or more of receiving a key and data related to an upcoming event from a server, validating the data related to the upcoming event based on current data acquired by the vehicle, receiving a function configured to address the upcoming event in response to validating the data related to the upcoming event, and unlocking the function in the vehicle with the key.

[0004] A further exemplary embodiment provides a non-transitory computer-readable medium including instructions that, when loaded by a processor, cause the processor to perform one or more of: receiving a key and data related to an upcoming event from a server; validating the data related to the upcoming event based on current data acquired by the vehicle; receiving a function configured to address the upcoming event in response to validating the data related to the upcoming event; and unlocking the function in the vehicle with the key. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1A illustrates an example of data flow in a transportation network, according to an exemplary embodiment. [Figure 1B] FIG. 1B illustrates a further example of data flow in a transportation network, according to an exemplary embodiment. [Figure 2A] FIG. 2A illustrates a transportation network diagram in accordance with an exemplary embodiment. [Figure 2B] FIG. 2B illustrates another transportation network diagram in accordance with an illustrative embodiment. [Figure 2C] FIG. 2C illustrates yet another transportation network diagram in accordance with an illustrative embodiment. [Figure 2D] FIG. 2D illustrates a further transportation network diagram in accordance with an illustrative embodiment. [Figure 2E] FIG. 2E illustrates another additional transportation network diagram in accordance with an illustrative embodiment. [Figure 2F] FIG. 2F illustrates a diagram showing the electrification of one or more elements, according to an exemplary embodiment. [Figure 2G] FIG. 2G illustrates a diagram showing the interconnections between various elements, according to an exemplary embodiment. [Figure 2H] FIG. 2H shows a further diagram illustrating the interconnections between various elements, according to an exemplary embodiment. [Figure 2I]FIG. 2I shows another further view illustrating interconnections between elements, according to an exemplary embodiment. [Figure 2J] FIG. 2J shows another further diagram illustrating a keyless entry system, according to an exemplary embodiment. [Figure 2K] FIG. 2K illustrates another further view of a CAN within a vehicle in accordance with an illustrative embodiment. [Figure 2L] FIG. 2L illustrates another further diagram illustrating end-to-end communication channels, according to an exemplary embodiment. [Figure 2M] FIG. 2M illustrates another further diagram illustrating an example vehicle using security certificates to perform secure V2V communications, according to an exemplary embodiment. [Figure 2N] FIG. 2N shows another further diagram depicting an example of a vehicle interacting with a security processor and a wireless device, according to an exemplary embodiment. [Figure 3A] FIG. 3A shows a flow diagram according to an exemplary embodiment. [Figure 3B] FIG. 3B illustrates another flow diagram according to an exemplary embodiment. [Figure 4] FIG. 4 illustrates a machine learning transportation network diagram in accordance with an exemplary embodiment. [Figure 5A] FIG. 5A illustrates an exemplary vehicle configuration for managing database transactions related to a vehicle, according to an exemplary embodiment. [Figure 5B] FIG. 5B illustrates another exemplary vehicle configuration for managing database transactions conducted between various vehicles, according to an exemplary embodiment. [Figure 6A] FIG. 6A illustrates a blockchain architecture configuration, according to an example embodiment. [Figure 6B] FIG. 6B illustrates another blockchain configuration, according to an example embodiment. [Figure 6C] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. [Figure 6D]FIG. 6D illustrates an exemplary data block, according to an exemplary embodiment. [Figure 7] FIG. 7 illustrates an exemplary system that supports one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

[0007] Communications between a vehicle and certain entities, such as remote servers, other vehicles, and local computing devices (e.g., smartphones, personal computers, vehicle-mounted computers, etc.), are sent and / or received and processed by one or more “components,” which may be hardware, firmware, software, or a combination thereof. A component is part of any of these entities, computing devices, or some other computing device. In one example, consensus decisions regarding blockchain transactions are performed by one or more computing devices or components associated with the vehicle (which may be any of the elements described and / or depicted herein) and one or more components outside of or remote from the vehicle.

[0008] The features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase "exemplary embodiment," "some embodiments," or other similar terms refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, throughout this specification, the appearances of the phrases "exemplary embodiment," "some embodiments," "other embodiments," or other similar terms do not necessarily all refer to the same group of embodiments, but rather that the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the figures, even if the depicted connections are one-way or two-way arrows, any connection between elements allows for one-way and / or two-way communication. In current solutions, transportation includes one or more of a car, truck, pedestrian-area battery electric vehicle (BEV), e-pallet, fuel cell bus, motorcycle, scooter, bicycle, boat, recreational vehicle, airplane, and any object used to transport people and / or goods from one place to another.

[0009] Additionally, although the term "message" may be used in describing the embodiments, other types of network data may be used, such as packets, frames, datagrams, etc. Furthermore, although certain types of messages and signaling may be depicted, the exemplary embodiments are not limited to certain types of messages and signaling.

[0010] Exemplary embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks for providing at least one of a transportation facility (also referred to herein as a vehicle or car), a data collection system, a data monitoring system, a verification system, an authentication 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, is processed to identify vehicle / vehicle status conditions and provide feedback on the status and / or changes of the transportation facility. In one example, a user profile is applied to a particular transportation facility / vehicle to authorize current vehicle events, service stops at service stations, authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

[0011] Within a communications infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. A blockchain is an example of a distributed database that includes an append-only, immutable data structure (i.e., a distributed ledger) that allows records to be maintained among untrusted parties. Herein, the untrusted parties are referred to as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record unless consensus is reached among the distributed peers. For example, peers execute a consensus protocol to validate storage entries in a blockchain, group the storage entries into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary for consistency. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains, including cryptocurrencies, can use consensus based on various protocols, such as proof-of-work (PoW). Conversely, a permissioned blockchain database can secure interactions between groups of entities that share a common goal but cannot fully trust each other, such as businesses exchanging funds, goods, information, etc. The solution can work in permissioned and / or permissionless blockchain settings.

[0012] Smart contracts are trusted, decentralized applications that leverage the tamper-proof properties of a shared or distributed ledger (in the form of a blockchain) and a basic agreement between member nodes called an endorsement or endorsement policy. Generally, blockchain entries are "endorsed" before being committed to the blockchain, and entries that are not endorsed are ignored. A typical endorsement policy allows the executable code of a smart contract to specify endorsers for the entry in the form of a set of peer nodes required for endorsement. When a client submits an entry to a peer identified in the endorsement policy, the policy is executed to validate the entry. After validation, the entry enters an ordering phase, in which a consensus protocol is used to generate an ordered sequence of endorsed entries, grouped into blocks.

[0013] A node is a communicating entity in a blockchain system. A "node" performs a logical function in the sense that multiple nodes of various types can run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes include various types, such as client nodes or submitting client nodes, which submit entry invocations to endorsers (e.g., peers) and broadcast entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client-submitted entries, commit entries, and maintain copies of the state and ledger of blockchain entries. Peers can also play the role of endorser. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each peer node in the system, when committing entries and modifying the blockchain world state. The world state can construct the initial blockchain entry, which typically contains control and setup information.

[0014] A ledger is a sequenced, tamper-proof record of all state transitions of a blockchain. State transitions result from invocations (i.e., entries) of executable code in smart contracts submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry commits a set of key-value pairs of assets to the ledger as one or more operands, such as create, update, delete, etc. The ledger contains a blockchain (also called a chain) that is used to store immutable, sequenced records in blocks. The ledger also contains a state database that maintains the current state of the blockchain. Typically, there is one ledger per channel. Each peer node maintains a copy of the ledger for each channel in which they are a member.

[0015] A chain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries, where N is greater than or equal to 1. The block header contains the hash of the block's entries and the hash of the previous block's header. In this way, all entries on the ledger are sequenced and cryptographically linked to each other. Therefore, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added blockchain block represents all entries on the chain that came before it, ensuring that all peer nodes have a consistent and trusted state. Chains are stored on the peer node filesystem (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0016] The current state of the immutable ledger represents the most recent values ​​for all keys contained in the chain entry log. The current state is sometimes referred to as the world state, as it represents the most recent key values ​​known to the channel. Invocations of smart contract executable code execute entries against the ledger's current state data. To streamline interactions with smart contract executable code, the most recent values ​​for keys are stored in a state database. Because the state database is simply an indexed view into the chain's entry log, it can be regenerated from the chain at any time. The state database is automatically restored (or generated if necessary) at peer node startup, before any entries are accepted.

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

[0018] Exemplary embodiments provide services to a particular vehicle and / or a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or an operator of a vehicle owned by another party. Vehicles may require service at certain intervals, and service needs require authentication before allowing service. A service center also provides services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirements (e.g., immediate, critical, medium, minor, etc.). Vehicle needs are monitored via one or more vehicles and / or road sensors or cameras that report sensory data to a central controller computing device within and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the interior of the vehicle, the exterior of the vehicle, fixed objects remote from the vehicle, and another vehicle in close proximity to the vehicle. Sensors may also relate to vehicle speed, vehicle braking, vehicle acceleration, fuel level, service needs, vehicle gear shifting, vehicle steering, etc. The sensors described herein may be devices such as wireless devices within and / or in proximity to the vehicle. Additionally, sensor information may be used to identify whether the vehicle is operating safely or whether the occupant has engaged in an unexpected vehicle condition, such as during the vehicle's access and / or usage period. Vehicle information collected before, during, and / or after vehicle operation is stored in transactions on a shared / distributed ledger, which are generated and committed to the immutable ledger in a "decentralized" manner as determined by a permissioned consortium, and therefore via blockchain membership groups.

[0019] Each party (i.e., owner, user, company, agency, etc.) wants to limit the exposure of personal information, and for this reason, blockchain and its immutability can be used to manage permissions for each specific user-vehicle profile. Smart contracts are used to provide rewards, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is needed, identify collision and / or deterioration events, identify safety concern events, identify event participants, and provide distribution to registered entities seeking access to such vehicle event data. Furthermore, results can be identified, and necessary information can be shared among registered companies and / or individuals based on a consensus approach involving blockchain. Such an approach could not be implemented on traditional centralized databases.

[0020] The various driving systems of the present solution may utilize software, arrays of sensors, and machine learning capabilities, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, etc. to create maps of the terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. may also be used in autonomous vehicles in place of LIDAR.

[0021] The solution, in some embodiments, involves authenticating a vehicle for service via an automated, rapid authentication scheme. For example, driving to a charging station or fuel pump is performed by the vehicle operator or autonomous vehicle, and authentication to charge or receive fuel is performed without delay when authentication is received by the service and / or charging station. The vehicle provides a communication signal providing the identity of the vehicle with a currently active profile linked to the account authorized to receive service, which can later be redeemed with a reward. Additional means may be used to provide further authentication. For example, another identifier may be wirelessly transmitted from the user's device to the service center to replace or supplement the initial authentication operation between the vehicle and the service center with an additional authentication operation.

[0022] The shared and received data is stored in a database, which maintains the data in one specific location, generally in one single database (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database is typically accessible from multiple different locations. Because it is in a single location, a centralized database is easier to manage, maintain, and control, especially for security purposes. Within a centralized database, data redundancy is minimized, as the single storage location of all data also means that a given data set has only one primary record. Blockchain is used to store data about transportation and transactions.

[0023] Any of the actions described herein may be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), head units, etc.) located on or outside the vehicle. The one or more processors may communicate with other processors on or outside other vehicles to utilize data transmitted by the vehicle. The one or more processors and other processors may send data, receive data, and utilize this data to perform one or more actions described or depicted herein.

[0024] In one embodiment, a solution is provided for provisioning external functionality to a vehicle. A vehicle's Trusted Execution Environment (TEE) dynamically processes keys and is used to unlock additional functionality received from a server (such as a cloud server) or inactive functionality present in the vehicle. The TEE is provided by a vehicle processor connected to the vehicle's components. The TEE within the vehicle is enabled by secure encrypted communications (i.e., encrypted data exchange) between the vehicle's processor, ECU, and all vehicle components.

[0025] The cloud server obtains information about events that may soon occur within the vehicle's operating environment. For example, the cloud server receives data about upcoming events, including changes in the operating environment, such as heavy rain, snow, slippery roads, ice, fog, traffic, accidents, etc., from weather-related data sources (e.g., via the Internet), data sources containing traffic information, weather maps, or other sources (e.g., GPS and road maps). The cloud server also identifies upcoming events, including changes in the driving surface (e.g., from asphalt to dirt, gravel, one-lane roads, etc.), from analysis of received data, such as from mapping data sources. These events require the activation of additional functionality in the vehicle. Therefore, the cloud server sends a key along with the upcoming event information to the vehicle. The vehicle verifies that the key and functionality are from a trusted source. In situations where the cloud server cannot be authorized, error processing can be performed by the vehicle's processor to determine the reason for the lack of authentication. To authorize the cloud server, the vehicle uses its ECU and sensor readings to verify the received upcoming event data. For example, the ECU provides data indicating changes in traction or gas consumption, and sensors provide data indicating changes in outside temperature and humidity. This information is analyzed by a processor to identify events such as rain or snow, which are provided by a cloud server. For example, high humidity and low outside temperature, along with increased gas consumption and changes in traction, identify that it is about to snow. In one embodiment, the vehicle authorizes the server by identifying upcoming events by obtaining data from other connected vehicles on the vehicle's network. The current vehicle queries connected vehicles traveling ahead of the current vehicle (towards the next event, etc.) based on the connected vehicle's GPS location and identifies the event using the connected vehicle's ECU readings.The content of the message from the cloud server is verified by the current vehicle's processor based on the current vehicle's ECU / sensor readings, the connected vehicle's ECU / sensor readings at the time prior to the event, or the connected vehicle's ECU / sensor readings when the next event begins to occur. For example, if the ECU / sensor readings indicate that snow is starting to fall (or is about to start falling), the vehicle's processor confirms the event data indicating snow provided by the cloud server. If the event is confirmed, the vehicle's processor unlocks (using the key received from the cloud server) and executes a function when the next event begins to occur (or immediately before the event). For example, a software patch (or update) is installed in the vehicle to activate a function such as enhanced traction control, an enhanced anti-lock braking system, torque distribution between four wheels, activation of an all-wheel drive function, activation of anti-fog lights, activation of an additional window heating function, adjustment of fuel injection, or other function. In one embodiment, the key received from the cloud server temporarily unlocks existing functions that are not activated on a particular model of vehicle during the event. The processing of the next event is performed automatically and is implemented in autonomous vehicles as well as human-operated vehicles. Alternatively, the vehicle may use the key to unlock a feature received from another vehicle connected to a cloud server over a secure network connection. Similarly, the vehicle may share the feature and key with another vehicle connected on the vehicle's network upon receiving an agreement from a cloud server connected to the vehicle on the vehicle's network. In one embodiment, the key and feature are deleted from the vehicle upon completion of the event, thereby advantageously leaving the vehicle without the key stored most of the time.

[0026] FIG. 1A illustrates an example of data flow in a vehicle network 100, according to an exemplary embodiment. A vehicle node TEE 130 includes a processor communicatively coupled to a server 110. In block 101, the server 110 generates a temporary key. The server 110 then transmits the temporary key along with upcoming event information to the vehicle TEE 130. In block 131, the vehicle TEE 130 determines the upcoming event information based on readings from the vehicle ECU and / or vehicle sensors. If the upcoming event is determined in block 133, the temporary key is stored in the vehicle in block 134. Otherwise, the process ends, and the vehicle does not request additional functionality from the server 110. In block 135, the TEE 130 modifies the temporary key based on an agreement with the server 110. The TEE 130 then obtains current data from the vehicle ECU and / or vehicle sensors in block 136. The current data is transmitted to the server 110 along with the modified temporary key. In block 102, the server 110 verifies the modified temporary key based on the temporary key generated in block 101. Because the modified key is a derivative of the temporary key (i.e., the parent key), the modified key can be verified by the parent key. If the modified key is successfully verified in block 102, the server 110 sends features based on the current data provided by the TEE 130. As described above, the features include software patches (updates) sent to the vehicle to activate features such as enhanced traction control, an enhanced anti-lock braking system, torque distribution between the four wheels, activation of an all-wheel drive function, activation of anti-fog lights, activation of additional window heating functions, adjustment of fuel injection, or other ECU functions. The features are based on current data reflecting conditions such as rain, snow, ice, fog, traffic congestion, an accident ahead, or a change in pavement type. In block 137, the features are stored in the vehicle's TEE 130 and executed by the vehicle's processor to modify the operation of the affected vehicle components.In block 139, the capabilities and keys are sent to the other vehicles based on agreement from server 110, as described above. After the event is complete, in block 138, the capabilities and modified keys are deleted from the vehicle's TEE 130.

[0027] 1B illustrates a further example data flow 150 in a vehicle network, according to an exemplary embodiment. As described above, cloud server 120 obtains information about upcoming events within the vehicle's 151 operating environment. For example, cloud server 120 receives data about upcoming events from weather maps and / or other sources (e.g., GPS and road maps) including changes in the operating environment, such as heavy rain, snow, slippery roads, ice, fog, traffic, accidents, etc. Cloud server 120 also identifies upcoming events including changes in the driving surface (e.g., from asphalt to dirt, gravel, one-lane roads, etc.). These events require the activation of additional functionality in vehicle 151. Accordingly, cloud server 120 transmits key 115 to the vehicle along with upcoming event information (not shown). Vehicle 151 verifies that key 115 and functionality are from a trusted source. To authorize cloud server 120, vehicle 151 uses its ECU and sensor readings to validate the received upcoming event data. For example, the ECU provides data indicating changes in traction or gas consumption, and sensors in the vehicle 151 provide data indicating changes in outside temperature and humidity. This information can be used to confirm an event, such as rain or snow, provided by the cloud server 120. In one embodiment, the vehicle authorizes the server by confirming the next event by obtaining data from other vehicles 152 traveling ahead of the current vehicle (toward the next event, etc.). The content of the message from the cloud server 120 is verified either in time prior to the event or as the next event begins to occur. Once the event is confirmed, the processor in the vehicle 151 unlocks using the key 115 received from the cloud server 120 and performs a function based on the function data 116 provided by the server 120 when the next event begins to occur (or just before the event).For example, a software patch (or update) may be installed on the vehicle to activate features such as enhanced traction control, an enhanced anti-lock braking system, torque distribution between four wheels, activation of all-wheel drive functionality, activation of anti-fog lights, activation of additional window heating functionality, adjustment of fuel injection, or other ECU functionality. In one embodiment, a key 115 received from cloud server 120 temporarily unlocks existing features not enabled on the particular model of vehicle 151 for the duration of the event. According to an exemplary embodiment, processing of the next event is performed automatically and is implemented in autonomous vehicles as well as human-operated vehicles. Alternatively, vehicle 151 may use key 115 to unlock feature data 116 received from another vehicle 152 connected to cloud server 120 over a secure network connection. Similarly, vehicle 151 may share feature data 116 and key 115 with another vehicle 152 upon receiving agreement 118 from cloud server 120. The keys 115 and functional data 116 are deleted from the vehicles 151 and 152 upon completion of the event, so that the vehicles advantageously remain without stored keys most of the time.

[0028] In one embodiment, an agreement to modify (or share) the key 115 is received from the cloud server 120, which explicitly consents to the modification of the key 115 by the vehicle 151. The vehicle 151 sends a consent request to the cloud server 120 before modifying the key 115. The vehicle 151 and the cloud server 120 are connected on a blockchain network. The agreement to modify the key 115 constitutes a blockchain consensus between at least the peer node represented by the vehicle 151 and the nodes of the cloud server 120. In some embodiments, the blockchain consensus includes agreement from other blockchain nodes (e.g., intermediate servers, other vehicles 152, etc.). The modified key 115 is recorded on the blockchain for future reference by execution of a smart contract. A trusted blockchain peer node (e.g., the vehicle 152) accesses the modified key 115 from the blockchain ledger.

[0029] FIG. 2A illustrates a transportation network diagram 200 according to an exemplary embodiment. The network includes elements including a transportation node 202 including a processor 204 and a transportation node 202′ including a processor 204′. The transportation nodes 202, 202′ communicate with each other via the processors 204, 204′ and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between the transportation nodes 202, 202′ may occur via private and / or public networks (not shown) or directly between the other transportation nodes and elements including one or more of a processor, memory, and software. While depicted as a single transportation node and processor, multiple transportation nodes and processors may be present. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the present elements.

[0030] 2B illustrates another transportation network diagram 210 according to an exemplary embodiment. The network includes elements including a transportation node 202 including a processor 204 and a transportation node 202' including a processor 204'. The transportation nodes 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between the transportation nodes 202, 202' may occur via private and / or public networks (not shown) or directly between the other transportation nodes and elements including one or more of a processor, memory, and software. The processors 204, 204' may further communicate with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transportation node 222, a computer 224, an I / O device 226, and a voice application 228. The processor 204, 204' may further be in communication with elements comprising one or more of a processor, memory, and software.

[0031] Although depicted as a single transportation node, processor, and element, there may be multiple transportation nodes, processors, and elements. Information or communication may occur to and / or from any of processors 204, 204′ and element 230. For example, mobile phone 220 may provide information to processor 204, which may cause transportation node 202′ to initiate an action and provide further or additional information to processor 204′, which may cause transportation node 202′ to initiate an action and provide further or additional information to mobile phone 220, transportation node 222, and / or computer 224. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the present elements.

[0032] 2C illustrates yet another vehicle network diagram 240, according to an exemplary embodiment. The network comprises elements including a node 205 that includes a processor 204 and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and to element 230 (depicted in FIG. 2B). The node 205 is a vehicle that includes a processor and a memory.

[0033] Although only one transportation node 205 is described in detail in this example, multiple such nodes may be connected to element 230. It should be understood that transportation node 205 may include additional components, and that some of the components described herein may be removed and / or modified without departing from the scope of the present application. Node 205 may be or include a computing device or server computer, etc., and may include a processor 204, which may be a semiconductor-based microprocessor, central processing unit (CPU), application specific integrated circuit (ASIC), field programmable gate array (FPGA), and / or another hardware device. While a single processor 204 is depicted, it should be understood that node 205 may include multiple processors, multiple cores, etc., without departing from the scope of the present application.

[0034] Node 205 also includes non-transitory computer-readable medium 242C having machine-readable instructions stored thereon that are executable by processor 204. Examples of machine-readable instructions are shown as 244C-249C and are further described below. Examples of non-transitory computer-readable medium 242C include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, non-transitory computer-readable medium 242C is random access memory (RAM), electrically erasable programmable read-only memory ("EEPROM"), hard disk, optical disk, or other type of storage device. The processor and / or computer-readable medium may reside wholly or partially within or external to vehicle node 205, such as node 205. Steps or functions stored on the computer-readable medium may be executed wholly or partially by the processor and / or any of the elements in any order.

[0035] Processor 204 executes machine-readable instructions 244C to receive a key and data associated with a next event from a server. Processor 204 executes machine-readable instructions 246C to verify the data associated with the next event based on current data acquired by the vehicle. Processor 204 executes machine-readable instructions 248C to receive a function configured to address the next event in response to verifying the data associated with the next event. Processor 204 executes machine-readable instructions 249C to unlock a function in the vehicle with the key. Processor and / or computer-readable medium 242C may reside completely or partially internal or external to the vehicle node. Additionally, one or more steps or functions may be added, omitted, combined, or performed at a later time.

[0036] FIG. 2D illustrates a further vehicle network diagram 250 according to an exemplary embodiment. The network comprises elements including a vehicle node 205, which includes a processor 204 and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and element 230 (depicted in FIG. 2B). The vehicle node 205 includes a processor and memory. The processor 204 executes one or more of machine-readable instructions 244D through 250D. The processor 204 executes the machine-readable instructions 244D to verify the key and the next event by transmitting data from sensors associated with the vehicle when the event begins to occur. The processor 204 executes the machine-readable instructions 246C to modify the key and transmit the modified key and data from sensors associated with the vehicle regarding the occurring event. The processor 204 executes machine-readable instructions 248D to modify the key based on agreement with the server, and in response to verification of the modified key based on the key at the server, receives a function at the vehicle based on data received from sensors associated with the vehicle. The processor 204 executes machine-readable instructions 250C to ascertain the next event associated with the key based on vehicle sensor or ECU readings. The processor and / or computer-readable medium 242D may reside wholly or partially within or external to the vehicle node. The steps or functions stored on the computer-readable medium 242D may be performed wholly or partially in any order by any of the processors and / or elements.

[0037] 2E illustrates a further vehicle network diagram 260, according to an example embodiment. Referring to FIG. 2E, network diagram 260 includes node 205 connected to server 210 and other vehicle nodes 202′ over a blockchain network 206. Vehicle nodes 202 and 202′ represent vehicles / vehicles. Blockchain network 206 includes ledger 208 for recording keys.

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

[0039] Processor 204 executes one or more of computer-readable instructions 244E-246E. Processor 204 executes machine-readable instructions 244E to modify the key based on an agreement with server 210, which agreement constitutes a blockchain consensus between at least peers represented by transportation nodes 205 and server 210. Processor 204 executes machine-readable instructions 246E to execute a smart contract to record the key on blockchain 206 in response to the blockchain consensus.

[0040] The processor and / or computer-readable medium 242E may reside wholly or partially within or external to the vehicle node. The steps or functions stored on the computer-readable medium 242E may be performed wholly or partially by any of the processors and / or elements in any order. Additionally, one or more steps or functions may be added, omitted, combined, performed at a later time, etc.

[0041] FIG. 2F shows diagram 265 depicting the electrification of one or more elements. In one embodiment, vehicle 266 provides power stored in its batteries to one or more elements, including other vehicles 268, charging stations 270, and an electrical grid 272. Electrical grid 272 is coupled to one or more charging stations 270, which are coupled to one or more vehicles 268. This configuration allows for the distribution of electricity / power received from vehicle 266. Vehicle 266 also interacts with other vehicles 268 via communication, for example, via vehicle-to-vehicle (V2V) technology, cellular, WiFi, etc. Vehicle 266 also interacts with other vehicles 268, charging stations 270, and / or electrical grid 272 in a wireless and / or wired manner. In one embodiment, vehicle 266 is routed (or routes itself) to electrical grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the present solution, a vehicle 266 can provide energy to one or more of the elements depicted herein in a variety of advantageous ways as described and / or depicted herein. Additionally, the safety and efficiency of the vehicle can be improved, and the environment can be positively impacted, as described and / or depicted herein.

[0042] The term "energy" is used to refer to any form of energy that may be received, stored, used, shared, and / or lost by a vehicle. Energy may be referenced in relation to a voltage source and / or current source of charge provided to the vehicle from an entity during charging / use operations. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or via alternative power sources, including, but not limited to, lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy sources, and energy generated in situ during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0043] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 so that vehicle 266 is left with enough charge to reach its destination. In one embodiment, a wireless connection is used to wirelessly direct the amount of energy transferred between vehicles 268, both of which are in motion. In one embodiment, a stationary vehicle, such as vehicle 266 (which may be autonomous), provides a predetermined amount of energy to charging station 270 and is instructed to return to its original location (e.g., its original location or another 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, factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (e.g., weight), the schedule of the passenger currently using the vehicle, the schedule of potential passengers waiting for the vehicle, etc., determine the amount of energy transferred to charging station 270. In one embodiment, vehicle 268 , charging station 270 and / or electrical grid 272 may provide energy to vehicle 266 .

[0044] In one embodiment, the solution described and depicted herein can be utilized to determine load impacts 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 including 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 on-board battery. In one embodiment, the solution can also be utilized to provide charge from a vehicle to a location based on factors such as the temperature of the location, the cost of energy, and the power level of the location. In one embodiment, the solution can also be utilized to manage the amount of energy remaining in the vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, the solution can also be utilized to notify the vehicle to provide a predetermined amount of energy from the on-board battery, the amount of energy to transfer being based on the distance from the vehicle to the module receiving the energy.

[0045] In one embodiment, the solution can be used to use a mobile energy storage unit that drives to a vehicle with excess energy using a determined route and deposits the stored energy into the electric grid. In one embodiment, the solution can be used to determine the priority of a vehicle's determination of its need to provide energy to the grid and the priority of the vehicle's current needs, such as the priority of passengers, next passengers, current cargo, or next cargo. In one embodiment, the solution can be used to determine when a vehicle is not moving, whether the vehicle will travel to a location where it will discharge excess energy into the energy grid and then return to the previous location. In one embodiment, the solution can be used to determine the amount of energy a vehicle needs to provide the required energy to another vehicle through a vehicle-to-vehicle energy transfer based on one or more conditions, such as weather, traffic, road conditions, vehicle conditions, and passengers and / or goods in the other vehicle, and to instruct the vehicle to route to the other vehicle to provide the energy. In one embodiment, the solution can be used to transfer energy from one operating vehicle to another operating vehicle. In one embodiment, the solution may also be used to recover energy by a vehicle based on the energy consumed by the vehicle to reach a meeting point with another vehicle and provide service and the expected energy consumption to return to the original location. In one embodiment, the solution may also be used to provide a remaining distance required to a charging station and determine the amount of energy the charging station should recover from the vehicle, the remaining charge being based on the remaining distance. In one embodiment, the solution may also be used to manage a vehicle being charged by multiple points at the same time, such as both a charging station via a wired connection and another vehicle via a wireless connection.In one embodiment, the solution can also be used to prioritize the distribution of energy to vehicles, with priority being given to vehicles that will provide a portion of their stored charge to another entity, such as the electric grid, a residence, etc. Additionally, the solution described and depicted with respect to Figure 2F can be used in this and other networks and / or systems.

[0046] FIG. 2G is a diagram 275 illustrating the interconnections between various elements. The solution is stored on and / or executed, in whole or in part, by one or more computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′ associated with various entities communicatively coupled to and in communication with network 286. Database 287 is communicatively coupled to the network and enables data storage and retrieval. In one embodiment, the database is an immutable ledger. One or more of the various entities are transportation facility 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructure 282, one or more residences 283, electric grid / charging stations 284, microphones 285, and / or another transportation facility 277. Other entities and / or devices, such as one or more individual users using a smartphone 278, a laptop 280, and / or a wearable device, can also interact with the solution. The smartphone 278, the laptop 280, the microphone 285, and other devices are connected to one or more of the connected computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′. One or more public buildings 281 include various institutions. One or more public buildings 281 utilize computing device 281′. One or more service providers 279 include a dealership, a tow truck service, a collision center, or other repair shop. One or more service providers 279 utilize computing device 279′. These various computing devices are directly and / or communicatively coupled to one another, for example, via a wired network, a wireless network, a blockchain network, etc. In one embodiment, the microphone 285 is utilized as a virtual assistant. In one embodiment, the one or more traffic infrastructures 282 include one or more traffic signals, one or more cameras, one or more sensors including vehicle speed sensors or traffic sensors, and / or other traffic infrastructure.One or more transportation infrastructures 282 utilize computing devices 282'.

[0047] In one embodiment, vehicles 277 / 276 can transport people, objects, permanently or temporarily attached equipment, etc. In one embodiment, vehicles 277 communicate with vehicles 276 via V2V communications through computers associated with each vehicle 276' and 277' and are referred to as vehicles, cars, vehicles, automobiles, etc. Vehicles 276 / 277 are self-propelled wheeled vehicles such as cars, sport utility vehicles (SUVs), trucks, buses, vans, or other motor- or battery- or fuel-cell-powered vehicles. For example, vehicles 276 / 277 can be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or other types of vehicles having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, planes, or boats, and other forms of vehicles capable of transportation. Vehicles 276 / 277 can be semi-autonomous or autonomous. For example, the vehicle 276 / 277 may be self-piloting and navigate without human input. An autonomous vehicle has and uses one or more sensors and / or navigation units to operate autonomously.

[0048] 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 have the vehicle display (visually, in another embodiment, verbally, etc.) on or from the vehicle the action the user needs to perform (which may be pre-recorded) and verify that it is the correct action. In one embodiment, the solution can also be used to determine how to fork data based on risk levels associated with the data and the driving environment, providing the vehicle with the ability to distribute a portion of the forked data with a low risk level to the passenger during a safe driving environment and then distribute the remaining portion of the forked data with a high risk level after the passenger departs the vehicle. In one embodiment, the solution can also be used to handle the transfer of vehicles across borders (such as countries, states, etc.) through the use of blockchain and / or smart contracts and apply the rules of the new area to the vehicle.

[0049] In one embodiment, the solution may be utilized to allow a vehicle to continue operating outside of a boundary when a consensus is reached by the vehicle based on the vehicle's operation and the vehicle's occupant characteristics. In one embodiment, the solution may be utilized to analyze the vehicle's available data upload / download speed, file size, and the speed / direction the vehicle is traveling to determine the distance required to complete the data upload / download and assign a secure area boundary for the data upload / download to occur. In one embodiment, the solution may be utilized to safely perform a normally dangerous maneuver when the system determines, for example, that an exit is approaching or the vehicle is not believed to be ready to exit (e.g., in an inappropriate lane or traveling at an inappropriate speed for the upcoming exit), and to instruct the subject vehicle and other nearby vehicles to allow the subject vehicle to exit safely. In one embodiment, the solution may be utilized to verify the diagnostics of another vehicle using one or more vehicles while both the one or more vehicles and the other vehicle are operating.

[0050] In one embodiment, the solution may be used to detect lane usage at a location and time of day and notify the vehicle's crew or instruct the vehicle to recommend or not recommend a lane change. In one embodiment, the solution may be used to eliminate the need to send information via email and for the driver / passenger to respond via email or by making a payment in person. In one embodiment, the solution may be used to provide services to vehicle crew, where the services provided are subscription-based and authorization is obtained from other vehicles connected to the crew's profile. In one embodiment, the solution may be used to record changes in the state of a rented object. In one embodiment, the solution may be used to seek blockchain consensus from other vehicles in proximity to a damaged vehicle. In one embodiment, the solution may be used to receive media from a server, such as an insurance entity server, and from a vehicle's computer regarding the accident. The server accesses one or more media files to access the vehicle's damage and stores the damage assessment on the blockchain. In one embodiment, a solution may be utilized to obtain consensus for determining the severity of an event from multiple devices over various periods of time prior to the event on the vehicle.

[0051] In one embodiment, the solution may be utilized to solve the problem of a lack of video evidence for vehicle-related accidents. The current solution details that the vehicle involved in the accident queries media related to the accident from other vehicles that may have been in the vicinity of the accident. In one embodiment, the solution may also be utilized to record specific portions of the vehicle that were damaged using vehicle and other devices (e.g., pedestrian cell phones, street light cameras, etc.).

[0052] In one embodiment, the solution may be utilized to warn vehicle crews when the vehicle is traveling toward a dangerous area and / or event, allowing the vehicle to notify the crew or a central controller of potentially dangerous areas on or near the vehicle's current route. In one embodiment, the solution may be utilized to detect when the vehicle is traveling at a high speed, and at least one other vehicle is used to assist in slowing the vehicle in a manner that minimizes traffic impact. In one embodiment, the solution may be utilized to identify dangerous driving situations in which media is captured by a vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one embodiment, the solution may be utilized to send a notification to one or more vehicle crews that the vehicle is approaching a traffic control sign on a road, and then receive indications of poor driving from other nearby vehicles if the vehicle crosses the sign. In one embodiment, the solution may also be utilized to partially disable a vehicle by (in some embodiments) limiting speed, restricting the ability to approach other vehicles nearby, limiting speed to a maximum, and only allowing a given number of miles per hour.

[0053] In one embodiment, the solution may be utilized to overcome the need to rely on software updates to correct vehicle problems when the vehicle is not operating correctly. Through observations of other vehicles along the route, a server may receive data from potentially multiple other vehicles observing unsafe or incorrect vehicle operation. Through analysis, these observations result in notifications to the vehicle when the data suggests unsafe or incorrect operation. In one embodiment, the solution may be utilized to provide notifications between the vehicle and persons outside the vehicle involved in potentially dangerous situations. In one embodiment, the solution may be utilized to transmit data to a server by either a device associated with an incident with the vehicle or a device proximate to the incident. Based on the severity of the incident or nearby incident, the server notifies the sender of the data. In one embodiment, the solution may be utilized to provide recommendations for vehicle operation to either the driver or passengers of the vehicle based on analysis of the data. In one embodiment, the solution may be utilized to establish geofences associated with physical structures and determine payment liability for the vehicle. In one embodiment, the solution may also be utilized to coordinate the ability to drop off a vehicle at a location using both the current state at the location and future states suggested using the navigation destinations of other vehicles. In one embodiment, the solution may also be utilized to coordinate the ability to automatically arrange for a vehicle to be dropped off at a location, such as a transportation rental entity.

[0054] In one embodiment, the solution can also be used to move the vehicle to a different location based on a user's event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user when the original or modified event ends. In one embodiment, the solution can also be used to enable verification of available locations in an area through existing vehicles in the area. The approximate time when the location will be available is also determined based on verification from the existing vehicles. In one embodiment, the solution can also be used to move the vehicle closer to a parking space when the parking space becomes available and the elapsed time since initial parking is shorter than the average time of the event. Furthermore, the vehicle is moved to a final parking space when the event is completed or according to the location of a device associated with at least one occupant of the vehicle. In one embodiment, the solution can also be used to plan parking in advance of upcoming congestion. The system can interact with the vehicle to offer some services at a lower price than the regular rate and / or direct the vehicle to alternative parking locations based on the vehicle's priority, enhancing pre-arrival parking optimization.

[0055] In one embodiment, the solution may be used to sell fractional ownership of a vehicle or in determining pricing and availability in ride-sharing applications. In one embodiment, the solution may be used to provide accurate and timely reporting of dealer sales activity, far beyond what is currently available. In one embodiment, the solution may be used to enable dealers to claim assets on the blockchain. By using the blockchain, consensus is obtained before the asset is moved. Additionally, the process is automated and payments are initiated on the blockchain. In one embodiment, the solution may be used to arrange for agreements to be made with multiple entities (such as service centers) where consensus is obtained and actions to be performed (such as diagnostics). In one embodiment, the solution may be used to associate digital keys with multiple users. A first user is the vehicle operator and a second user is the vehicle manager. The keys are authenticated by a server, where the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution may be used to determine the required services at the vehicle's destination. One or more service stops capable of providing the required service are provided that are within an area on the route to the destination and have availability to perform the service. The vehicle's navigation is updated with the determined service stops. A smart contract containing a reward value for the service is identified, and a blockchain transaction is stored in a distributed ledger of transactions.

[0056] In one embodiment, the solution can also be used to interact with service provider vehicles and vehicle occupant profiles to determine services and products that may be of interest to the vehicle occupant. These services and products are determined by the occupant's history and / or preferences. The vehicle then receives offers from the service provider vehicles and, in another embodiment, meets with the vehicle to provide the service / product. In one embodiment, the solution can also be used to detect vehicles within a predetermined range and send service offers (e.g., maintenance offers, product offers, etc.) to the vehicle. Agreements are made between the system and the vehicle, and service providers are selected by the system to provide the agreements. In one embodiment, the solution can also be used to assign one or more vehicles as road managers, which assist in traffic control. Road managers can generate road indicators (such as lights, displays, and sounds) to assist traffic flow. In one embodiment, the solution can also be used to alert vehicle drivers via devices, which can be traffic lights or located near intersections. Alerts are sent when an event occurs, such as when the light turns green and the vehicle ahead in the vehicle list is not moving.

[0057] FIG. 2H is another block diagram 290 illustrating the interconnections between different elements in one example. A vehicle 276 is presented, including ECUs 295, 296 and a head unit (otherwise known as an infotainment system) 297. An electronic control unit (ECU) is an embedded system in automotive electronics that controls one or more of the vehicle's electrical systems or subsystems. ECUs include, but are not limited to, managing the vehicle's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECUs are connected to the vehicle's controller area network (CAN) bus 294. The ECUs also communicate with the vehicle's computer 298 via the CAN bus 294. The vehicle's processor / sensor 298 (e.g., the vehicle's computer) can communicate with external elements, such as a server 293, via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 contains its own security policy. The security policy defines the allowable processes that can be executed in the appropriate context. In one embodiment, the security policy resides partially or entirely in the vehicle computer 298.

[0058] ECUs 295, 296 and head unit 297 each include custom security function elements 299 that define authenticated processes and the contexts in which these processes are permitted to operate. Context-based authentication for determining the validity of a process enables the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's controller area network (CAN bus). If the ECU encounters an unauthorized process, it can block the operation of the process. The vehicle's ECU can use various contexts to determine whether a process is operating within its permitted scope, such as proximity contexts such as nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects; operational contexts such as indications of whether the vehicle is moving or parked, the vehicle's current speed, and transmission status; devices connected to the vehicle via wireless protocols; user-related contexts such as infotainment usage, cruise control, parking assistance, and driving assistance; location-based contexts; and / or other contexts.

[0059] In one embodiment, the solution described and depicted herein can be utilized to partially disable a vehicle by (in some embodiments) limiting its speed, limiting its ability to approach other nearby vehicles, limiting its speed to a maximum value, and only allowing a given number of miles per hour. In one embodiment, the solution can also be utilized to facilitate vehicle ownership exchanges using blockchain, where data is transmitted to a server by either a device associated with an incident with the vehicle or a device in close proximity to the incident. Based on the severity of the incident or nearby incidents, the server notifies the sender of the data. In one embodiment, the solution can also be utilized to help the vehicle avoid the incident, for example, when the vehicle is involved in an accident, where the server queries other vehicles in close proximity to the incident. The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the incident from multiple vantage points. In one embodiment, the solution can also be utilized to determine that a sound from the vehicle is atypical and transmit data regarding the sound as well as the location of the possible source to the server, where the server can determine the possible cause and avoid a potentially dangerous situation. In one embodiment, the solution may also be used to establish a location boundary through the system when a vehicle is involved in an accident. The boundary is based on decibels associated with the accident. Multimedia content for devices within the boundary is captured to assist in further understanding the accident scenario. In one embodiment, the solution may also be used to associate a vehicle with an accident and then capture media captured by devices in proximity to the accident location. The captured media is saved as media segments. The media segments are sent to another computing device, which builds an audio profile of the accident. This audio profile may assist in understanding the details surrounding the accident.

[0060] In one embodiment, the solution may be utilized to record areas where a potential event has occurred, such as when a vehicle is in or may be in contact with another vehicle (moving or parked), using sensors that record audio, video, motion, etc., and the system captures data from sensors present on the vehicle and / or one or more of a fixed or moving object. In one embodiment, the solution may also be utilized to identify a new state of the vehicle during a vehicle event and determine that the vehicle has been damaged by comparing that state to a vehicle condition profile, thereby allowing for the safe and secure capture of critical data from vehicles about to engage in a harmful event.

[0061] In one embodiment, the solution may also be utilized to alert a transportation vehicle's crew when the transportation vehicle determines, via one or more sensors, that the transportation vehicle is approaching or descending a one-way street in the wrong direction. The transportation vehicle has sensors / cameras / maps that interact with the solution's system. The system knows the geographic location of the one-way street. The system may, for example, audibly notify the crew, "approaching a one-way street." In one embodiment, the solution may also be utilized to enable transportation vehicles to receive payments, which may allow autonomous vehicle owners to monetize the data their vehicle sensors collect and store, create incentives for vehicle owners to share their data, provide additional data to entities that may improve future vehicle performance, provide services to vehicle owners, and the like.

[0062] In one embodiment, the solution may be utilized to increase or decrease vehicle functionality according to vehicle actions over a period of time. In one embodiment, the solution may be utilized to assign fractional ownership to a vehicle. Sensor data regarding one or more vehicles and devices proximate to the vehicle is used to determine the vehicle's status. Fractional ownership of the vehicle is determined based on the status, and new responsibilities for the vehicle are provided. In one embodiment, the solution may be utilized to provide data to a replacement / installation component, the data attempting to subvert an authorized functionality of the replacement / installation component, and in response to non-subversion of the authorized functionality, the component is authorized to use the authorized functionality of the replacement / installation component.

[0063] In one embodiment, the solution can also be used to provide individuals with the ability to ensure that a passenger is in the vehicle and that the passenger will reach a specific destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authenticated to interact with the passenger. Also, pickup, drop-off, and location are noted. All of the above are stored in an immutable format on the blockchain. In one embodiment, the solution can also be used to determine driver characteristics through driving style analysis and other factors, and take action if the driver is not driving in a manner that is typical of how the driver has previously driven in certain conditions, such as daytime, nighttime, rainy, snowy, etc. Additionally, vehicle attributes are also considered. Attributes include weather, whether headlights are on, whether navigation is in use, whether the HUD is in use, the volume of media being played, etc. In one embodiment, the solution can also be used to notify vehicle passengers of dangerous situations when items in the vehicle indicate that the passenger may not be aware of the situation.

[0064] In one embodiment, the solution can be used to attach a calibration device to a rig fixed to the vehicle, and various sensors on the vehicle can automatically self-calibrate based on what should be detected by the calibration device compared to what is actually detected. In one embodiment, the solution can be used to request consensus from multiple service centers using blockchain when a vehicle requiring service submits fault information, allowing remote diagnostic capabilities, and consensus from the other service centers is requested on what the critical threshold for the data is. Once consensus is received, the service center submits the security level of the fault to be stored on the blockchain. In one embodiment, the solution can be used to determine the difference between sensor data external to the vehicle and its own sensor data. The vehicle requests software from a server to correct the problem. In one embodiment, the solution can be used to enable messaging between vehicles nearby or within the area when an event (e.g., a collision) occurs.

[0065] Referring to FIG. 2I, an operating environment 290A for a connected vehicle is shown, according to some embodiments. As depicted, vehicle 276 includes a controller area network (CAN) bus 291A connecting vehicle elements 292A-299A. Other elements may be connected to the CAN bus but are not depicted herein. Depicted elements connected to the CAN bus include a sensor set 292A, an electronic control unit 293A, an autonomous function or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, vehicle 276 includes a processor 296A, memory 297A, a communication unit 298A, and an electronic display 299A.

[0066] The processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array for performing operations and providing electronic display signals to the display unit 299A. The processor 296A processes data signals and includes a variety of computing architectures, including complex instruction set computer (CISC) architectures, reduced instruction set computer (RISC) architectures, or architectures implementing a combination of instruction sets. The vehicle 276 includes one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) communicatively coupled to each other may be used with the present solution.

[0067] Memory 297A is a non-transitory memory that stores instructions or data accessed and executed by processor 296A. The instructions and / or data include code for executing the techniques described herein. Memory 297A is 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 also includes non-volatile memory or similar permanent storage devices and media, including hard disk drives, floppy disk drives, CD-ROM devices, DVD-ROM devices, DVD-RAM devices, DVD-RW devices, flash memory devices, or some other mass storage device for permanently storing information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). A vehicle may include one or more memories 297A without departing from current solutions.

[0068] The memory 297A of the vehicle 276 stores one or more of the following types of data: navigation route data 295A and autonomous function data 294A. In some embodiments, the memory 297A stores data necessary for the navigation application 295A to provide functionality.

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

[0070] ECU 293A controls the operation of many systems of vehicle 276, including ADAS system 294A. ECU 293A responds to commands received from navigation system 295A to disable unsafe and / or unselected autonomous functions during journeys controlled by ADAS system 294A. In this manner, navigation system 295A controls whether ADAS system 294A is activated or enabled so that ADAS system 294A is activated for a given navigation route.

[0071] Sensor set 292A includes any sensor in vehicle 276 that generates sensor data. For example, sensor set 292A includes short-range and long-range sensors. In some embodiments, sensor set 292A of vehicle 276 includes one or more of the following vehicle sensors: a camera, a LIDAR sensor, an ultrasonic sensor, an automobile engine sensor, a radar sensor, a laser photometer, a manifold absolute pressure sensor, an infrared detector, a motion detector, a thermostat, a sound detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, a mass airflow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timer, an air-fuel ratio meter, a blind spot meter, a curb feeler, 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 fluid 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, a mapping function, and other types of automobile sensors. Navigation system 295A stores sensor data in memory 297A.

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

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

[0074] In one embodiment, the solutions described and depicted herein may also be utilized to manage emergency scenarios and vehicle functionality when a vehicle is determined to be entering an area without network access. In one embodiment, the solutions may also be utilized to manage and provide vehicle functionality (e.g., audio, video, navigation, etc.) without network connectivity. In one embodiment, the solutions may also be utilized to determine when a profile of a person in proximity to the vehicle matches profile attributes of a profile of at least one occupant within the vehicle. A notification is sent from the vehicle to establish communication.

[0075] In one embodiment, the solution may be utilized to analyze the availability of occupants in each vehicle available for voice communication based on the time remaining in the vehicle and the context of the communication to be performed. In one embodiment, the solution may be utilized to determine two levels of threat of a roadway obstacle, receive a gesture indicating that the obstacle has not risen to an above-threshold warning, and proceed along the roadway by the vehicle. In one embodiment, the solution may be utilized to delete sensitive data from the vehicle when it is damaged in a way that renders it unusable.

[0076] In one embodiment, the solution may be used to verify that customer data to be deleted has indeed been deleted from all necessary locations within an enterprise to demonstrate GDPR compliance. In one embodiment, the solution may be used to provide compensation from one transportation facility to another transportation facility in exchange for safety-related data, important notifications, etc. to enhance the autonomy capabilities of a low-level automated vehicle. In one embodiment, the solution may be used to provide the transportation facility with the ability to receive data based on a first biometric associated with a passenger. The transportation facility then decrypts the encrypted data based on verification of a second biometric, the second biometric being a continuation of the first biometric. The transportation facility provides unencrypted data to the passenger when only the passenger can receive it, deletes the sensitive portion of the unencrypted data when the sensitive portion is provided, and deletes the non-sensitive portion after a time associated with the biometric has elapsed. In one embodiment, the solution may be used to provide the transportation facility with the ability to authenticate an individual based on weight and grip force applied to the transportation facility's steering wheel. In one embodiment, the solution may also be utilized to provide the vehicle with features that exist but are not currently enabled, and to present features to the vehicle occupants that reflect the occupant's characteristics.

[0077] In one embodiment, the solution may also be utilized to enable vehicle modifications, particularly changes to the interior and exterior of the vehicle, to reflect and assist at least one occupant. In another embodiment, replicating a occupant's work environment and / or home environment is disclosed. If the system determines that a user is in "work mode" or "home mode," the system attempts to "recreate" the user's work / home environment while the user is inside the vehicle. All data regarding the interior and exterior of the vehicle and the various occupants using the vehicle is stored on a blockchain and executed via smart contracts. In one embodiment, the solution may also be utilized to detect occupant gestures to assist in communication with nearby vehicles so the vehicle can steer accordingly. In one embodiment, the solution may also be utilized to provide a vehicle with the ability to detect intended gestures using a gesture definition data store. In one embodiment, the solution may also be utilized to provide a vehicle with the ability to take various actions based on a user's gait and gestures. In one embodiment, the solution may be utilized to ensure that a transportation driver currently engaged in various operations (e.g., driving while talking to a navigation system) does not exceed an unsafe number of operations before a gesture is permitted.

[0078] In one embodiment, the solution may be utilized to assign a status to each occupant in a vehicle and validate gestures from the occupant based on the occupant's status. In one embodiment, the solution may be utilized to collect sound details related to a collision (such as where, which direction, rising or falling, from which device, data related to the device such as type, manufacturer, owner, number of simultaneous sounds, time of day the sounds were emitted, etc.) and provide the collected details to a system that assists in determining the details related to the collision through analysis of the data. In one embodiment, the solution may be utilized to provide a determination that operation of the vehicle is unsafe. A vehicle includes multiple components that interact to control the vehicle, each component associated with a separate component key. An encryption key is transmitted to the vehicle to degrade the vehicle's functionality. In response to receiving the encryption key, the vehicle disables one or more of the component keys. Disabling one or more of the component keys results in one or more of restricting the vehicle from traveling faster than a given speed, restricting the vehicle from traveling closer than a predetermined distance to another vehicle, and restricting the vehicle from traveling greater than a threshold distance.

[0079] In one embodiment, the solution can also be used to provide instructions from one specific vehicle (trying to vacate a location) to another specific vehicle (trying to occupy a location), with blockchain being used to perform authentication and coordination. In one embodiment, the solution can also be used to determine fractional responsibility for a vehicle. For example, if multiple people own a vehicle, the usage of the vehicle over time can be used by the system to update fractional ownership. Other embodiments, including minimum ownership of a vehicle based on vehicle availability rather than vehicle usage, and determination of the vehicle's driver, as well as others, may be included herein.

[0080] In one embodiment, the solution can be used to allow a vehicle user to subscribe to a closed group of people, such as family or friends. For example, a user may want to share membership, in which case the associated transaction is stored on a blockchain or traditional database. When subscribed materials are requested by a user who is not the primary subscriber, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber shared their profile. In one embodiment, the solution can be used to allow a person to use secondary transportation to reach their intended destination. Functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining which type of alternate transportation to use) are used in determining the secondary transportation. In one embodiment, the solution can be used to allow occupants in an accident to access other transportation to continue to their original destination.

[0081] In one embodiment, the solution can be used to propagate software / firmware uploads to a first subset of vehicles. This first set of vehicles tests the update, and if the test is successful, the update is propagated to an additional set of vehicles. In one embodiment, the solution can be used to propagate software / firmware updates from a master vehicle to vehicles, where the update is propagated from a first subset through a network of vehicles, then to a larger subset, and so on. A portion of the update is sent first, and then the remaining portion is sent from the same or another vehicle. In one embodiment, the solution can be used to provide updates for the vehicle's computer to the vehicle and the vehicle's operator / occupant's devices. The update may be approved by all drivers and / or all occupants. The software update is provided to the vehicle and device. The user does not need to do anything; they simply approach the vehicle and the functionality occurs automatically. A notification is sent to the device indicating the software update is complete. In one embodiment, the solution may also be utilized to verify that an OTA software update was performed by a qualified technician and the generation of a status by one or more vehicle components regarding the originator of the verification code, the procedure for receiving the software update over the air, the information contained in the software update, and the results of the verification.

[0082] In one embodiment, the solution may be utilized to provide the ability for a second component to analyze software updates from a first component, then verify a first portion of critical updates and a second portion of non-critical updates, assign the verified first portion to one process in the vehicle, run the verified first portion in one process for a predetermined period of time, and, depending on a positive result based on the predetermined period, run the verified first portion in another process after the predetermined period. In one embodiment, the solution may be utilized to provide a selection of services to a vehicle crew member, the services based on a profile of the vehicle crew member and a shared profile shared with the crew member's profile. In one embodiment, the solution may be utilized to store user profile data on a blockchain and intelligently present offers and recommendations to a user based on the user's automatically collected purchasing history and preferences obtained from the user profile on the blockchain.

[0083] To properly secure a vehicle, the vehicle must be protected not only from unauthorized physical access but also from unauthorized remote access (e.g., cyber threats). In one embodiment, the vehicle is equipped with a secure access system, such as keyless entry, to prevent unauthorized physical access. Meanwhile, in one embodiment, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications with the vehicle.

[0084] Electronic control units (ECUs) are nodes within a vehicle that control tasks ranging from operating windshield wipers to anti-lock braking systems. ECUs are often connected to each other through a central vehicle network called the Controller Area Network (CAN). Cutting-edge features like autonomous driving are heavily dependent on new and complex ECU implementations such as advanced driver assistance systems (ADAS), sensors, and more. These new technologies have helped improve vehicle safety and the driving experience, but they have also increased the number of external communication units within the vehicle, making them more vulnerable to attack. Below are some examples of securing vehicles from physical and remote intrusions:

[0085] FIG. 2J illustrates a keyless entry system 290B for preventing unauthorized physical access to a vehicle 291B, according to an exemplary embodiment. Referring to FIG. 2J, in one embodiment, a key fob 292B transmits commands to the vehicle 291B using radio frequency signals. In this example, the key fob 292B includes a transmitter 2921B having an antenna capable of transmitting short-range wireless signals. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving the short-range wireless signals transmitted from the transmitter 2921B. The key fob 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, that control their respective devices, where memory in (or accessible to) the CPUs 2922B and 2913B is present. In one embodiment, the key fob 292B and the vehicle 291B each include a power source 2924B and 2915B for powering their respective devices.

[0086] When a user presses button 293B on key fob 292B (or otherwise activates the fob), CPU 2922B activates within key fob 292B and transmits a data stream to transmitter 2921B, which outputs the data stream via the antenna. The data stream is a 64- to 128-bit signal that includes one or more of a preamble, a command code, and a rolling code. The signal is transmitted at a rate between 2 KHz and 20 KHz, although embodiments are not limited thereto. In response, receiver 2911B of vehicle 291B acquires the signal from transmitter 2921B, demodulates the signal, and transmits the data stream to CPU 2913B, which decodes the signal and transmits a command (e.g., lock doors, unlock doors, etc.) to command module 2912B.

[0087] If the key fob 292B and the vehicle 291B use a fixed code between them, a replay attack becomes feasible. In this case, if an attacker can capture / eavesdrop on the fixed code during short-range communication, the attacker can replay this code and break into the vehicle 291B. To improve security, the key fob and the vehicle 291B can use a rolling code that changes with each use. Here, the key fob 292B and the vehicle 291B are synchronized with an initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. The key fob 292B and the vehicle 291B also contain a shared algorithm for modifying the initial seed 2914B each time the button 293B is pressed. The next key press takes the result of the previous key press as input and converts it into the next number in the sequence. In some cases, vehicle 291B may store multiple next codes (e.g., 255 next codes) in case a key press on key fob 292B is not detected by vehicle 291B, so that multiple key presses on key fob 292B that are not heard by vehicle 291B do not prevent the vehicle from becoming out of sync.

[0088] In addition to rolling codes, key fob 292B and vehicle 291B may employ other methods to make attacks even more difficult. For example, various frequencies may be used to transmit the rolling codes. As another example, two-way communication between transmitter 2921B and receiver 2911B may be used to establish a secure session. As another example, the code may have an expiration date or timeout. Furthermore, the solution described and depicted with respect to FIG. 2J can be utilized in this network as well as other networks and / or systems, including those described and depicted herein.

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

[0090] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver is used to send messages to and receive messages from CAN bus 297C. For example, transceiver 2911C converts data from microcontroller 2912C into the format of CAN bus 297C and converts data from CAN bus 297C into a format for microcontroller 2912C. However, in one embodiment, microcontroller 2912C interprets messages and determines which messages to send using ECU software installed on microcontroller 2912C.

[0091] Various security protocols can be implemented to protect CAN 290C from cyber threats. For example, sub-networks (e.g., sub-networks A and B) can be used to divide CAN 290C into smaller sub-CANs, limiting an attacker's ability to remotely access the vehicle. In the example of FIG. 2K, ECUs 291C and 292C are part of the same sub-network, and ECU 293C is part of a separate sub-network. Additionally, a firewall 294C (or gateway, etc.) can be added to block messages from crossing sub-networks and traversing CAN bus 297C. If an attacker gains access to one sub-network, they cannot access the entire network. In one embodiment, to further secure the sub-networks, the most critical ECUs are not located on the same sub-network.

[0092] Although not shown in Figure 2K, other examples of security controls within the CAN include an Intrusion Detection System (IDS) that is added to each sub-network and can read all passing data to detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle user. Other possible security protocols include encryption / security keys used to obscure messages. As another example, in one embodiment, an authentication protocol is implemented that allows a message to authenticate itself.

[0093] In addition to protecting the vehicle's internal network, the vehicle can also be protected when communicating with external networks, such as the Internet. One advantage of connecting a vehicle to a data source, such as the Internet, is that information from the vehicle can be transmitted over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve a combination of telecommunications and informatics. Furthermore, the present solution, such as that described and depicted with respect to FIG. 2K, can be utilized in this network as well as other networks and / or systems, including those described and depicted herein.

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

[0095] Secure management of data begins with vehicle 291D. In some embodiments, device 296D collects information before, during, and after a trip. Data includes GPS data, trip data, passenger information, diagnostic data, fuel data, speed data, etc. However, device 296D may only transmit collected information back to host server 295D in response to vehicle ignition and trip completion. Furthermore, communications may be initiated solely by device 296D, and not by host server 295D. Thus, in one embodiment, device 296D does not accept communications initiated by external sources.

[0096] To perform the communication, the device 296D can establish a secure private network between the device 296D and the host server 295D. Here, the device 296D includes a tamper-resistant SIM card that provides secure access to the carrier network 294D via a radio tower 292D. When preparing to send data to the host server 295D, the device 296D establishes a one-way secure connection with the host server 295D. The carrier network 294D communicates with the host server 295D using one or more security protocols. As a non-limiting example, the carrier network 294D communicates with the host server 295D through a VPN tunnel that allows access through the host server's 295D firewall 293D. As another example, the carrier network 294D uses data encryption (e.g., AES encryption) when transmitting data to the host server 295D. In some cases, the system can use multiple security measures, such as both VPN and encryption, to further secure the data.

[0097] In addition to communicating with external servers, vehicles can also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other, roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.), and the like via wireless networks. Wireless networks include one or more of WiFi networks, cellular networks, dedicated short-range communication (DSRC) networks, and the like. Vehicles use V2V communications to provide other vehicles with information regarding the vehicle's speed, acceleration, braking, direction, and the like. Thus, vehicles can be aware of situations ahead before they become visible, thereby significantly reducing collisions. Furthermore, the solution described and depicted with respect to FIG. 2L can be utilized in this network as well as other networks and / or systems, including those described and depicted herein.

[0098] FIG. 2M illustrates example 290E of vehicles 293E and 292E performing secure V2V communication using security certificates, according to an exemplary embodiment. Referring to FIG. 2M, vehicles 293E and 292E communicate with each other through V2V communication over a short-range network, a cellular network, or the like. Prior to sending a message, vehicles 293E and 292E sign the message using their respective public key certificates. For example, vehicle 293E signs the V2V message using public key certificate 294E. Similarly, vehicle 292E signs the V2V message using public key certificate 295E. In one embodiment, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0099] Upon receiving communications from each other, the vehicles verify the signatures using, for example, certificate authority 291E. For example, vehicle 292E uses certificate authority 291E to verify that public key certificate 294E used by vehicle 293E to sign the V2V communication is authentic. If vehicle 292E successfully verifies public key certificate 294E, the vehicle knows the data is from a legitimate source. Similarly, vehicle 293E uses certificate authority 291E to verify that public key certificate 295E used by vehicle 292E to sign the V2V communication is authentic. Furthermore, the solution as described and depicted with respect to FIG. 2M can be utilized in this network, as well as other networks and / or systems, including those described and depicted herein.

[0100]

[0033] Figure 2N shows yet another diagram 290F depicting an example vehicle interacting with a security processor and wireless devices, according to an exemplary embodiment. In some embodiments, the computer 224 shown in Figure 2B includes a security processor 292F as shown in example process 290F of Figure 2N. In particular, the security processor 292F performs authentication, authorization, cryptography (e.g., encryption), etc., on data transmissions sent between ECUs and other devices on the vehicle's CAN bus, and on data messages sent between different vehicles.

[0101] In the example of FIG. 2N, security processor 292F includes authentication module 293F, authorization module 294F, and cryptographic module 295F. Security processor 292F is implemented within a vehicle's computer and communicates with other elements of the vehicle, such as ECU / CAN network 296F, wired / wireless devices 298F such as wireless network interfaces, input ports, etc. Security processor 292F ensures that data frames (e.g., CAN frames, etc.) transmitted internally within the vehicle (e.g., via ECU / CAN network 296F) are secure. Similarly, security processor 292F ensures that messages transmitted between different vehicles and to devices attached to or connected via wires to the vehicle's computer are secure.

[0102] For example, the authentication module 293F stores passwords, usernames, PIN codes, biometric scans, etc. for various users of the vehicle. The authentication module 293F determines whether a user (or technician) has permission to access a particular environment, such as the vehicle's computer. In some embodiments, the authentication module communicates with a network interface to download the necessary authentication information from an external server. When a user wishes to change the vehicle's settings or modify the vehicle's technical details, either through a console or GUI within the vehicle or through an attached / connected device, the authentication module 293F requires the user to verify themselves in some way before such settings are changed. For example, the authentication module 293F requests a username, password, PIN code, biometric scan, predefined line drawing or gesture, etc. In response, the authentication module 293F determines whether the user has the necessary permission (e.g., access) being requested.

[0103] The authorization module 294F is used to authorize internal communications between ECUs on a vehicle's CAN network. For example, the authorization module 294F provides information for authorizing communications between ECUs. For example, the authorization module 294F transmits a bit signature algorithm to the ECUs on the CAN network. The ECUs use the bit signature algorithm to insert authorization bits into the CAN field of CAN frames. All ECUs on the CAN network typically receive each CAN frame. The bit signature algorithm dynamically changes the position, amount, etc. of the authorization bits each time a new CAN frame is generated by one of the ECUs. The authorization module 294F also provides a list (safe list) of ECUs that are exempt and do not need to use authorization bits. The authorization module 294F communicates with a remote server to retrieve updates to the bit signature algorithm, etc.

[0104] Cryptographic module 295F stores asymmetric key pairs used by the vehicle to communicate with other external user devices and vehicles. For example, cryptographic module 295F provides private keys used by the vehicle to encrypt / decrypt communications, and corresponding private keys are provided to other user devices and vehicles so that the other devices can decrypt / encrypt their communications. Cryptographic module 295F communicates with a remote server to receive new keys, key updates, new vehicle, user, etc. keys, etc. Cryptographic module 295F also sends updates to the local private / public key pair to the remote server.

[0105] FIG. 3A illustrates a flow diagram 300 of a method according to an exemplary embodiment. Referring to FIG. 3A, the exemplary method is performed by a transportation node 205 (see FIG. 2C). It should be understood that the method depicted in FIG. 3A may include additional operations, and that some of the operations described herein may be removed and / or modified without departing from the scope of the present application. Also, the description of method 300 is provided with reference to the functionality depicted in FIG. 2C for illustrative purposes. In particular, processor 204 of node 205 performs some or all of the operations included in method 300.

[0106] 3A, in block 302, processor 204 receives a key and data related to a next event from a server. In block 304, processor 204 verifies the data related to the next event based on current data acquired by the vehicle. In block 306, processor 204 receives a function configured to handle the next event in response to verifying the data related to the next event. In block 308, processor 204 unlocks the function in the vehicle with the key.

[0107] FIG. 3B illustrates another flow diagram 320 of an exemplary method according to an exemplary embodiment. Referring to FIG. 3B, method 320 includes one or more of the following steps: In block 322, processor 204 verifies the key by transmitting data from sensors associated with the vehicle when an event begins to occur. In block 324, processor 204 modifies the key and transmits the modified key and data from sensors associated with the vehicle regarding the occurring event. In block 326, processor 204 modifies the key based on an agreement with the server and receives a function based on data received from sensors associated with the vehicle in response to the server verifying the modified key based on the key. In block 328, processor 204 identifies a next event associated with the key based on vehicle sensor or ECU readings. In block 330, processor 204 modifies the key based on agreement with the server. The agreement constitutes a blockchain consensus between at least the peer represented by the vehicle and the server. In block 332, processor 204 records the key on the blockchain in response to the blockchain consensus.

[0108] 4 illustrates a machine learning vehicle network diagram 400 in accordance with an example embodiment. Network 400 includes vehicle nodes 402 that interface with a machine learning subsystem 406. The vehicle nodes include one or more sensors 404.

[0109] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by a machine learning system 410 that generates predictions by finding patterns in one or more training datasets. In some embodiments, the machine learning subsystem 406 resides within the transportation node 402. In other embodiments, the machine learning subsystem 406 resides outside of the transportation node 402.

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

[0111] In a further embodiment, vehicle node 402 transmits data from one or more sensors 404 to machine learning training system 410. In yet another embodiment, machine learning subsystem 406 transmits data from sensors 404 to machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may utilize machine learning network 400 as described herein.

[0112] FIG. 5A illustrates an exemplary vehicle configuration 500 for managing database transactions related to a vehicle, according to an exemplary embodiment. Referring to FIG. 5A, when a particular vehicle / vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle receives assets 510 and / or expels / transfers assets 512 according to the transaction. A vehicle processor 526 resides within the vehicle 525, and communication exists between the vehicle processor 526 and a database 530, and between the vehicle processor 526 and a transaction module 520. The transaction module 520 records information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, unexpected events, etc. These transactions in the transaction module 520 are replicated in the database 530. Database 530 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle, on-board outside the vehicle, directly accessible to the vehicle, and / or accessible to the vehicle via a network.

[0113] FIG. 5B illustrates an exemplary vehicle configuration 550 for managing database transactions between various vehicles, according to an exemplary embodiment. Vehicle 525 engages another vehicle 508 to perform various actions, such as sharing, transferring, acquiring, or the like, a service call, when the vehicle reaches a state where it needs to share service with another vehicle. For example, vehicle 508 may need to charge its battery and / or may have tire issues and may be on route to pick up a package for delivery. A transportation processor 528 resides within vehicle 508, and communication exists between transportation processor 528 and database 554 and transaction module 552. Vehicle 508 notifies another vehicle 525 that is within its network and operating on its blockchain member services. A transportation processor 526 resides within vehicle 525, and communication exists between transportation processor 526 and database 530 and transaction module 520. Vehicle 525 then receives information to perform the package pickup from vehicle 508 and / or from a server (not shown) via a wireless communication request. The transaction is recorded in transaction modules 552 and 520 of both vehicles. When credits are transferred from vehicle 508 to vehicle 525, a record of the transferred service is recorded in database 530 / 554, assuming the blockchains are different or recorded on the same blockchain used by all members. Database 554 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle, on-board outside the vehicle, directly accessible, and / or accessible over a network.

[0114] FIG. 6A illustrates a blockchain architecture configuration 600 according to an exemplary embodiment. Referring to FIG. 6A, the blockchain architecture 600 includes a group of blockchain member nodes 602-606 as part of a blockchain element, e.g., a blockchain group 610. In one exemplary embodiment, a permissioned blockchain is not accessible to all parties, but only to members who are authorized to access the blockchain data. Blockchain nodes participate in numerous activities, such as the addition and validation process (consensus) of blockchain entries. One or more of the blockchain nodes approve entries based on an endorsement policy and provide ordering services for all blockchain nodes. Blockchain nodes initiate blockchain actions (e.g., authentication) and attempt writes to the blockchain's immutable ledger, a copy of which is also stored on the underlying physical infrastructure.

[0115] Once a transaction is received and approved by the consensus model dictated by the member nodes, the blockchain transaction 620 is stored in the computer's memory. The approved transaction 626 is stored in the blockchain's current block and committed to the blockchain via a commit procedure that involves performing a hash of the transaction's data content in the current block and referencing a previous hash in a previous block. Within the blockchain reside one or more smart contracts 630 that define the terms of the transaction agreement and actions contained in smart contract executable application code 632, such as registered recipients, vehicle capabilities, requirements, permissions, sensor thresholds, etc. The code is configured to identify whether the requesting entity is registered to receive vehicle services, what service features it is entitled to / requested to receive given its profile status, and monitor these actions in subsequent events. For example, when a service event occurs and a user is in the vehicle, monitoring of sensor data is triggered to identify that a certain parameter, such as vehicle charge level, is above / below a certain threshold for a certain period of time, resulting in a change in current status, which necessitates sending an alert to an administrator (i.e., vehicle owner, vehicle operator, server, etc.) so that the service can be identified and stored for reference. The vehicle sensor data collected is based on the type of sensor data used to gather information about the vehicle's status. The sensor data also forms the basis for vehicle event data 634, such as where to go, average speed, maximum speed, acceleration, whether there was a collision, whether the expected route was followed, where the next destination is, whether safety measures have been taken, whether the vehicle has enough charge / fuel, etc. All such information forms the basis for smart contract terms 630, which are then stored on the blockchain.For example, sensor thresholds stored in a smart contract can be used as criteria for whether a detected service is needed and when and where the service should be performed.

[0116] FIG. 6B illustrates a shared ledger configuration according to an example embodiment. Referring to FIG. 6B, an example blockchain logic 640 includes a blockchain application interface 642 as an API or plug-in application that links to computing devices and execution platforms for specific transactions. The blockchain configuration 640 includes one or more applications linked to an application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.) that can be created according to customized configurations desired by participants, and that can maintain their own state, control their own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via an append to the distributed ledger.

[0117] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code, and when the application code is executed, transaction conditions become active. When smart contract 630 is executed, an approved transaction 626 is generated and then transferred to blockchain platform 652. The platform includes security / authentication 658, a computing device 656 that performs transaction management, and a storage unit 654 as memory that stores transactions and smart contracts on the blockchain.

[0118] A blockchain platform includes various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.) and the underlying physical computer infrastructure that are used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain exposes interfaces that provide access to the virtual execution environments necessary to process program code and interact with the physical infrastructure. Cryptographic trust services are used to verify entries, such as asset exchange entries, and keep the information private.

[0119] The blockchain architecture configurations of Figures 6A and 6B process and execute program / application code via one or more interfaces exposed by and services provided by the blockchain platform. As a non-limiting example, smart contracts may be created to implement reminders, updates, and / or other notifications subject to changes, updates, etc. The smart contracts themselves may be used to identify authentication and access requirements and rules associated with ledger usage. For example, information may include new entries processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. Results may include decisions to reject or approve new entries based on criteria defined in the smart contract and / or peer consensus. Physical infrastructure may be utilized to retrieve any of the data or information described herein.

[0120] In a smart contract's executable code, the smart contract is authored via high-level application and programming languages ​​and then written into a block in the blockchain. A smart contract includes executable code that is registered, stored, and / or replicated on the blockchain (e.g., a distributed network of blockchain peers). An entry is an execution of the smart contract code that may be executed in response to a condition associated with the smart contract being met. Execution of the smart contract causes trusted modifications to the state of the digital blockchain ledger. Blockchain ledger modifications resulting from the execution of the smart contract are automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0121] Smart contracts write data to the blockchain in the form of key-value pairs. Additionally, smart contract code can read values ​​stored in the blockchain and use these values ​​in application operations. Smart contract code can write the output of various logical operations into the blockchain. The code is used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be public and / or encrypted and kept private. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and is then deleted once the data needed for the blockchain has been identified.

[0122] The smart contract executable code may include a code interpretation of the smart contract with additional functionality. As described herein, the smart contract executable code is program code deployed on a computing network and executed together and validated by chain validators during the consensus process. The smart contract executable code receives a hash and retrieves a hash from the blockchain associated with a data template created by using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the smart contract executable code sends an authentication key to the requested service. The smart contract executable code may write associated cryptographic details to blockchain data.

[0123] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. Referring to FIG. 6C, exemplary configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., blockchain) 668. The server represents a service provider entity that queries vehicle service providers to share user profile rating information when a known, established user profile seeks to rent a vehicle with an established rating profile. Server 666 receives and processes data regarding the vehicle's service requirements. When a service event occurs, e.g., vehicle sensor data indicates the need for fuel / charging or maintenance service, a smart contract is used to invoke rules, thresholds, sensor information collection, etc., that are used to invoke the 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. The transaction includes the parties, requirements (e.g., age 18, service candidate, valid driver's license, etc.), reward level, distance traveled during the event, registered recipients authorized to access the event and operate vehicle services, rights / permissions, sensor data to be read during operation of the vehicle event to record details of the upcoming service event and identify the vehicle's condition status, and thresholds used to determine whether the service event is completed and whether the vehicle's condition status has changed.

[0124] FIG. 6D illustrates a blockchain block 680 and the contents of block structures 682A-682n that can be added to a distributed ledger, according to an example embodiment. Referring to FIG. 6D, a client (not shown) submits entries to a blockchain node to perform an activity on the blockchain. As an example, a client is an application acting on behalf of a requester, such as a device, person, or entity, that proposes an entry in the blockchain. Multiple blockchain peers (e.g., blockchain nodes) maintain a copy of the blockchain network state and the distributed ledger. Various types of blockchain nodes / peers exist in a blockchain network, including endorsing peers that simulate and approve entries proposed by clients, and committing peers that verify the approvals, validate the entries, and commit the entries to the distributed ledger. In this example, a blockchain node may act as an endorser node, a committer node, or both.

[0125] The system includes a blockchain that stores immutable, ordered records in blocks and a state database (current world state) that maintains the current state of the blockchain. There is one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel in which it is a member. The blockchain is an entry log structured as hash-linked blocks, with each block containing a sequence of N entries. Blocks include various components, such as those shown in Figure 6D. Block links are generated by appending the hash of the previous block's header to the current block's block header. In this way, all entries on the blockchain are ordered and cryptographically linked, which prevents tampering with blockchain data without breaking the hash links. Furthermore, the links ensure that the most recent block in the blockchain represents all entries that came before it. The blockchain is stored in a peer file system (local or attached storage) that supports append-only blockchain workloads.

[0126] The current state of the blockchain and distributed ledger is stored in a state database, where the current state data represents the most recent values ​​for all keys contained in the blockchain's on-chain entry log. Invocations of smart contract executable code execute entries against the current state of the state database. To make the interaction of these smart contract executable codes highly efficient, the most recent values ​​for all keys are stored in the state database. Because the state database contains an indexed view into the blockchain's entry log, it can be regenerated off-chain at any time. The state database is automatically restored (or generated if necessary) at peer startup, before entries are accepted.

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

[0128] The ordering service accepts approved entries, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service initiates a new block when a threshold number of entries is reached, a timer times out, or another condition is met. In this example, a blockchain node is a committing peer that received data block 682A for storage on the blockchain. The ordering service consists of a cluster of orderers. The ordering service does not process entries and smart contracts or maintain a shared ledger. Rather, the ordering service accepts approved entries and specifies the order in which these entries are committed to the distributed ledger. The architecture of the blockchain network is designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

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

[0130] Referring to FIG. 6D , a block 682A (also referred to as a data block) stored in a blockchain and / or distributed ledger includes multiple data segments, such as block headers 684A-684n, transaction-specific data 686A-686n, and block metadata 688A-688n. It should be understood that the various depicted blocks and their contents, e.g., block 682A and its contents, are for illustrative purposes only and are not meant to limit the scope of the illustrative embodiments. In some cases, both the block header 684A and block metadata 688A may be smaller than the transaction-specific data 686A, which stores entry data, although this is not a requirement. Block 682A stores transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) in block data 690A-690n. Block 682A also includes a link to a previous block (e.g., on the blockchain) in block header 684A. In particular, block header 684A includes a hash of the previous block's header. The block header 684A also includes a unique block number, a hash of the block data 690A of the current block 682A, etc. The block numbers of the blocks 682A are unique and assigned in incremental / sequential order starting from zero. The first block in a blockchain is sometimes called the genesis block and contains information about the blockchain, its members, the data stored in the blockchain, etc.

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

[0132] In some embodiments, block data 690A also stores transaction-specific data 686A, which adds additional information to the hash-linked chain of blocks in the blockchain. Thus, data 686A can be stored in an immutable log of blocks on a distributed ledger. Several advantages of storing such data 686A are reflected in various embodiments disclosed and depicted herein. Block metadata 688A stores multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields include a signature at the time of block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, and the last persisted offset of the ordering service that ordered the block. The signature, last constituent block, and orderer metadata are added by the ordering service. Meanwhile, the block committer (e.g., a blockchain node) adds valid / invalid information based on endorsement policies, validation of read / write sets, etc. The entry filter includes a byte array with a size equal to the number of entries in block data 610A and a validation code that identifies whether the entry was valid or invalid.

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

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

[0135] An exemplary storage medium is coupled to the processor such that the processor reads information from and writes information to the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and storage medium may reside in an application specific integrated circuit ("ASIC"). Alternatively, the processor and storage medium may reside as separate components. For example, FIG. 7 shows an exemplary computer system architecture 700 that represents or is integrated with any of the components described above.

[0136] 7 is not intended to suggest any limitation regarding the scope of use or functionality of the application embodiments described herein, although computing node 700 may nonetheless implement and / or perform any of the functionality described above.

[0137] Computing node 700 may include computer system / server 702 operating in 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, thick clients, handheld devices, laptop devices, multiprocessor systems, multiprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of these systems or devices.

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

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

[0140] A bus may represent any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example and not limitation, an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0141] The computer system / server 702 typically includes a variety of computer system-readable media. Such media may be any available media accessible by the computer system / server 702, including both volatile and nonvolatile, removable and non-removable media. In one embodiment, the system memory 706 implements the flow diagrams of other figures. The system memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. The computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the memory 706 is provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In such cases, each is connected to the bus by one or more data medium interfaces. As further depicted and explained below, memory 706 includes at least one program product having a set (e.g., at least one) program module configured to perform the functions of various embodiments of the application.

[0142] A program / utility having a set (at least one) program module is stored in memory 706, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, comprises an implementation of a network environment. The program modules generally perform the functions and / or methodologies of various embodiments of the applications as described herein.

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

[0144] Additionally, the computer system / server 702 communicates with one or more external devices via I / O devices 712 (such as I / O adapters), which may include one or more devices that allow a user to interact with the computer system / server 702, such as a keyboard, pointing device, display, voice recognition module, etc., and / or any device (e.g., network card, modem, etc.) that allows the computer system / server 702 to communicate with one or more computing devices. Such communication occurs through the device's I / O interface 712. Nevertheless, the computer system / server 702 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter. As depicted, the device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that other hardware and / or software components, not shown, may be used with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives and data archive storage systems.

[0145] While at least one exemplary embodiment of the system, method, and non-transitory computer-readable medium has been illustrated in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but rather is capable of numerous rearrangements, modifications, and substitutions, as defined by the following claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein or in a distributed architecture, including pairs of transmitters, receivers, or both. For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Furthermore, the functionality described herein may be performed at various times and in conjunction with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or multiple protocols. Furthermore, messages transmitted or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0146] 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 other suitable computing device, or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in localized and distributed fashions consistent with computing technology.

[0147] It should be noted that some of the system functionality described herein has been presented as modules to emphasize implementation independence. For example, a module may 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 may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0148] Also, modules may be implemented at least partially in software for execution by various types of processors. An identified unit of executable code comprises one or more physical or logical blocks of computer instructions organized, for example, as an object, procedure, or function. Nevertheless, the executable files of an identified module need not be physically located together, but may include heterogeneous instructions stored in different locations that, when logically combined, constitute the module and achieve the module's predetermined purpose. Furthermore, modules may be stored on a computer-readable medium, for example, a hard disk drive, a flash device, a random access memory (RAM), a tape, or any other such medium used to store data.

[0149] In practice, a module of executable code may be a single instruction or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data is identified and illustrated herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set, distributed in different locations, including different storage devices, or exist at least in part solely as electronic signals over a system or network.

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

[0151] Those skilled in the art will readily appreciate that the above can be implemented using a different order of steps and / or using hardware elements in different configurations than those disclosed. Thus, while the present application has been described in terms of these preferred embodiments, certain modifications, variations, and alternative configurations will be apparent to those skilled in the art.

[0152] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely exemplary, and that the scope of the present application should be defined solely by the appended claims when considering the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. receiving, at the vehicle, from a server, a key and data associated with a next event; verifying, by the vehicle, the data related to the upcoming event based on current data acquired by the vehicle; receiving, in response to verifying the data related to the upcoming event, functionality configured to address the upcoming event at the vehicle; unlocking the functionality on the vehicle with the key; and A method comprising:

2. The method of claim 1 , wherein the verifying includes transmitting, by the vehicle, data from a sensor associated with the vehicle when the event begins to occur.

3. modifying the key by the vehicle; transmitting, by the vehicle, the modified key and data from sensors associated with the vehicle regarding the event occurring; The method of claim 1 , comprising:

4. modifying the key in accordance with an agreement with the server; receiving, at the vehicle, the function based on the data received from the sensor associated with the vehicle in response to verifying the modified key based on the key at the server; The method of claim 3, comprising:

5. The method of claim 1 , comprising determining the next event associated with the key based on a sensor or ECU reading of the vehicle.

6. 10. The method of claim 1, further comprising: modifying the key based on an agreement with the server, the agreement constituting a blockchain consensus between at least a peer represented by the transportation facility and the server.

7. 10. The method of claim 6, further comprising executing a smart contract to record the modified key on a blockchain in response to the blockchain consensus.

8. a transportation processor; A memory containing machine-readable instructions; A system comprising: The machine-readable instructions, when executed by the processor, cause the processor to: receiving a key and data associated with a next event from a server; verifying the data related to the next event based on current data obtained by a processor of the vehicle; receiving a function configured to address the upcoming event in response to verifying the data related to the upcoming event; unlocking the functionality on the vehicle with the key; and A system that executes the following.

9. The system of claim 8 , wherein the validation includes data from a sensor associated with the vehicle that is transmitted when the event begins to occur.

10. 10. The system of claim 8, wherein the instructions further cause the processor to modify the key and transmit the modified key and data from a sensor associated with the vehicle regarding the event occurring.

11. 9. The system of claim 8, wherein the instructions further cause the processor to modify the key based on an agreement with the server, and receive the function based on the data received from the sensor associated with the vehicle in response to verification of the modified key based on the key at the server.

12. The system of claim 8 , wherein the instructions further cause the processor to ascertain the next event associated with the key based on a sensor or ECU reading of the vehicle.

13. 10. The system of claim 8, wherein the instructions further cause the processor to modify the key based on an agreement with the server, the agreement constituting a blockchain consensus between at least a peer represented by the vehicle and the server.

14. 14. The system of claim 13, wherein the instructions further cause the processor to execute a smart contract to record the key on a blockchain in response to the blockchain consensus.

15. A non-transitory computer-readable medium containing instructions, The instructions, when loaded by a processor, cause the processor to: receiving a key and data associated with a next event from a server; validating the data related to the upcoming event based on current data acquired by a vehicle; receiving a function configured to address the upcoming event in response to verifying the data related to the upcoming event; unlocking the functionality on the vehicle with the key; and A non-transitory computer-readable medium for causing the execution of

16. The non-transitory computer-readable medium of claim 15 , wherein the verifying includes transmitting data from a sensor associated with the vehicle when the event begins to occur.

17. 16. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when loaded by a processor, cause the processor to modify the key and transmit the modified key and data from a sensor associated with the vehicle regarding the event occurring.

18. 16. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when loaded by a processor, cause the processor to modify the key based on an agreement with the server and, in response to verification of the modified key based on the key at the server, receive the function based on the data received from the sensor associated with the vehicle.

19. 16. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when loaded by a processor, cause the processor to modify the key based on an agreement with the server, the agreement constituting a blockchain consensus between at least a peer represented by the vehicle and the server.

20. 20. The non-transitory computer-readable medium of claim 19, further comprising instructions that, when loaded by a processor, cause the processor to execute a smart contract to record the key on a blockchain in response to the blockchain consensus.

Images