Secure transport of data sharing

Abstract

The present disclosure relates to secure transportation data sharing. Example operations include one or more of receiving, by a server, a request for particular data, determining, by the server, based on one or more current settings of a transportation vehicle and a current route of the transportation vehicle, that the transportation vehicle is capable of providing the particular data, requesting, by the server, that the transportation vehicle provide the particular data for a value, and receiving, by the server, the particular data.

Description

Technical Field

[0001] This application relates to secure transportation data sharing. Background Technology

[0002] Vehicles or means of transport, such as cars, motorcycles, trucks, airplanes, and trains, typically provide transportation services for 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 means of transport. Summary of the Invention

[0003] An example embodiment provides a method comprising one or more of the following: receiving a request for specific data by a server, determining, by the server, a means of transport that can provide the specific data based on one or more current settings of the means of transport and the current route of the means of transport, requesting, by the server, the means of transport to provide the specific data for the value, and receiving, by the server, the specific data.

[0004] Another example embodiment provides a means of transport including a memory communicatively coupled to a processor, wherein the processor performs one or more of the following: receiving a request for specific data, determining a means of transport capable of providing the specific data based on one or more current settings of the means of transport and the current route of the means of transport, requesting the means of transport to provide the specific data for a value, and receiving the specific data.

[0005] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a request for specific data by a server; determining, by the server, a means of transport that can provide the specific data based on one or more current settings of the means of transport and the current route of the means of transport; requesting, by the server, that the means of transport provide the specific data for the value; and receiving, by the server, the specific data. Attached Figure Description

[0006] Figure 1A An example system diagram of a means of transport operation according to an example embodiment is illustrated.

[0007] Figure 1B The illustration shows an example of the selection and utilization of means of transport during data sharing processing, according to an example embodiment.

[0008] Figure 1C The illustration shows a system diagram of a vehicle attached to a license document according to an example embodiment.

[0009] Figure 2A Another transportation network diagram of a transportation operation sensor according to an example embodiment is illustrated.

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

[0011] Figure 2C The illustration shows yet another transportation network diagram according to an example embodiment.

[0012] Figure 2D The illustration shows another transportation network diagram according to an example embodiment.

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

[0014] Figure 2F The diagram illustrates the electrification of one or more components according to an example embodiment.

[0015] Figure 2G The diagram illustrates the interconnections between different elements according to an example embodiment.

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

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

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

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

[0020] Figure 3C Another flowchart according to an example embodiment is illustrated.

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

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

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

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

[0025] Figure 6B The illustration shows another blockchain configuration according to an example embodiment.

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

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

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

[0029] It will be readily understood that the components described and illustrated herein, as generally presented in the figures, 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-transitory computer-readable media, and systems shown in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments.

[0030] Communication between one or more vehicles and entities such as remote servers and local computing devices (e.g., smartphones, personal computers, embedded computers in the vehicles), can be received and processed by one or more “components,” which can be hardware, firmware, software, or a combination thereof. A component can be part of any of these entities or computing devices or other computing devices. In one example, consensus decisions related to blockchain transactions can be performed by computing devices or components associated with one or more vehicles and by one or more components located outside or at remote locations on one or more vehicles. Consensus decisions or protocols are the process of reaching agreement on values, states, results, inputs, outputs, conditions, etc., among one or more nodes or peers in a network.

[0031] The features, structures, or characteristics described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, the use of the phrases "example embodiment," "some embodiments," or other similar language throughout 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 phrases "example embodiment," "some embodiments," "in other embodiments," or other similar language appearing throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the figures, even if the connections drawn are unidirectional or bidirectional arrows, any connection between elements may allow unidirectional and / or bidirectional communication. In the present solution, the means of transport may include one or more of automobiles, trucks, battery electric vehicles (BEVs) for pedestrian zones, e-Palette vehicles, 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.

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

[0033] 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, a verification 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 / means 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, and authorize subsequent vehicle rental services, as well as enable vehicle-to-vehicle communication.

[0034] Within 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 untrusted parties. These untrusted 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 without consensus 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 these blocks. For consistency, this process forms the ledger by ordering storage entries as needed. In public or permissionless blockchains, any party can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). Conversely, permissioned blockchain databases can protect interactions between a group of entities sharing common goals but not fully trusting or able to fully trust each other (such as businesses exchanging funds, goods, information, etc.). This solution can work in both permissioned and / or permissionless blockchain settings.

[0035] Smart contracts are trusted, distributed applications that leverage the tamper-proof properties of a shared or distributed ledger (potentially in the form of a blockchain) and a fundamental protocol among member nodes known as endorsement or endorsement policy. Generally, 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 required for endorsement. When a client sends an entry to the peers specified in the endorsement policy, the entry is executed to verify it. After verification, the entry enters a sorting phase, where a consensus protocol is used to produce an ordered sequence of endorsed entries grouped into blocks.

[0036] 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 client or commit client nodes, which 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 entries, and maintain the state and copies of the ledger of blockchain entries. Peers can also have the role of endorsers. Ordering service nodes, or orderers, are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasts 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 entry, which typically contains control and setup information.

[0037] 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, sorting nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, etc. The ledger includes a blockchain (also called a chain), which is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Each channel typically has its own ledger. Each peer node maintains a copy of the ledger for each channel for which it is a member.

[0038] A chain is a log of entries constructed as a hashed chain of blocks, with each block containing a sequence of N entries, where N is equal to or greater than 1. The block header includes the hash of the block's entries, as well as the hash of the header of the previous block. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash chain. The hash of the most recently added blockchain block represents every entry that arrived on the chain 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.) to efficiently support the append-only nature of blockchain workloads.

[0039] The current state of an immutable ledger represents the latest value of all keys contained in the chain's entry log. Because the current state represents the latest key-value pair known to the channel, it is sometimes referred to as the world state. Smart contract executables invoke execution entries based on the ledger's current state data. To enable efficient interaction between these smart contract executables, the latest value of the key can be stored in a state database. The state database can simply be 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 (or generated as needed) when peers start up and before entries are accepted.

[0040] The difference between blockchain and traditional databases is that blockchain is not a centralized store, but a decentralized, immutable, and secure store, where nodes must share changes to the records in the store. Some inherent properties of blockchain that contribute to its implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0041] 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 service can be received. Furthermore, service centers may provide services to vehicles in the vicinity based on the vehicle's current route plan and relative service level requirements (e.g., immediate, severe, moderate, 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 inside and / or outside the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object away from the vehicle, and 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 inside and / or near the vehicle. Furthermore, sensor information can be used to identify whether a vehicle is operating safely and whether occupants are in any unexpected vehicle conditions, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger as determined by a licensing body, and thus in a “decentralized” manner, such as via a blockchain membership group.

[0042] Each stakeholder (i.e., owners, users, companies, agents, etc.) may wish to restrict the disclosure of private information; therefore, blockchain and its immutability can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide value (which can be currency, credit, goods, services, etc.), quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when services are needed, identify conflict and / or demotion events, identify security-related issues, identify the parties involved in an event, and distribute the data to registered entities seeking access to such vehicle event data. Similarly, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on a "consensus" approach associated with the blockchain. Such an approach cannot be implemented on traditional centralized databases.

[0043] 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 terrain and road maps that the vehicle can use for navigation and other destinations. In some embodiments, GPS, maps, cameras, sensors, etc., can also be used in place of LIDAR in autonomous vehicles.

