Safe Data Sharing of Conveyor

Abstract

To provide a method, a server, and a storage medium for providing an optimal route for vehicles including a car, two-wheeled vehicle, truck, aircraft, and train, or a transport.SOLUTION: A method includes one or more of receiving, by a server, a request for particular data, determining, by the server, a transport that can provide the particular data based on one or more current settings of the transport and a current route of the transport, requesting, by the server, the transport to provide the particular data for a value, and receiving, by the server, the particular data.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] Cross - reference to Related Applications This application is related to co - pending U.S. Patent Application Serial No. IP - A - 4799 entitled "Data Delivery to Transportation Users", the content of which is incorporated herein by reference in its entirety and made a part hereof.

Background Art

[0002] Vehicles or transportation machines such as cars, motorcycles, trucks, airplanes, trains, etc. generally satisfy the transportation needs of users and / or goods in various ways. Functions related to the transportation machine can be identified and used by various computing devices such as smartphones or computers located on and / or outside the transportation machine.

Summary of the Invention

[0003] One embodiment provides a method including one or more of: receiving, by a server, a request for specific data; determining, by the server, a transportation machine capable of providing the specific data based on one or more current settings of the transportation machine and the current route of the transportation machine; requesting, by the server, that the transportation machine provide the specific data for value; and receiving, by the server, the specific data.

[0004] Another embodiment provides a transportation machine including a memory communicatively connected to a processor, the processor performing one or more of: receiving a request for specific data; determining a transportation machine capable of providing the specific data based on one or more current settings of the transportation machine and the current route of the transportation machine; requesting that the transportation machine provide the specific data for value; and receiving the specific data.

[0005] A further embodiment provides a non-transitory computer-readable storage medium storing instructions that cause a processor to perform one or more of: receiving, by a server, a request for specific data when read by the processor; determining, by the server, a transporter capable of providing the specific data based on one or more current settings of the transporter and the current route of the transporter; requesting, by the server, that the transporter provide the specific data for value; and receiving, by the server, the specific data. BRIEF DESCRIPTION OF THE DRAWINGS

[0006]

Figure 1A

Figure 1B

Figure 1C

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 2E

Figure 2F

Figure 2G

Figure 2H

Figure 2I

Figure 3A

Figure 3B

Figure 3C

Figure 4

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 7

[0007] As will be readily understood, as described in this specification and shown in the figures, these components can be arranged and designed in a variety of different configurations. Therefore, although embodiments of at least one method, apparatus, non-transitory computer-readable medium, and system will be described in detail later, it is not intended to limit the scope claimed by this application as shown in the attached figures, but merely represents selected embodiments.

[0008] Communication between a transporter and specific entities such as a remote server and local computers (e.g., smartphones, personal computers, computers incorporated into the transporter, etc.) can be received and processed by one or more "components" that can be hardware, firmware, software, or a combination thereof. A component can be any of these entities or computers, or any part of other computers. In one example, the consensus determination related to a blockchain transaction can be made by a computing device or component related to the transporter and one or more components located outside or at a distance from the transporter. A consensus determination or protocol is a process for achieving agreement among one or more nodes or peers in a network regarding values, states, results, inputs, outputs, situations, etc.

[0009] The functions, configurations, or characteristics described herein may be combined in any suitable manner in one or more embodiments. For example, the use of phrases such as "Examples", "Some embodiments", or other similar words throughout this specification means that the specific functions, structures, or characteristics described in relation to the embodiments may be included in at least one embodiment. Thus, "Examples", "In some examples", "In other examples", or similar expressions do not necessarily mean the same group of embodiments throughout this specification, and in one or more embodiments, the described functions, structures, or characteristics may be combined in any suitable manner. In the figures, any connection between elements may permit one-way and / or two-way communication, whether the depicted connection is one-way or two-way. In this solution, the transporter may include one or more of a vehicle, truck, battery electric vehicle (BEV) in a walking area, e-Palette, fuel cell bus, motorcycle, scooter, bicycle, boat, recreational vehicle, airplane, and any object that can be used to transport a person and / or an object from one location to another.

[0010] In addition, although 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. Further, specific types of messages and signaling may be depicted in the examples, but they are not limited to specific types of messages and signaling.

[0011] The examples provide a method, system, component, non - transitory computer - readable medium, device, and / or network that provides at least one of a transporter (also referred to herein as a vehicle or car), a data collection system, a data monitoring system, a verification system, an authentication system, and a vehicle data distribution system. Vehicle state data received in the form of communication messages such as wireless data network communications and / or wired communication messages may be processed to identify the state of the vehicle / transporter and provide feedback to the state and / or changes of the transporter. In one example, a user profile may be applied to a specific transporter / vehicle to authorize a current vehicle event, to authorize a subsequent vehicle rental service, to authorize a service stop at a service station, and to enable the vehicle to perform vehicle - to - vehicle communication.

[0012] In a communication infrastructure, a distributed database is a distributed storage system that includes multiple nodes that communicate with each other. A blockchain is an example of a distributed database that includes an additional dedicated immutable data structure (i.e., a distributed ledger) capable of maintaining records among untrusted members. Untrusted members are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no peer can change the database records without a consensus obtained among the distributed peers. For example, a peer may execute a consensus protocol to verify the storage entries of a blockchain, group the storage entries into blocks, and construct a hash chain through the blocks. The ledger is formed by ordering the storage entries as necessary for consistency through this process. In a public or permissionless blockchain, anyone can participate without a specific identity. A public blockchain may include cryptocurrencies and uses consensus based on various protocols such as proof of work (PoW). In contrast, a permissioned blockchain database can securely enable interactions within a group of entities that share a common goal, such as an enterprise that exchanges funds, goods, information, and the like, but do not fully trust or cannot fully trust each other. This solution can function in an environment of permissioned and / or permissionless blockchains.

[0013] A smart contract is a trusted distributed application that leverages a shared or distributed ledger (which may take the form of a blockchain), tamper resistance, and a basic agreement among member nodes called an endorsement or endorsement policy. Generally, blockchain entries are "endorsed" before being committed to the blockchain, and unendorsed entries are ignored. With a typical endorsement policy, the smart contract executable code can identify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified by the endorsement policy, the entry is executed to verify it. After verification, the entry enters the ordering phase, and a consensus protocol is used to generate an ordered sequence of entries that are endorsed and grouped into blocks.

[0014] A node is a communication entity in a blockchain system. A "node" can perform a logical function such that multiple different types of nodes can be executed on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes can include different types such as a client that submits a call to an entry to an endorser (e.g., a peer) and broadcasts an entry proposal to an ordering service (e.g., an ordering node), or a submitting client node. Other types of nodes can be peer nodes that can receive entries submitted by a client, commit the entries, and maintain a copy of the state and the ledger of blockchain entries. A peer can also serve as an endorser. An ordering service node or orderer is a node that performs a communication service to all nodes and implements a delivery compensation such that when an entry is committed and a change to the blockchain's world state occurs, it broadcasts to each peer node in the system. The world state can typically constitute the initial blockchain entries including control and setup information.

[0015] The ledger is an ordered and tamper-resistant record of all state transitions of the blockchain. State transitions are caused by calls (i.e., entries) to smart contract executable code submitted by participating members (such as client nodes, ordering nodes, endorser nodes, peer nodes, etc.). The result of an entry is a set of key-value pairs of assets that are committed to the ledger as one or more operands of creation, update, deletion, and the like. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable and ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Typically, there is one ledger for each channel. Each peer node maintains a copy of the ledger for each channel of which it is a member.

[0016] The chain is an entry log in the structure of blocks linked by hashes, and each block contains a sequence of N entries. Here, N is 1 or more. The block header includes not only the hash of the header of the preceding block but also the hash of the entries of the block. In this way, all entries of the ledger are ordered and cryptographically linked. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block indicates all entries of the previous chain, enabling the guarantee that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, external storage, cloud, etc.) that effectively supports the property of only addition in the workload of the blockchain.

[0017] The current state of the immutable ledger represents the latest values of all keys included in the chain entry log. Since the current state indicates the latest key values known to the channel, it may be referred to as the world state. Entries are executed against the current state data of the ledger by calls to smart contract executable code. To effectively perform these smart contract executable code interactions, the latest values of the keys may be stored in a state database. The state database may simply be an indexed view of the chain entry log and can thus be regenerated from the chain at any time. The state database may be automatically restored (or created if necessary) when the peer node starts up and before entries are admitted.

[0018] What differentiates a blockchain from a conventional database is that a blockchain is rather a distributed, immutable, and secure storage instead of a central repository, where nodes have to share the changes of the records in the storage. Characteristics that are unique to blockchains and useful for blockchain implementations include, without limitation, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

[0019] Embodiments provide services to a particular vehicle and / or a user profile applicable to the vehicle. For example, the user may be the owner of the vehicle or the driver of a vehicle owned by another party. The vehicle may request services at specific intervals, and the service needs may require authentication before permission to receive the service is granted. Also, the service center may provide services to vehicles in the nearby area according to the vehicle's current route plan and the relative level of service requests (e.g., immediate, severe, moderate, mild, etc.). The vehicle's needs may be monitored by one or more vehicle and / or road sensors, or cameras, which report the sensed data to a central management computer device inside and / or away from the vehicle. This data is transferred to a management server for review and action. The sensors may be provided in one or more locations among inside the transporter, outside the transporter, on a fixed object away from the transporter, and on another transporter in the vicinity of the transporter. The sensors may be associated with the speed of the transporter, the braking of the transporter, the acceleration of the transporter, the fuel level, the service needs, the gear shifting of the transporter, the steering of the transporter, and the like. The sensors described herein may also be devices such as wireless devices inside and / or in the vicinity of the transporter. Also, the sensor information may be used to identify whether the vehicle is operating safely or whether the user is involved in any unexpected vehicle situations such as entry into and / or use period of the vehicle. The vehicle information collected before, during, and / or after the operation of the vehicle may be identified, judged by a consortium that gives permission, and stored in a transaction of a shared / distributed ledger that can be generated and committed to an immutable ledger by a "decentralized" method such as via a blockchain membership group.

[0020] Each stakeholder (i.e., owner, user, company, agency, etc.) may want to limit the exposure of personal information and can thus use blockchain and its immutability to manage permissions to each specific user vehicle profile. Smart contracts can be used for the provision of value (which may be currency, credit, goods, services, and the like), quantification of user profile scores / evaluations / reviews, application of permissions for vehicle events, determination of when services are needed, identification of collision and / or degradation events, identification of safety concern events, identification of event constituents, and provision of distribution to registered entities seeking access to such vehicle event data. Also, results may be identified and shared among registered companies and / or individuals as needed, based on a consensus approach related to the blockchain. Such an approach could not be achieved with conventional centralized databases.

