Providing an external function for a vehicle

Abstract

Example operations include one or more of the following: receiving, at a vehicle, data and a key associated with an upcoming event from a server; verifying, by the vehicle, the data associated with the upcoming event based on current data acquired by the vehicle; receiving, at the vehicle, functionality configured to address the upcoming event in response to verification of the data associated with the upcoming event; and unlocking the functionality on the vehicle through the key.

Description

Background Technology

[0001] Vehicles or means of transport, such as cars, motorcycles, trucks, airplanes, and trains, typically provide transportation services to passengers and / or goods in various ways. Functions associated with these means of transport can be identified and utilized by various computing devices, such as smartphones or computers located on or outside the vehicle. Summary of the Invention

[0002] One example embodiment provides a method comprising: at a means of transport, receiving data and a key associated with an upcoming event from a server; verifying the data associated with the upcoming event by the means of transport based on current data acquired by the means of transport; in response to the verification of the data associated with the upcoming event, receiving at the means of transport a function configured to respond to the upcoming event; and unlocking the function on the means of transport using the key.

[0003] Another example embodiment provides a system including: a memory communicatively coupled to a processor, wherein the processor performs one or more of the following: receiving data and a key associated with an upcoming event from a server; verifying the data associated with the upcoming event based on current data acquired by the vehicle; receiving, in response to the verification of the data associated with the upcoming event, a function configured to respond to the upcoming event; and unlocking the function on the vehicle using the key.

[0004] Other example embodiments provide a non-transient computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following steps: receiving data and a key associated with an upcoming event from a server; verifying the data associated with the upcoming event based on current data acquired by a vehicle; receiving functionality configured to respond to the upcoming event in response to the verification of the data associated with the upcoming event; and unlocking functionality on the vehicle using the key. Attached Figure Description

[0005] Figure 1A An example of data flow in a transportation network according to an exemplary embodiment is illustrated.

[0006] Figure 1B The illustration shows another example data flow in a transportation network according to an example embodiment.

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

[0008] Figure 2B Another transportation network diagram according to an example embodiment is illustrated.

[0009] Figure 2C Another transportation network diagram according to an example embodiment is illustrated.

[0010] Figure 2D Another transportation network diagram according to an example embodiment is illustrated.

[0011] Figure 2E Another transportation network diagram according to an example embodiment is illustrated.

[0012] Figure 2F The illustration depicts the electrification of one or more elements according to an example embodiment.

[0013] Figure 2G The illustration depicts the interconnection between different elements according to an example embodiment.

[0014] Figure 2H Another diagram illustrating the interconnection between different elements according to an example embodiment is shown.

[0015] Figure 2I Another diagram illustrating the interconnection between depicting elements according to an example embodiment is shown.

[0016] Figure 2J Another diagram illustrating a keyless access system according to an example embodiment is shown.

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

[0018] Figure 2L Another diagram depicting an end-to-end communication channel according to an example embodiment is shown.

[0019] Figure 2M Another illustration is shown, according to an example embodiment, depicting a vehicle performing secure V2V communication using a security certificate.

[0020] Figure 2N Another illustration is shown, depicting an example of a vehicle interacting with a security processor and a wireless device according to an example embodiment.

[0021] Figure 3A A flowchart according to an example embodiment is illustrated.

[0022] Figure 3B Another flowchart according to an example embodiment is illustrated.

[0023] Figure 4 The diagram illustrates a machine learning transportation network according to an example embodiment.

[0024] Figure 5A The illustration shows an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

[0025] Figure 5B The illustration shows another example vehicle configuration for managing database transactions between various vehicles, according to an example embodiment.

[0026] Figure 6A The diagram illustrates a blockchain architecture configuration according to an example embodiment.

[0027] Figure 6B Another blockchain configuration according to an example embodiment is illustrated.

[0028] Figure 6C The illustration shows a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0029] Figure 6D An example data block according to an example embodiment is illustrated.

[0030] Figure 7 An example system supporting one or more of the example embodiments is illustrated. Detailed Implementation

[0031] As will be readily understood, as generally described and illustrated in the accompanying drawings, this component can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transient computer-readable media, and systems presented in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments.

[0032] Communication between a vehicle and entities such as remote servers, other vehicles, and local computing devices (e.g., smartphones, personal computers, embedded computers in the vehicle), can be sent and / or received and processed by one or more “components,” which may be hardware, firmware, software, or a combination thereof. A component may be part of any of these entities or computing devices or other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components associated with the vehicle (which may be any element described and / or depicted herein) and one or more components located outside or remotely from the vehicle.

[0033] The features, structures, or characteristics described throughout this specification can be combined in one or more embodiments in any suitable manner. For example, the use of phrases such as “example embodiment,” “some embodiments,” or other similar language in this specification refers to the fact that a particular feature, structure, or characteristic described in connection with that embodiment can be included in at least one embodiment. Therefore, the appearance of phrases such as “example embodiment,” “some embodiments,” “other embodiments,” or other similar language throughout this specification does not necessarily refer to the same set of embodiments, but rather that the described features, structures, or characteristics can be combined in one or more embodiments in any suitable manner. In the figures, even if the depicted connections are unidirectional or bidirectional arrows, any connection between elements may permit unidirectional and / or bidirectional communication. In the present solution, the means of transportation may include one or more of automobiles, trucks, battery electric vehicles (BEVs) for pedestrian zones, e-Palettes, fuel cell buses, motorcycles, scooters, bicycles, ships, recreational vehicles, aircraft, and any object that can be used to transport people and / or goods from one location to another.

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

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

[0036] Within a communication infrastructure, a decentralized database is a distributed storage system comprising multiple nodes that communicate with each other. A blockchain is an example of a decentralized database, comprising an append-only immutable data structure (i.e., a distributed ledger) capable of maintaining records between distrustful parties. These distrustful parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record until consensus is reached among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage entries, group storage entries into blocks, and construct a hash chain via blocks. For consistency, this process forms the ledger by ordering storage entries as necessary. In public or permissionless blockchains, anyone can participate without specific identification. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). Conversely, permissioned blockchain databases can ensure interactions between a group of entities that share a common goal but do not trust or cannot fully trust each other, such as in commerce involving the exchange of funds, goods, information, etc. This solution can work in permissioned and / or permissionless blockchain settings.

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

[0038] A node is a communication entity in a blockchain system. In the sense that multiple nodes of different types can run on the same physical server, a "node" can perform logical functions. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as clients or committing client nodes that submit entry requests to endorsers (e.g., peers) and broadcast entry suggestions to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit those entries, and maintain the state and copy of the blockchain entries in the ledger. Peers can also act as endorsers. Ordering service nodes or ordering parties are nodes that run communication services for all nodes and implement delivery guarantees such as broadcasting to every peer in the system when an entry is submitted and the world state of the blockchain is modified. The world state can constitute the initial blockchain entries, which typically include control and setup information.

[0039] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be caused by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs being committed to the ledger as one or more operands such as create, update, delete, etc. The ledger includes a blockchain (also known as a chain) used to store immutable, sequential records in blocks. The ledger also includes a state database that keeps track of the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for each channel in which it is a member.

[0040] A chain is a log of entries constructed as hashed linked blocks, with each block containing a sequence of N entries, where N is equal to or greater than 1. The block header includes the hashes of the block's entries and the hashes of the headers of previous blocks. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, the ledger data cannot be tampered with without breaking the hash chain. The hash of the most recently added blockchain block represents every entry on the chain that came before it, ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer-to-peer file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0041] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain's entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes referred to as the world state. Smart contract executables invoke entries by referring to the ledger's current state data. To make these smart contract executables interact efficiently, the latest values ​​of the keys can be stored in a state database. The state database can be simply an indexed view of the chain's entry log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored after peer startup but before entries are accepted (or generated when needed).

[0042] The difference between blockchain and traditional databases is that blockchain is not a central storage device, but a decentralized, immutable, and secure storage device, in which nodes must share changes to the records stored on the device. Some inherent properties of blockchain that help enable it include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0043] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. Vehicles may require service at certain intervals, and service requests may require authorization before being authorized to receive service. Additionally, service centers may provide services to vehicles in a nearby area based on the vehicle's current route plan and relative service level requirements (e.g., immediate, severe, intermediate, minor, etc.). Vehicle demand may be monitored via one or more vehicle and / or road sensors or cameras, which report the sensed data to a central controller computer device located inside and / or separately from the vehicle. This data is forwarded to a management server for viewing and action. Sensors may be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object separate from the vehicle, or on another vehicle nearby. Sensors may also be associated with the vehicle's speed, braking, acceleration, fuel level, service demand, gear shifting, steering, etc. As described herein, sensors may also be devices such as wireless devices located in and / or near the vehicle. Additionally, sensor information can be used to identify whether a vehicle is operating safely and whether occupants have been involved in any unforeseen vehicle situations (such as during vehicle entry, exit, and / or usage periods). Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to the immutable ledger in a “decentralized” manner (such as via a blockchain membership group), as determined by a licensed consortium.

[0044] Each stakeholder (i.e., owner, user, company, agent, etc.) may wish to restrict the disclosure of private information; therefore, blockchain and its immutability can be used to manage the licensing of each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / checks, apply vehicle event licenses, determine when service is needed, identify collisions and / or degradation events, identify safety hazard issues, identify event participants, and distribute the data to registered entities seeking access to such vehicle event data. Furthermore, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on consensus methods associated with the blockchain. This approach cannot be implemented on traditional centralized databases.

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

[0046] In some embodiments, this solution includes authorizing the service to the vehicle via an automated and rapid authentication scheme. For example, the vehicle operator or autonomous vehicle may drive to a charging station or fuel pump, and if the service and / or charging station receives authorization, authorization to receive electricity or fuel can be performed without any delay. The vehicle may provide a communication signal providing an identifier of the vehicle with a current activity profile linked to the authorized account receiving the service, which can later be corrected through compensation. Additional measures may be used to provide further authentication, such as wirelessly sending another identifier from the user's device to the service center to replace or supplement the initial authorization work between the vehicle and the service center with additional authorization work.