[0044] In some embodiments, this solution includes authorizing the vehicle to provide service via an automated and rapid authentication scheme. For example, driving to a charging station or fuel pump can be performed by a vehicle operator or autonomous vehicle, and authorization to receive charge or fuel can be performed without any delay once the service station and / or charging station receives authorization. The vehicle can provide a communication signal that identifies the vehicle with a current activity profile linked to an authorized account for receiving service, which can then be corrected by providing a value. Further authentication can be provided using other measures, such as another identifier wirelessly transmitted from the user's device to the service center to replace or supplement the initial authorization work between the vehicle and the service center through additional authorization work.

[0045] Shared and received data can be stored in a database that maintains the data in a single location (e.g., a database server). This location is typically a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database can usually be accessed from multiple different points. Centralized databases are easy to manage, maintain, and control, especially for security purposes, because they are located in a 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.

[0046] Figure 1AA sample system diagram 100 is illustrated, showing the operation of a means of transport according to an example embodiment. (Reference) Figure 1A System 100 includes a selected means of transport 120, which can be selected to provide transport data to a server 130 responsible for communicating with the means of transport 120. Furthermore, a third-party entity 110 may be an interested party seeking access to the transport data collected by the selected means of transport 120. System 100 may include requests sent from the third-party entity 110, such as a remote server or device communicating with server 130, which is responsible for managing data collection associated with one or more means of transport in a specific area.

[0047] In one embodiment, when server 130 receives request 112, for specific vehicle data (such as sensor data, road data, occupant-related data, operational data, etc.), server 130 can identify that the vehicle is currently located and / or operating in a specific region or area and can satisfy the data requirements associated with data request 112. Data requirements may include occupant-specific data (one or more), location-specific data, road data, driving behavior data, data usage information, data from other vehicles, etc. Examples of occupant-specific data may include the vehicle's speed, the road used, the time of transport, operational choices, and other occupant actions. Road data may include the vehicle's vector movement, the time the vehicle spends on the road throughout the day, identified road conditions, and the vehicle's performance.

[0048] Server 130 can identify the requested data 112 and identify candidate vehicles 114 based on criteria associated with the requested data. For example, the requested data may be based on a specific location, the number of passengers in the vehicle, etc. Vehicles monitored in the area of ​​interest can be potential candidates, provided that those vehicles meet the requested data(s) requirements. Server 130 can also select only those vehicles identified as willing to share their specific vehicle information, which can be identified from the identified sharing settings 116. This determination may be based on vehicle profiles and / or passenger profiles stored in server 130. In another embodiment, vehicle profiles may be stored in third-party device 110 and / or vehicle 120 and / or passenger profiles may also be stored in third-party device 110 and / or vehicle 120. Once server 130 has selected vehicle 120 that can provide the requested specific data, based on one or more current settings of the vehicle and its current route, server 130 can communicate with the selected vehicle 120 via wireless communication signals (such as cellular communication signals). The communication signals can be transmitted from server 130 to a communication module that communicates with a communication device associated with the selected vehicle 120. The communication device can be an onboard communication module of vehicle 120 and / or a mobile device located inside and / or attached to the vehicle.

[0049] Vehicle 120 can receive notifications that information collected via onboard sensors can be periodically collected and shared. A license file 122 can be retrieved from server 130 and forwarded to vehicle 120 to apply settings to the vehicle during data collection and sharing operations. In one embodiment, the license file 122 may be stored in third-party device 110 and / or vehicle 120. Data may be collected along the route of the vehicle and / or for a period of time as the vehicle moves 124. The data can then be forwarded 126 to server 130, which can apply the data to a data file format specified by third party 110. The finalized data can be forwarded 128 to the third party to satisfy a query for requested data 112. Once data collection and sharing are complete, server 130 can receive the value associated with the data (which may be used immediately or later) and apply that value to vehicle 120, such as by including the value in a vehicle profile stored in server 130.

[0050] Figure 1B The illustration depicts Example 150 of the selection and utilization of means of transport during data sharing processing, according to an example embodiment. (Reference) Figure 1BServer 130 can communicate via communication entity 154, such as a wireless communication device, to send / receive communications to / from multiple vehicles 162-169 along a route. Each vehicle can communicate via wireless and / or cellular communication devices installed in the vehicle or via mobile devices operated by passengers. The process may also include determining that one or more of the multiple vehicles 162-169 are configured to share data based on one or more passenger profiles and one or more attributes of one or more vehicles. Requests for data may include an area of ​​interest 152, such as a radius around a center point (e.g., 20 miles), origin location, destination location, passage through a specific area, etc. All known vehicles participating in that area can be identified by server 130, which is part of the communication network among vehicles 162-169 in that area. When one or more vehicles match data criteria (e.g., location, travel schedule, passenger requirements, vehicle type, weather conditions, road conditions, vehicle status, etc.), the eligible vehicle (such as 162) is identified to determine whether the sharing request is valid for that vehicle / passenger profile. If effective, then the means of transport will be selected and monitored for data collection purposes.

[0051] During the sharing process, server 130 may perform one or more of the following: retrieve a license file from storage, apply one or more current settings of the license file to the vehicle before receiving specific data requested by a third party, and then collect and / or share the specific data with the third party (which may be another vehicle). Once the data collection and sharing requirements are met, vehicle 162 may be assigned or provided a value to comply with the data sharing process. This value may be assigned to a profile, data file, blockchain transaction, or any other data record structure. Data criteria may include specific requirements for a number of occupants, which may be determined at the current time prior to participation in the sharing operation. For example, requirements may specify that there is only one or at least two occupants on the vehicle before data collection and sharing. Other requirements may be that the vehicle travels to a specific location, a specific distance, and / or operates for a specific amount of time when data is collected. For a particular selected vehicle (such as 162), portions of the requested specific data may be identified, captured, and shared based on the number of occupants and other data requirement criteria, and then shared with stakeholders. In another example, only a portion of the specific data may be collected based on the number of occupants. For example, a data request might require the collection of certain data only for one passenger in the transportation vehicle. Therefore, if there are two passengers in the vehicle, only some data can be collected to satisfy other data requests. Once one passenger leaves the vehicle, the remaining data can be collected and shared. Thus, additional collection operations can be requested to complete the data collection and sharing process. In one embodiment, the value can be provided incrementally upon receiving data. If the received data is undesirable (incomplete, outdated, unreadable or incomprehensible, corrupted, etc.), a message can be sent to the transportation vehicle and / or the value can be reduced.

[0052] Figure 1C A system diagram 170 of a transport vehicle attached to a license document, according to an example embodiment, is illustrated. (Reference) Figure 1C Prior to a specific data collection operation, the selected vehicle 162 can be identified by server 130 as a candidate for the data collection service. Server 130 can apply license file 180 to vehicle 162 through specific processing. Information associated with license file 180 can be created by application interface 182, which allows the occupants / owners of the vehicle to access the settings of license file 180. Certain settings can be configured, such as the type of data to be shared, when and where data can be shared, indications for not sharing data, frequency of data sharing, data expiration, data storage, data usage requirements, etc.

[0053] In one example embodiment, the vehicle 162 can receive an invitation to share data, and accepting such an invitation can enable a blockchain transaction to occur. This process may include verification of specific data shared from at least one component of the vehicle (as described or depicted herein) or associated with server 140. Verification may also include blockchain consensus between a peer group consisting of the vehicle and at least one component. Furthermore, depending on the transaction that occurs, a smart contract may be executed by the vehicle to record the verification and the at least one component on the blockchain based on the blockchain consensus.