[0021] The various drive systems of this solution can use software, an array of sensors and machine learning capabilities, a light detection and ranging (LIDAR) projector, radar, ultrasonic sensors, etc. to create maps of terrains and roads that the transporter can use for navigation and other purposes. In some embodiments, in autonomous vehicles, GPS, maps, cameras, sensors, and the like can also be used instead of LIDAR.

[0022] This solution, in certain embodiments, includes authenticating a vehicle to a service via an automated and rapid authentication scheme. For example, driving to a charging station or fuel pump may be performed by the vehicle's driver or by an autonomous transport vehicle, and authentication to receive charging or fuel may be performed without delay, provided that the authentication is received by the service and / or charging station. The vehicle may provide a communication signal that provides an identification of the vehicle with a currently active profile associated with an account permitted to receive the service, which may later be modified by providing a value. Additional methods may be used to provide further authentication, such as another identifier being wirelessly transmitted from the user's device to the service center to replace or supplement the initial authentication effort between the transport vehicle and the service center with an additional authentication effort.

[0023] Shared and received data may maintain the data in a single database (e.g., a database server) and may be stored in a database generally located in one specific location. This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can typically be accessed from multiple different locations. A centralized database is easy to manage, maintain, and control, especially for security purposes, because it is in one place. Within a centralized database, there is a single storage location for all data, and a set of data has only one main record, minimizing data redundancy. A blockchain may be used to store data and transactions related to the transport vehicle.

[0024] FIG. 1A is a diagram 100 showing an example of a system for the operation of a transporter according to an embodiment. Referring to FIG. 1A, the system 100 includes a selected transporter 120 that can be selected to provide transporter data to a server 130 responsible for communicating with the transporter 120. The third-party entity 110 can be a stakeholder that is searching for access to transporter data collected by the selected transporter 120. The system 100 may include a request sent from a third-party entity 110, such as a device in communication with a remote server or server 130 responsible for managing data collection related to one or more transporters within a specific area.

[0025] In one embodiment, if the server 130 receives a request 112 for specific transporter data, such as sensor data, road data, user-related data, operation data, etc., the server 130 may identify a transporter that is located and / or operating within a specific region or area and can satisfy the data request related to the data request 112. The data request may include user-specific data, location-specific data, road data, driving behavior data, data usage information, and other transporter data. Examples of user-specific data may include the speed of the transporter, the roads used, the time spent in the transporter, the selection of operations, and other actions of the user. Road data may include the vector movement of the transporter, the time the transporter entered the road, the identified road conditions, the performance of the transporter, etc.

[0026] Server 130 identifies the requested data 112 and identifies the transportation vehicle candidates 114 based on criteria related to the requested data. For example, the requested data may be based on a specific location, the number of users in the transportation vehicle, etc. Transportation vehicles being monitored or of interest in a certain area may be potential candidates if they meet the data request. Server 130 may select only those transportation vehicles identified as desiring to share specific transportation vehicle information that can be identified from the identification sharing setting 116. This determination may be based on the profile of the transportation vehicle stored in server 130 and / or the profile of the user that may be stored in server 130. In another embodiment, the profile of the transportation vehicle may be stored in the third-party device 110, and / or in the transportation vehicle 120, and / or in the profile of the user that may be stored in the third-party device 110 and / or in the transportation vehicle 120. If server 130 selects the transportation vehicle 120 that can provide the specific data requested based on one or more current settings of the transportation vehicle and the current route of the transportation vehicle at 118, server 130 may communicate with the selected transportation vehicle 120 via a wireless communication signal such as a cellular phone communication signal. The communication signal may be transmitted from server 130 to a communication module that communicates with a communication device associated with the selected transportation vehicle 120. The communication device may be an in-vehicle communication module of the transportation vehicle 120 and / or a mobile device located inside and / or fixed on the transportation vehicle.

[0027] The transporter 120 may receive a notification that information collected via in-vehicle sensors is periodically collected and shared. To apply settings to the transporter during data collection and sharing operations, a license file 122 may be retrieved from the server 130 and transferred to the transporter 120. In one embodiment, the license file 122 may be stored in the third-party device 110 and / or within the transporter 120. Data may be collected at 124 along the path of the transporter, and / or over a period of time, and while the transporter is in motion. The data may be transferred to the server 130 at 126, and the data file format specified for the third party 110 may be applied to the data. The completed data may be transferred to the third party at 128 to answer a query for the requested data 112. Once data collection and sharing are complete, the server 130 may receive value (either immediately or for later use) associated with the data, such as by including value in the transporter profile stored in the server 130, and apply the value to the transporter 120.

[0028] Figure 1B shows Example 150 of the selection and use of a transporter during the data sharing process according to an embodiment. Referring to Figure 1B, the server 130 may communicate on the route with a plurality of transporters 162 to 169 or through a communication entity 154 such as a wireless communication device for transmitting and receiving communication from or to them. Each transporter may communicate via a wireless and / or mobile phone-based communication device attached to the transporter or via a mobile device operated by the user. The process may also include determining that one or more of the plurality of transporters 162 to 169 are configured to share data based on one or more user profiles and one or more attributes of one or more transporters. The data request may include a region of interest 152 with a radius (e.g., 20 miles (about 32.2 kilometers)) from a central point, a departure point, a destination, passing through a specific region, etc. All known and participating transporters within the region may be identified to the server 130, which is part of the communication network between the transporters 162 to 169 in that region. If one or more transporters meet the data criteria (e.g., location, action plan, user request, transporter type, weather conditions, road conditions, transporter conditions, etc.), a transporter such as 162 that is qualified is identified to determine whether the sharing request is active for that transporter / user profile. If it meets the criteria, the transporter is selected and monitored for the purpose of data collection.

[0029] During the common procedure operation, server 130 may perform one or more of the following: retrieving a license file from memory, applying one or more current settings of the license file to the transporter before receiving specific data being searched by a third party, and then collecting and / or sharing (which may be another transporter) the specific data with the third party. If the data collection and sharing requirements are met, transporter 162 may be assigned or provided with a value corresponding to the data sharing process. The value may be assigned to a profile, data file, blockchain transaction, or any other data recording structure. The data criteria may include specific requirements for the number of users determinable at the current time before involving in the sharing operation. For example, the requirement may be that only one or at least two users are in the transporter before data collection and sharing. Other requirements may be that the transporter moves to a specific location, a specific distance, and / or operates for a specific time while collecting data. For a specific selected transporter such as 162, a portion of the specific data requested can be identified, captured, and shared based on the number of users and other data requirement conditions, and then shared with the entity of interest. In another example, only a portion of the specific data may be collected based on the number of users. For example, the data requirement may request the collection of specific data of only one user in the transporter, and thus when there are two users in the transporter, only a portion of the data may be collected to meet other data requirements. If one of the users leaves the transporter, other portions of the data may be collected and shared. As a result, additional collection operations may be required to complete the data collection and sharing process. In one embodiment, the value may be provided step by step in response to the reception of data. If the received data is not as desired (the data is incomplete, old, unreadable or incomprehensible, damaged, etc.), sending a message to the transporter and / or reducing the value may be implemented.

[0030] Figure 1C shows a system diagram 170 of a transport vehicle in accordance with an embodiment, in association with a license file. Referring to Figure 1C, a selected transport vehicle 162 may be identified as a candidate for a data collection service by a server 130 prior to a collection effort of specific data. The server 130 may apply a license file 180 to the transport vehicle 162 by a specific process. Information belonging to the license file 180 may be created by an application interface 182 that permits a user / owner of the transport vehicle to access the settings of the license file 180. Specific settings such as the type of data to be shared, when and where the data can be shared, an instruction not to perform data sharing, the frequency of data sharing, the expiration date of the data, the storage device of the data, data usage requirements, etc. may be configured.

[0031] In one embodiment, the transport vehicle 162 may receive an invitation for data sharing, and acceptance of such an invitation may trigger a blockchain transaction. The process may include verification of specific data shared by at least one component of the transport vehicle (as described or depicted herein) or associated with the server 140. The verification may include a blockchain consensus among a peer group consisting of the transport vehicle and at least one component. Also, in response to the occurrence of a transaction, a smart contract for recording the verification and at least one component on the blockchain may be executed by the transport vehicle based on the blockchain consensus.

[0032] In one embodiment, the data may be identified as confidential and / or secure data. This data includes, without limitation, driving data, user data, transportation vehicle data, customer data, vehicle manufacturer data, third-party data. Access to transportation system resources by an application may 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 management of third-party data and personal information of the user (e.g., name, email address, e-mail address, phone number, and / or demographic information). Also of interest may be the utilization of the platform such as information belonging to the Internet provider, browser type, IP address of the website, visited web pages, downloaded and / or consumed multimedia, etc. during data collection operations.

[0033] Data related to the transporter may use license file 180 to manage access by the application to vehicle system resources (such as controller area network data, autonomous driving vehicle mode data, system log data, etc.), access and preferences permitted to the customer within the vehicle (such as digital key / smart key box), access by the application to customer data (such as name, address, positioning location, vehicle internal / external camera data, etc.), and customer consent data such as settings stored in license file 180. License file 180 may be used to determine which data may be transmitted. For example, if the customer / user desires to share data, consent may be documented, and license file 180 may be retrieved, accessed, and updated. When license file 180 expires, the data is automatically deleted from the transporter or one or more third-party servers. The use of license file 180 enables access to the transporter location, automatically complies with local laws, can flexibly respond to changes in laws, and provides the ability to detect / determine which users are in the vehicle and their locations within the vehicle.

[0034] The license file 180 may include the level of consent (e.g., full, partial, none) and data types (e.g., vehicle operation, vehicle location, user activity data, environmental data, sensor data, etc.) that can be provided by the vehicle and / or the driver / user of the vehicle. In some cases, the vehicle and / or the user may be instructed by the data sharing operation to perform specific operations such as sharing of route / location, involvement in charging / fuel interaction, acceleration, deceleration, activation of functions (e.g., brake function, light function, autonomous driving function, etc.), increase / decrease of the operation level, and / or the time when the vehicle is available. Based on the license file, the vehicle may instruct the user to perform specific activities such as turning, traveling on a specific route, at a speed of "y" for "x" minutes, on lane "z", etc. If the requirements are met, the data may be stored in a completion file, sent to a server, authenticated / verified, and confirmed via the server and / or third-party devices.