[0047] Shared and received data can be stored in a database that keeps the data in a single location (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database is typically accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, especially for security purposes, due to their single location. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a given set of data has only one master record. Blockchain can be used to store data and transactions related to transportation vehicles.

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

[0049] In one embodiment, a solution is provided for providing external functionality to a vehicle. A trusted execution environment (TEE) for the vehicle can be used to dynamically process keys and unlock additional functionality received from a server (such as a cloud server) or inactive functionality present on the vehicle. The TEE can be provided by a vehicle processor connected to the vehicle components. The TEE within the vehicle is implemented through secure, encrypted communication (i.e., encrypted data exchange) between the vehicle processor, ECU, and all vehicle components.

[0050] Cloud servers can acquire information about events that may soon occur in the driving environment of a vehicle. For example, a cloud server can receive data on upcoming changes in the driving environment, such as heavy rain, snow, slippery roads, icing, fog, traffic, and accidents, from weather-related data sources (such as via the internet), data sources containing traffic information, weather maps, or other sources (such as GPS and road maps). Cloud servers can also identify upcoming events, including changes in driving surfaces (e.g., from asphalt to dirt roads, gravel roads, single-lane roads, etc.), by analyzing received data from sources such as mapping data sources. These events may require the activation of additional functions on the vehicle. Therefore, the cloud server can send a key along with information about the upcoming events to the vehicle. The vehicle verifies that the key and functions originate from a trusted source. In cases where the cloud server cannot be authenticated, the vehicle's processor can perform error handling to determine the reason for the lack of authorization. To authenticate the cloud server, the vehicle can use readings from its ECU and sensors to confirm the received data on upcoming events. For example, the ECU can provide data indicating changes in traction or gas consumption, and sensors can provide data indicating changes in external temperature and humidity. The processor can analyze this information to confirm events such as rain or snow provided by the cloud server. For example, high humidity and low outdoor temperatures, along with increased gas consumption and traction changes, may confirm that snowfall is about to begin. In one embodiment, the vehicle can authenticate the server by obtaining data from other vehicles connected through the transportation network to confirm the upcoming event. The current vehicle can query connected vehicles based on the GPS location of connected vehicles traveling before the current vehicle (towards the upcoming event, etc.) to confirm the event using the ECU readings of the connected vehicles. The content of the message from the cloud server can be verified by the current vehicle's processor based on the ECU / sensor readings of the current vehicle or the ECU / sensor readings of connected vehicles at the time before the event or when the upcoming event begins. For example, if the ECU / sensor readings indicate that snowfall is beginning (or will begin), the event data indicating snowfall provided by the cloud server is confirmed by the vehicle's processor. Once the event is confirmed, the vehicle processor can unlock (using a key received from the cloud server) and can perform functions when the upcoming event begins (or shortly before the event). For example, software patches (or updates) can be installed on vehicles to trigger features such as enhanced traction control, enhanced anti-lock braking systems, torque distribution between the four wheels, activation of all-wheel drive, activation of fog lights, activation of additional heated windows, adjustment of fuel injection, or other functions.In one embodiment, a key received from a cloud server can temporarily unlock existing functions not activated on a particular model of vehicle during the duration of the event. The handling of upcoming events is performed automatically and can be implemented on both autonomous and human-driven vehicles. Alternatively, the vehicle can use the key to unlock functions received from another vehicle connected to the cloud server via a secure network connection. Similarly, upon receiving a protocol from a cloud server connected to the vehicle via the transportation network, the vehicle can share functions and keys with another vehicle connected via the transportation network. In one embodiment, the key and functions are removed from the vehicle upon completion of the event. Therefore, it is advantageous that the vehicle remains without any keys stored on it most of the time.

[0051] Figure 1AAn example of data flow in a transportation network 100 according to an exemplary embodiment is illustrated. A TEE 130 of a transportation vehicle node may have a processor communicatively connected to a server 110. In block 101, the server 110 may generate a temporary key. The server 110 may then send the temporary key along with upcoming event information to the transportation vehicle TEE 130. In block 131, the transportation vehicle TEE 130 may confirm the upcoming event information based on readings from the transportation vehicle ECU and / or transportation vehicle sensors. If the upcoming event is confirmed in block 133, the temporary key is stored on the transportation vehicle in block 134. Otherwise, the process ends, and the transportation vehicle does not request additional functionality from the server 110. In block 135, the TEE 130 may modify the temporary key based on a protocol with the server 110. Then, in block 136, the TEE 130 may acquire current data from the transportation vehicle ECU and / or transportation vehicle sensors. The current data may be sent to the server 110 along with the modified temporary key. In box 102, server 110 can verify the modified temporary key based on the temporary key generated in box 101. Since the modified key is a derived key of the temporary key (i.e., the parent key), it can be verified by the parent key. If the verification of the modified key in box 102 is successful, server 110 can send a function based on the current data provided by TEE 130. As discussed above, the function may include software patches (or updates) that can be sent to the vehicle to trigger features such as enhanced traction control, enhanced anti-lock braking system, torque distribution between the four wheels, activation of all-wheel drive, activation of fog lights, activation of additional window defrosting, fuel injection adjustment, or other ECU functions. The function is based on conditions such as rain, snow, icing, fog, traffic congestion, or changes in road surface type or an accident ahead. In box 137, the function is stored in the vehicle's TEE 130 and executed by the vehicle processor to modify the operation of the implemented vehicle components. As discussed above, in box 139, based on the protocol from server 110, the function and key can be sent to other means of transport. After the event is completed, in box 138, the function and modified key can be removed from the TEE 130 of the means of transport.

[0052] Figure 1BOther example data flows in the transportation network 150 according to an example embodiment are illustrated. As discussed above, cloud server 120 can obtain information about events that will occur in the driving environment of vehicle 151. For example, cloud server 120 can receive data from weather maps and / or other sources (e.g., GPS and road maps) about upcoming events including changes in the driving environment such as heavy rain, snow, slippery roads, icing, fog, traffic, accidents, etc. Cloud server 120 can also identify upcoming events including changes in driving surfaces (e.g., changes from asphalt to dirt roads, gravel roads, single-lane roads, etc.). These events may require the activation of additional functions at vehicle 151. Therefore, cloud server 120 can send key 115 along with information about the upcoming events (not shown) to vehicle 151. Vehicle 151 verifies that key 115 and the functionality are from a trusted source. To authenticate cloud server 120, vehicle 151 can use readings from its ECU and sensors to confirm the received upcoming event data. For example, the ECU can provide data indicating changes in traction or gas consumption, and the sensors of vehicle 151 can provide data indicating changes in external temperature and humidity. This information can confirm events such as rain or snow provided by cloud server 120. In one embodiment, the vehicle can authenticate the server by obtaining data from other vehicles 152 traveling ahead of the current vehicle (towards the upcoming event, etc.) to confirm the upcoming event. The content of the message from cloud server 120 can be verified either before the event or when the upcoming event begins. Once the event is confirmed, the vehicle 151 processor can use the key 115 received from cloud server 120 to unlock and perform functions based on functional data 116 provided by server 120 when the upcoming event begins (or shortly before the event). For example, a software patch (or update) can be installed on the vehicle to trigger functions such as enhanced traction control, enhanced anti-lock braking system, torque distribution between the four wheels, activation of all-wheel drive, activation of fog lights, activation of additional window heating, fuel injection adjustment, or other ECU functions. In one embodiment, the key 115 received from cloud server 120 can temporarily unlock existing functions that are not enabled on a particular model of vehicle 151 during the duration of the event. According to an exemplary embodiment, the handling of upcoming events is performed automatically and can be implemented on both autonomous and human-driven vehicles. Alternatively, vehicle 151 can use key 115 to unlock functional data 116 received from another vehicle 152 connected to cloud server 120 via a secure network connection. Similarly, upon receiving protocol 118 from cloud server 120, vehicle 151 can share functional data 116 and key 115 with another vehicle 152.Upon completion of the event, key 115 and functional data 116 are removed from vehicles 151 and 152. Therefore, advantageously, the vehicles remain unused most of the time.

[0053] In one embodiment, a protocol for modifying (or sharing) key 115 may be received from cloud server 120, explicitly agreeing to the modification of key 115 by vehicle 151. Vehicle 151 may send a consent request to cloud server 120 before modifying key 115. Vehicle 151 and cloud server 120 may be connected via a blockchain network. The protocol for modifying key 115 may constitute a blockchain consensus at least between the peer node represented by vehicle 151 and the cloud server 120 node. In some embodiments, blockchain consensus may include consent from other blockchain nodes (e.g., an intermediary server, another vehicle 152, etc.). The modified key 115 may be recorded together on the blockchain for future reference when executing smart contracts. Trusted blockchain peer nodes (e.g., vehicle 152) may access the modified key 115 from the blockchain ledger.

[0054] Figure 2A A diagram 200 illustrating a transportation network according to an example embodiment is shown. The network includes elements including a transportation node 202 containing a processor 204 and a transportation node 202' containing a processor 204'. Transportation nodes 202, 202' communicate with each other via processors 204, 204' and other elements (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and their elements (including one or more of processors, memory, and software). Although depicted as a single transportation node and processor, multiple transportation nodes and processors may exist. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by this element.

[0055] Figure 2BA further transportation network diagram 210 according to an example embodiment is illustrated. This network includes components including a transportation node 202 containing a processor 204 and a transportation node 202' containing a processor 204'. Transportation nodes 202, 202' communicate with each other via processors 204, 204' and other components (not shown) including transceivers, transmitters, receivers, storage devices, sensors, and other components capable of providing communication. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and components (including one or more of processors, memory, and software). Processors 204, 204' can also communicate with one or more components 230, including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, transportation nodes 222, computers 224, I / O devices 226, and voice applications 228. Processors 204, 204' can also communicate with one or more of the following components: processor, memory, and software.

[0056] Although depicted as a single transportation node, processor, and element, multiple transportation nodes, processors, and elements may exist. Information or communication may occur to and / or from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide processor 204 with information that can initiate action by transportation node 202, and may also provide processor 204' with information or data that can initiate action by transportation node 202', and may also provide information 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 this element.

[0057] Figure 2C The illustration shows another transport network diagram 240 according to an example embodiment. This network includes elements, including nodes 205 containing a processor 204 and a non-transient computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and element 230 (in...). Figure 2B (As depicted in the text). Node 205 can be a transport vehicle that includes a processor and memory.

[0058] Although this example describes only one transportation node 205 in detail, multiple such nodes can be connected to element 230. It should be understood that transportation node 205 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of this application. Node 205 may be or include computing devices or server computers, etc., and may include 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. Although 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 this application.

[0059] Node 205 may also include a non-transient computer-readable medium 242C on which machine-readable instructions executable by processor 204 may be stored. Examples of machine-readable instructions are shown as 244C to 249C and are discussed further below. Examples of the non-transient computer-readable medium 242C may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transient computer-readable medium 242C may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices. The processor and / or computer-readable medium may reside wholly or partially inside or outside a vehicle node such as node 205. Steps or features stored in the computer-readable medium may be executed wholly or partially by any processor and / or element in any order.

[0060] Processor 204 can execute machine-readable instructions 244C to receive data and keys associated with an upcoming event from the server. Processor 204 can execute machine-readable instructions 246C to verify the data associated with the upcoming event based on current data acquired by the vehicle. Processor 204 can execute machine-readable instructions 248C to receive functionality configured to respond to the upcoming event in response to the verification of the data associated with the upcoming event. Processor 204 can execute machine-readable instructions 249C to unlock functionality on the vehicle using a key. The processor and / or computer-readable medium 242C can reside wholly or partially inside or outside the vehicle node. Additionally, one or more steps or features can be added, omitted, combined, executed at a later time, etc.

[0061] Figure 2DFigure 250 illustrates another transportation network according to an example embodiment. This network includes elements, including a transportation node 205 containing a processor 204 and a non-transient computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and element 230 (in...). Figure 2B (Depicted in the image). The vehicle node 205 includes a processor and memory. The processor 204 can execute one or more of machine-readable instructions 244D to 250D. The processor 204 can execute machine-readable instruction 244D to verify a key and an upcoming event by sending data from sensors associated with the vehicle at the start of an event. The processor 204 can execute machine-readable instruction 246D to modify the key and send the modified key and data related to the ongoing event from sensors associated with the vehicle. The processor 204 can execute machine-readable instruction 248D to modify the key based on a protocol with a server, and in response to verification of the modified key at the server based on the key pair, receive data at the vehicle based on data received from sensors associated with the vehicle. The processor 204 can execute machine-readable instruction 250D to confirm an upcoming event associated with the key based on sensor or ECU readings of the vehicle. The processor and / or computer-readable medium 242D may reside wholly or partially inside or outside the vehicle node. The steps or features stored in the computer-readable medium 242D can be executed, in whole or in part, by any of the processors and / or elements in any order.

[0062] Figure 2E Another transportation network diagram 260 according to an example embodiment is illustrated. (Refer to...) Figure 2E Network diagram 260 includes node 205 connected to server 210 and another transportation node 202' via blockchain network 206. Transportation nodes 202 and 202' can represent transportation vehicles. Blockchain network 206 can have a ledger 208 for recording keys.

[0063] Although this example describes only one node 205 in detail, multiple such nodes can be connected to block 206. It should be understood that node 205 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of this application. Node 205 may have a computing device or server computer, etc., and may include a processor 204, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or another hardware device. Although 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 this application. Node 205 may be a vehicle, server, or any device including a processor and memory.

[0064] Processor 204 can execute one or more of machine-readable instructions 244E to 246E. Processor 204 can execute machine-readable instruction 244E to modify the key based on a protocol with server 210, wherein the protocol constitutes blockchain consensus at least between the peer represented by vehicle node 205 and server 210. Processor 204 can execute machine-readable instruction 246E to execute a smart contract to record the key on blockchain 206 in response to blockchain consensus.

[0065] The processor and / or computer-readable medium 242E may reside wholly or partially inside or outside the transport node. Steps or features stored in the computer-readable medium 242E may be executed wholly or partially by any of the processors and / or elements in any order. Furthermore, one or more steps or features may be added, omitted, combined, executed at a later time, etc.

[0066] Figure 2FA diagram 265 illustrates the electrification of one or more components. In one embodiment, a vehicle 266 can supply power stored in its battery to one or more components, including other vehicles 268, charging stations 270, and a power grid 272. The power grid 272 is coupled to one or more charging stations 270, which may be coupled to one or more vehicles 268. This configuration enables the distribution of power / energy received from the vehicle 266. The vehicle 266 can also interact with other vehicles 268, for example, via vehicle-to-vehicle (V2V) technology, cellular communication, WiFi, etc. The vehicle 266 can also interact wirelessly and / or wiredly with other vehicles 268, charging stations 270, and / or the power grid 272. In one embodiment, the vehicle 266 is routed (or routes itself) to the power grid 272, charging stations 270, or other vehicles 268 in a secure and efficient manner. Using one or more embodiments of this solution, the vehicle 266 can supply power to one or more of the components depicted herein in various advantageous manners as described and / or illustrated herein. Furthermore, as described and / or depicted in this article, the safety and efficiency of transportation can be improved, and the environment can be positively impacted.

[0067] The term "energy" can be used to refer to any form of energy received, stored, used, shared, and / or lost by a means of transport. During charging / use operations, energy can refer to energy in conjunction with a voltage source and / or current supply of electrical energy provided from an entity to the means of transport. Energy can also be in the form of fossil fuels (e.g., for use in hybrid means of transport) or by means of alternative power sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy, and energy generated in flight during energy sharing and / or use operations to increase or decrease one or more transport energy levels at a given time.

[0068] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 such that sufficient charge remains in vehicle 266 to reach its destination. In one embodiment, a wireless connection is used to wirelessly guide the amount of energy transferred between vehicles 268, where both vehicles may be in motion. In one embodiment, a stationary vehicle, such as vehicle 266 (which may be autonomous), is guided to provide a certain amount of energy to charging station 270 and return to its original location (e.g., its original location or a different destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect surplus energy from at least one other vehicle 268 and transfer the stored surplus energy to charging station 270. In one embodiment, various factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), occupant schedules while the vehicle is in use, and expected occupant schedules while waiting for the vehicle determine the amount of energy to be transferred to charging station 270. In one embodiment, vehicle 268, charging station 270, and / or power grid 272 may provide energy to vehicle 266.

[0069] In one embodiment, the solution described and depicted herein can be used to determine the load effect on the vehicle and / or system, provide energy to the vehicle and / or system based on future needs and / or priorities, and provide intelligence between the device containing the module and the vehicle, enabling the device's processor to wirelessly communicate with the vehicle regarding the amount of energy stored in the vehicle's battery. In one embodiment, the solution can also be used to provide charging from the vehicle to a location based on factors such as temperature at the location, energy cost, and power level at the location. In one embodiment, the solution can also be used 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 used to instruct the vehicle to provide a certain amount of energy from the vehicle's battery, wherein the amount of energy to be transferred is based on the distance from the vehicle to the module for receiving the energy.

[0070] In one embodiment, the solution may also utilize a mobile energy storage unit that travels along a determined path to a vehicle with excess energy and stores the energy in the power grid. In one embodiment, the solution may also utilize the priority of the vehicle's energy supply needs to the power grid and the priority of the vehicle's current needs, such as the priority of passengers, or incoming passengers, or current cargo, or incoming cargo. In one embodiment, the solution may also utilize the determination that when a vehicle is idle, it decides to move to a location to release excess energy into the energy grid and then return to its previous location. In one embodiment, the solution may also utilize one or more conditions, such as weather, traffic, road conditions, vehicle conditions, and passengers and / or cargo in another vehicle, to determine the amount of energy required for a vehicle to provide energy to another vehicle via vehicle-to-vehicle energy transfer and to instruct the vehicle to route to the other vehicle and provide energy. In one embodiment, the solution may also utilize the transfer of energy from a moving vehicle to another moving vehicle. In one embodiment, the solution may also utilize the recovery of energy based on the energy consumed by the vehicle to reach the meeting point with another vehicle, the energy consumed in providing the service, and the estimated energy consumed in returning to the original location. In one embodiment, the solution can also provide the remaining distance required to reach the charging station, and the charging station determines the amount of energy to be recovered from the vehicle, where the remaining capacity is based on the remaining distance. In one embodiment, the solution can also manage vehicles being charged simultaneously from more than one point, such as a charging station via a wired connection and another vehicle via a wireless connection. In one embodiment, the solution can also apply a priority system for allocating energy to vehicles, where priority is given to vehicles that will provide a portion of their stored energy to another entity such as the power grid, a residence, etc. Additionally, it can utilize, for example, relative to... Figure 2F This solution is described and depicted.

[0071] Figure 2GThis diagram illustrates the interconnections between different components 275. This solution can be stored, in whole or in part, on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277' associated with various entities, all of which are communicatively coupled and communicate with 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 may be vehicles 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, power grids / charging stations 284, microphones 285, and / or another vehicle 277. Other entities and / or devices, such as one or more private users using smartphones 278, laptops 280, and / or wearable devices, may also interwork with this solution. Smartphone 278, laptop computer 280, microphone 285, and other devices can be connected to one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various institutions. One or more public buildings 281 may utilize computing device 281'. One or more service providers 279 may include dealerships, towing services, collision repair centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computer devices may be directly and / or communicatively coupled to each other, such as via wired networks, wireless networks, blockchain networks, etc. In one embodiment, microphone 285 may be used as a virtual assistant. In one embodiment, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructures 282 may utilize computing device 282'.

[0072] In one embodiment, vehicle 277 / 276 is capable of transporting people, objects, permanent or temporary fixed installations, etc. In one embodiment, vehicle 277 can communicate with vehicle 276 via V2V communication through a computer associated with each vehicle 276' and 277', and can be referred to as a vehicle, car, vehicle, automobile, etc. Vehicle 276 / 277 can be a self-propelled wheeled vehicle such as a car, SUV, truck, bus, van, or other electric motor or battery-powered or fuel cell-powered vehicle. For example, vehicle 276 / 277 can be an electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or ships, and any other form of transport capable of transporting. Vehicle 276 / 277 can be semi-autonomous or autonomous. For example, vehicle 276 / 277 can self-operate and navigate without human input. Autonomous vehicles can have and use one or more sensors and / or navigation units for autonomous driving.

[0073] In one embodiment, the solution described and depicted herein can be used to determine access to a vehicle via blockchain consensus. In one embodiment, the solution can be used to perform profile verification before enabling occupants to use the vehicle. In one embodiment, the solution can be used to instruct (visually, but in another embodiment, verbally, etc.) the actions that the user needs to perform (which may be pre-recorded) on or from the vehicle and verify that these actions are correct. In one embodiment, the solution can also be used to provide the ability for the vehicle to determine how to fork data based on the risk level associated with the data and the driving environment, and to allocate a portion of the forked data (with a lower risk level during safe driving conditions) to the occupants, and later allocate the remaining portion of the forked data (with a higher risk level) to the occupants after they have left the vehicle. In one embodiment, the solution can also be used to handle the transfer of vehicles across borders (such as countries / states) using blockchain and / or smart contracts, and to apply the rules of the new area to the vehicle.

[0074] In one embodiment, the solution can also be used to enable the vehicle to continue operating outside the boundary when a consensus is reached based on the vehicle's operation and the characteristics of its occupants. In one embodiment, the solution can also be used to analyze the vehicle's available data upload / download speed, file size, and the vehicle's current speed / direction to determine the distance required to complete the data upload / download and to allocate safe zone boundaries for the data upload / download to be performed. In one embodiment, the solution can also be used to safely perform normally dangerous maneuvers, such as when the system determines that an exit is approaching but the vehicle does not appear ready to leave (e.g., in the wrong lane or traveling at a speed unfavorable to an upcoming exit), and to instruct the main vehicle and other nearby vehicles to allow the main vehicle to leave safely. In one embodiment, the solution can also be used to verify the diagnostics of one or more vehicles while both one or more vehicles and another vehicle are in motion.

[0075] In one embodiment, the solution can also detect lane usage at a specific location and time of day to inform vehicle occupants or guide vehicles to recommend or discourage lane changes. In one embodiment, the solution can also eliminate the need for information sent via mail and for drivers / occupants to respond by using mail or making payments in person. In one embodiment, the solution can also provide services to vehicle occupants, where the services are subscription-based and licenses are obtained from other vehicles connected to the occupant's profile. In one embodiment, the solution can also record changes in the condition of a leased object. In one embodiment, the solution can also seek blockchain consensus from other vehicles near the damaged vehicle. In one embodiment, the solution can also receive media potentially related to the accident from a server, such as an insurance entity server, or from the vehicle's computer. The server accesses one or more media files to access the damage to the vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also achieve consensus to determine the severity of an event from multiple devices at different times prior to the event related to the vehicle.

[0076] In one embodiment, the solution can also address the problem of a lack of video evidence related to accidents involving vehicles. The current solution details retrieving accident-related media from other vehicles that may have been nearby. In one embodiment, the solution can also utilize vehicles and other devices (e.g., pedestrians' mobile phones, streetlight cameras, etc.) to record specific parts of the damaged vehicle.

[0077] In one embodiment, the solution can also be used to warn occupants when the vehicle is navigating toward a hazardous area and / or event, enabling the vehicle to notify occupants or a central controller of potential hazardous areas on or near the current transport route. In one embodiment, the solution can also be used to detect when the vehicle is traveling at a high speed, using at least one other vehicle to slow the vehicle down in a manner that contributes to minimal traffic disruption. In one embodiment, the solution can also be used to identify hazardous driving situations in which media is captured by vehicles involved in the hazardous driving situation. A geofence is established based on the distance of the hazardous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one embodiment, the solution can also be used to send a notification to one or more occupants of the vehicle that the vehicle is approaching a traffic control sign on the road, and then, if the vehicle crosses the sign, receive instructions of bad driving from other nearby vehicles. In one embodiment, the solution can also be used to partially inoperable the vehicle by (in some embodiments) limiting speed, limiting the ability to approach another vehicle, limiting speed to a maximum value, and allowing only a given number of miles per time period.

[0078] In one embodiment, these solutions can also be used to overcome the need to rely on software updates to correct problems with a vehicle when it is not being operated correctly. By observing other vehicles on the route, the server receives data from multiple other potential vehicles from which unsafe or incorrect operation of a vehicle is observed. Through analysis, these observations may lead to notifications to the vehicle when the data indicates unsafe or incorrect operation. In one embodiment, the solution can also be used to provide notification between the vehicle and potential hazardous situations involving persons outside the vehicle. In one embodiment, the solution can also be used to send data to the server via devices associated with or near an accident involving the vehicle. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one embodiment, the solution can also be used to provide recommendations for operating the vehicle to the driver or passengers based on data analysis. In one embodiment, the solution can also be used to establish geofencing associated with physical structures and determine liability for payment to the vehicle. In one embodiment, the solution can also be used to coordinate the ability to drop off a vehicle at a location using both the current state at the location and the suggested future state of navigation destinations using other vehicles. In one embodiment, the solution can also be used to coordinate the ability to automatically schedule vehicle drop-offs at locations such as transportation rental entities.

[0079] In one embodiment, the solution can also be used to move a vehicle to another location based on a user's event. More specifically, the system tracks the user's device and, at the end of the original or modified event, modifies the vehicle to be moved closer to the user. In one embodiment, the solution can also be used to verify the availability of locations within an area by using existing vehicles within that area. The approximate time it takes for a location to become available is also determined based on verification from existing vehicles. In one embodiment, the solution can also be used to move the vehicle to a closer parking space when a parking space becomes available and less than the average time of the event has elapsed since the initial parking. Furthermore, the vehicle is moved to a final parking space when the event is complete or based on the location of the device associated with at least one occupant of the vehicle. In one embodiment, the solution can also be used to plan parking ahead of an approaching crowd. The system interacts with the vehicle to offer services at a price below full fare and / or guides the vehicle to alternative parking locations based on vehicle priority, thereby optimizing parking conditions before arrival.

[0080] In one embodiment, the solution can also be used to sell partial ownership of a transportation vehicle or to determine pricing and availability in ride-sharing applications. In one embodiment, the solution can also be used to provide accurate and timely reporting on dealer sales activities far beyond current availability. In one embodiment, the solution can also be used to enable dealers to request assets via blockchain. Consensus is reached before any asset movement using blockchain. Furthermore, the process is automated, and payments can be initiated via blockchain. In one embodiment, the solution can also be used to arrange agreements with multiple entities, such as service centers, where consensus is reached and actions (such as diagnostics) are performed. In one embodiment, the solution can also be used to associate digital keys with multiple users. The first user can be the operator of the transportation vehicle, and the second user is the responsible party for the transportation vehicle. These keys are authorized by a server, where proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be used to determine the services required at the transportation vehicle's destination. One or more service locations capable of providing the required services are located within an area along the route to the destination and have availability to perform the services. The navigation of the transportation vehicle is updated with the determined service locations. A smart contract containing the compensation value for the services is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

[0081] In one embodiment, the solution can also be used to match service provider vehicles with passenger profiles to identify services and goods that passengers in the vehicle may be interested in. These services and goods are determined by passenger history and / or preferences. The vehicle then receives a quote from the service provider vehicle, and in another embodiment, meets with the vehicle to provide the service / goods. In one embodiment, the solution can also be used to detect vehicles within a range and send service quotes (such as maintenance quotes, product quotes, etc.) to the vehicles. An agreement is reached between the system and the vehicle, and the system selects a service provider to provide the agreement. In one embodiment, the solution can also be used to assign one or more vehicles as road managers, where road managers help control traffic. Road managers can generate road indicators (such as lights, displays, sounds) to facilitate traffic flow. In one embodiment, the solution can also be used to warn vehicle drivers via devices, where the devices may be traffic lights or located near intersections. The warning is sent upon the occurrence of an event, such as when the light turns green and the vehicle ahead in the vehicle list does not move.

[0082] Figure 2H This is another block diagram illustrating the interconnection between different components in an example 290. A vehicle 276 is presented, and the vehicle includes ECUs 295, 296 and a head unit (also referred to as an infotainment system) 297. An Electronic Control Unit (ECU) is an embedded system in automotive electronics that controls one or more electronic systems or subsystems within the vehicle. ECUs may include, but are not limited to, the management of the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's Controller Area Network (CAN) bus 294. The ECU can also communicate with the vehicle's computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as the vehicle computer) 298 can communicate with external components such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296, and head unit 297 may contain its own security policy. The security policy defines the permissible processes that can be executed in the appropriate context. In one embodiment, the security policy may be partially or wholly set in the vehicle computer 298.

[0083] ECUs 295, 296, and host unit 297 may each include custom safety function elements 299 that define authorized processes and the contexts that permit these processes to operate. Context-based authorization, which determines the validity of a process when it can be executed, enables the ECU to maintain safe operation and prevents unauthorized access from components such as the vehicle's controller area network (CAN) bus. When the ECU encounters an unauthorized process, it can prevent the process from running. The vehicle ECU can use various contexts to determine whether a process is operating within its permitted limits, such as proximity contexts (e.g., nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects), operational contexts (e.g., indications of whether the vehicle is moving or parked, the vehicle's current speed, and transmission status), user-related contexts (e.g., devices connected to the vehicle via wireless protocols, infotainment use, cruise control, parking assistance, and driver assistance), location-based contexts, and / or other contexts.

[0084] In one embodiment, the solutions described and depicted herein can also be used to partially inoperable a vehicle by (in some embodiments) limiting speed, restricting the ability to approach another vehicle, limiting speed to a maximum value, and allowing only a given number of miles per time period. In one embodiment, the solutions can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent from devices associated with or near an accident involving the vehicle to a server. The server notifies the sender of the data based on the severity of the accident or near-accident. In one embodiment, the solutions can also be used to help vehicles avoid accidents, such as when a vehicle is involved in an accident, by the server querying other vehicles near the accident. The server attempts to obtain data from other vehicles, allowing it to understand the nature of the accident from multiple vantage points. In one embodiment, the solutions can also be used to determine that the sound emanating from the vehicle is atypical and send sound-related data and possible source locations to the server, where the server can determine possible causes and avoid potentially dangerous situations. In one embodiment, the solutions can also be used to establish a location boundary via the system when a vehicle is involved in an accident. This boundary is based on the decibel level associated with the accident. Multimedia content from devices within the boundary is obtained to help further understand the accident scenario. In one embodiment, the solution can also associate the vehicle with the accident and then capture media obtained by a device located near the accident. The captured media is saved as media clips. These media clips are sent to another computing device to construct a sound profile of the accident. This sound profile will help to understand more details surrounding the accident.

[0085] In one embodiment, the solution can also utilize sensors to record audio, video, motion, etc., thereby recording the area where a potential event has occurred, such as if the vehicle has come into contact with or may come into contact with another vehicle (while moving or parked). The system captures data from sensors that may reside on one or more fixed or moving objects on the vehicle. In one embodiment, the solution can also determine that the vehicle has been damaged by using sensor data to identify new vehicle conditions during a transportation event and comparing that condition with a vehicle condition profile, thereby enabling the safe and reliable capture of critical data from the vehicle that is about to be involved in a harmful event.

[0086] In one embodiment, the solution can also be used to warn occupants of a vehicle when one or more sensors have determined that the vehicle is approaching or traveling in an incorrect manner along a one-way road. The vehicle has sensors / cameras / maps that interact with the system of the current solution. The system knows the geographic location of the one-way road. For example, the system can use an audio message to inform occupants that a one-way road is approaching. In one embodiment, the solution can also be used to reward vehicles, enabling autonomous vehicle owners to monetize the data collected and stored by their vehicle's sensors, thereby incentivizing vehicle owners to share their data and provide additional data to entities to improve future vehicle performance, provide services to vehicle owners, etc.

[0087] In one embodiment, the solution can also be used to add or remove vehicle characteristics based on the vehicle's actions over a period of time. In another embodiment, the solution can also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicles is used to determine the condition of the vehicles. Based on the condition, partial ownership of the vehicles is determined, and new responsibilities are assigned to the vehicles. In one embodiment, the solution can also be used to provide data to a replacement / upgrade component, wherein the data attempts to subvert the authorized functions of the replacement / upgrade component, and in response to non-subversion of the authorized functions, licenses the use of the authorized functions of the replacement / upgrade component through the component.

[0088] In one embodiment, the solution can also provide individuals with the ability to ensure that a passenger is in the vehicle and that the passenger is at a specific destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authorized to interact with the passenger. Furthermore, passenger pick-up, drop-off, and location are noted. All of the above is stored immutably on a blockchain. In one embodiment, the solution can also determine the driver's characteristics and other elements in cases where the driver is not driving in a normal manner (such as a manner the driver has previously driven in specific conditions, such as daytime, nighttime, rain, snow, etc.) by analyzing driving style. Additionally, vehicle attributes are considered. Attributes include weather, whether headlights are on, whether navigation is being used, whether a HUD is being used, the volume of media being played, etc. In one embodiment, the solution can also notify the passenger of a dangerous situation when items within the vehicle indicate that the passenger may be unaware of a hazardous situation.

[0089] In one embodiment, the solution can also utilize a calibration device mounted on a dedicated rig fixed to the vehicle, where various sensors on the vehicle can automatically self-adjust based on a comparison between what the calibration device should detect and what it actually detects. In another embodiment, the solution can also utilize a blockchain to request consensus from multiple service centers when a vehicle requiring service sends fault information that allows for remote diagnostics, requiring consensus from other service centers regarding the severity threshold of the data. Once consensus is received, the service centers can send the failsafe level to the blockchain for storage. In yet another embodiment, the solution can also utilize a discrepancy between sensor data from outside the vehicle and sensor data from within the vehicle itself. The vehicle requests software from the server to correct the problem. In yet another embodiment, the solution can also utilize a message passing mechanism for nearby or regional vehicles when an event (e.g., a collision) occurs.

[0090] Reference Figure 2I The illustration depicts an operating environment 290A for a connected vehicle according to some embodiments. As depicted, the vehicle 276 includes a Controller Area Network (CAN) bus 291A connecting components 292A to 299A of the vehicle. Other components may be connected to the CAN bus and are not depicted herein. The depicted components connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0091] Processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to display unit 299A. Processor 296A processes data signals and may include various computing architectures, including Complex Instruction Set Computer (CISC) architecture, Reduced Instruction Set Computer (RISC) architecture, or architectures implementing instruction set combinations. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not depicted) communicatively coupled to each other may be used with this solution.