[0054] In one example embodiment, the data can be identified as sensitive and / or security data. This data includes, but is not limited to, trip data, passenger data, transportation data, customer data, vehicle manufacturer data, and third-party data. Application access to transportation system resources can be securely managed to include access to various types of data via various access operations (e.g., Controller Area Network data, autonomous vehicle mode data, system log data, sensor data, etc.). Other types of data may include location data, driving data, vehicle status data, etc. Other operations may include managing third-party data and personal passenger information (e.g., name, mailing address, email address, (one or more) telephone numbers, and / or demographic information). During data collection operations, platform usage can also be of interest, such as information related to internet providers, browser types, website IP addresses, accessed web pages, downloaded and / or consumed multimedia, etc.

[0055] Vehicle-related data can be managed using License File 180 to manage application access to vehicle system resources (e.g., Controller Area Network data, autonomous vehicle mode data, system log data, etc.), authorized customer access and in-vehicle preferences (e.g., digital key / smart key box), application access to customer data (e.g., name, address, geolocation, internal / external vehicle camera data, etc.), and customer consent data (such as settings stored in License File 180). License File 180 can also be used to determine what data can be transferred. For example, if a customer / occupant wishes to share data, consent is recorded, and License File 180 can be retrieved, accessed, and updated. When License File 180 expires, the data is automatically deleted from the vehicle or from one or more third-party servers. The use of License File 180 provides access to the vehicle's location and automatically adapts to local laws, allowing flexibility in the event of any changes in legal rules, and also provides the ability to detect / determine which occupants are in the vehicle and their locations within the vehicle.

[0056] The license document 180 may include the level of consent (e.g., full, partial, none) and the type of data (e.g., vehicle operation, vehicle location, occupant activity data, environmental data, sensor data, etc.), which may be provided by the vehicle and / or its driver / passengers. In some cases, data sharing operations may prompt the vehicle and / or occupants to perform certain actions, such as sharing routes / locations, participating in charging / refueling interactions, accelerating, decelerating, activating features (e.g., braking features, lighting features, autopilot features, etc.), increasing / decreasing the level of operation, and / or the amount of time available for the vehicle. The vehicle may prompt the user to perform specific actions based on the license document, such as turning and traveling at speed "y" for "x" minutes in lane "z" on a specific route. Once the requirements are met, the data may be stored in the completed file, sent to a server, and authorized / verified and confirmed via the server and / or third-party devices.

[0057] A license can be associated with one or more passengers / occupants and / or one or more owners of a means of transport, as well as one or more goods and / or services associated with the means of transport. For example, a means of transport may be carrying various items, such as three occupants and two parcels, and may be dispatched to perform a service (such as picking up another parcel, supplying electricity to the grid, etc.). Each of the occupants, parcels, and services may have an associated license that provides rules and procedures for how any data associated with each of the occupants, parcels, and services will be retrieved, used, stored, and / or deleted. Each license may also provide different rules and procedures for the same item. For example, if traveling alone, an occupant may wish to provide more data to the means of transport and / or third parties, while if traveling with another passenger, no data may be provided. Moreover, if the third party is of a certain type, then data (such as price, quantity, purpose, purchaser, user, etc.) may be provided for that type of parcel or service, while a subset of the relevant data may be provided for another type of third party.

[0058] Figure 2AA transportation network diagram 200 according to an example embodiment is illustrated. The network includes components comprising a transportation node 202 having a processor 204 and a transportation node 202' having a processor 204'. Transportation nodes 202 and 202' communicate with each other via processors 204 and 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 and 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. 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 component.

[0059] Figure 2B Another transportation network diagram 210 according to an example embodiment is illustrated. The network includes components comprising a transportation node 202 having a processor 204 and a transportation node 202' having 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.

[0060] Although depicted as a single transport node, processor, and element, multiple transport nodes, processors, and elements may exist. Information or communication may occur and / or originate from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204, which may initiate action by transport node 202; it may further provide such information or additional information to processor 204', which may initiate action by transport node 202'; or it may further provide such information or additional information to mobile phone 220, transport 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.