[0035] In addition to one or more articles and / or services associated with the vehicle, the license file may be associated with one or more passengers / users and / or one or more owners of the vehicle. For example, the vehicle may be scheduled to transport three users and various items such as two parcels and perform one service (such as receiving another parcel, providing power to a grid, etc.). Each user, parcel, and service can have an associated license file that provides the rules and procedures for whether the data related to each user, parcel, and service is retrieved, used, stored, and / or deleted. Each license file can provide different rules and procedures for the same item. For example, a user may wish to provide more data to the vehicle and / or a third party when traveling alone and no data at all when traveling with another passenger. Also, if the third party is of a specific type, the parcel or service type may provide related data (such as price, quantity, use, purchaser, user, etc.), and if the third party is of another type, a subset of the related data may be provided.

[0036] Figure 2A shows a transporter network diagram 200 according to an embodiment. The network includes components including a transporter node 202' including a processor 204' in addition to a transporter node 202 including a processor 204. The transporter nodes 202, 202' communicate with each other via other elements (not shown) including a transceiver, a transmitter, a receiver, a storage device, a sensor, and other elements capable of providing other communications in addition to the processors 204, 204'. The communication between the transporter nodes 202, 202' may occur directly, via a private and / or public network (not shown), or via other transporter nodes and elements including one or more of a processor, a memory, and software. Although depicted as a single transporter node and processor, multiple transporter nodes and processors may exist. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be used and / or provided by this element.

[0037] Figure 2B is a diagram 210 showing another transporter network according to an embodiment. The network includes components including a transporter node 202' including a processor 204' in addition to a transporter node 202 including a processor 204. The transporter nodes 202, 202' communicate with each other via other elements (not shown) including a transceiver, a transmitter, a receiver, a storage device, a sensor, and other elements capable of providing other communications in addition to the processors 204, 204'. The communication between the transporter nodes 202, 202' may occur directly, via a private and / or public network (not shown), or via other transporter nodes and elements including one or more of a processor, a memory, and software. The processors 204, 204' are further communicable with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transporter node 222, a computer 224, an I / O device 226, and a voice application 228. The processors 204, 204' are further communicable with elements including one or more of a processor, a memory, and software.

[0038] Although depicted as a single transport node, processor, and element, there may be multiple transport nodes, processors, and elements. Information or communication may occur to and / or from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204 that causes transport node 202 to initiate action, and further provide information or additional information to processor 204' that causes transport node 202' to initiate action, and further provide information or additional information to mobile phone 220, transport node 222, and / or computer 224. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be used and / or provided by this element.

[0039] FIG. 2C is a diagram 240 showing yet another transport network according to an embodiment. The network comprises an element including a node 205 that includes a processor 204 and a non-transitory computer-readable medium 242C. Processor 204 is communicatively connected to computer-readable medium 242C and element 230 (depicted in FIG. 2B). Node 205 may be, according to an embodiment, a transport, a server, or a combination of both.

[0040] Processor 204 performs one or more of receiving a request for specific data at 244C, determining at 246C a transport capable of providing the specific data based on one or more current settings of the transport and the current route of the transport, requesting at 248C that the transport provide the specific data for value, and receiving the specific data at 250C.

[0041] FIG. 2D is a diagram 250 showing yet another transporter network according to an embodiment. The network comprises elements including a node 205 including a processor 204 and a non-transitory computer-readable medium 242D. The processor 204 is communicatively connected to the computer-readable medium 242D and an element 230 (depicted in FIG. 2B). The node 205 may be a server, a transporter, or a combination of both.

[0042] The processor 204 identifies a plurality of transporters on the current route at 244D, determines that one or more of the plurality of transporters are configured to share specific data based on one or more user profiles and one or more attributes of one or more transporters, pulls a license file at 246D, applies one or more current settings of the license file to the transporter before receiving the specific data, provides the specific data to a third party, and provides value to the transporter, identifies attributes related to the current route of the transporter at 248D, collects specific data over a certain period based on the attributes related to the current route of the transporter, determines the number of users in the transporter at the current time at 250D, determines which portion of the specific data is capturable and shareable based on the number of users, and receives a portion of the specific data based on the number of users, and executes one or more of the above.

[0043] FIG. 2E is a diagram 260 showing yet another transporter network according to an embodiment. Referring to FIG. 2E, the network diagram 260 includes a node 205 connected to other transporter nodes 202' and an update server node 203 via a blockchain network 206. The nodes 205 and 202' may represent transporters / vehicles. The blockchain network 206 may have a ledger 208 for storing software update verification data and a source of verification for future use (e.g., for auditing).

[0044] Although this example has been described in detail, only one node 205 or multiple such nodes may be connected to the blockchain 206. The node 205 may include additional components, and it should be understood that some of the components described in this specification may be removed and / or modified without departing from the scope of the present application. The node 205 may have a computing device or a server computer, or the like, and may include a processor 204 that can be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other hardware devices. Although a single processor 204 is depicted, it should be understood that the node 205 may include multiple processors, multiple cores, or the like without departing from the scope of the present application.

[0045] The processor 204 performs one or more of: receiving verification of specific data shared from at least one component at 244E, where the verification comprises a blockchain consensus between a transport node and a peer group consisting of at least one component; and executing, at 246E, a smart contract for recording the verification and at least one component on the blockchain based on the blockchain consensus.

[0046] All or part of the processor and / or computer-readable medium may be provided inside or outside the transport node. Some or all of the steps or functions stored in the computer-readable medium may be executed by any processor and / or element in any order. In addition, one or more of the steps or functions may be added, deleted, combined, executed later, etc.

[0047] Figure 2F is a diagram 265 showing electrification of one or more elements according to an embodiment. In one embodiment, the transporter 266 may provide the power stored in its battery to one or more elements including other transporters 268, a charging station 270, and an electrical grid 272. The electrical grid 272 is connected to one or more of the charging stations 270 that may be connected to one or more transporters 268. This configuration enables distribution of the electricity / power received from the transporter 266. The transporter 266 may interact with other transporters 268 via vehicle-to-vehicle (V2V) technology, cellular phone communication, WiFi, and the like. The transporter 266 may interact with other transporters 268, the charging station 270, and / or the electrical grid 272 in wireless and / or wired ways. In one embodiment, the transporter 266 is routed (or routes itself) to the electrical grid 272, the charging station 270, or another transporter 268 in a safe and effective manner. Using one or more embodiments of this solution, the transporter 266 can provide energy to one or more of the elements depicted herein in various ways that provide the advantages described and / or depicted herein. Further, the safety and efficiency of the transporter may be improved and may have a positive impact on the environment as described and / or depicted herein.

[0048] The term "energy" may be used to refer to any type of energy received, stored, used, shared, and / or lost by a transporter. Energy may be referred to in conjunction with a voltage source and / or current supply of the charge being provided, supplied from an entity to the transporter during a charging / usage operation. Energy may be in the form of fossil fuel (e.g., for use in a hybrid transporter) or alternative power sources including, without limitation, lithium-based, nickel-based, hydrogen fuel cell, atomic / nuclear energy, energy sources based on nuclear fusion, and energy generated on the fly during energy sharing and / or during an operation of use to increase or decrease the energy level of one or more transporters over a period of time.

[0049] In one embodiment, the charging station 270 manages the amount of energy transferred from the transporter 266 so that there is sufficient charge remaining in the transporter 266 to reach the destination. In one embodiment, a wireless connection is used to wirelessly indicate the amount of energy transfer between transporters 268, and both transporters may be in motion. In one embodiment, an idle vehicle such as vehicle 266 (which may be self-driving) is instructed to provide a certain amount of energy to the charging station 270 and return to its original position (e.g., the place where it was, or a different destination). In one embodiment, a mobile energy storage device (not shown) is used to collect surplus energy from at least one other transporter 268 and transfer the stored surplus energy to the charging station 270. In one embodiment, factors such as distance, time, as well as traffic conditions, road conditions, environmental / weather conditions, the state of the vehicle (weight, etc.), the schedule of the user using the vehicle, the expected schedule of the user waiting for the vehicle, etc. determine the amount of energy transferred to the charging station 270. In one embodiment, the transporter 268, the charging station 270, and / or the electrical grid 272 can provide energy to the transporter 266.

[0050] In one embodiment, the solution described and depicted herein may be used to determine the loading effect of a transporter and / or system, provide energy to the transporter and / or system based on future needs and / or priorities, and provide intelligence that enables a processor of a device, including a module, to wirelessly communicate with a vehicle regarding the amount of energy stored in the vehicle's battery. In one embodiment, the solution may be used to provide charging from a transporter to a location based on factors such as the temperature of the location, the cost of energy, and the power level of the location. In one embodiment, the solution may be used to manage the amount of energy remaining in a transporter after a certain amount of the charge has been transferred to a charging station. In one embodiment, the solution may be used to notify a vehicle that a certain amount of energy is to be provided from the battery of a transporter, and the amount of energy transferred is based on the distance to the module receiving the energy from the transporter.

[0051] In one embodiment, the solution may be used to move excess energy to a transporter using a determined route and to use a mobile energy storage unit to deposit the stored energy into the electrical grid. In one embodiment, the solution can be used to determine the priority of the current needs of the transporter, such as the priority of the determination of the transporter for the need to provide energy to the grid, and the priority of the passengers or future passengers, or the priority of the current cargo or future cargo. In one embodiment, when the vehicle is in an idle state, the solution can be used to move the vehicle to a location to release excess energy to the energy grid and to determine the decision to return to the previous location. In one embodiment, the solution is based on one or more situations such as weather, traffic, road conditions, vehicle condition, and users and / or cargo on another transporter, to determine the amount of energy required by the transporter to provide energy from one transporter to another transporter, and then route the transporter to another transporter and instruct it to provide energy. In one embodiment, the solution can be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, the solution can be used to draw energy from the transporter based on the energy consumed by the transporter to reach a meeting place with another transporter and the estimated energy consumption used when returning to the original place after providing the service. In one embodiment, the solution may be used to provide the remaining distance to the charging station and to determine the amount of energy drawn by the charging station by the transporter, and the remaining charge is based on the remaining distance. In one embodiment, the solution can be used to manage transporters that are charged simultaneously at one or more locations, such as wired from a charging station and wirelessly from another transporter. In one embodiment, the solution can be used to apply priorities to the energy consumption of the transporter and to give priority to transporters that provide a portion of the stored charge to the electrical grid, a residence, and another entity of the same kind.Furthermore, the solution described and depicted with reference to FIG. 2F can be used in this and other networks and / or systems.