[0092] Memory 297A is a non-transient memory that stores instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include code for performing the techniques described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other storage device. In some embodiments, memory 297A may also include a medium of non-volatile memory or similar persistent storage device, which may include a hard disk drive, floppy disk drive, CD-ROM device, DVD-ROM device, DVD-RAM device, DVD-RW device, flash memory device, or some other high-capacity storage device based on permanent underlying storage information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Without departing from the present solution, vehicle 276 may include one or more memories 297A.

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

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

[0095] ECU 293A controls the operation of many systems of the vehicle 276, including ADAS system 294A. ECU 293A can, in response to instructions received from navigation system 295A, disable any unsafe and / or unselected autonomous features for the duration of a journey controlled by ADAS system 294A. In this way, navigation system 295A can control whether ADAS system 294A is activated or enabled, allowing it to be activated for a given navigation route.

[0096] Sensor group 292A may include any sensor in vehicle 276 that generates sensor data. For example, sensor group 292A may include short-range and long-range sensors. In some embodiments, sensor group 292A of vehicle 276 may include one or more of the following vehicle sensors: camera, LIDAR sensor, ultrasonic sensor, automotive engine sensor, radar sensor, laser altimeter, manifold absolute pressure sensor, infrared detector, motion detector, thermostat, sound detector, carbon monoxide sensor, carbon dioxide sensor, oxygen sensor, mass airflow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air-fuel ratio meter, blind spot meter, curb clearance meter, defect detector, Hall effect sensor, parking sensor, radar gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission fluid temperature sensor, turbo speed sensor (TSS), variable reluctance sensor, vehicle speed sensor (VSS), water sensor, wheel speed sensor, GPS sensor, mapping function, and any other type of automotive sensor. Navigation system 295A may store sensor data in memory 297A.

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

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