[0061] Figure 2C A further transportation network diagram 240 according to an example embodiment is illustrated. This network includes elements comprising node 205, which includes processor 204 and non-transitory computer-readable medium 242C. Processor 204 is communicatively coupled to computer-readable medium 242C and element 230 (in... Figure 2B (As depicted in the example embodiment). Depending on the example embodiment, node 205 may be a vehicle, a server, or a combination of both.

[0062] The processor 204 performs one or more of the following: receiving a request for specific data 244C, determining a vehicle that can provide the specific data based on one or more current settings of the vehicle and the current route of the vehicle 246C, requesting the vehicle to provide the specific data for the value 248C, and receiving the specific data 250C.

[0063] Figure 2D A further transportation network diagram 250 according to an example embodiment is illustrated. The network includes elements, including node 205, which includes processor 204 and non-transitory computer-readable medium 242D. Processor 204 is communicatively coupled to computer-readable medium 242D and element 230 (which in... Figure 2B (As depicted in the text). Node 205 can be a server, a transport vehicle, or a combination of both.

[0064] Processor 204 performs one or more of the following: identifying multiple vehicles along the current route and determining that one or more of the multiple vehicles are configured to share specific data based on one or more occupant profiles and one or more attributes of one or more vehicles 244D; retrieving a license file, applying one or more current settings of the license file to the vehicle before receiving the specific data, and providing the specific data to a third party and providing values ​​to the vehicle 246D; identifying attributes associated with the current route of the vehicle, and collecting specific data over a period of time based on the attributes associated with the current route of the vehicle 248D; determining the number of occupants in the vehicle at the current time, determining which portions of the specific data can be captured and shared based on the number of occupants, and receiving a portion of the specific data based on the number of occupants 250D.

[0065] Figure 2E A further transportation network diagram 260 according to an example embodiment is illustrated. (Reference) Figure 2E Network diagram 260 includes node 205 connected to other transportation vehicle nodes 202' and update server node 203 via blockchain network 206. Nodes 205 and 202' may represent transportation vehicles. Blockchain network 206 may have a ledger 208 for storing software update verification data and verification sources for future use (e.g., for auditing).

[0066] Although this example describes only one node 205 in detail, multiple such nodes can be connected to the blockchain 206. It should be understood that node 205 may include additional components and some 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, and may include a processor 204, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or other hardware device. Although a single processor 204 is depicted, it should be understood that node 205 may include multiple processors, multiple cores, etc., without departing from the scope of this application.

[0067] The processor 204 performs one or more of the following: receiving verification of specific data shared from at least one component, and the verification includes blockchain consensus 244E between a peer group consisting of a vehicle and at least one component, and executing a smart contract based on the blockchain consensus to record the verification and the at least one component on the blockchain 246E.

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

[0069] Figure 2F Figure 265 illustrates the electrification of one or more components. In one embodiment, vehicle 266 can provide power stored in its battery to one or more components, including one or more other vehicles 268, one or more charging stations 270, and one or more power grids 272. One or more power grids 272 are coupled to one or more charging stations 270, which can be coupled to one or more vehicles 268. This configuration allows for the distribution of power received from vehicle 266. Vehicle 266 can also interact with one or more other vehicles 268 via vehicle-to-vehicle (V2V) technology, cellular communication, WiFi, etc. Vehicle 266 can also interact wirelessly and / or wiredly with other vehicles 268, one or more charging stations 270, and / or one or more power grids 272. In one embodiment, vehicle 266 travels safely and efficiently along a route (or travels itself along a route) to one or more power grids 272, one or more charging stations 270, or one or more other vehicles 268. Using one or more embodiments of this solution, the transport vehicle 266 can supply energy to one or more elements depicted herein in a variety of advantageous manners as described and / or illustrated herein. Furthermore, the safety and efficiency of the transport vehicle can be improved, and it can positively impact the environment as described and / or illustrated herein.

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

[0071] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 such that vehicle 266 has sufficient charge remaining to reach its destination. In one embodiment, a wireless connection is used to wirelessly guide the transfer of a certain amount of energy between vehicles 268, where the vehicles may all be in motion. In one embodiment, an idle vehicle, such as vehicle 266 (which may be autonomous), is guided to charging station 270 to provide a certain amount of energy 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 at charging station 270. In one embodiment, factors determine the amount of energy transferred to charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), occupancy schedule(s) when using the vehicle, expected occupancy schedule(s) when waiting for the vehicle, etc. In one embodiment, one or more vehicles 268, one or more charging stations 270, and / or one or more power grids 272 may provide energy to vehicle 266.

[0072] In one embodiment, the solution described and depicted herein can be used to determine the impact of load on a vehicle and / or system to provide energy to the vehicle and / or system based on future needs and / or priorities, and to provide intelligence between the device containing the module and the vehicle, allowing 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 charge from the vehicle to the location based on factors such as temperature at the location, the cost of energy, and the power level at the location. In one embodiment, the solution can also be used to manage the amount of remaining energy 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 battery on the vehicle, wherein the amount of energy to be transferred is based on the distance from the vehicle to the module receiving the energy.

[0073] In one embodiment, the solution can also be used to utilize a mobile energy storage unit that travels along a defined path to a vehicle with excess energy and stores the energy into the power grid. In one embodiment, the solution can also be used to determine a defined priority of the vehicle's need to supply energy to the power grid, and a priority of the vehicle's current needs, such as the priority of passengers, or upcoming passengers, or current cargo, or upcoming cargo. In one embodiment, the solution can also be used to determine when the vehicle is idle, it decides to maneuver to a location to release excess energy into the energy grid and then return to its previous location. In one embodiment, the solution can also be used to determine the amount of energy required by a vehicle based on one or more conditions (such as weather, traffic, road conditions, vehicle conditions, passengers, and / or cargo in another vehicle) to provide the required energy to another vehicle via vehicle-to-vehicle energy transfer, and to instruct the vehicle to travel along a route to another vehicle and provide energy. In one embodiment, the solution can also be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, the solution can also be used to retrieve energy from a vehicle based on the energy spent by the vehicle to reach a rendezvous point with another vehicle, to provide service, and to estimate the energy spent returning to its original location. In one embodiment, the solution can also be used to provide the remaining distance required for a charging station, and the charging station determines the amount of energy to retrieve from the vehicle, where the remaining charge is based on the remaining distance. In one embodiment, the solution can also be used to manage vehicles being charged simultaneously by more than one point, such as a charging station connected via a wired connection and another vehicle connected via a wireless connection. In one embodiment, the solution can also be used to apply priority to the allocation of energy to vehicles, where priority is given to vehicles that will provide a portion of their stored charge to another entity, such as a power grid, a residence, etc. Furthermore, as per [the relevant information]... Figure 2F The solution described and depicted here can be used in this and other networks and / or systems.

[0074] Figure 2GThis diagram illustrates the interconnections between the different components 275. This solution can be fully or partially stored on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and / or 277' associated with various entities, all of which are communicatively coupled to and communicate with network 286. Database 287 is communicatively coupled to the network and allows for the storage and retrieval of data. In one embodiment, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, a power grid / charging station 284, a microphone 285, and / or another vehicle 277. Other entities and / or devices, such as one or more private users using smartphones 278, laptops 280, and / or wearable devices, may also interoperate with this solution. Smartphone 278, laptop 280, microphone 285, and other devices may 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 centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computing devices may be directly and / or communicatively coupled to 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 transportation 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 transportation infrastructure. One or more transportation infrastructures 282 may utilize computing device 282'.

[0075] 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, automobile, vehicle, motor vehicle, etc. Vehicle 276 / 277 can be a self-propelled wheeled vehicle, such as an automobile, SUV, truck, bus, van, or other motorized 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 with a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or ships, and any other form of transportation 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 from the primary driver.

[0076] 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 also be used to perform profile verification before allowing occupants to use the vehicle. In one embodiment, the solution can also be used to instruct the vehicle to (visually, but in another embodiment verbally, etc.) perform actions required by the user on or from the vehicle (which may be pre-recorded) and verify that these actions are correct. In one embodiment, the solution can also be used to provide the vehicle with the ability to determine, based on the risk level associated with the data and the driving environment, how to fork data at a lower risk level and distribute a portion of the forked data to the occupants during a safe driving environment, and then distribute the remaining portion of the forked data to the occupants at a higher risk level after they leave the vehicle. In one embodiment, the solution can also be used to process vehicle transfers across borders (such as county / state / etc.) and apply rules for the new area to the vehicle using blockchain and / or smart contracts.

[0077] In one embodiment, the solution can also be used to allow a vehicle to continue operating outside a boundary when the vehicle's operation and the characteristics of its occupants reach a consensus. 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 speed / direction to determine the distance required to complete the data upload / download and allocate a safe zone boundary for the data upload / download to be performed. In one embodiment, the solution can also be used to perform normally dangerous maneuvers safely, such as when the system determines an exit is imminent and when the vehicle does not appear ready to exit (e.g., in the wrong lane or traveling at a speed unfavorable for an upcoming exit) and instructs the target vehicle and other nearby vehicles to allow the target vehicle to exit safely. In one embodiment, the solution can also be used to verify the diagnostics of another vehicle using one or more vehicles while one or more vehicles and another vehicle are in motion.

[0078] In one embodiment, the solution can also be used to detect lane usage at a location and time of day to notify vehicle occupants or instruct vehicles to recommend or discourage lane changes. In one embodiment, the solution can also eliminate the need for sending messages via mail and for drivers / occupants to respond by using mail or making payments in person. In one embodiment, the solution can also be used to provide services to vehicle occupants, wherein the services provided are subscription-based and licenses are obtained from other vehicles connected to the occupant's profile. In one embodiment, the solution can also be used to record changes in the condition of rented objects. In one embodiment, the solution can also be used to seek blockchain consensus from other vehicles near the damaged vehicle. In one embodiment, the solution can also be used to receive media from a server, such as an insurance entity server, from a computer on a vehicle that may be associated with the accident. The server accesses one or more media files to access damage to the vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also be used to reach consensus at different times prior to the event related to the vehicle to determine the severity of the event from multiple devices.

[0079] In one embodiment, the solution can also be used to 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 near the accident, using the vehicle involved in the accident. In one embodiment, the solution can also be used to record specific parts of the damaged vehicle using the vehicle and other devices (e.g., pedestrian cellular phones, streetlight cameras, etc.).

[0080] In one embodiment, the solution can also be used to warn occupants when the vehicle is navigating toward a hazardous area and / or event, thereby allowing the vehicle to notify occupants or the central controller of a potential hazardous area on or near the current vehicle route. In one embodiment, the solution can also be used to detect when the vehicle is traveling at high speed and to help slow it down using at least one other vehicle in a manner that minimizes traffic impact. In one embodiment, the solution can also be used to identify dangerous driving situations in which media is captured by the vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geofence.

[0081] In one embodiment, the solution can also be used to send a notification to one or more occupants of a vehicle that the vehicle is approaching a traffic control sign on the road, and then, if the vehicle crosses the sign, receive instructions for 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, restricting the ability to approach another vehicle, limiting speed to a maximum value, and allowing only a given mileage per time period.

[0082] In one embodiment, the solution can also be used to overcome the problem of relying on software updates to correct a vehicle when it is not being operated correctly. By observing other vehicles on the route, the server receives data from multiple potential other vehicles to observe unsafe or incorrect operation of the vehicles. Through analysis, these observations can generate notifications to the vehicles 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 people outside the vehicle. In one embodiment, the solution can also be used to send data to the server via devices associated with or near the 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 occupants 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 return a vehicle at a location using its current state and a proposed future state using other vehicles' navigation destinations. In one embodiment, the solution can also be used to coordinate the ability to automatically schedule vehicle returns at locations such as vehicle rental entities.

[0083] 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 modifies the vehicle to be moved near the user at the end of the original or modified event. In one embodiment, the solution can also be used to allow verification of available locations within an area using existing vehicles. The approximate time when a location becomes available is also determined based on verification of existing vehicles. In one embodiment, the solution can also be used to move the vehicle to a nearby parking space when it becomes available and the elapsed time since the initial parking is less than the average time of the event. Furthermore, the vehicle is moved to the 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 improving parking optimization before arrival.

[0084] In one embodiment, the solution can also be used to sell partial ownership of a transportation vehicle or to determine pricing and availability in a ride-sharing application. In one embodiment, the solution can also be used to provide accurate and timely reporting of dealer sales activities far exceeding currently available information. In one embodiment, the solution can also be used to allow dealers to request assets via blockchain. Consensus is reached before any asset is moved 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 the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be used to determine the services required for the transportation vehicle's destination. One or more service locations are located in areas capable of providing the required services, both within the area along the route to the destination and with availability for providing the services. The navigation of the transportation vehicle is updated using the determined service locations. A smart contract containing the service value is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

[0085] In one embodiment, the solution can also be used to match service provider vehicles with passenger profiles to determine 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, the vehicle provides / delivers services. In one embodiment, the solution can also be used to detect vehicles within range and send service quotes (such as maintenance quotes, product quotes, etc.) to those 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 assist traffic flow. In one embodiment, the solution can also be used to warn drivers of vehicles via devices, where the devices may be traffic lights or proximity to intersections. Alerts are sent when events occur, such as when a light turns green and a vehicle ahead of a train does not move.

[0086] Figure 2H This is another block diagram illustrating the interconnection between different components in Example 290. A vehicle 276 is presented and includes ECUs 295, 296 and a head unit (also referred to as an infotainment system) 297. An Electrical Control Unit (ECU) is an embedded system in automotive electronics used to control one or more electrical systems or subsystems in the vehicle. An ECU may include, but is not limited to, managing 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 may also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as the vehicle computer) 298 may 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 permitted processes that can be executed in an appropriate context. In one embodiment, the security policy may be provided partially or entirely in the vehicle computer 298.