[0052] Figure 2G shows the interconnections between different elements 275. The present solution may be stored in and / or executed in whole or in part by one or more of the computers 278’, 279’, 281’, 282’, 283’, 284’, 276’, 285’, 287’ and 277’ that are communicatively connected to and communicate with the network 286 and are associated with various entities. The database 287 is communicatively connected to the network and can store and retrieve data. In one embodiment, the database is an immutable ledger. One or more of the various entities are the transporter 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, the electrical grid / charging station 284, the microphone 285, and / or another transporter 277. One or more other entities and / or devices, one or more private users using a smartphone 278, a laptop 280, and / or a wearable device may cooperate with the present solution. The smartphone 278, the laptop 280, the microphone 285, and other devices may be connected to one or more connected computing devices 278’, 279’, 281’, 282’, 283’, 284’, 276’, 285’, 287’, and 277’. One or more public buildings 281 may include various agencies. One or more public buildings 281 may use the computing device 281’. One or more service providers 279 may include dealerships, tow truck services, collision repair centers or other repair shops. One or more service providers 279 may use the computing device 279’. These various computer devices may be directly and / or communicatively connected to each other via a wired network, a wireless network, a blockchain network, and the like. In one embodiment, the 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 infrastructures. One or more transportation infrastructures 282 may use the computing device 282’.

[0053] In one embodiment, the transporter 277 / 276 is capable of transporting people, objects, permanent or temporarily fixed devices, and the like. In one embodiment, the transporter 277 communicates via V2V communication with the transporter 276 and through a computer associated with each transporter 276' and 277', and may be referred to as a transporter, car, vehicle, automobile, and the like. The transporter 276 / 277 may be a vehicle with self-propelled wheels such as a car, sports utility vehicle, truck, bus, van, or other motor or battery-driven or fuel cell transporter. The transporter 276 / 277 may be an electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Examples of other vehicles may be bicycles, scooters, trains, airplanes, or boats, and any other form of movable vehicle. The transporter 276 / 277 may be semi-autonomous or autonomous. For example, the transporter 276 / 277 may perform auto-pilot and navigate without human input. An autonomous vehicle has one or more sensors and / or a navigation unit and may be used for automatic driving.

[0054] In one embodiment, the solution described and depicted herein may be used to determine access to a transporter via blockchain consensus. In one embodiment, the solution may be used to verify a profile before permitting a user to use a transporter. In one embodiment, the solution indicates, on or from the transporter, actions (which may be pre-recorded) that a user needs to perform (e.g., visually, and in another embodiment, also by adding sound, etc.) and may be used to verify that the actions are correct. In one embodiment, the solution divides data based on a risk level associated with the data and the driving environment, distributes a portion with a low risk level of the divided data among users during a safer driving environment, and gives the transporter the ability to determine a method of distributing the remaining portion with a high risk level of the divided data to the user after the user has left the transporter. In one embodiment, the solution may be used to move a vehicle across boundaries (e.g., countries / states, etc.) and apply the rules of the new area to the vehicle through the use of blockchain and / or smart contracts.

[0055] In one embodiment, the solution may be used to enable the transporter to continue operating beyond the boundary when consensus has been reached by the transporter based on the operation of the transporter and the characteristics of the users of the transporter. In one embodiment, the solution analyzes the available transporter data upload / download speed, file size, and the movement speed / direction of the transporter, and may be used to determine the distance required for data upload / download completion and assign a safe area boundary for the execution of data upload / download. In one embodiment, the solution is used to safely perform normally dangerous operations, such as instructing the transporter and nearby transporters to safely exit when the system determines that an exit is approaching but the transporter appears not to be ready to exit (e.g., is in the wrong lane or moving at a speed that prevents it from exiting from the approaching exit). In one embodiment, the solution may be used to verify the diagnosis of one or more vehicles by another transporter while both the one or more vehicles and the other transporter are in motion.

[0056] In one embodiment, the solution may be used to detect the use of lanes at a certain time and place and notify the users of the transporter, or to recommend or not recommend lane changes to the transporter. In one embodiment, the solution may be used to eliminate the need to send information by email or to reply by the driver / user by making payments directly via email. In one embodiment, the solution may be used to provide services to the users of the transporter, and the services provided are based on subscriptions and obtain permissions from other transporters based on the user profiles. In one embodiment, the solution may be used to record changes in the state of rented objects. In one embodiment, the solution may be used to search for blockchain consensus from other transporters in the vicinity of a damaged transporter. In one embodiment, the solution may be used to receive media from a server such as an insurance company server or from a transporter computer that may be related to an accident. The server accesses the damage of the transporter and accesses one or more media files to store the evaluation of the damage in the blockchain. In one embodiment, the solution may be used to obtain consensus from numerous devices multiple times for the purpose of determining the severity of an event prior to the event related to the transporter.