[0099] In one embodiment, the solution described and depicted herein can be used to manage emergencies and vehicle characteristics when a vehicle is determined to enter an area without network access. In one embodiment, the solution can also be used to manage and provide characteristics (such as audio, video, navigation, etc.) within a vehicle without network connectivity. In one embodiment, the solution can also be used to determine when the profile of a person near the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0100] In one embodiment, the solution can also be used to analyze the availability of voice communication for occupants in a given vehicle based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one embodiment, the solution can also be used to determine two threat levels of road congestion and receive an alert indicating that the obstruction has not risen above a threshold and that the vehicle is proceeding along the road. In one embodiment, the solution can also be used to remove sensitive data from the vehicle when it is damaged to the point of being unusable.

[0101] In one embodiment, the solution can also be used to verify that customer data to be removed has been genuinely removed from all required locations within the enterprise demonstrating GDPR compliance. In one embodiment, the solution can also be used to enhance the autonomy of lower-level autonomous vehicles by providing consideration for exchanging data related to safety, important notifications, etc., from one vehicle to another. In one embodiment, the solution can also be used to provide the vehicle with the ability to receive data based on a first biometric associated with an occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuation of the first biometric. When only the occupant is capable of receiving unencrypted data, the vehicle provides the unencrypted data to the occupant, deleting sensitive portions of the unencrypted data while providing sensitive portions, and deleting non-sensitive portions after the time period associated with the biometric has elapsed. In one embodiment, the solution can also be used to provide the vehicle with the ability to verify an individual based on the weight and grip pressure applied to the vehicle's steering wheel. In one embodiment, the solution can also be used to provide the vehicle with features that exist but are not currently enabled, thereby presenting the vehicle's occupants with features reflecting the characteristics of the occupants.