[0087] ECUs 295, 296, and head unit 297 may each include a custom safety function element 299 that defines authorized processes and the contexts in which these processes are allowed to run. Context-based authorization for determining the validity of a process's execution allows the ECU to maintain safe operation and prevent unauthorized access from components such as the vehicle controller area network (CAN bus). When the ECU encounters an unauthorized process, it can prevent that process from running. The vehicle ECU can use various contexts to determine whether a process is operating within its permitted boundaries, 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, transmission status), user-related contexts (e.g., devices connected to the vehicle via wireless protocols, use of the infotainment system, cruise control, parking assistance, driver assistance), location-based contexts, and / or other contexts).

[0088] In one embodiment, the solution described and depicted herein can 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 mileage per time period. In one embodiment, the solution 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 proximity to the accident. In one embodiment, the solution can also be used to help a vehicle avoid accidents, such as when the vehicle is involved in an accident, by querying the server of other vehicles near the accident. The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one embodiment, the solution can also be used to determine that the sound emanating from the vehicle is atypical and transmit 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 solution can also be used to establish a location boundary via the system when the 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 be used to associate a vehicle with an accident and then capture media obtained by a device near the accident location. The captured media is saved as media clips. The media clips are sent to another computing device, which builds an audio profile of the accident. This audio profile will help to understand more details about the accident.

[0089] In one embodiment, the solution can also be used to utilize sensors to record audio, video, motion, etc., to record areas where potential events have occurred, such as whether 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 be located on one or more vehicles and / or fixed or moving objects. In one embodiment, the solution can also be used to identify new conditions of the vehicle during a vehicle incident by using sensor data and comparing that condition with a vehicle condition profile to determine if the vehicle has been damaged, thereby enabling the safe and secure capture of critical data from vehicles impending a hazardous incident.

[0090] In one embodiment, the solution can also be used to warn occupants of a vehicle when it determines via one or more sensors that it is approaching or traveling along a one-way street in the wrong direction. 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 street. For example, the system can notify occupants with an audio message “approaching a one-way street.” In one embodiment, the solution can also be used to allow vehicles to be compensated, thereby allowing autonomous vehicle owners to monetize the data collected and stored by their vehicle sensors, thus incentivizing owners to share their data and provide additional data to entities that improve future vehicle performance, provide services to owners, etc.

[0091] In one embodiment, the solution can also be used to increase or decrease 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 means of transport. Sensor data associated with one or more means of transport and equipment proximate to the means of transport is used to determine the condition of the means of transport. The partial ownership of the means of transport is determined based on the condition and provides new responsibilities for the means of transport. In one embodiment, the solution can also be used to provide data to a replacement / upgrade component, wherein the data attempts to disable the authorized functions of the replacement / upgrade component, and in response to non-disruption of the authorized functions, the component allows the use of the authorized functions of the replacement / upgrade component.

[0092] In one embodiment, the solution can also be used to provide individuals with the ability to ensure that a passenger is in the vehicle and that the passenger reaches a specific destination. Furthermore, 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. Additionally, boarding, alighting, and location are taken into account. All of the above are stored immutably on a blockchain. In one embodiment, the solution can also be used to determine the driver's characteristics through analysis of driving style and other factors to take action when the driver is not driving in a normal manner (such as the way the driver previously drove in specific conditions, such as daytime, nighttime, rain, snow, etc.). Furthermore, 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 be used to notify passengers in the vehicle of dangerous situations when items inside the vehicle indicate that the passenger may be unaware of a hazard.

[0093] In one embodiment, the solution can also be used to mount calibration equipment on a drilling rig fixed to a vehicle, where various sensors on the transport vehicle are capable of automatically self-adjusting based on a comparison between what the calibration equipment should detect and what it actually detects. In one embodiment, the solution can also be used to request consensus from multiple service centers using blockchain when a transport vehicle requiring service sends fault information, thereby enabling remote diagnostics, where consensus is required from other service centers on a severity threshold for the data. Once consensus is received, the service centers can send the failsafe level to the blockchain for storage. In one embodiment, the solution can also be used to determine discrepancies between sensor data external to the transport vehicle and sensor data from the transport vehicle itself. The transport vehicle requests software from the server to correct the problem. In one embodiment, the solution can also be used to allow messaging between nearby or regional transport vehicles when an event occurs (e.g., a collision).

[0094] refer to Figure 2I The figure illustrates an operating environment 290A for a connected vehicle according to some embodiments. As shown, the vehicle 276 includes a Controller Area Network (CAN) bus 291A connecting components 292A-299A of the vehicle. Other components may be connected to the CAN bus and are not shown herein. The components depicted 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.

[0095] 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) architectures, Reduced Instruction Set Computer (RISC) architectures, 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 shown) that are communicatively coupled to each other may be used with this solution.

[0096] Memory 297A is a non-transitory 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 memory device. In some embodiments, memory 297A may also include non-volatile memory or similar permanent storage devices and media, which may include hard disk drives, floppy disk drives, CD-ROM devices, DVD-ROM devices, DVD-RAM devices, DVD-RW devices, flash memory devices, or some other high-capacity storage devices for permanent information storage. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Vehicle 276 may include one or more memories 297A without departing from the current solution.