[0057] In one embodiment, the solution may be used to solve problems that occur due to the lack of video evidence of an accident related to the transporter. This solution details that the transporter involved in the accident makes inquiries about the media related to the accident from other transporters that may have been in the vicinity at the time of the accident. In one embodiment, the solution can be used to record specific parts of a damaged transporter using the transporter and other devices (such as a pedestrian's mobile phone, streetlight camera, etc.).

[0058] In one embodiment, the solution can be used to allow a vehicle to warn a user when the vehicle is heading towards a dangerous area and / or event, and to notify the user or a central controller that a potentially dangerous area exists on or near the current vehicle route. In one embodiment, the solution can be used to detect that a vehicle is traveling at high speed and to assist at least one other vehicle in reducing its speed in a manner that minimizes its impact on traffic. In one embodiment, the solution can be used to identify a dangerous driving situation and to take media by a vehicle involved in the dangerous driving situation. A geofence is established based on the distance from the dangerous driving situation, and additional media is taken by at least one other vehicle within the established geofence. In one embodiment, the solution may be used to send a notification to one or more users of a vehicle that the vehicle is approaching a traffic control mark on the road, and if the vehicle crosses the mark, to receive an indication from other nearby vehicles that the driving skill is low. In one embodiment, the solution may be used to partially disable (in certain embodiments) the vehicle in a manner such as speed limit, limit on the ability to approach other vehicles, limit to a maximum speed, permission for only a certain number of miles given in a certain time.

[0059] In one embodiment, the solution may be used to overcome the need for software updates to correct problems with the transporter when the transporter is not being operated correctly. By observing other transporters along a route, the server receives data from multiple other potentially transporters that have been observed to be operating unsafely or incorrectly. Through analysis, when these observations suggest an unsafe or incorrect operation from the data, a notification is consequently sent to the transporter. In one embodiment, the solution may be used to provide notifications between the transporter and potential dangerous situations involving people outside the transporter. In one embodiment, the solution may be used to transmit data from a device related to an accident of the transporter or from a device in the vicinity of the accident to the server. Based on the severity of the accident or the situation near the accident, the server notifies the sender of the data. In one embodiment, the solution may be used to provide recommendations to the driver or user of the transporter regarding the operation of the transporter based on the analysis of the data. In one embodiment, the solution may be related to the physical structure and may be used to establish a geopreference for determining the liability for payment of the transporter. In one embodiment, the solution can be used to coordinate the ability to abandon a vehicle at a location based on both the current state at that location and the proposed future state using the navigation destinations of other vehicles. In one embodiment, the solution may be used to coordinate the ability to automatically arrange for the pickup and drop-off of a vehicle at a location, such as a transporter rental operator.

[0060] In one embodiment, the solution may be used to move a transporter to another location based on a user event. More specifically, the system tracks the user's device and changes the transporter to move near the user upon the end of the original or modified event. In one embodiment, the solution may be used to permit verification of available locations within an area through transporters present in the area. Based on verification from the present transporters, an approximate time when a location becomes available may be determined. In one embodiment, the solution may be used to move the transporter to a closer parking space when the parking space becomes available in a situation where the time from the time of first parking is shorter than the average time of that event. Further, when the event is completed, or the transporter is moved to the final parking space according to the position of the device associated with at least one user of the transporter. In one embodiment, the solution may be used to plan parking before a future crowd. The system interacts with the transporter, provides the service at the highest to lowest price, and / or guides the transporter to an alternative parking location based on the priority of the transporter to optimize the parking situation before arrival.

[0061] In one embodiment, the solution may be used to sell fractional ownership of a transporter or to determine the availability of valuation and ride-sharing. In one embodiment, the solution may be used to provide an accurate and timely report of a store's sales far beyond what is currently available. In one embodiment, the solution may be used to enable a store to claim assets on a blockchain. By using a blockchain, consensus can be obtained before any asset is transferred. Additionally, since the process is automated, payments can be initiated via the blockchain. In one embodiment, the solution may be used to arrange an agreement by multiple entities (such as a service center) where consensus is obtained and an action (such as a diagnosis) is taken. In one embodiment, the solution may be used to associate digital keys with multiple users. The first user may be a driver of a transporter, and the second user may be an operator responsible for the transporter. These keys are authenticated by a server, and the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution may be used to determine the services required at the destination of a transporter. There are one or more service locations within the area along the route to the destination that can provide the required services and have the availability to perform the services. The navigation of the transporter is updated based on the determined service locations. A smart contract including the value of the service is identified, and the blockchain transaction of this transaction is stored in a distributed ledger.

[0062] In one embodiment, the solution may be used to interface a service provider's vehicle to a vehicle user's profile in order for the vehicle user to determine services and items that may be of interest. These services and items are determined from the user's history and / or preferences. The vehicle receives an offer from the service provider from the vehicle, and in another embodiment, meets with the vehicle providing the service / item. In one embodiment, the solution may be used to detect vehicles in a range and send service proposals (repair proposals, product proposals, or the like) to the vehicles. An agreement is made between the system and the vehicle, and the service provider providing the agreement by the system is selected. In one embodiment, the solution may be used to allocate one or more vehicles as road administrators to assist in traffic control. The road administrator may generate road indicators (such as lights, displays, sounds, etc.) to assist in the flow of traffic. In one embodiment, the solution may be used to warn the driver of a vehicle by a device located near a traffic signal or intersection. The warning is sent in the event of an event such as the signal turning green but the leading vehicle in the vehicle column not moving.

[0063] FIG. 2H is a block diagram 290 showing another example of the interconnection between different elements. A transporter 276 is presented that includes an ECU 295, an ECU 296, and a head unit (also known as an infotainment system) 297. An electronic control unit (ECU) is an embedded system of automotive electronics that controls one or more electrical systems or subsystems of a transporter. The ECU may include, without limitation, the management of the transporter's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, differential electronic circuit, and active suspension. The ECU is connected to the controller area network (CAN) bus 294 of the transporter. The ECU may also communicate with the transporter computer 298 via the CAN bus 294. The processor / sensor of the transporter (such as the transporter computer) may communicate, via a network 292 (such as the Internet), 298 with an external element such as a server 293. Each ECU 295, ECU 296, and head unit 297 may include its own security policy. The security policy defines permissible processes that can be executed in an appropriate context. In one embodiment, the security policy may be provided, in part or in whole, within the transporter computer 298.

[0064] ECU 295, ECU 296, and the head unit 297 may each include a custom safety function element 299 that defines the permitted processes and the context in which the processes are permitted to run. Context-based authentication that determines the validity of whether a process may be executed enables the ECU to maintain safe operation and prevent unauthorized access from elements such as the controller area network (CAN bus) of the vehicle. If the ECU encounters an unauthorized process, the ECU can block the process from operating. An automotive ECU can use different contexts such as the local context, such as the proximity to nearby objects, the distance to approaching objects, speed, and relative trajectories to other moving objects, whether the vehicle is in motion or parked, the current speed of the vehicle, the state of the transmission, etc., the operational context, devices connected to the vehicle via a wireless protocol, the use of infotainment, driving control, parking assistance, driving assistance, etc., the user-related context, location-based context, and / or other contexts to determine whether the process is being used within the permitted boundaries.

[0065] In one embodiment, the solutions described and depicted herein may be used to partially disable a transporter (in certain embodiments) in ways such as speed limit, limitation on the ability to approach other vehicles, limitation to a maximum speed, permission for only a certain number of miles given in a time period. In one embodiment, the solution may be used to send data from a device associated with a transporter involved in an accident or from a device in the vicinity of the accident to a server and to use a blockchain to facilitate the exchange of vehicle ownership. Based on the severity of the accident or near-accident condition, the server notifies the sender of the data. In one embodiment, the solution can be used by a server to query other transporters in the vicinity of an accident in case a transporter gets involved in an accident, so that the transporter can avoid the accident. The server tries to obtain data from other transporters and the server becomes able to understand the characteristics of the accident from multiple advantageous positions. In one embodiment, the solution determines that the sound of a transporter is abnormal, sends data related to the sound and the location of the possible sound source to the server, and the server can determine the possible cause and use it to avoid a potentially dangerous situation. In one embodiment, the solution can be used to establish a position boundary via a system when a transporter gets involved in an accident. This boundary is based on the decibel value associated with the accident. Multimedia content of devices within the boundary is obtained to further understand the accident scenario. In one embodiment, the solution may be used to associate a vehicle with an accident and capture the media obtained by a device in the vicinity of the location of the accident. The captured media is stored as a media segment. The media segment is sent to another computing device that constructs an audio profile of the accident. The audio profile helps to understand more details surrounding the accident.

[0066] In one embodiment, the solution may be used to record audio, video, actions, etc. in order to record areas where potential events have occurred, such as the vehicle coming into contact with or potentially coming into contact with another vehicle (while in motion or parked), and the system captures data from sensors that may be on one or more vehicles and / or belong to fixed or moving objects. In one embodiment, the solution may be used to determine that a vehicle has malfunctioned using sensor data, identify new situations of the vehicle during a vehicle event, and compare the situation with the vehicle's situation profile, enabling critical data to be safely and reliably obtained from a vehicle that may be involved in a harmful event.

[0067] In one embodiment, the solution can be used to warn the vehicle user when the vehicle is determined to be moving in the wrong direction on a one-way street via one or more sensors. The vehicle has sensors / cameras / maps that interact with the system of this solution. The system knows the geographical location of the one-way street. The system may audibly inform the user that they are "approaching a one-way street". In one embodiment, the solution monetizes the data collected and stored by vehicle sensors by the owner of an autonomous vehicle, creates an incentive for the vehicle owner to improve the performance of future vehicles and share data for providing services to the vehicle owner, etc., and provides additional data to the entity, and may be used for the vehicle to obtain a reward.

[0068] In one embodiment, the solution may be used to increase or reduce the vehicle's functions according to the vehicle's operation over a period of time. In one embodiment, the solution may be used to assign fractional ownership to a transporter. Sensor data related to one or more transporters and devices in the vicinity of the transporter is used to determine the state of the transporter. The fractional ownership of the transporter is determined based on the state, and new responsibilities for the transporter are provided. In one embodiment, the solution may be used to provide data to components for exchange / upfit, where the data attempts to impair the authenticated functions of the components for exchange / upfit, and the components permit the components for exchange / upfit to use the authenticated functions provided that the authenticated functions are not impaired.

[0069] In one embodiment, the solution may be used to give an individual the ability to ensure that the user is inside the transporter and that the user reaches a specific destination. Further, the system ensures that the driver (in the case of a non-autonomous transporter) and / or other users interact with the user. Also, boarding, alighting, and location are notified. All of the above are stored in an immutable form on the blockchain. In one embodiment, the solution may be used to determine the driver's characteristics through analysis of driving style and other factors, and to take action when the driver is not driving in the normal way, such as how the driver has driven in specific situations such as during the day, at night, in rain, snow, etc. Further, the attributes of the transporter are also taken into account. The attributes consist of weather, whether the headlights are on, whether navigation is in use, whether HUD is in use, the volume of the media being played, etc. In one embodiment, the solution may be used to notify a user inside a transporter in a dangerous situation when an item inside the transporter indicates that the user is unaware of the dangerous situation.

[0070] In one embodiment, the solution may be used to mount a calibration device on equipment fixed to a vehicle, and can be automatically fine-tuned based on a comparison between what various sensors of the transport machine actually detect and what should be detected by the calibration device. In one embodiment, the solution can be used to use a blockchain to request a consensus from multiple service centers when a transport machine in need of service transmits information about a failure that enables a remote diagnosis function, and at that time, a consensus from other service centers regarding the severity threshold of the data is required. Once the consensus is received, the service center transmits it to store the safety level of the failure in the blockchain. In one embodiment, the solution may be used to determine the difference between the data of sensors outside the transport machine and the sensor data of the transport machine itself. The transport machine requests software for fixing the problem to the server. In one embodiment, the solution can be used to enable message exchange by transport machines in the vicinity or in that area when an event (e.g., a collision) occurs.

[0071] Referring to FIG. 2I, the operating environment 290A of a connected transport machine in some embodiments is shown. As depicted, the transport machine 276 includes a Controller Area Network (CAN) bus 291A that connects elements 292A through 299A of the transport machine. Other elements may be connected to the CAN bus but are not depicted here. The depicted elements connected to the CAN bus include a sensor set 292A, an electronic control unit 293A, an autonomous function or Advanced Driver Assistance System (ADAS) 294A, and a navigation system 295A. In one embodiment, the transport machine 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0072] Processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose control device, and / or a similar processor array that executes calculations and transmits an electronic display signal to the display unit 299A. Processor 296A can include various computer architectures that process data signals and include an architecture that implements a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or a combination of instruction sets. The transporter 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical structures (not shown) that are communicably connected to each other may be used in this solution.

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

[0074] The memory 297A of the transporter 276 may store one or more types of data among the navigation route data 295A and the autonomous function data 294A. In some embodiments, the memory 297A stores data that may be required for the navigation application 295A to provide functions.

[0075] The navigation system 295A may describe at least one navigation route including a start point and a final point. In one embodiment, the navigation system 295A of the transport device 276 receives a request from the user including the start point and the final point regarding the navigation route. The navigation system 295A may inquire (via the network 292) a real-time data server 293 such as a server providing a driving direction about navigation route data regarding the navigation route including the start point and the final point. The real-time data server 293 transfers the navigation route data to the transport device 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the transport device 276.

[0076] The ECU 293A controls many operations of the systems including the ADAS system 294A of the transport device 276. The ECU 293A may respond to an instruction received from the navigation system 295A and deactivate any autonomous functions that are not safe and / or not selected during the journey controlled by the ADAS system 294A. In this way, the navigation system 295A may control its activation or activation state so as to be activated for the navigation route given by the ADAS system 294A.

[0077] Sensor set 292A may include any sensors that generate sensor data within transporter 276. For example, sensor 292A may include sensors for short distances and sensors for long distances. In certain embodiments, the sensor set 292A of transporter 276 includes a camera, a LIDAR sensor, an ultrasonic sensor, an automotive engine sensor, a radar sensor, a laser altimeter, an intake pressure sensor, an infrared detector, a motion sensor, a thermostat, a sound detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, an air volume sensor, an engine refrigerant temperature sensor, a throttle opening sensor, a crankshaft position sensor, a valve timer, an air-fuel ratio meter, a blind spot monitor, a curve feeler, a defect detector, a Hall effect sensor, a parking sensor, a radar gun, a speedometer, a speed sensor, a tire pressure monitoring sensor, a torque sensor, a transmission fluid temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a moisture sensor, a wheel speed sensor, a GPS sensor, a mapping function, and one or more of vehicle sensors such as any other type of automotive sensor. Navigation system 295A may store sensor data in memory 297A.

[0078] Communication unit 298A transfers and receives data to / from network 292 or to / from other communication channels. In certain embodiments, communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make transporter 276 a DSRC-equipped device.

[0079] Transporter 276 may interact with other transporters 277 via V2V technology. In one embodiment, V2V communication senses radar information regarding the relative distance to external objects, receives GPS information of the transporter, sets an area as the area where other transporters 277 are located based on the sensed radar information, calculates the probability that the GPS information of the target vehicle is located in the set area, and identifies transporters and / or objects related to the radar information and GPS information of the target vehicle based on the calculated probability.

[0080] In one embodiment, the solution described and depicted herein can be used for emergency scenarios and the management of vehicle functions when it is determined that the vehicle has entered an area without network access. In one embodiment, the solution can be used to manage and provide vehicle functions (such as audio, video, navigation, etc.) without a network connection. In one embodiment, the solution can be used to determine whether the profile of a person near the vehicle matches the profile attributes of at least one user profile inside the vehicle. A notification is sent from the vehicle to establish communication.

[0081] In one embodiment, the solution can be used to analyze the convenience of users who are inside each vehicle and are convenient for voice communication based on the remaining time inside the vehicle and the context of the communication to be made. In one embodiment, the solution can be used to determine two levels of threat of road obstacles, receive gestures that may indicate that the warning has not risen above the threshold due to the obstacles, and be used by the vehicle to proceed along the road. In one embodiment, the solution may be used to delete confidential data from the vehicle if the vehicle is damaged to the point where it can no longer be used.