[0102] In one embodiment, the solution may also allow modification of the vehicle (particularly the interior and exterior) to reflect and assist at least one occupant in one embodiment. In another embodiment, the re-creation of an occupant's work and / or home environment is disclosed. When a user is in the vehicle, if it is determined that the user is in "work mode" or "home mode," the system may attempt to "recreate" the user's work / home environment. All data related to the interior and exterior of the vehicle and the various occupants utilizing the vehicle are stored on a blockchain and executed via smart contracts. In one embodiment, the solution may also detect occupant postures to assist communication with nearby vehicles, which can then be manipulated accordingly. In one embodiment, the solution may also provide the vehicle with the ability to detect expected postures using a posture definition data storage area. In one embodiment, the solution may also provide the vehicle with the ability to take various actions based on the user's gait and posture. In one embodiment, the solution may also ensure that the driver of the vehicle currently performing various operations (e.g., talking while driving with navigation on) has not exceeded the number of unsafe operations before being permitted to make postures.

[0103] In one embodiment, the solution can also be used to assign a state to each occupant in the vehicle and verify the occupant's posture based on the occupant's state. In another embodiment, the solution can also be used to collect details of collision-related sounds (location, direction, ascent or descent, originating device, device-related data (such as type, manufacturer, owner), and the number and timing of simultaneous sounds) and provide them to the system, where analysis of the data helps determine details about the collision. In yet another embodiment, the solution can also be used to provide a determination that the vehicle's operation is unsafe. The vehicle includes multiple components that interoperate to control the vehicle, and each component is associated with a separate component key. An encryption key is sent to the vehicle to reduce its functionality. In response to receiving the encryption key, the vehicle disables one or more of the component keys. Disabling one or more component keys results in limiting the vehicle's speed to no greater than a given speed, limiting the distance between the vehicle and another vehicle to no more than a certain distance, and limiting the vehicle's distance traveled to no more than a threshold distance, or one or more of the following:

[0104] In one embodiment, the solution can also be used to provide instructions from one particular vehicle (about to vacate a space) to another particular vehicle (attempting to occupy a space), with blockchain used to perform authentication and coordination. In one embodiment, the solution can also be used to determine partial ownership of the vehicle. In cases where multiple people own a single vehicle, the system updates partial ownership using the vehicle's usage, which can change over time. As will be included in other embodiments in the application, this includes determining the minimum ownership of the vehicle's driver and other vehicles based on the vehicle's availability rather than its usage.

[0105] In one embodiment, the solution can also be used to allow a user to subscribe to his / her subscription together with a closed group of people, such as family members or friends, while on the vehicle. For example, a user might want to share membership, and if so, the relevant transactions are stored in a blockchain or traditional database. When subscription materials are requested by a user who is not the primary subscriber, a blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared a profile. In one embodiment, the solution can also be used to enable people to use supplemental transportation to reach their desired destination. Functional relation values ​​(e.g., values ​​indicating various parameters and their importance in determining which type of alternative transportation to use) are used to determine the supplemental transportation. In one embodiment, the solution can also be used to allow occupants in an accident to obtain alternative transportation to continue to their initial destination.

[0106] In one embodiment, the solution can also be used to propagate software / firmware updates to a first subset of the vehicles. This first set of vehicles tests the update, and when the test is successful, the update is propagated to another set of vehicles. In one embodiment, the solution can also be used to propagate software / firmware updates from the main vehicle to the vehicles, where the update is propagated through a network of vehicles in the first subset, then larger subsets, etc. A portion of the update may be sent first, and then the remainder sent from the same or another vehicle. In one embodiment, the solution can also be used to provide updates to the vehicle's computer to the devices of the vehicle and its operators / occupants. This update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicles and devices. Users do not need to do anything; they simply approach the vehicle, and the functionality appears automatically. A notification indicating that the software update is complete is sent to the devices. In one embodiment, the solution can also be used to verify that the OTA software update was performed by a qualified technician and that one or more vehicle components generate a status related to: the originator of the verification code, the process for wirelessly receiving the software update, the information contained in the software update, and the verification result.