[0097] The memory 297A of the vehicle 276 can 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 that the navigation application 295A may need to provide functionality.

[0098] 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 request for a navigation route from a user, wherein the request includes a start point and an end point. Navigation system 295A can query real-time data server 293 (via network 292), such as a server providing driving directions, to obtain navigation route data corresponding to the navigation route including the start point and end point. Real-time data server 293 transmits navigation route data to vehicle 276 via wireless network 292, and communication system 298A stores navigation data 295A in memory 297A of vehicle 276.

[0099] 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, deactivate any unsafe and / or unselected autonomous features during 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.

[0100] 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, air mass flow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air-fuel ratio meter, blind spot meter, curb detector, defect detector, Hall effect sensor, parking sensor, radar gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission oil temperature sensor, turbine 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.

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

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

[0103] In one embodiment, the solution described and depicted herein can be used to manage emergency scenarios and vehicle characteristics when it is determined that a vehicle has entered 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 the vehicle in the absence of a network connection. In one embodiment, the solution can also be used to determine when the profile of a person approaching the vehicle matches profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

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

[0105] In one embodiment, the solution can also be used to verify that customer data to be removed has indeed been removed from all required locations within the enterprise to demonstrate GDPR compliance. In one embodiment, the solution can also be used to provide consideration for exchanging data related to safety, important notifications, etc., from one vehicle to another to enhance the autonomy of lower-level autonomous vehicles. 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 the occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuum of the first biometric. The vehicle only provides unencrypted data to the occupant if the occupant is able to receive unencrypted data and if sensitive portions of the unencrypted data are removed when provided, and non-sensitive portions are removed after a period of time associated with the biometric. In one embodiment, the solution can also be used to provide the vehicle with the ability to verify an individual based on weight and grip force applied to the vehicle's steering wheel. In one embodiment, the solution can also be used to provide the vehicle with existing but currently inactive features, thereby presenting the vehicle's occupants with features reflecting occupant characteristics.

[0106] In one embodiment, the solution can also be used to allow modification of the vehicle, particularly its interior and exterior, to react to and assist at least one occupant. In another embodiment, reconstructing an occupant's work and / or home environment is disclosed. If the system determines that a user is in "work mode" or "home mode," the system can attempt to "reconstruct" the user's work / home environment while the user is in the vehicle. All data related to the vehicle's interior and exterior, and the various occupants using the vehicle, is stored on a blockchain and executed via smart contracts. In one embodiment, the solution can also be used to detect occupant gestures to aid in communication with nearby vehicles, which can then be manipulated accordingly. In one embodiment, the solution can also be used to provide the vehicle with the ability to detect anticipated gestures using a gesture definition data repository. In one embodiment, the solution can also be used to provide the vehicle with the ability to take various actions based on the user's gait and gestures. In one embodiment, the solution can also be used to ensure that a vehicle driver currently performing various operations (e.g., driving while navigating, etc.) does not exceed the number of unsafe actions before being permitted to make gestures.

[0107] In one embodiment, the solution can also be used to assign a state to each occupant in the vehicle and verify occupant gestures based on the occupant's state. In one embodiment, the solution can also be used to collect collision-related sound details (location, direction, ascent or descent, from which device, data associated with the device such as type, manufacturer, owner, and the number of simultaneous sounds, the time of sound emission, etc.) and provide them to the system, where analysis of the data helps determine detailed information about the collision. In one 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. A cryptographic key is sent to the vehicle to reduce vehicle functionality. In response to receiving the cryptographic key, the vehicle disables one or more component keys. Disabling one or more component keys results in one or more of the following: limiting the vehicle to a given speed, limiting the distance the vehicle cannot approach another vehicle, and limiting the vehicle to travel beyond a threshold distance.

[0108] In one embodiment, the solution can also be used to provide instructions from one specific vehicle (about to vacate a space) to another specific vehicle (seeking to occupy a space), with the blockchain used for authentication and coordination. In one embodiment, the solution can also be used to determine partial ownership of a vehicle, such as in cases where multiple people own a vehicle, and the system updates partial ownership using the vehicle's usage, which may change over time. Other embodiments will be included in this application, including minimum ownership of a vehicle based not on its usage but on its availability, the identification of the vehicle's driver, and other factors.

[0109] In one embodiment, the solution can also be used to allow a user to share their subscription with a closed group of people, such as family members or friends, within a vehicle. For example, a user might want to share a membership, and if so, the associated transaction is stored in a blockchain or traditional database. When a user, as a non-primary subscriber, requests subscribed material, 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 allow a person to reach their intended destination using one or more supplemental vehicles. Functional relation values ​​(e.g., values ​​indicating various parameters and their importance in determining the type of alternative vehicle to be used) are used to determine the supplemental vehicle. In one embodiment, the solution can also be used to allow occupants in an accident to board other vehicles to continue their journey to their initial destination.

[0110] In one embodiment, the solution can also be used to propagate software / firmware updates to a first subset of the vehicles. The 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 propagates from the first subset via the vehicle network, then to larger subsets, and so on. A portion of the update may be sent first, followed by the remainder from the same vehicle or another vehicle. In one embodiment, the solution can also be used to provide updates to the vehicle's computer to the vehicles and the devices of the vehicle operators / occupants. The update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicles and(one or more) devices. Users do not need to do anything; the functionality occurs automatically simply by being near the vehicle. A notification is sent to(one or more) devices indicating that the software update has been completed. In one embodiment, the solution can also be used to verify that the OTA software update was performed by a qualified technician and that one or more vehicle components generate a status related to: the initiator of the verification code, the wireless reception of the software update, the information contained in the software update, and the verification result.

[0111] In one embodiment, the solution can also be used to provide the ability to parse software updates located in the first component via a second component. This involves verifying a first portion of critical updates and a second portion of non-critical updates, assigning the verified first portion to a process within the transportation vehicle, running the verified first portion using that process for a period of time, responding to a positive result based on that period, and then running the verified first portion with other processes after that period. In one embodiment, the solution can also be used to provide passengers with a choice of services, where services are based on passenger profiles and shared profiles shared with the passenger profiles. In one embodiment, the solution can also be used to 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.

[0112] Figure 3A A flowchart 300 according to an example embodiment is illustrated. (Reference) Figure 3A The processor may perform one or more of the following: receiving a request for specific data 302; determining, based on one or more current settings of the means of transport and the current route of the means of transport, that the transmission of the specific data may be provided 304; requesting the means of transport to provide the specific data for the value 306; and receiving the specific data 308.

[0113] Figure 3B Another flowchart 320 according to an example embodiment is illustrated. (Reference) Figure 3BThe processor may perform one or more of the following: identify multiple vehicles along the current route and determine that one or more of the multiple vehicles are configured to share specific data based on one or more occupant profiles and one or more attributes of one or more vehicles 322; retrieve a license file; apply one or more current settings of the license file to the vehicles before receiving the specific data; provide the specific data to a third party and provide values ​​to the vehicles 324; identify attributes associated with the current route of the vehicles; collect specific data over a period of time based on the attributes associated with the current route of the vehicles 326; determine the number of occupants in the vehicles at the current time; determine which portions of the specific data can be captured and shared based on the number of occupants; and receive a portion of the specific data based on the number of occupants 328.

[0114] Figure 3C A further flowchart 340 according to an example embodiment is illustrated. (Reference) Figure 3C The processor may perform one or more of the following: receiving verification of specific shared data from at least one component, and the verification includes blockchain consensus 342 between a peer group consisting of a vehicle and at least one component, and executing a smart contract based on the blockchain consensus to record the verification and the at least one component on the blockchain 344.

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

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

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