[0082] In one embodiment, the solution may be used to verify that customer data that should be deleted has actually been deleted from all required locations within an enterprise implementing GDPR compliance. In one embodiment, the solution may be used to provide consideration in exchange for data regarding safety, important notifications, etc. from one transporter to another in order to enhance the autonomous performance of low-level autonomous vehicles. In one embodiment, the solution may be used to provide a transporter with the ability to receive data based on a first biometric measurement related to a user. And the transporter decrypts the encrypted data based on verification of a second biometric measurement that is a continuum of the first biometric measurement. Since a confidential portion is provided and a non-confidential portion is provided after a certain time has elapsed related to the biometric measurement, the transporter provides the user with the unencrypted data when only the user can receive the unencrypted data and delete the confidential portion of the decrypted data. In one embodiment, the solution may be used to give a transporter the ability to verify an individual based on weight and the gripping pressure applied to the transporter's handle. In one embodiment, the solution may be used to provide a vehicle with the function of presenting to a vehicle user a function that reflects the characteristics of a user who exists but is not currently activated.

[0083] In one embodiment, the solution may be used to enable changes to the interior of the transport vehicle, in addition to the exterior of the transport vehicle, in particular to reflect and assist at least one user with respect to the transport vehicle. In another embodiment, it is disclosed to recreate the user's work and / or home environment. The system attempts to "recreate" the user's work and / or home environment when it determines whether the user is in "work mode" or "home mode" while the user is inside the transport vehicle. All data inside and outside the transport vehicle, in addition to the various users using the transport vehicle, is stored in a blockchain and executed via a smart contract. In one embodiment, the solution may be used to detect the user's gestures so that the transport vehicle can communicate with nearby transport vehicles and steer according to the results. In one embodiment, the solution may be used to provide a transport vehicle with the ability to detect intended gestures using a data storage device for gesture definitions for a particular transport vehicle. In one embodiment, the solution may be used to provide a transport vehicle with the ability to take various actions based on the user's footsteps and gestures. In one embodiment, the solution may be used to ensure that the driver of a transport vehicle currently involved in various operations (e.g., driving while navigating and conversing) does not exceed the number of unsafe operations before being permitted to gesture.

[0084] In one embodiment, the solution may assign a status to each user within the transporter and use it to verify the user's gestures from the user's status. In one embodiment, the solution may collect details of sounds related to a collision (at what position, in what direction, ascending or descending, from which device, data related to the device such as type, manufacturer, owner, etc., as well as the number of simultaneous sounds and the number of times the sound was emitted, etc.) and provide it to the system for use in analyzing the data to help determine the details of the collision. In one embodiment, the solution may be used to provide a determination that the transporter is not safe to operate. The transporter includes a plurality of components that are interoperated to control the transporter, and each component is associated with a separate component key. An encryption key is sent to the transporter to reduce the functionality of the transporter. Upon receiving the encryption key, the transporter invalidates one or more component keys. Invalidating one or more component keys results in one or more of the following: the transporter is restricted from moving faster than a given speed, the transporter is prevented from approaching another transporter closer than a certain distance, and the transporter is prevented from traveling a distance greater than a threshold.

[0085] In one embodiment, the solution may be used to provide instructions from one particular (vacating a location) transporter to another particular (seeking a location to occupy) transporter and perform authentication and coordination using a blockchain. In one embodiment, the solution may be used to determine a partial responsibility of the transporter. If a single transporter is owned by multiple people, the system uses the usage situation of the transporter, which changes over time, to update fractional ownership. Other embodiments include minimal ownership of the transporter based on the availability of the transporter rather than its usage, as well as applications that include the judgment of the transporter's driver and other people.

[0086] In one embodiment, the solution can be used within a transporter for a user to permit his / her subscription to a closed group of people such as family or friends. For example, the user may want to share the membership, and if so, the relevant transactions are stored in a blockchain or a conventional database. If a subscribed material is requested by a user who is not the primary subscriber, the blockchain node (i.e., the transporter) can verify that the person who requested the service is a permitted person to whom the subscriber has shared the profile. In one embodiment, the solution may be used to enable a person to use an auxiliary transporter to reach the intended destination. Functional relevance values (e.g., various parameters for determining which type of alternative transporter to use and values indicating their importance) are used to determine the auxiliary transporter. In one embodiment, the solution may be used to allow a user who has been in an accident to access another transporter to continue moving towards the original destination.

[0087] In one embodiment, the solution may be used to propagate the upload of software / firmware to a first subset of vehicles. This first subset of vehicles tests the update, and if the test is successful, the update is propagated to a further set of vehicles. In one embodiment, the solution may be used to propagate a software / firmware update from a master vehicle to a vehicle, and the update is propagated through the vehicle's network to a larger subset, etc. from the first subset. A part of the update may be sent first, and the remaining part may be sent from the same vehicle or from another vehicle. In one embodiment, the solution may be used to provide an update to a vehicle computer of a vehicle and to the devices of the driver / user of the vehicle. The update is presumably permitted by all drivers and / or users. The software update is provided to the vehicle and the devices. The user does not need to do anything, but if they go near the vehicle, the function is automatically executed. A notification that the software update is complete is sent to the device. In one embodiment, the solution may be used to generate a status regarding the verification that an OTA software update is executed by a qualified technician, and the creator of the verification code, the procedure for wirelessly receiving the software update, the information included in the software update, and the result of the verification, by components of one or more vehicles.

[0088] In one embodiment, the solution may be used to provide the second component with the ability to decrypt software updates located at the first component. Then, verify the first part of the critical update and the second part of the non-critical update, allocate the verified first part to one process of the transporter, execute the verified first part by one process for a period of time, and in response to a positive result during that period, execute the verified first part together with another process after that period. In one embodiment, the solution may be used to provide service selection to the user, and the service is based on the user profile of the transporter user and the shared profile shared with the user profile. In one embodiment, the solution may store user profile data in a blockchain and use it to intelligently propose and recommend to the user from the automatically collected user purchase history and preferences obtained from the user profile of the blockchain.

[0089] Figure 3A shows a flowchart 300 of an example. Referring to Figure 3A, the processor may perform one or more of receiving a request for specific data at 302, determining at 304 a transporter capable of providing specific data based on one or more current settings of the transporter and the current route of the transporter, requesting at 306 to provide the transporter with specific data for value, and receiving the specific data at 308.

[0090] FIG. 3B shows another flow diagram 320 of an embodiment. Referring to FIG. 3B, the processor identifies a plurality of conveyors on the current route at 322, determines that one or more of the plurality of conveyors are configured to share specific data based on one or more user profiles and one or more attributes of one or more conveyors, retrieves a license file at 324, applies one or more current settings of the license file to the conveyor before receiving the specific data, provides the specific data to a third party, and provides value to the conveyor, identifies attributes related to the current route of the conveyor at 326, collects specific data over a certain period based on the attributes related to the current route of the conveyor, determines the number of users in the conveyor at the current time at 328, determines which portion of the specific data can be captured and shared based on the number of users, and receives a portion of the specific data based on the number of users, and may perform one or more of the above.

[0091] FIG. 3C shows yet another flow diagram 340 of an embodiment. Referring to FIG. 3C, the processor may receive verification of specific data shared from at least one component at 342, where the verification comprises a blockchain consensus between a conveyor and a peer group comprising at least one component, and execute a smart contract for recording the verification and at least one component on the blockchain based on the blockchain consensus at 344, and may perform one or more of the above.

[0092] FIG. 4 shows a diagram 400 of a machine learning conveyor network according to an embodiment. Network 400 includes conveyor nodes 402 that interface with a machine learning subsystem 406. The conveyor nodes include one or more sensors 404.

[0093] The machine learning subsystem 406 is a mathematical artifact created by the machine learning training system 410 and includes a learning model 408 that generates predictions by discovering patterns in one or more training data sets. In certain embodiments, the machine learning subsystem 406 belongs inside the transporter node 402. In other embodiments, the machine learning subsystem 406 belongs outside the transporter node 402.

[0094] The transporter node 402 sends data from one or more sensors 404 to the machine learning subsystem 406. The machine learning subsystem 406 provides the data from the one or more sensors 404 to the learning model 408, and the learning model 408 returns one or more predictions. The machine learning subsystem 406 sends one or more instructions to the transporter node 402 based on the predictions from the learning model 408.

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

[0096] Figure 5A shows a configuration example 500 of a vehicle for managing database transactions related to a vehicle according to an embodiment. Referring to Figure 5A, a specific transporter / vehicle 525 is involved in transactions (e.g., vehicle services, dealership transactions, delivery / collection, transportation services, etc.), and the vehicle may receive an asset at 510 and / or release / transport an asset at 512 according to the transaction. A processor 526 of the transporter exists within the vehicle 525, and there is communication between the transporter processor 526, the database 530, the transporter processor 526, and the transaction module 520. The transaction module 520 may record information such as assets, crew members, credits, service descriptions, dates, times, locations, results, notifications, unexpected events, etc. These transactions within the transaction module 520 may be replicated in the database 530. The database 530 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, may be mounted on the transporter, may not be mounted on the transporter, may be directly and / or accessible via a network, or may be accessible to the transporter.

[0097] Figure 5B shows vehicle configuration example 550 for the management of database transactions carried out between various vehicles according to an embodiment. When the vehicle reaches a state where the service needs to be shared with another vehicle, vehicle 525 interacts with another vehicle 508 and performs various actions such as sharing, transporting, obtaining service calls, etc. For example, vehicle 508 may be approaching its battery charging deadline and / or have a problem with its tires and be on the way to pick up the goods to be delivered. The transporter's processor 528 is present within vehicle 508, and there is communication between the transporter processor 528, database 554, and transaction module 552. Vehicle 508 notifies another vehicle 525 that is within its network and operating on its blockchain member service. The transporter's processor 526 is present within vehicle 525, and there is communication between the transporter processor 526, database 530, transporter processor 526, and transaction module 520. Vehicle 525 may receive information about a request to pick up goods via wireless communication from vehicle 508 and / or a server (not shown). The transaction is recorded in the transaction modules 552 and 520 of both vehicles. Credit is transferred from vehicle 508 to vehicle 525, and assuming the blockchains are different one by one, the record of the transferred service is recorded in database 530 / 554 or in the same blockchain used by all members. Database 554 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, may be installed on the transporter, may not be installed on the transporter, and may be accessible directly and / or via the network.

[0098] FIG. 6A shows a blockchain architecture configuration 600 according to an embodiment. Referring to FIG. 6A, the blockchain architecture 600 may include certain blockchain elements, such as a group of blockchain member nodes 602 to 606, as part of a blockchain group 610. In one embodiment, for a permissioned blockchain, only members with access permission to the blockchain data, rather than all parties, can access it. Blockchain nodes participate in various activities such as the addition and verification process (consensus) of blockchain entries. One or more blockchain nodes may endorse entries according to an endorsement policy and provide an ordering service to all blockchain nodes. Blockchain nodes initiate blockchain actions (such as authentication), search for and write to the immutable ledger of the blockchain stored in the blockchain, and a copy is also stored in the underlying physical infrastructure that supports it.