[0107] In one embodiment, the solution may also provide the ability for a second component to parse software updates located in a first component. Then, a first portion of a critical update and a second portion of a non-critical update are verified. The verified first portion is assigned to a process within the transportation vehicle, a process runs the verified first portion for a period of time, and in response to a positive result based on that period, another process runs the verified first portion after that period. In one embodiment, the solution may also provide service options to passengers, where services are based on passenger profiles of the transportation vehicle and shared profiles shared with the passenger profiles. In one embodiment, the solution may also store user profile data in a blockchain and intelligently present offers and recommendations to users based on automatically collected purchase history and preferences obtained from user profiles on the blockchain.

[0108] To fully ensure the security of a transportation vehicle, it is essential to protect it from unauthorized physical access and unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, in one embodiment, the transportation vehicle is equipped with a secure access system such as keyless entry. Simultaneously, in another embodiment, security protocols are added to the transportation vehicle's computers and computer networks to facilitate secure remote communication to and from the transportation vehicle.

[0109] Electronic control units (ECUs) are nodes within a vehicle that control everything from activating windshield wipers to systems like anti-lock braking systems (ABS). ECUs are often interconnected via a central network within the vehicle, which may be referred to as a controller area network (CAN). State-of-the-art features such as autonomous driving heavily rely on the implementation of new, sophisticated ECUs, including advanced driver assistance systems (ADAS) and sensors. While these new technologies have helped improve vehicle safety and the driving experience, they have also increased the number of external communication units within the vehicle, making them more vulnerable to attack. Below are some examples of protecting vehicles from physical and remote intrusion.

[0110] Figure 2J The illustration shows a keyless entry system 290B, according to an example embodiment, for preventing unauthorized physical access to a means of transport 291B. (Refer to...) Figure 2JIn one embodiment, key card 292B sends commands to vehicle 291B using radio frequency signals. In this example, key card 292B includes a transmitter 2921B with an antenna capable of transmitting short-range wireless radio signals. Vehicle 291B includes a receiver 2911B with an antenna capable of receiving short-range wireless signals transmitted from transmitter 2921B. Key card 292B and vehicle 291B also include CPUs 2922b and 2913B, respectively, for controlling the respective devices. Here, the memory (or CPU-accessible memory) of CPUs 2922B and 2913B is also included. In one embodiment, each of key card 292B and vehicle 291B includes power supplies 2924B and 2915B for powering the respective devices.

[0111] When a user presses button 293B on key card 292B (or otherwise actuates the key card), the CPU 2922B within key card 292B is activated and sends a data stream output via antenna to transmitter 2921B. This data stream can be a long signal of 64 to 128 bits, including one or more of a preamble, command code, and rolling code. The signal can be transmitted at a rate between 2 kHz and 20 kHz, but the embodiment is not limited to this. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends the data stream to CPU 2913B. The CPU decodes the signal and sends a command (e.g., lock / unlock door, etc.) to command module 2912B.

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

[0113] Besides the rolling code, the key card 292B and the transport vehicle 291B can employ other methods to make attacks more difficult. For example, different frequencies can be used to send the rolling code. As another example, a secure session can be established using bidirectional communication between the transmitter 2921B and the receiver 2911B. As yet another example, the code may have a limited expiration or timeout. Additionally, exploits such as those relative to... can be used in this network and other networks and / or systems (including those described and depicted herein). Figure 2J This solution is described and depicted.

[0114] Figure 2K The illustration shows a Controller Area Network (CAN) 290C within a vehicle according to an example embodiment. (Refer to...) Figure 2K The CAN 290C includes a CAN bus 297C with high-side and low-side terminals, and multiple electronic control units (ECUs) 291C, 292C, 293C, etc., connected to the CAN bus 297C via wired connections. The CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. The CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard), which allows ECUs 291C to 293C to send commands to each other at the root level. Meanwhile, ECUs 291C to 293C represent controllers used to control electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other features.

[0115] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send messages to and receive messages from the CAN bus 297C. For example, transceiver 2911C can convert data from the microcontroller 2912C into a format suitable for the CAN bus 297C, and can also convert data from the CAN bus 297C into a format suitable for the microcontroller 2912C. Meanwhile, in one embodiment, the microcontroller 2912C uses ECU software installed therein to interpret messages and also determines what messages to send.

[0116] To protect the CAN 290C from cyber threats, various security protocols can be implemented. For example, the CAN 290C can be divided into smaller sub-CANs using subnets (e.g., subnets A and B, etc.), thus restricting an attacker's ability to remotely access the vehicle. Figure 2KIn the example, ECUs 291C and 292C can be part of the same subnet, while ECU 293C is part of a separate subnet. Furthermore, a firewall 294C (or gateway, etc.) can be added to prevent messages from crossing the subnets and traversing the CAN bus 297C. If an attacker gains access to one subnet, they cannot gain access to the entire network. To further secure the subnets, in one embodiment, the most critical ECUs are not placed on the same subnet.

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

[0118] In addition to protecting the internal network of a transportation vehicle, it can also be protected when communicating with external networks such as the Internet. One benefit of connecting a transportation vehicle to a data source such as the Internet is that information from the vehicle can be transmitted over the network to remote locations for analysis. Examples of transportation 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 computer science. Furthermore, technologies such as those described and depicted herein can be utilized in this network and other networks and / or systems (including those described and depicted herein). Figure 2K This solution is described and depicted.

[0119] Figure 2L The illustration depicts a secure end-to-end vehicle communication channel according to an example embodiment. (Refer to...) Figure 2L The telematics network 290D includes a vehicle 291D and a host server 295D (e.g., a web server, cloud platform, database, etc.) located at a remote location and connected to the vehicle 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D can be installed within the network inside the vehicle 291D. Furthermore, although not shown, the device 296D can connect to other components of the vehicle 291D, such as a CAN bus, an onboard diagnostic (ODBII) port, a GPS system, a SIM card, a modem, etc. The device 296D can collect data from any of these systems and transmit the data to the server 295D via the network.

[0120] Secure data management begins with the vehicle 291D. In some embodiments, the device 296D may collect information before, during, and after the trip. This data may include GPS data, driving data, passenger information, diagnostic data, fuel data, speed data, etc. However, the device 296D may only transmit the collected information back to the host server 295D in response to vehicle ignition and trip completion. Furthermore, communication may be initiated solely by the device 296D and not by the host server 295D. Thus, in one embodiment, the device 296D will not accept communication initiated by external sources.

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

[0122] In addition to communicating with external servers, vehicles can also communicate with each other. Specifically, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other via wireless networks and with roadside infrastructure such as traffic lights, signs, cameras, parking meters, etc. Wireless networks can include one or more of Wi-Fi networks, cellular networks, Dedicated Short Range Communication (DSRC) networks, etc. Vehicles can use V2V communication to provide other vehicles with information about their speed, acceleration, braking, and direction (to name just a few). Therefore, vehicles can gain insight into the situation ahead before it becomes visible, significantly reducing collisions. Furthermore, features such as relative to... can be utilized in this network and other networks and / or systems (including those described and depicted herein). Figure 2L This solution is described and depicted.

[0123] Figure 2M The illustration shows an example 290E of transport vehicles 293E and 292E performing secure V2V communication using a security certificate according to an example embodiment. (Refer to...) Figure 2MVehicles 293E and 292E can communicate with each other via V2V communication over short-range networks, cellular networks, etc. Before sending a message, vehicles 293E and 292E can sign the message using their respective public key certificates. For example, vehicle 293E can sign a V2V message using public key certificate 294E. Similarly, vehicle 292E can sign a V2V message using public key certificate 295E. In one embodiment, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0124] Upon receiving communication from each other, the transport vehicle can use a certification authority 291E, etc., to verify the signature. For example, the transport vehicle 292E can verify with the certification authority 291E that the public key certificate 294E used by the transport vehicle 293E to sign the V2V communication is authentic. If the transport vehicle 292E successfully verifies the public key certificate 294E, the transport vehicle knows that the data comes from a legitimate source. Similarly, the transport vehicle 293E can use the certification authority 291E to verify that the public key certificate 295E used by the transport vehicle 292E to sign the V2V communication is authentic. Additionally, it is possible to utilize, as relative to, other methods in this network and other networks and / or systems (including those described and depicted herein). Figure 2M This solution is described and depicted.

[0125] Figure 2N Another illustration 290F shows an example of a transportation vehicle depicting interaction with a security processor and a wireless device according to an exemplary embodiment. In some embodiments, Figure 2B The computer 224 shown may include a security processor 292F, such as Figure 2N The example process is shown in 290F. Specifically, the security processor 292F can perform authorization, authentication, encryption (e.g., encryption) on data transmissions between ECUs and other devices on the vehicle's CAN bus, as well as on data messages transmitted between different vehicles.

[0126] exist Figure 2NIn the example, the security processor 292F may include an authorization module 293F, an authentication module 294F, and an encryption module 295F. The security processor 292F can be implemented within the computer of the transport vehicle and can communicate with other components of the transport vehicle, such as the ECU / CAN network 296F, wired and wireless devices 298F such as wireless network interfaces, input ports, etc. The security processor 292F can ensure the security of data frames (e.g., CAN frames, etc.) transmitted internally within the transport vehicle (e.g., via the ECU / CAN network 296F). Similarly, the security processor 292F can ensure the security of messages transmitted between different transport vehicles and to devices connected to or attached to the computer of the transport vehicle via cabling.

[0127] For example, the authorization module 293F can store passwords, usernames, PIN codes, biometric scans, etc., for different users of the transportation vehicle. The authorization module 293F can determine whether a user (or technician) is authorized to access certain settings, such as the transportation vehicle's computer. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user expects to change transportation vehicle settings or modify technical details of the transportation vehicle via a console or GUI within the transportation vehicle or via an attached / connected device, the authorization module 293F may require the user to authenticate themselves in some way before changing such settings. For example, the authorization module 293F may require usernames, passwords, PIN codes, biometric scans, predefined line drawings or gestures, etc. In response, the authorization module 293F can determine whether the user has the necessary permissions (access, etc.) requested.