[0118] 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 the sensor data 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 as described herein.

[0119] Figure 5A The illustration depicts an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. Reference Figure 5A When a specific means of transport / vehicle 525 engages in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or discharge / transfer assets 512 according to (one or more) the transaction. A means of transport processor 526 is located within 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 copied to database 530. Database 530 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be accessed on the means of transport, outside the means of transport, directly and / or via a network, or accessible by the means of transport.

[0120] Figure 5BThe 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, vehicle 525 can engage with another vehicle 508 to perform various actions, such as sharing, transferring, or receiving service calls. For example, vehicle 508 might be experiencing battery charging and / or tire problems and may be en route to retrieve a package for delivery. A vehicle processor 528 is located in vehicle 508, and communication exists between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle 525 operating within its network and on its blockchain member service. A vehicle processor 526 is located in vehicle 525, and communication exists between vehicle processor 526, database 530, and transaction module 520. Vehicle 525 can then request information from vehicle 508 and / or from a server (not shown) via wireless communication 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 used by all members. Database 554 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be accessed on the vehicle, outside the vehicle, directly, and / or via a network.

[0121] Figure 6A The illustration shows a blockchain architecture configuration 600 according to an example embodiment. (Reference) 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 with permitted access rights to the blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processes (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and attempt to write to the immutable blockchain ledger stored in the blockchain, copies of which may also be stored on the underlying physical infrastructure.

[0122] When blockchain transaction 620 is received and approved by the consensus model defined by the member nodes, the transaction is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and submitted to the blockchain via a submission 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, whose definitions include terms of transaction protocols and actions in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. This code can be configured to identify whether requesting entities are registered to receive vehicle services, which service characteristics they are entitled to / required to receive given their profile status, and whether their actions are monitored in subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring can be triggered, and a parameter (e.g., vehicle charge level) can be identified as being above / below a specific threshold for a specific time period. The result might then be a change to the current state, which requires sending an alert to management (e.g., vehicle owner, vehicle operator, server, etc.) to identify and store the service 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 be based on vehicle event data 634, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, whether there has been any collision, whether the expected route has been taken, the next destination, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All this information can serve as the basis for 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 the service should be performed.

[0123] Figure 6B The illustration shows a shared ledger configuration according to an example embodiment. (Reference) 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.) that can be created according to a customized configuration sought by the participants, and can maintain its own state, control its own assets, and receive external information. This can be deployed as entries and installed on all blockchain nodes via attachment to the distributed ledger.

[0124] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, upon execution, activates the terms and conditions of the transactions. Smart contract 630, upon execution, causes the generation of 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 a storage component 654 that serves as a storage device for storing transactions and smart contracts within the blockchain.

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

[0126] Figure 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code through one or more interfaces and services exposed by the blockchain platform. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications regarding changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. 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 data or information described herein can be retrieved using physical infrastructure.

[0127] 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 executed in response to the satisfaction of conditions associated with the smart contract. The execution of a smart contract can trigger one or more trusted modifications to the state of the digital blockchain ledger. The 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.

[0128] 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. The 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 maintained as private. Temporary data used / generated by smart contracts is maintained in memory by the provisioned execution environment and is then deleted once the data required by the blockchain is identified.

[0129] Executable code for a smart contract can include a code interpretation of the smart contract, as well as additional features. As described herein, executable code for a smart contract can be program code deployed on a computing network, where it is executed and verified together by chain validators during consensus processing. The executable code receives hashes and retrieves hashes 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 from the stored identifier template data, the executable code for the smart contract sends an authorization key to the requested service. The executable code for the smart contract can also write data associated with cryptographic details to the blockchain.

[0130] Figure 6C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Reference) Figure 6C Example configuration 660 provides information sharing with a distributed ledger (i.e., blockchain) 668 for vehicle 662, user equipment 664, and server 666. The server may represent a service provider entity that, in the event that a known and established user profile is attempting to lease a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 666 may be receiving and processing data related to vehicle service requests. As service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., age of 18, qualified candidates, valid driver's license, etc.), value level, distance traveled during the event, recipient of registration to allow entry into the event and preside over vehicle service, permissions / permissions, sensor data retrieved during the vehicle event, details of recording the next service event and actions to identify the vehicle's condition status, and thresholds for determining whether the service event has been completed and whether the vehicle's condition status has changed.

[0131] Figure 6D The illustration shows a blockchain block 680 that can be added to a distributed ledger according to an example embodiment, and the contents of block structures 682A to 682n. (Reference) 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, individual, or entity) to submit entries to 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 may exist in a blockchain network, including endorsing peers that simulate and endorse entries submitted by clients, and submitting peers that verify endorsements, validate entries, and submit them to the distributed ledger. In this example, a blockchain node could act as an endorser node, a submitter node, or both.

[0132] This system comprises a blockchain that stores immutable, ordered 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 copy of the distributed ledger for each channel for which it is a member. This blockchain is an entry log structured as hashed, linked blocks, where each block contains a sequence of N entries. Blocks can include various components, such as... Figure 6D The components shown are linked. Blocks can be linked by adding a hash of the previous block's header to the current block's 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 links. Furthermore, due to the links, the latest block in the blockchain represents every entry that arrived before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports only attached blockchain workloads.

[0133] The current state of a blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest value of all keys ever contained in the blockchain's entry log. Smart contract executables invoke execution entries against the current state in the state database. To make these smart contract executable interactions highly efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after a peer initiates operations but before accepting entries (or generated when needed).

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

[0135] The ordering service accepts endorsed entries, sorts them into blocks, and delivers these blocks to submitting peers. For example, the ordering service can initiate a new block when a threshold of entries has been reached, a timer expires, or other conditions are met. In this example, the blockchain node is the submitting peer, which has received data block 682A for storage on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle input, smart contracts, or maintain a shared ledger. Instead, it accepts endorsed entries and specifies the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

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

[0137] refer to Figure 6DBlock 682A (also known as a data block) stored on the blockchain and / or distributed ledger may include multiple data segments, 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 blocks and their contents depicted, such as block 682A and its contents, are for illustrative purposes only 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, which stores entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A to 690n. Block 682A may also include links to previous blocks (e.g., on the blockchain) within its block header 684A. Specifically, block header 684A may include hashes of the headers of previous blocks. Block header 684A may also include a unique block number, a hash of the block data 690A of the current block 682A, etc. The block number of block 682A may be unique and assigned incrementally / sequentially starting from zero. The first block in the blockchain may be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

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

[0139] In some embodiments, block data 690A may also store transaction-specific data 686A, which adds additional information to the blockchain of hash-linked blocks in the blockchain. Thus, data 686A can be stored in the immutable log of blocks on a 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, the last offset persisted by a sorting service that sorts the blocks, etc. The signature, the last configured block, and the sorter metadata may be added by the 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. The 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.

[0140] Other blocks 682B through 682n in the blockchain also have a header, file, and value. However, unlike the first block 682A, the headers of each of the other blocks 684A through 684n include the hash value of the preceding block. The hash value of the preceding block can be simply the hash 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 trace from the Nth block 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.

[0141] The above embodiments can be implemented using hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program can be implemented 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.

[0142] 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 discrete components. For example, Figure 7 The illustration shows an example computer system architecture 700, which can be represented or integrated into any of the components mentioned above.

[0143] Figure 7 This is not intended to imply any limitation on the scope or functionality of the embodiments of this application described herein. In any case, the compute node 700 is capable of implementing and / or performing any of the functional sets described herein.

[0144] Within compute node 700, there is a computer system / server 702 that can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 702 include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop 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 aforementioned systems or devices.

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

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