[0099] When a transaction is received, the blockchain transaction 620 is stored in the computer's memory and approved by a consensus model defined by the member nodes. The approved transaction 626 is stored in the current block of the blockchain and committed to the blockchain via a commit procedure that includes hashing the data content of the transaction to the current block and referencing the previous hash of the previous block. Within the blockchain, there may be one or more smart contracts 630 that define actions included in the transaction agreement and the smart contract executable application code 632, such as registered recipients, vehicle functions, requests, permissions, sensor thresholds, etc. The code may identify whether the entity making the request is registered to receive vehicle services, what service characteristics they have the right / claim to receive in light of their profile status, and whether to monitor their actions at subsequent events. For example, a service event may occur while a user is in the vehicle, triggering sensor data monitoring, and it may be identified that a specific parameter, such as the vehicle's charge level, exceeds / falls below a specific threshold over a specific period, and as a result, the current state may be changed, and it may be required to send a warning to the parties responsible for management (i.e., vehicle owner, vehicle operator, server, etc.), whereby the service can be identified and stored for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle's state. The sensor data may be the basis of vehicle event data 634, such as the location to move to, average speed, maximum speed, acceleration, whether a collision has occurred, whether the expected route has been traveled, what the next destination is, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All such information may be the basis for the smart contract conditions 630 and stored in the blockchain. For example, the sensor thresholds stored in the smart contract may be used as the basis for determining whether the detected service is required and when and where the service should be executed.

[0100] Figure 6B shows the configuration of the shared ledger according to the embodiment. Referring to Figure 6B, the blockchain logic example 640 includes a blockchain application interface 642 as an API or a plugin application linked to a computing device and an execution platform for a specific transaction. The blockchain configuration 640 may include one or more applications that can access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), can be created by a customized configuration sought by participants, can maintain its own state, can control its own assets, and can receive external information. This can be deployed and installed as an entry on all blockchain nodes via addition to the distributed ledger.

[0101] The smart contract application code 644 provides the basis for blockchain transactions by establishing application code such that transaction terms are enabled when executed. The smart contract 630, when executed, causes the generation of specific approved transactions 626 and transfers them to the blockchain platform 652. The platform includes a computing device 656 that executes security / authentication 658 and transaction management, and a storage unit 654 as a memory that stores transactions and smart contracts in the blockchain.

[0102] The blockchain platform may be used to provide access to blockchain data, services (such as encryption credit services, virtual execution environments, etc.), and various layers of underlying physical computer infrastructure that receive and store new entries and seek access to data entries for auditors. The blockchain may expose an interface that provides access to a virtual execution environment necessary to process program code and involve the physical infrastructure. The encryption credit service may be used to verify entries such as asset exchange entries and keep information private.

[0103] The configuration of the blockchain architecture in FIGS. 6A and 6B may process and execute program / application code by the blockchain platform via one or more exposed interfaces and provided services. By way of non-limiting example, smart contracts may be created to make reminders, updates, and / or other notifications that are conditions such as changes, updates, etc. Smart contracts may be used to identify rules related to authentication and access the ledger's requests and uses. For example, the information may include new entries that may be processed by one or more processing entities (such as processors, virtual machines, etc.) included in the blockchain layer. The result may include a decision to reject or approve a new entry based on criteria defined within the smart contract and / or the consensus of peers. The physical infrastructure may be used to retrieve any data or information described herein.

[0104] Within the smart contract executable code, the smart contract may be created via a high-level application and programming language and written into the blocks of the blockchain. The smart contract may include executable code that is registered, stored, and / or replicated on a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of smart contract code that can be executed in response to the conditions related to the smart contract being met. The execution of the smart contract triggers a trusted change in the state of the digital blockchain ledger. The changes to the blockchain ledger caused by the execution of the smart contract are automatically replicated into the distributed network of blockchain peers through one or more consensus protocols.

[0105] The smart contract may write data to the blockchain in the format of key-value pairs. Further, the smart contract code can read the values stored on the blockchain and use them for application operations. The smart contract code can write the outputs of various logical operations to the blockchain. The code may be used to create temporary data structures within a virtual machine or other computing platform. The data written to the blockchain may be public and / or encrypted and maintained as private. The temporary data used / created by the smart contract is held in memory by the provided execution environment and deleted once the data required by the blockchain is identified.

[0106] Smart contract executable code may include code interpretation of smart contracts and other functions. As described herein, smart contract executable code may be program code that is deployed on a computing network and executed and verified together by chain validators during a consensus process. Smart contract executable code receives a hash and extracts from the blockchain a hash related to a data template created by using a previously stored feature extractor. When the hash of the hash identifier matches the hash created by the stored identifier's template data, the smart contract executable code sends an authentication key to the requested service. Smart contract executable code may write data regarding encryption details to the blockchain.

[0107] FIG. 6C shows the configuration of a blockchain for storing blockchain transaction data according to an embodiment. Referring to FIG. 6C, configuration example 660 provides vehicle 662, user device 664, and server 666 that share information with a distributed ledger (i.e., a blockchain) 668. The server may represent an entity of a service provider that queries a vehicle service provider to share user profile rating information in the event that a known and established user profile is attempting to rent a vehicle with an established and rated profile. Server 666 may receive and process data related to service requests for the vehicle. Smart contracts may be used to call rules, thresholds, sensor information collection, etc. to call a vehicle service event when a service event occurs, such as when vehicle sensor data indicates a need for fuel / charging, maintenance service, etc. Blockchain transaction data 670 is stored for each transaction, such as access events, subsequent updates to the service state of the vehicle, event updates, etc. The transaction may include members of the configuration, requirements (e.g., being 18 years old, service eligible candidate, valid driver's license, etc.), value levels, distance traveled during the event, recipients who are permitted and registered to access the event and host vehicle services, rights / permissions, sensor data obtained during vehicle event operations to identify the vehicle's situation by leaving a log of details of the next service event, and thresholds used to determine whether the service event has been completed and whether the vehicle's state has changed.

[0108] FIG. 6D shows blockchain block 680 that can be added to the distributed ledger according to an embodiment, and the content of block structures 682A to 682n. Referring to FIG. 6D, a client (not shown) may send an entry to a blockchain node to execute an activity on the blockchain. For example, the client may be an application that acts on behalf of a requester such as a device, person, or entity that proposes an entry to the blockchain. A plurality of blockchain peers (e.g., blockchain nodes) may maintain a copy of the state of the blockchain network and the distributed ledger. Within the blockchain network, there may be different types of blockchain nodes / peers such as an endorse peer that simulates and endorses an entry proposed by a client, and a commit peer that verifies the endorsement, confirms the entry, and commits the entry to the distributed ledger. In this example, the blockchain node may act as an endorse node, a commit node, or both.

[0109] The system includes a blockchain that stores immutable and ordered records in blocks, and a state database (current world state) that maintains the state of the current blockchain. There may be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel of which it is a member. This blockchain is an entry log and is composed of blocks linked by hashes, and each block contains a series of N entries. The block may include various components as shown in FIG. 6D. The link of the block may be generated by adding the hash of the header of the previous block into the block header of the current block. In this way, all entries of the blockchain are ordered and cryptographically linked, preventing the blockchain data from being tampered with without breaking the hash link. Further, due to the link, the latest block of the blockchain represents all previous entries. This blockchain may be stored on a peer file system (local or attached storage device) that supports the workload of the blockchain that is append-only.

[0110] The current state of the blockchain and the distributed ledger may be stored in the state database. Here, the current state data represents the latest values of all keys included in the chain entry log of the blockchain so far. Entries are executed against the current state of the state database by calling smart contract executable code. To make smart contract executable code interactions extremely effective, the latest values of all keys are stored in the state database. The state database may include an indexed view of the chain entry log to the blockchain and can thus be regenerated from the chain at any time. The state database may be automatically restored (or created if necessary) when the peer starts up and before entries are accepted.

[0111] The endorsing node receives an entry from the client and endorses the entry based on the simulation result. The endorsing node concludes a smart contract that simulates the entry proposal. If the endorsing node endorses the entry, the endorsing node creates an entry endorsement, which is a signed reply from the endorsing node to the client application and indicates the endorsement of the simulated entry. The way to endorse an entry depends on an endorsement policy that may be specified on the smart contract executable code. An example of an endorsement policy is that a majority of the peers to endorse must endorse the entry. Different channels may have different endorsement policies. The endorsed entry is transferred by the client application to the ordering service.

[0112] The ordering service accepts the endorsed entries, orders them into blocks, and delivers the blocks to the committing peers. For example, the ordering service may start a new block when the number of entries reaches a threshold, when a timer expires, or based on other conditions. In this example, the blockchain node is the committing peer that received the data block 682A to be stored on the blockchain. The ordering service may be composed of a group of orderers. The ordering service does not process entries or smart contracts and does not maintain a shared ledger. Rather, the ordering service may accept the endorsed entries and specify the order in which those entries are committed to the distributed ledger. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0113] Entries are written to the distributed ledger in a non-conflicting order. The order of the entries is established to ensure that updates to the state database become effective when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering occurs by solving a cryptographic puzzle or mining, in this example, the members of the distributed ledger may select the ordering mechanism that best suits the network.

[0114] Referring to FIG. 6D, a block 682A (also referred to as a data block) stored on a blockchain and / or a distributed ledger may include a plurality of data segments such as block headers 684A to 684n, transaction-specific data 686A to 686n, and block metadata 688A to 688n. It will be understood that the various blocks and their contents, such as block 682A and its contents, are for illustrative purposes only and are not intended to limit the scope of the embodiments. In some cases, block header 684A and block metadata 688A may be smaller than transaction-specific data 686A that stores entry data, but this is not required. Block 682A may store information on N (e.g., 100, 500, 1000, 2000, 3000, etc.) entries of transactions within block data 690A to 690n. Block 682A may include a link to a previous block (e.g., on the blockchain) within block header 684A. In particular, block header 684A may include a hash of the header of the previous block. Block header 684A may also include a unique block number, a hash of block data 690A of the current block 682A, and the like. The block number of block 682A may be unique and may start from 0 and be assigned in ascending and consecutive order. The first block of the blockchain may be referred to as a genesis block and includes information about the blockchain, its members, data stored therein, and the like.

[0115] The block data 690A may store the entry information of each entry recorded in the block. For example, the entry data may include the type of entry, version, timestamp, channel ID for the distributed ledger, entry ID, epoch, visibility of the payload, smart contract executable code path (deploy tx), name of the smart contract executable code, version of the smart contract executable code, input (smart contract executable code and functions), identification of the client (creator) such as public key and certificate, signature of the client, identity of the endorser, signature of the endorser, hash of the proposal, events of the smart contract executable code, response status, namespace, read set (list such as keys and versions read from the entry), write set (list such as keys and values), start key, end key, list of keys, Merkle tree query summary, and one or more of the like. The entry data may be stored for each of the N entries.