[0128] The authentication module 294F can be used to authenticate internal communication between ECUs on a vehicle's CAN network. As an example, the authentication module 294F can provide information for authenticating communication between ECUs. For example, the authentication module 294F can send a bit signature algorithm to the ECUs on the CAN network. The ECUs can use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. Each time one of the ECUs generates a new CAN frame, the bit signature algorithm can dynamically change the position, amount, etc., of the authentication bits. The authentication module 294F can also provide a list of ECUs that are exempt from using authentication bits (a security list). The authentication module 294F can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

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

[0130] Figure 3A A flowchart 300 illustrating a method according to an example embodiment is shown. (Refer to...) Figure 3A It can be made by transport node 205 (see Figure 2C ) Execute the example method. It should be understood that... Figure 3A The method 300 described herein may include additional operations, and some operations described herein may be removed and / or modified without departing from the scope of this patent application. Reference is also made for illustrative purposes. Figure 2C The features described herein are used to describe method 300. Specifically, the processor 204 of node 205 can perform some or all of the operations included in method 300.

[0131] refer to Figure 3A In box 302, processor 204 can receive data and a key associated with an upcoming event from the server. In box 304, processor 204 can verify the data associated with the upcoming event based on current data acquired by the vehicle. In box 306, processor 204 can receive functionality configured to respond to the upcoming event in response to the verification of the data associated with the upcoming event. In box 308, processor 204 can unlock functionality on the vehicle using the key.

[0132] Figure 3B Another flowchart 320 is illustrated according to an example method of an example embodiment. (Refer to...) Figure 3BMethod 320 may further include one or more of the following steps. In box 322, processor 204 may verify the key by sending data from sensors associated with the vehicle at the start of an event. In box 324, processor 204 may modify the key and may send the modified key and data related to the ongoing event from sensors associated with the vehicle. In box 326, processor 204 may modify the key based on a protocol with the server, and in response to verification of the modified key at the server based on the key, may receive functionality based on data received from sensors associated with the vehicle. In box 328, processor 204 may confirm an upcoming event associated with the key based on vehicle sensor or ECU readings. In box 330, processor 204 may modify the key based on a protocol with the server. This protocol may constitute a blockchain consensus between at least the peer represented by the vehicle and the server. In box 332, processor 204 may record the key on the blockchain in response to the blockchain consensus.

[0133] Figure 4 The diagram illustrates a machine learning transportation network 400 according to an example embodiment. Network 400 includes transportation nodes 402 that interface with a machine learning subsystem 406. Each transportation node includes one or more sensors 404.

[0134] The machine learning subsystem 406 includes a learning model 408, which is a mathematical product created by a machine learning training 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 the transportation node 402.

[0135] Transportation 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. Based on the predictions from learning model 408, machine learning subsystem 406 sends one or more instructions to transportation node 402.

[0136] In another embodiment, the transportation node 402 can send data from one or more sensors 404 to the machine learning training system 410. In yet another embodiment, the machine learning subsystem 406 can send data from the sensors 404 to the machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein can utilize the machine learning network 400 described herein.

[0137] Figure 5A The illustration depicts an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. (Refer to...) Figure 5A When a specific means of transport / vehicle 525 engages in transactions (e.g., vehicle service, dealership transactions, delivery / pickup, transportation services, etc.), the vehicle can receive assets 510 and / or evict / transfer assets 512 according to the transaction. A means of transport processor 526 resides in vehicle 525, and communication exists between means of transport processor 526, database 530, and transaction module 520. Transaction module 520 can record information such as assets, parties, credit, service description, date, time, location, results, notifications, and unexpected events. Transactions in transaction module 520 can be replicated to database 530. Database 530 can be one of SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be on the means of transport, off the means of transport, directly accessed and / or accessed via a network, or accessible to the means of transport.

[0138] Figure 5B The illustration depicts an example vehicle configuration 550 for managing database transactions between various vehicles, according to an example embodiment. When vehicle 525 reaches a state requiring service sharing with another vehicle, it can engage with another vehicle 508 to perform various actions such as sharing, delivery, and receiving service calls. For example, vehicle 508 may need to charge its battery and / or may have tire problems or may be on its route to pick up a package to be delivered. A vehicle processor 528 resides in vehicle 508, and communication exists between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle 525 operating in its network and on its blockchain member service. A vehicle processor 526 resides in vehicle 525, and communication exists between vehicle processor 526, database 530, and transaction module 520. Vehicle 525 can then receive information from vehicle 508 and / or a server (not shown) via a wireless communication request to perform package retrieval. Transactions are recorded in transaction modules 552 and 520 of both vehicles. Credit is transferred from vehicle 508 to vehicle 525, and the record of the transferred service is recorded in databases 530 / 554 (assuming the blockchains are different from each other) or in the same blockchain available to all members. Database 554 can be one of the following: SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and can be on the vehicle, off the vehicle, or accessed directly and / or via a network.

[0139] Figure 6AThe illustration shows a blockchain architecture configuration 600 according to an example embodiment. (Refer to...) Figure 6A The blockchain architecture 600 may include certain blockchain elements, such as a group of blockchain member nodes 602-606 as part of blockchain group 610. In one example embodiment, the permissioned blockchain is not accessible to all parties, but only to those members who have permission to access the blockchain data. Blockchain nodes participate in many activities, such as the blockchain entry addition and verification process (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide a sorting service for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and attempt to write to the immutable blockchain ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0140] Blockchain transaction 620 is stored in the computer's memory upon receipt and approval by the consensus model defined by the member nodes. Approved transactions 626 are stored in the current block of the blockchain and submitted to the blockchain via a commit process that includes hashing the data content of the transaction in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 630 may exist, defining terms of transaction protocols and actions, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc., included in the smart contract executable application code 632. The code can be configured to identify whether a requesting entity is registered to receive vehicle services, which service characteristics they are authorized / requested to receive given their profile state, and whether their behavior in subsequent events is monitored. For example, when a service event occurs and a user is riding in the vehicle, sensor data monitoring can be triggered, and specific parameters, such as the vehicle's battery level, can be identified as being above / below a specific threshold for a specific time period. The result could then be a change in the current state, requiring an alert to be sent to the administrator (i.e., vehicle owner, vehicle operator, server, etc.), thus the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's status. Sensor data can also form the basis of vehicle event data 634, such as the intended location, average speed, maximum speed, acceleration rate, presence of any collisions, whether a predicted route has been taken, the next destination, whether safety measures are in place, and whether the vehicle has sufficient battery / fuel. All this information can form the basis of smart contract terms 630, which are then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary and when and where that service should be performed.

[0141] Figure 6BThe illustration shows a shared ledger configuration according to an example embodiment. (Refer to...) Figure 6B Blockchain logic example 640 includes a blockchain application interface 642, which serves as an API or plug-in application linked to computing devices and execution platforms for specific transactions. Blockchain configuration 640 may include one or more applications linked to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.). This program / application code may be created according to a customized configuration sought by the participants and may maintain its own state, control its own assets, and receive external information. It may be deployed as an entry and installed on all blockchain nodes via attachment to the distributed ledger.

[0142] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that activates the terms and conditions of the transactions upon execution. Smart contract 630, upon execution, generates certain approved transactions 626, which are then forwarded to the blockchain platform 652. This platform includes security / authorization 658, computing devices for executing transaction management 656, and storage devices 654 that serve as storage for the transactions and smart contracts on the blockchain.

[0143] A blockchain platform can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure. These layers can be used to receive and store new entries and provide access to auditors attempting to access data entries. The blockchain can expose interfaces that provide access to the virtual execution environment necessary to process program code and establish a close relationship with the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and maintain the privacy of information.

[0144] Figure 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code via one or more interfaces exposed by the blockchain platform and the services it provides. As a non-restricted example, smart contracts can be created to execute alerts, updates, and / or other notifications affected by changes, updates, etc. The smart contract itself can be used to identify authorization and access requests related to the ledger and the rules associated with their use. For example, this information may include a new entry, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The result may include deciding to reject or approve the new entry based on criteria defined in the smart contract and / or the consensus of the peers. Any of the data or information described herein can be retrieved using physical infrastructure.

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

[0146] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. This code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and kept private. Temporary data used / generated by smart contracts is maintained in memory by the supplied execution environment and then deleted once the data needed by the blockchain is identified.

[0147] Smart contract executable code can include a code interpretation of the smart contract with additional features. As described herein, smart contract executable code can be program code deployed on a computing network, executed on the network, and verified 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 using a previously stored feature extractor. If the hash of the hash identifier matches a hash created using the stored identifier template data, the smart contract executable code sends an authorization key to the requested service. The smart contract executable code can also write data associated with cryptographic details to the blockchain.

[0148] Figure 6C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Refer to...) Figure 6CExample configuration 660 enables vehicle 662, user equipment 664, and server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that, in the event that a known and established user profile is attempting to rent a vehicle with an established rating profile, consults the vehicle service provider to share user profile rating information. Server 666 may be receiving and processing data related to vehicle service requests. When service events occur, such as vehicle sensor data indicating a need for fuel / electricity, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., that can be used to invoke vehicle service events. For each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc., blockchain transaction data 670 is maintained. The transaction may include the parties, requirements (e.g., being 18 years of age or older, a qualified candidate, a valid driver's license, etc.), compensation level, distance traveled during the event, the recipient of the registration authorized to access the event and host the vehicle service, rights / licenses, sensor data retrieved during the vehicle event operation to record details of the next 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.

[0149] Figure 6D The illustration shows blockchain block 680, which can be added to the distributed ledger according to an example embodiment, and the contents of block structures 682A to 682n. (Refer to...) Figure 6D A client (not shown) can submit entries to a blockchain node to establish an activity on the blockchain. As an example, the client could be an application acting on behalf of a requester, such as a device, person, or entity, to propose an entry for the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsing peers and submitting peers. Endorsing peers impersonate and endorse entries proposed by clients, while submitting peers verify the endorsements, validate the entries, and submit the entries to the distributed ledger. In this example, a blockchain node can act as an endorser node, a submitter node, or both.

[0150] This system comprises a blockchain that stores immutable sequential records in blocks and a state database (current world state) that maintains the current state of the blockchain. Each channel can have a distributed ledger, and each peer maintains its own distributed ledger copy for each channel for which it is a member. This blockchain is an entry log, constructed as a hashed chain of blocks where each block contains a sequence of N entries. Blocks can include, for example, Figure 6DThe blockchain comprises various components, such as the structure shown. A chain of blocks can be generated by adding the hash of the header of the previous block to the current block's block header. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash chain. Furthermore, because of the chain, the latest block in the blockchain represents every entry that came before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports attaching only blockchain workloads.

[0151] The current state of the blockchain and its distributed ledger can be stored in a state database. Here, the current state data represents the latest values ​​of all keys ever included in the blockchain's entry log. Smart contract executables call entries by referring to the current state in the state database. To make these smart contract executable interactions extremely efficient, the latest values ​​of all keys are stored in the state database. The state database is an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after peers start up but before entries are accepted (or generated when needed).

[0152] Endorsing nodes receive entries from clients and endorse them based on the simulation results. Each endorsing node holds a smart contract representing the simulated entry proposal. When an endorsing node endorses an entry, it creates an entry endorsement, which is a signed response from the endorsing node to the client application instructing the simulated entry to be endorsed. The method of endorsing an entry depends on the endorsement policy, which can be specified within the smart contract's executable code. An example of an endorsement policy is "most endorsing peers must endorse the entry." Different channels can have different endorsement policies. The client application forwards the endorsed entry to the ordering service.

[0153] The ordering service accepts endorsed entries, sorts them into blocks, and then passes the blocks to committing peers. For example, the ordering service can initiate a new block when a threshold for entries is reached, a timer expires, or other conditions occur. In this example, the blockchain nodes are committing peers that have received data block 682A to be stored on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle entries, smart contracts, or the shared ledger. Specifically, the ordering service can accept endorsed entries and specify the order in which these entries are committed to the distributed ledger. The architecture of the blockchain network can be designed to allow specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) to be pluggable components.