[0147] A bus refers to any one or more of several types of bus architectures, including memory buses or memory controllers using any of the various bus architectures, peripheral buses, accelerated graphics ports, and processor or local buses. As an example and not 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.

[0148] Computer system / server 702 typically includes a variety of computer system readable media. Such media can be any available media accessible to computer system / server 702, and it includes 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. By way of 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 may be provided for reading and writing from removable non-volatile disks (e.g., "floppy disks"), and optical disk drives may be provided for reading or writing from removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media). In these cases, each drive may be connected to a bus via one or more data media interfaces. 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.

[0149] A program / utility having a set (at least one) of program modules may be stored in memory 706. By way of example and not limitation, such program modules include an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules typically perform functions and / or methods as described in the various embodiments of this application herein.

[0150] As those skilled in the art will recognize, aspects of this application can be implemented as systems, methods, or computer program products. Therefore, aspects of this application can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which can generally be referred to as "circuit," "module," or "system." Here, aspects of this application can take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0151] The computer system / server 702 can also communicate via I / O device 712 (such as an I / O adapter) with one or more external devices (which may include a keyboard, pointing device, display, voice recognition module, etc.), one or more devices that enable a user to interact with the computer system / server 702, and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., a network card, modem, etc.). Such 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 shown, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown in the figure, other hardware and / or software components can be used in conjunction with the computer system / server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, belt drives, and data archiving storage systems.

[0152] While 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 should be understood that this application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions set forth and defined in the following claims. For example, the capabilities of the systems in the various figures can be executed 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 the various modules can be performed by one or more of these modules. In addition, the functions described herein can be performed at different times and in relation to various events inside or outside the modules or components. Moreover, information transmitted between the 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. Furthermore, messages transmitted or received by any module can be transmitted or received directly and / or via one or more other modules.

[0153] Those skilled in the art will recognize that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the foregoing functionality 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 a localized and distributed manner consistent with computing technologies.

[0154] 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 including custom-designed very large-scale integration (VLSI) circuits or gate arrays, such as off-the-shelf semiconductors of 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.

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

[0156] In practice, a module of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data can be identified and represented within this module, 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 different storage devices, and can exist at least in part as electronic signals on a system or network.

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

[0158] It will be readily understood by those skilled in the art that the above can be practiced using steps in a different order and / or using hardware components in a configuration different from the disclosed configuration. Therefore, while 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.

[0159] While preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application is limited only by the appended claims when considering the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

[0160] Cross-reference to related applications

[0161] This application relates to co-pending U.S. nonprovisional patent application number IP-A-4799 entitled “TRANSPORT OCCUPANT DATA DELIVERY”, which was filed on the same day and is incorporated herein by reference in its entirety.

Claims

1. A method comprising: The server receives requests from third parties for specific data about the means of transport. The server determines the transportation vehicle capable of providing the specific data based on the vehicle's current settings and current route. In response to the determination, the server sends a file containing license information to the vehicle, so that the vehicle applies the current settings according to the license information, and the server can access the vehicle's system resources to collect and retain the specific data according to the license information; The server receives a portion of the specific data that conforms to the license information from the means of transport. The server formats the portion of the specific data into a format specified by the third party. The server sends the formatted specific data to the third party. as well as The server sends the value associated with the specific data to the means of transport. Specifically, when a file containing the license information expires, the specific data is automatically deleted from the vehicle.

2. The method of claim 1, comprising: Identify multiple modes of transport along the current route; and It is determined that one or more of the plurality of vehicles are configured to share the specific data based on one or more passenger profiles and one or more attributes of the one or more vehicles.

3. The method of claim 1, comprising: Identify attributes associated with the current route of the transport vehicle; and The specific data is collected over a period of time based on attributes associated with the current route of the transportation vehicle.

4. The method of claim 1, comprising: Determine the number of passengers in the vehicle at the current time; Determine which portions of the specific data can be captured and shared based on the number of occupants; as well as A portion of the specific data is received based on the number of occupants.

5. The method of claim 1, further comprising receiving verification of the shared specific data from at least one component by the vehicle, wherein the verification comprises blockchain consensus between a peer group consisting of the vehicle and the at least one component.

6. The method of claim 5, comprising executing a smart contract by the means of transport to record the verification and the at least one component on a blockchain based on blockchain consensus.

7. A server, comprising: The processor is configured as Receive requests for specific data about the means of transport from third parties; The transportation vehicle capable of providing the specific data is determined based on its current settings and current route. In response to the determination, the server sends a file containing license information to the vehicle, so that the vehicle applies the current settings according to the license information, and the server can access the vehicle's system resources to collect and retain the specific data according to the license information; Receive a portion of the specific data that conforms to the permit information from the means of transport; Format the specific data portion into a format specified by the third party; Send the formatted specific data to the third party; as well as The value associated with the specific data is sent to the means of transport. Specifically, when a file containing the license information expires, the specific data is automatically deleted from the vehicle.

8. The server of claim 7, wherein the processor is further configured to Identify multiple modes of transport along the current route; and It is determined that one or more of the plurality of vehicles are configured to share the specific data based on one or more passenger profiles and one or more attributes of the one or more vehicles.

9. The server of claim 7, wherein the processor is further configured to Identify attributes associated with the current route of the transport vehicle; and The specific data is collected over a period of time based on attributes associated with the current route of the transportation vehicle.

10. The server of claim 7, wherein the processor is further configured to Determine the number of passengers in the vehicle at the current time; Determine which portions of the specific data can be captured and shared based on the number of occupants; and A portion of the specific data is received based on the number of occupants.

11. The server of claim 7, wherein the processor is further configured to Receive verification of the shared specific data from at least one component, wherein the verification includes blockchain consensus between a peer group consisting of the vehicle and the at least one component.

12. The server of claim 11, wherein the processor is further configured to Execute a smart contract to record the verification and at least one component on the blockchain based on blockchain consensus.

13. A non-transitory computer-readable storage medium configured to store instructions that, when executed, cause a processor to execute: The server receives requests from third parties for specific data about the means of transport. The server determines the transportation vehicle capable of providing the specific data based on the vehicle's current settings and current route. In response to the determination, the server sends a file containing license information to the vehicle, so that the vehicle applies the current settings according to the license information, and the server can access the vehicle's system resources to collect and retain the specific data according to the license information; The server receives a portion of the specific data that conforms to the license information from the means of transport. The server formats the portion of the specific data into a format specified by the third party. The server sends the formatted specific data to the third party. as well as The server sends the value associated with the specific data to the means of transport. Specifically, when a file containing the license information expires, the specific data is automatically deleted from the vehicle.

14. The non-transitory computer-readable storage medium of claim 13, wherein the processor is further configured to execute Identify multiple modes of transport along the current route; and It is determined that one or more of the plurality of vehicles are configured to share the specific data based on one or more passenger profiles and one or more attributes of the one or more vehicles.

15. The non-transitory computer-readable storage medium of claim 13, wherein the processor is further configured to execute Identify attributes associated with the current route of the transport vehicle; and The specific data is collected over a period of time based on attributes associated with the current route of the transportation vehicle.

16. The non-transitory computer-readable storage medium of claim 13, wherein the processor is further configured to execute Determine the number of passengers in the vehicle at the current time; Determine which portions of the specific data can be captured and shared based on the number of occupants; and A portion of the specific data is received based on the number of occupants.

17. The non-transitory computer-readable storage medium of claim 13, wherein the processor is further configured to execute Receive verification of the shared specific data from at least one component, wherein the verification includes blockchain consensus between a peer group consisting of the vehicle and the at least one component.

Images