[0116] In one embodiment, the block data 690A may also store transaction-specific data 686A that adds additional information to the chain of blocks linked by hashes in the blockchain. Thus, the data 686A may be stored in the immutable log of blocks on the distributed ledger. The advantages of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. The block metadata 688A may store a plurality of fields of metadata (e.g., as a byte array or the like). The metadata fields may include a signature of block creation, a reference to the last configuration block, an entry filter that identifies valid and invalid entries within the block, the last offset left by an ordering service that orders the blocks, and the like. The signature, the last configuration block, and the orderer metadata may be added by the ordering service. On the other hand, a committer of the block (such as a blockchain node) may add valid / invalid information based on an endorsement policy, verification of read / write sets, and the like. The entry filter may include a byte array of the same size as the number of entries in the block data 610A and a verification code that identifies whether the entry was valid / invalid.

[0117] The other blocks 682B through 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the headers 684A through 684n in the other blocks includes the hash value of the previous block. The hash value of the previous block may be the hash of only the header of the previous block or the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, it is possible to perform block-by-block tracking from the Nth block to the genesis block (and related initial files) as indicated by the arrow 692, establishing an auditable and immutable chain of custody.

[0118] The foregoing embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination as described above. The computer program may be embodied on a computer-readable medium such as a storage medium. For example, the computer program may be provided 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 disk, removable disk, compact disk read-only memory (CD-ROM), or any other type of storage medium known in the art.

[0119] Examples of storage media may be connected to the processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral with the processor. The processor and the storage medium may be provided in an application specific integrated circuit (ASIC). Alternatively, the processor and the storage medium may exist as separate components. For example, FIG. 7 shows an example of a computer system architecture 700 that may represent or may be integrated with any of the foregoing components and the like.

[0120] FIG. 7 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein. Nevertheless, the computing node 700 is capable of implementing and / or executing any of the functions disclosed hereinabove.

[0121] Within the computing node 700, there is a computer system / server 702 operable in a variety of general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 702 include, without limitation, personal computer systems, server computer systems, thin clients, thick clients, small or portable devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer devices, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computer environments including any of the foregoing systems or devices, and the like.

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

[0123] As shown in FIG. 7, the computer system / server 702 in the cloud computing node 700 is shown in the form of a general-purpose computing device. The components of the computer system / server 702 may include, without limitation, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor or processing unit 704.

[0124] The bus may represent one or more of several bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, or a processor or local bus using any of a variety of bus architectures. Such architectures include, by way of non-limiting example, 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.

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

[0126] A program / utility having one set (at least one) of program modules may be stored in memory 706, by way of non-limiting example, along with an operating system, one or more application programs, other program modules, and program data. Each 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. The program modules generally execute the functions and / or methodologies of the various embodiments of the present application described herein.

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

[0128] The computer system / server 702 may communicate with one or more external devices via an I / O device 712 (such as an I / O adapter) that may include one or more devices that enable a user to interact with the computer system / server 702, such as a keyboard, a pointing device, a display, a speech recognition module, etc., and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (such as a network card, a modem, etc.). Such communication may occur via the I / O interface of device 712. Further, the computer system / server 702 may communicate via a network adapter with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (such as the Internet). As depicted, device 712 communicates with other components of the computer system / server 702 via a bus. Although not shown, it should be understood that other hardware and / or software components may be used in conjunction with the computer system / server 702. Non-limiting examples include microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drivers, and data archive storage systems, etc.

[0129] Although at least one example of a system, method, and non-transitory computer-readable medium is shown in the accompanying drawings and described in detail above, the present invention is not limited to the disclosed embodiments, and it will be understood that various rearrangements, changes, and substitutions are possible as defined and clarified by the following claims. For example, the capabilities of the system in the various figures can be performed by one or more of the modules or components described herein or by a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or some of the functions performed by an independent module may be performed by one or more of these modules. Further, the functions described herein may be performed at various times and in relation to various events internal or external to the module or component. Also, the information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or a plurality of protocols. Also, a message transmitted or received by any module may be transmitted or received directly and / or via one or more other modules.

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

[0131] Note that some of the system functions described in this specification are presented as modules to emphasize implementation independence more. For example, a module may be implemented as a hardware circuit comprising off-the-shelf semiconductors such as custom very large-scale integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. A module may also be implemented within a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, image processing device, or the like.

[0132] A module may also be implemented at least partially within software and executed by various types of processors. An identified portion of the executable code may comprise, for example, one or more physical or logical blocks of computer instructions that may be grouped as, for example, objects, procedures, or functions. However, the executable files of the identified modules need not be physically placed together, and may include heterogeneous instructions stored in different locations, such as modules and archives that achieve the use of the modules mentioned when logically combined. Further, a module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, flash device, random access memory (RAM), tape, or other medium for storing data.

[0133] In fact, a module of executable code may be a single instruction or multiple instructions, and may be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data is identified and shown within modules in this specification, and may be embodied in any suitable form and organized into any suitable data structure. The operational data may be collected as a single data set, or may be distributed in different locations including forms spanning different storage devices, and at least a portion may exist simply as electrical signals on a system or network.

[0134] As will be readily understood, the components of the present application can be arranged and designed in a variety of different configurations as described in this specification and shown in the figures. Accordingly, the detailed description of the embodiments is not intended to limit the scope of the present application, but merely to represent selected embodiments of the present application.

[0135] Those skilled in the art will readily understand that the foregoing may be implemented by steps in a different order and / or by hardware elements having a configuration different from that disclosed. Accordingly, although the present application has been described based on preferred embodiments, specific modifications, changes, and alternative configurations will be apparent to those skilled in the art.

[0136] Preferred embodiments of the present application have been described, but the described embodiments are for illustrative purposes only, and it will be understood that the scope of the present application is defined only by the appended claims, taking into account all equivalents or modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. Receiving a request for specific data by a server; Determining, by the server, a transporter capable of providing the specific data based on one or more current settings of the transporter and a current route of the transporter, wherein the one or more current settings include a level of provision of the specific data; Requesting, by the server, that the transporter provide the specific data for value; Receiving the specific data by the server; A method comprising the above.

2. Identifying a plurality of transporters on the current route; Determining, based on one or more user profiles and one or more attributes of the one or more transporters, that one or more of the plurality of transporters are configured to share the specific data; The method according to claim 1, further comprising the above.

3. Retrieving a license file; Applying the one or more current settings of the license file to the transporter before receiving the specific data; Providing the specific data to a third party and providing the value to the transporter; The method according to claim 1, further comprising the above.

4. Identifying an attribute related to the current route of the transporter; Collecting the specific data over a certain period based on the attribute related to the current route of the transporter; The method according to claim 1, further comprising the above.

5. Determining the number of users in the transporter at the current time; Determining which portion of the specific data is capturable and sharable based on the number of users; Receiving a portion of the specific data based on the number of users; The method according to claim 1, further comprising the above.

6. The method according to claim 1, comprising the transporter receiving verification of the specific data shared from at least one component, wherein the verification comprises a blockchain consensus between the transporter and a peer group consisting of the at least one component.

7. The method according to claim 6, comprising the transporter executing a smart contract to record the verification and the at least one component on a blockchain based on the blockchain consensus.

8. Receiving a request for specific data; Determine a conveyor capable of providing the specific data based on one or more current settings of the conveyor and the current route of the conveyor, wherein the one or more current settings include a level of providing the specific data, Request to provide the specific data for the value of the conveyor, Receive the specific data, A server including a processor configured to:

9. The processor is further configured to Identify a plurality of conveyors on the current route, Determine that one or more of the plurality of conveyors are configured to share the specific data based on one or more user profiles and one or more attributes of the one or more conveyors, The server according to claim 8, configured to:

10. The processor is further configured to Extract a license file, Apply the one or more current settings of the license file to the conveyor before receiving the specific data, Provide the specific data to a third party and provide the value to the conveyor, The server according to claim 8, configured to:

11. The processor is further configured to Identify an attribute associated with the current route of the conveyor, Collect the specific data over a certain period based on the attribute associated with the current route of the conveyor, The server according to claim 8, configured to:

12. The processor is further configured to Determine the number of users in the conveyor at the current time, Determine which portion of the specific data is capturable and sharable based on the number of users, Receive a portion of the specific data based on the number of users, The server according to claim 8, configured to:

13. The processor is further configured to Be configured to receive verification of the specific data shared by at least one component, The verification comprises a blockchain consensus among the conveyor and a peer group consisting of the at least one component, The server according to claim 8.

14. The processor is further configured to Execute a smart contract for recording the verification and the at least one component on a blockchain based on the blockchain consensus, The server according to claim 13.

15. Receiving a request for specific data by a server, Determining, by the server, a transport vehicle capable of providing the specific data based on one or more current settings of the transport vehicle and a current route of the transport vehicle, wherein the one or more current settings include a level of providing the specific data; Requiring, by the server, that the transport vehicle provide the specific data for value; Receiving, by the server, the specific data; A non-transitory computer-readable storage medium storing instructions for causing a processor to perform the above at runtime.

16. The processor further Identifying a plurality of transport vehicles on the current route; Determining, based on one or more user profiles and one or more attributes of the one or more transport vehicles, that one or more of the plurality of transport vehicles are configured to share the specific data; The non-transitory computer-readable storage medium according to claim 15, configured to perform the above.

17. The processor further Fetching a license file; Applying the one or more current settings of the license file to the transport vehicle before receiving the specific data; Providing the specific data to a third party and providing the value to the transport vehicle; The non-transitory computer-readable storage medium according to claim 15, configured to perform the above.

18. The processor further Identifying an attribute related to the current route of the transport vehicle; Collecting the specific data over a certain period based on the attribute related to the current route of the transport vehicle; The non-transitory computer-readable storage medium according to claim 15, configured to perform the above.

19. The processor further Determining the number of users at the current time of the transport vehicle; Determining which portion of the specific data is capturable and sharable based on the number of users; Receiving a portion of the specific data based on the number of users; The non-transitory computer-readable storage medium according to claim 15, configured to perform the above.

20. The processor further Receiving verification of the specific data shared by at least one component, the verification comprising a blockchain consensus among a peer group consisting of the transport vehicle and the at least one component. The verification includes a blockchain consensus among a peer group consisting of the transport vehicle and the at least one component. The non-transitory computer-readable storage medium according to claim 15.

Images