[0154] Entries are written to the distributed ledger in a consistent order. Establishing this order ensures that updates to the state database are valid when they are committed to the network. Unlike cryptocurrency blockchain systems that sort entries by solving cryptographic puzzles or mining (e.g., Bitcoin), in this example, the parties to the distributed ledger can choose the sorting mechanism best suited to the network.

[0155] Reference Figure 6D Block 682A (also referred to as a data block) stored on the blockchain and / or distributed ledger may include multiple data fragments such as block headers 684A to 684n, transaction-specific data 686A to 686n, and block metadata 688A to 688n. It should be understood that the various boxes and contents depicted, such as block 682A and its contents, are merely illustrative and are not intended to limit the scope of the exemplary embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A storing the entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A to 690n. Block 682A may also include links to previous blocks (e.g., on the blockchain) within the block header 684A. Specifically, block header 684A may include the hash of the headers of previous blocks. Block header 684A may also include a unique block number, the hash of block data 690A of the current block 682A, etc. The block number of block 682A can be unique and assigned incrementally / sequentially starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

[0156] Block data 690A can store entry information for each entry recorded within a block. For example, entry data may include one or more of the following: entry type, version, timestamp, channel ID of the distributed ledger, entry ID, period, payload visibility, smart contract executable code path (deployment tx), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identifier, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkel tree query digest, etc. Entry data for each of N entries can be stored.

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

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

[0159] The above embodiments can be implemented in hardware, as a computer program executed by a processor, as firmware, or a combination thereof. The computer program can be embodied on a computer-readable medium such as a storage medium. For example, the computer program can 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, hard disks, removable disks, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0160] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as separate components. For example, Figure 7The illustration shows an example computer system architecture 700, which can be represented or integrated into any of the aforementioned components.

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

[0162] Within compute node 700, there exists a computer system / server 702 that can operate alongside numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or portable devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0163] A computer system / server 702 can be described within the overall context of a computer system executing computer system executable instructions such as program modules. Typically, a program module can include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system / server 702 can be implemented in a distributed computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside on both local computer system storage media and remote computer system storage media, including memory storage devices.

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

[0165] A bus refers to one or more of any type of bus architecture, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. For example, and not as a limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0166] Computer system / server 702 typically includes a variety of computer system readable media. This media can be any available media accessible to computer system / server 702, and it includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements a flowchart of another diagram. System memory 706 may include computer system readable media in the form of volatile memory such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. For example only, memory 706 may be provided for reading and writing from non-removable non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, disk drives for reading and writing to non-removable non-volatile disks (e.g., "floppy disks") and optical disk drives for reading or writing to removable non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media may be provided. In this case, each may be connected to a bus via one or more data media. As will be further depicted and described below, memory 706 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of this application.

[0167] A program / utility having a set (at least one) of program modules can be stored in memory 706 (for example, but not limited to) as well as in an operating system, one or more applications, other program modules, and program data. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules typically perform functions and / or methods as described herein in various embodiments of this application.

[0168] As those skilled in the art will understand, aspects of this application can be implemented as a system, method, or computer program product. Therefore, aspects of this application can take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which are generally referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application can take the form of a computer program product implemented on one or more computer-readable media having computer-readable program code embodied thereon.

[0169] The computer system / server 702 can also communicate with one or more external devices via I / O devices 712 (such as I / O adapters). I / O devices 712 may include a keyboard, indicating devices, a display, a voice recognition module, etc., one or more devices enabling a user to interact with the computer system / server 702, and / or any device enabling the computer system / server 702 to communicate with one or more other computing devices (e.g., network interface cards, modems, etc.). This communication can occur via the I / O interface of device 712. Again, the computer system / server 702 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter. As depicted, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0170] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that this application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined in the appended claims. For example, the capabilities of the systems in the various figures can be implemented by one or more of the modules or components described herein or in a distributed architecture, and may include transmitters, receivers, or pairs of both. For example, all or part of the functions performed by individual modules can be performed by one or more of these modules. In addition, the functions described herein can be performed internally or externally to modules or components at various times in relation to various events. Furthermore, information transmitted between modules can be transmitted via at least one of the following: data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or via multiple protocols. Additionally, messages sent or received by any of the modules can be sent or received directly and / or via one or more of the other modules.

[0171] Those skilled in the art will understand that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of these devices. Presenting the above-described functions as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in local and distributed forms consistent with computing technologies.

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

[0173] Modules can also be implemented, at least partially, in software for execution by various types of processors. The identified executable code unit may, for example, comprise one or more physical or logical blocks of computer instructions that can be organized, for example, into objects, procedures, or functions. However, the executable files of the identified module do not need to be physically located together, but may include different instructions stored in different locations that, when logically combined, encompass the module and implement its stated purpose. Additionally, the module may be stored on a computer-readable medium, such as a hard disk drive, flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0174] In practice, executable code modules can be single instructions or multiple instructions, and can even be distributed across several different code segments, different programs, and multiple storage devices. Similarly, operational data can be identified and illustrated within the modules herein, and can be implemented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations, including across different storage devices, and can exist at least partially as electronic signals within the system or network.

[0175] It will be readily understood that the components of this application, as generally described and illustrated in the accompanying drawings, can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely to represent selected embodiments of the application.

[0176] It will be readily understood by those skilled in the art that the above can be practiced in a different order of steps and / or with hardware components configured differently from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent.

[0177] Although preferred embodiments of this application have been described, it is to be understood that the described embodiments are merely illustrative, and the scope of this application will be defined solely by the appended claims when considering a range of equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method for providing external functions to a means of transport, comprising: At the transportation vehicle, data and keys associated with the upcoming event are received from the server; The means of transport verifies data associated with the upcoming event based on current data acquired by the means of transport; In response to the verification, the function configured to respond to the upcoming event is received at the means of transport; as well as The function is unlocked on the vehicle using the key; The key is modified by the vehicle based on a protocol with the server, and the function is received at the vehicle based on the modified key and data related to the event in progress.

2. The method of claim 1, wherein the verification includes data transmitted by the vehicle from sensors associated with the vehicle when the event begins to occur.

3. The method of claim 1, further comprising sending the modified key and the data related to the ongoing event from sensors associated with the vehicle via the vehicle.

4. The method of claim 1, further comprising the function of receiving data received from sensors associated with the vehicle at the vehicle in response to verification of the modified key at the server based on the key.

5. The method of claim 1, further comprising identifying an upcoming event associated with the key based on readings from vehicle sensors or ECU readings.

6. The method of claim 1, further comprising modifying the key based on a protocol with the server, wherein the protocol constitutes a blockchain consensus between at least the peer represented by the means of transport and the server.

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

8. A system for providing external functions to a means of transport, comprising: Processor for transport vehicles; The memory stores machine-readable instructions that, when executed by the processor, cause the processor to: Receive data and keys associated with the upcoming event from the server; The data associated with the upcoming event is verified based on the current data obtained by the processor of the vehicle. In response to the verification, receive the functionality configured to handle the upcoming event; as well as The function is unlocked on the vehicle using the key; The key is modified by the vehicle based on a protocol with the server, and the function is received at the vehicle based on the modified key and data related to the events that have occurred.

9. The system of claim 8, wherein the verification includes data from sensors associated with the vehicle transmitted when the event begins to occur.

10. The system of claim 8, wherein the instructions further cause the processor to send the modified key and event-related data from sensors associated with the vehicle.

11. The system of claim 8, wherein the instructions further cause the processor to receive data based on data received from sensors associated with the vehicle in response to verification of the modified key at the server based on the key.

12. The system of claim 8, wherein the instructions further cause the processor to confirm an upcoming event associated with the key based on readings from vehicle sensors or ECU readings.

13. The system of claim 8, wherein the instructions further cause the processor to modify the key based on a protocol with the server, wherein the protocol constitutes a blockchain consensus between at least the peer represented by the means of transport and the server.

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

15. A non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform the following operations: Receive data and keys associated with the upcoming event from the server; The data associated with the upcoming event is verified based on the current data obtained from the means of transport; In response to the verification, receive the functionality configured to handle the upcoming event; as well as The function is unlocked on the vehicle using the key; The key is modified by the vehicle based on a protocol with the server, and the function is received at the vehicle based on the modified key and data related to the event in progress.

16. The non-transient computer-readable medium of claim 15, wherein the verification includes transmitting data from sensors associated with the vehicle when the event begins to occur.

17. The non-transient computer-readable medium of claim 15, further comprising instructions that, when read by a processor, cause the processor to send the modified key and the data related to the ongoing event from sensors associated with the vehicle.

18. The non-transient computer-readable medium of claim 15, further comprising instructions that, when read by a processor, cause the processor to receive data based on data received from sensors associated with the vehicle in response to verification of the modified key at the server based on the key.

19. The non-transient computer-readable medium of claim 15, further comprising instructions that, when read by a processor, cause the processor to modify the key based on a protocol with the server, wherein the protocol constitutes a blockchain consensus at least between the peer represented by the vehicle and the server.

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

Images