Power Allocation to Conveyor

Abstract

To provide a method.SOLUTION: An example operation includes one or more of determining, by a station, a first group of transports in need of charge and a second group of transports capable of providing charge, prioritizing, by the station, at least one transport of the second group to come to the station at a time prior to when at least one transport of the first group comes to the station, receiving, at the station, a first amount of charge from the at least one transport of the second group, and providing, from the station, a second amount of charge to the at least one transport of the first group.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] Cross - reference to Related Applications This application is related to a co - pending U.S. patent application entitled "Dynamic Energy Control of a Transporter" and a U.S. patent application entitled "Wireless Energy Transfer to a Transporter Based on Route Data", both filed on the same day, and the contents of which are incorporated herein by reference in their entirety to form a part of this specification.

Background Art

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

Summary of the Invention

[0003] One embodiment provides a method including one or more of: determining, by a station, a first group of transporters in need of charging and a second group of transporters capable of providing charging; prioritizing, by the station, such that at least one transporter of the second group arrives at the station earlier than at least one transporter of the first group when at least one transporter of the first group comes to the station; receiving, at the station, a first amount of charge from at least one transporter of the second group; and providing, from the station, a second amount of charge to at least one transporter of the first group.

[0004] Another embodiment provides a station including a memory communicatively connected to a processor, the processor determining a first group of vehicles in need of charging and a second group of vehicles capable of providing charging, prioritizing at least one vehicle in the second group to arrive at the station earlier than at least one vehicle in the first group, receiving a first charge amount from at least one vehicle in the second group, and providing a second charge amount to at least one vehicle in the first group, and executing one or more of the above.

[0005] A further embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the station to determine a first group of vehicles in need of charging and a second group of vehicles capable of providing charging, prioritize at least one vehicle in the second group to arrive at the station earlier than at least one vehicle in the first group, receive a first charge amount from at least one vehicle in the second group at the station, and provide a second charge amount from the station to at least one vehicle in the first group, and cause the processor to execute one or more of the above.

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, the components can be arranged and designed in a wide variety of different configurations as described herein and shown in the figures. Accordingly, embodiments of at least one method, apparatus, non-transitory computer-readable medium, and system will be described in detail hereinafter, but are not intended to limit the scope claimed by this application, and merely represent 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. The components can be any part of these entities or computers, or other computers. In one example, the consensus determination related to blockchain transactions can be made by a computing device or component associated with the transporter and one or more components located outside or away from the transporter. A consensus determination or protocol is a process for achieving agreement among one or more nodes or peers in a network in terms of values, states, results, inputs, outputs, situations, etc.

[0009] The functions, configurations, or characteristics described in this specification 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 vehicles, trucks, battery electric vehicles (BEVs) within a walking radius, e-Palettes, fuel cell buses, motorcycles, scooters, bicycles, boats, recreational vehicles, airplanes, and any object that can be used to transport people and / or objects 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] An embodiment provides a method, system, component, non-transitory computer-readable medium, apparatus, 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 particular 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 modify the database records without 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 the immutability of a shared or distributed ledger (which may take the form of a blockchain) 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. A typical endorsement policy allows the smart contract executable code to 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 an ordering phase, and a consensus protocol is used to generate an ordered sequence of entries that have been 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 a logical entity that controls them in various ways. Nodes can include different types such as a client that submits an entry call 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 act as an endorser. An ordering service node or orderer is a node that performs a communication service to all nodes and implements 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 an initial blockchain entry that includes control and setup information.

[0015] The ledger is an ordered and tamper-resistant record of all state transitions of a 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) used to store immutable and ordered records. The ledger also includes a state database that maintains the current state of the blockchain. Typically, there is one ledger for one 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 structured as blocks linked by hashes, and each block contains a sequence of N entries. Here, N is 1 or more. The block header contains 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 the entries in 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 blockchain block added immediately before indicates all the 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 piano node file system (i.e., local, external storage, cloud, etc.) that effectively supports the property of only adding 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. The current state is sometimes called the world state because it indicates the latest key values known to the channel. Entries are executed against the current state data of the ledger by calling smart contract executable code. To effectively perform these smart contract executable code interactions, the latest values of the keys may be stored in the state database. The state database may simply be an indexed view of the chain entry log and can therefore be regenerated from the chain at any time. The state database may be automatically restored (or created if necessary) when the piano node starts up and before entries are admitted.

[0018] What makes a blockchain different from a traditional database is that a blockchain is a distributed, immutable, and secure storage rather than a central storage, where nodes have to share changes to the records in the storage. Characteristics that are unique to the blockchain and useful for the implementation of the blockchain include, without limitation, immutable ledger, smart contract, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

[0019] Embodiments provide services to a specific vehicle and / or a user profile applied 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 requirements (e.g., immediate, severe, moderate, mild, etc.). The needs of the vehicle 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 the inside of the transporter, the outside of 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 period of use of the vehicle. The vehicle information collected before, during, and / or after the operation of the vehicle may be identified, determined by a consortium that grants permissions, and stored in a transaction of a shared / distributed ledger that can be committed to an immutable ledger by a "distributed" method such as via a blockchain membership group.

[0020] Various stakeholders (i.e., owners, users, companies, agents, etc.) may want to limit the exposure of personal information, and thus, the blockchain and its immutability can be used to manage permissions to each specific user vehicle information. Smart contracts can be used for providing compensation, quantifying user profile scores / evaluations / reviews, applying permissions for vehicle events, determining when services are requested, identifying collision and / or degradation events, identifying safety concern events, identifying event constituents, and providing distribution to registered entities seeking access to such vehicle event data. Also, results may be identified and, based on a consensus approach related to the blockchain, the necessary information can be shared among registered companies and / or individuals. 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 identification of the vehicle having a currently active profile associated with an account permitted to receive the service, which may later be corrected by compensation. 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 additional authentication efforts.

[0023] Shared and received data may maintain the data in a single database (e.g., a database server) and generally be stored in a database in one particular 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 transportation.

[0024] Figure 1A shows Diagram 100 of the power allocation system among the transport vehicles of the embodiment. Referring to Figure 1A, system 100 also operates as a computer-based communication node and includes a server that receives and shares information related to the state of transport vehicles operating on a transport support network, and a station 120 such as a charging station that communicates with various other network entities such as transport vehicles and mobile devices. In one embodiment, station 120 sends a notification to transport vehicles 110 / 130 in the vicinity of the station. For example, it is within a predefined distance threshold (e.g., X miles) from station 120. The notification may include a request for transport vehicle or group of transport vehicles 110 / 130 to supply or receive a charging amount at a specific time via station 120 or one or more other charging stations. Each transport vehicle in transport vehicle group 110 / 130 may communicate its current energy state 112 / 114 to station 120 before providing or receiving charging. The state information may include the current charging amount stored in each transport vehicle, the charging amount required for a certain period depending on the transport route or navigation plan or past usage information, and whether the transport vehicle wishes to share / receive charging at station 120. The term "charging" is used to indicate electrical charging, but any type of energy may be shared / received at the station and shared / received by other transport vehicles.

[0025] Charging station 120 may maintain a record of the positions of the transport vehicles, which may include which transport vehicles are not passing through an exit or the path to one or more charging stations 120 (e.g., via GPS, position tracking, etc.). In one embodiment, transport vehicles 110 / 130 are notified that it is appropriate for them to divert towards one or more charging stations 120. The scheduling of the utilization of one or more charging stations 120 may use stored data records stored in a remote server or the memory of station 120. The scheduling may be performed by a remote server or station 120.

[0026] In one embodiment, the charging station 120 determines an approximate time required to route a transporter to or from the charging station and may notify the transporter to route to the charging station based on the availability of an empty charging station, the availability of charging, and / or the availability of planned charging in the future. This procedure ensures that the charging station is as efficient as possible in receiving / providing transfer energy to the transporter. In one embodiment, the charging station 120 can determine the current charge level, the future planned charge level when the transporter arrives at the charging station, the transfer rate of the transporter (power versus time), the availability of the charging station, the amount of charge to be transferred to each participating transporter, and the time to transfer the charge. In another embodiment, one or more transporters can provide this information to the charging station 120. This charge transfer information, identified and used by the charging station and / or withdrawn by the charging station on a per-transporter basis, is used to establish a number of created requests and is sent to a portion of the transporters that route to the charging station to transfer the charge, while other transporters may continue to travel their respective routes without being requested to go to a particular station 120.

[0027] When station 120 has information belonging to various transporter groups 110 / 130, the station 120 may then determine the charging needs of the first and second groups of transporters 116. Based on the charging needs, the total number of transporters within the distance threshold of the network may be categorized into two main groups, such as those currently in need of charging and those capable of providing current charging. The groups may be further redefined into subgroups, for example, in the case of the first group 110 that needs charging, within a specific period, and for those currently in need of charging and those that do not currently need charging but will need charging before arriving at the final destination or before the plan is achieved. The second group 130 may be further redefined into multiple subgroups, such as those that can immediately move to station 120 to provide charging and those that provide charging but not in the required amount and / or not currently available. The transporter candidates identified to provide / receive charging in the first and second groups are then prioritized at 118 in the order of first, second, third, etc. to move to the charging station 120 at a specific time and, as a result, in a specific order.

[0028] In one example, the transporter 1 may provide 50 energy units (e.g., X watts "W"), and the transporter 2 may receive 40 units that may be required at a particular time. Then, at the charging station, there will be a net plus of 10 units. The transporter 3 may require 30 units, but since the required amount exceeds the net plus amount (equal to 10 units) that has been accumulated, the charging station cannot permit this action. However, the charging station 120 can provide less than 10 units and still be in a net plus position. In certain situations, since the required amount (i.e., 30 units) is much more than the amount that can be provided, the charging station may not permit such an action (i.e., providing 9 units). Further, this amount (i.e., up to 9 units) may be saved for another transporter that requires only 10 units, as the amounts are similar. Regarding the same example, the transporter 3 requires 30 units, but the charging station can provide only up to 9 units to keep the energy amount positive. Then, the charging station can schedule to deposit up to 22 units with the transporter 4 so that the transporter 3 can obtain 30 units (resulting in a net plus of 1 unit for the charging station). This scheduling function of the charging station provides the ability to control the use of charging before and during peak usage periods. During peak periods, charging is consumed more frequently and / or more quickly than during other periods of a particular day or week. The transporter is selected and notified to move to the station to receive charging at 124 and provide it at 122 as commanded. The order in which the transporter is invited to come to the station 120 depends on the available net plus energy amount and the time required for the transporter to arrive.

[0029] Figure 1B shows an example of a network of conveyors identified into two separate groups according to an embodiment. Referring to Figure 1B, Example 150 includes a first group 160 of three conveyors 162 to 166, although any group may include any numbered conveyors. This group 160 shows conveyors that are undercharged and in need of a charging service and are looking to obtain more charging or find it. The second group 170 shows conveyors 172 to 176, which are identified as having shareable charging and are located within a specific distance from a charging station 180 having a processor, memory, and communication functions. A processor communicatively connected to the memory and communication functions (which may include wired and / or wireless functions) is configured to communicate with one or more conveyors of the first group 160 and the second group 170. In implementation, the station 180 determines the conveyors of the first group 160 in need of charging and the conveyors of the second group 170 capable of providing charging, and may prioritize at least one conveyor such as conveyor 174 of the second group (see Figure 1C) to come to the station before at least one conveyor of the first group such as conveyor 164 comes to the station. For this selection and prioritization, there are various attributes to consider when allocating time for conveyors to the station, such as which conveyor is attempting to start the longest route, which conveyor is the farthest from the destination (such as home), which conveyor currently has the lowest charge level, which conveyor currently has the highest charge level, which conveyor is the closest to home, etc. The station 180 may execute the station allocation by a notification process used by the station to request, via a cellular communication system, at the station, or from a server, to perform such a service. The allocation may command which conveyor must arrive at the station when and where, the amount of charge received from at least one conveyor of the second group, and the second amount of charge provided from the station to at least one conveyor of the first group. Generally, the station must have a charge amount that exceeds the charge amount expected to be shared with the conveyors receiving the planned charge, but the net charge amount may be temporarily changed to include the charge amount expected at the current time.For example, a transporter 174 providing charging is halfway along the route, and the amount of charge is considered to be a positive value. As a result, the transporter 164 receiving the charge proceeds to receive the charge, and the transporter 174 providing the charge may arrive at a later time than the transporter 164 receiving the charge. The amount of charge provided may be less than or equal to the currently available amount of charge. However, as described above, the scheduled increase or decrease in charge available at the station 180 may cause the amount of charge provided at a particular time to exceed the available amount depending on the scheduled arrival times of other transporters providing charge.

[0030] This process may also include determining the current amount of charge at the station 180 at the current time, and determining a future time at which at least one transporter in the second group will come to the station based on at least one of the current amount of charge, the first amount of charge requested from two or more transporters in the first group, and the second amount of charge available from two or more transporters in the second group. In this example, one or more transporters in each group are considered for this charge providing / sharing process. By identifying the needs of all or other members of a group, the station 180 can make a more effective plan for determining when transporters 162 to 166 and 172 to 176 should arrive and in what order they should arrive at the station 180.

[0031] Figure 1C shows another example 190 of energy allocation between transport machines according to an embodiment. Figure 1C shows that the transport machines 174 of group 2 with 170 provide charging by a wired or wireless attachment process, while the transport machines 164 of group 1 with 160 receive charging by a wired or wireless receiving process. Also, when determining the required charging amount, a second charging amount required by at least one transport machine of the first group is determined, and at least one transport machine of the second group coming to the station is selected based on the fact that the required charging amount is less than the sum of the current charging amount of the station and the first charging amount. This process prevents the scenario where there is no charging amount sufficient to meet the required and expected amounts. This process may also include determining the available charging amount and the charging time required to achieve the charging amount based on the position of at least one transport machine of the second group and the current charging amount of the station. A request is transferred to at least one transport machine of the second group so that at least one transport machine of the second group comes to the station after at least one transport machine of the first group arrives at the station.

[0032] The process may also include the station receiving verification of the charging provided from at least one component, where the verification comprises a blockchain consensus between the station and a peer group consisting of the station and at least one component described and / or depicted herein, and the station executing a smart contract for recording the charging provision event and at least one component on the blockchain based on the blockchain consensus. The blockchain transaction may be performed by any event detection cycle or via a specific data detection procedure. In one example, a component or sensor records information when a related event such as a charging event occurs. For example, when a transport machine is about to arrive and receive / share charging, the station records the event data to the server and commits the data to the blockchain.

[0033] Figure 2A shows a transporter network diagram 200 according to an embodiment. The network comprises components including transporter nodes 202' including a processor 204' in addition to nodes 202 (transporters, charging stations, servers, etc.) including a processor 204. The 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 nodes 202, 202' may occur directly, via a private and / or public network (not shown), or via other transporter nodes and elements comprising one or more of a processor, a memory, and software. Although depicted as a single transporter node and processor, there may be multiple transporter nodes and processors. One or more of the applications, functions, steps, solutions, etc. described and / or depicted herein may be used and / or provided by this element.

[0034] Figure 2B is a diagram 210 showing another transporter network according to an embodiment. The network comprises components including transporter nodes 202' including a processor 204' in addition to nodes 202 (transporters, charging stations, servers, etc.) including a processor 204. The 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 nodes 202, 202' may occur directly, via a private and / or public network (not shown), or via other transporter nodes and elements comprising one or more of a processor, a memory, and software. The processors 204, 204' are further communicable with one or more elements 230 including sensors 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 comprising one or more of a processor, a memory, and software.

[0035] Although a single transport node, processor, and element are depicted, multiple transport nodes, processors, and elements may exist. Information or communication may occur to and / or from any of processors 204, 204' and element 230. For example, mobile phone 220 may provide information to processor 204 that causes 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.

[0036] Figure 2C is a diagram 240 showing yet another transport network according to an embodiment. The network comprises a charging station node, a server and / or a transport including processor 204, and an element including node 202 such as non-transitory computer-readable medium 242C. Processor 204 is communicatively connected to computer-readable medium 242C and element 230 (depicted in FIG. 2B).

[0037] Processor 204 performs one or more of: determining at 244C a first group of transports in need of charging and a second group of transports capable of providing charging; prioritizing at 246C such that at least one transport of the second group arrives at the station earlier than at least one transport of the first group when at least one transport of the first group arrives at the station; receiving at 248C a first charge amount from at least one transport of the second group; and providing at 250C a second charge amount to at least one transport of the first group.

[0038] FIG. 2D is a diagram 250 showing yet another transporter network according to an embodiment. The network comprises elements including a node 202 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).

[0039] The processor 204 determines the current charge amount at the station at time 246D, and based on the current charge amount, determines the future time when at least one transporter of the second group will come to the station, the first charge amount required by two or more transporters of the first group, and the second charge amount available from two or more transporters of the second group, and determines, at 248D, the second charge amount required by at least one transporter of the first group, and selects at least one transporter of the second group that will come to the station based on the fact that the required charge amount is less than the sum of the current charge amount of the station and the first charge amount, determines, at 250D, the available charge amount and the charge time required to achieve the charge amount based on the position of at least one transporter of the second group and the current charge amount of the station, and transfers a request to at least one transporter of the second group to come to the station at a time after at least one transporter of the first group arrives at the station. performs one or more of the following.

[0040] 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 202 connected to a transporter node 202' and an update server node 203 via a blockchain network 206. The nodes 202 and 202' may represent transporters / vehicles, charging stations, and / or servers. The blockchain network 206 may have a ledger 208 for storing software update verification data and information sources for verification for future use (e.g., auditing).

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

[0042] The processor 204 performs one or more of receiving verification of charging provided from at least one component at 244E, where the verification comprises a blockchain consensus between the station and a peer group consisting of at least one component, and executing, at 246E, a smart contract for recording the charging and at least one component provided based on the blockchain consensus to the blockchain.

[0043] All or part of the processor and / or the 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. Additionally, addition, deletion, combination, subsequent execution, etc. may be performed on one or more steps or functions.

[0044] Figure 2F is Figure 265 showing electrifying one or more elements according to an embodiment. In one embodiment, the transport vehicle 266 may provide the power stored in its battery to one or more elements including other transport vehicles 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 transport vehicles 268. This configuration enables the distribution of the electricity / power received from the transport vehicle 266. The transport vehicle 266 may interact with other transport vehicles 268 via vehicle-to-vehicle communication (V2V) technology, cellular phone communication, WiFi, and the like. The transport vehicle 266 may interact with other transport vehicles 268, the charging station 270, and / or the electrical grid 272 in a wireless and / or wired manner. In one embodiment, the transport vehicle 266 is routed (or routes itself) to the electrical grid 272, the charging station 270, or other transport vehicles 268 in a safe and effective manner. By using one or more embodiments of the present solution, the transport vehicle 266 can provide energy to one or more elements depicted herein in various ways that bring the advantages described and / or depicted herein. Further, the safety and efficiency of the transport vehicle may be improved and may have a positive impact on the environment as described and / or depicted herein.

[0045] The term "energy" may be used to indicate any type of energy received, stored, used, shared, and / or lost by a transport vehicle. Energy may be referred to in conjunction with a voltage source and / or current supply of the charge provided and supplied from an entity to the transport vehicle during a charging / using operation. Energy may be in the form of a fossil fuel (e.g., for use in a hybrid transport vehicle) or an alternative power source 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 an energy sharing and / or using operation to increase or decrease the energy level of one or more transport vehicles over a period of time.

[0046] 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, where 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 location (e.g., its original position 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, traffic conditions, road conditions, environmental / weather conditions, vehicle state (weight, etc.), the schedule of the passengers using the vehicle, and the expected schedule of the passengers waiting for the vehicle 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.

[0047] 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 included in a module and a vehicle to wirelessly communicate with the 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 the 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 the vehicle that a certain amount of energy is to be provided from the transporter's battery, where the amount of energy transferred is based on the distance to the module receiving the energy from the transporter.

[0048] 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 that stores the energy and deposits it 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 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 determines the amount of energy required by a transporter based on one or more conditions such as weather, traffic, road conditions, vehicle condition, and users and / or cargo on another transporter, in order to provide energy from one transporter to another transporter, and then routes the transporter to another transporter and instructs 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 a 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, where 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 a transporter and to prioritize transporters that provide a portion of the stored charge to the electrical grid, a residence, and other entities 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.

[0049] Figure 2G is a diagram showing the interconnections between different elements 275. The present solution may be stored in 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, and / or may be executed in whole or in part by one or more of these computers. 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 a 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, an electric grid / charging station 284, a 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 computer 280, and / or a wearable device may cooperate with the present solution. The smartphone 278, the laptop computer 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 a dealership, a tow truck service, a collision repair center or other repair shop. 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, a vehicle speed sensor or a traffic sensor, and / or other transportation infrastructure. One or more transportation infrastructures 282 may use the computing device 282’.

[0050] In one embodiment, the transporter 277 / 276 can transport 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 automatic steering and navigation without human input. An autonomous vehicle has one or more sensors and / or a navigation unit and may be used for automatic driving.

[0051] 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 a user is permitted to use a transporter. In one embodiment, the solution indicates, on or from a transporter, actions (which may be pre-recorded) that a user needs to perform (e.g., visually, and in another embodiment by adding audio as well), and may be used to verify that the actions are correct. In one embodiment, the solution may be used to give a transporter the ability to divide data based on a risk level associated with the data and the driving environment, distribute a portion of the divided data with a low risk level among users for a safer driving environment, and then, after a user has left the transporter, determine a method of distributing the remaining portion of the divided data with a high risk level to the user. In one embodiment, the solution may be used to move a vehicle across boundaries (e.g., countries / states, etc.) and apply the rules of a new area to the vehicle through the use of a blockchain and / or smart contracts.

[0052] In one embodiment, the solution may be used to enable the transporter to continue operating beyond the boundary when a 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 transporter movement speed / direction, determines the distance required for data upload / download completion, and may be used to allocate 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., in the wrong lane or moving at a speed that does not allow it to exit 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.

[0053] In one embodiment, the solution may be used to detect the use of a lane at a certain time and place and inform the user of the transporter, or to recommend or not recommend a lane change 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 a payment directly by email. In one embodiment, the solution may be used to provide services to the users of the transporter, where the services provided are based on a subscription and obtain permissions from other transporters based on the user's profile. In one embodiment, the solution may be used to record changes in the state of a rented object. In one embodiment, the solution may be used to search for a 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 an in-vehicle 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 many times for the purpose of determining the severity of an event prior to an event related to the transporter.

[0054] 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 an inquiry for 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 (e.g., a pedestrian's mobile phone, a streetlight camera, etc.).

[0055] 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 for the vehicle 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 way that minimizes its impact on traffic. In one embodiment, the solution can be used to identify a dangerous driving situation and for a vehicle involved in the dangerous driving situation to take media. 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 can 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 can be used (in certain embodiments) to partially disable a vehicle, such as by means of speed limits, limits on the ability to approach other vehicles, limits to maximum speed, permission for only a certain number of miles in a given time.

[0056] 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 in an unsafe or incorrect manner. 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 state close to 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 geofence for determining the liability for payment of the transporter. In one embodiment, the solution can be used to coordinate the ability to drop off a vehicle at a location based on both the current state at that location and the proposed future state using the navigation destination of other vehicles. In one embodiment, the solution may be used to coordinate the ability to automatically arrange for the drop off of a vehicle at a location, such as by a transporter rental operator.

[0057] 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 closer to the user upon the end of the original or changed 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 a parking space becomes available in a situation where the time since first parked is shorter than the average time of that event. Further, when the event is completed, or in accordance with the location of the device associated with at least one user of the transporter, the transporter is moved to a final parking space. In one embodiment, the solution may be used to plan parking before a future crowd visit. The system interacts with the transporter, provides the service at the highest yet cheapest 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.

[0058] In one embodiment, the solution may be used to sell fractional ownership of a transportation vehicle or to determine the availability of valuation and ridesharing. 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 performed. In one embodiment, the solution may be used to associate digital keys with multiple users. The first user may be a driver of a transportation vehicle, and the second user may be an operator responsible for the transportation vehicle. 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 transportation vehicle. 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 transportation vehicle is updated based on the determined service locations. A smart contract including the compensation value of the service is identified, and the blockchain transaction of this transaction is stored in the distributed ledger.

[0059] 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 on 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 within 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 when the signal turns green but the leading vehicle in the vehicle queue does not move.

[0060] 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, 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. A processor / sensor of the transporter (such as a transporter computer) can communicate with an external element such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 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 whole or in part within the transporter computer 298.

[0061] ECU 295, ECU 296, and the head unit 297 may each include a custom security function element 299 that defines the permitted processing and the context in which the processing is 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. Automotive ECUs can use different contexts such as the proximity context, such as the distance to nearby objects, approaching objects, speed, and relative trajectory to other moving objects, to determine whether the process is being used within the permitted boundaries, the operational context indicating whether the vehicle is moving or parked, the current speed of the vehicle, the state of the transmission, etc., the device connected to the vehicle via a wireless protocol, the context related to the user such as the use of infotainment, driving control, parking assistance, driving assistance, the location-based context, and / or other contexts.

[0062] In one embodiment, the solution described and depicted herein may be used to partially disable a transporter (in certain embodiments) in ways such as limiting its speed, limiting its ability to approach other vehicles, limiting it to a maximum speed, permitting only a certain number of miles given in a period of time. In one embodiment, the solution may be used to send data from a device associated with a transporter involved in an accident, or 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 the situation near the accident, the server notifies the sender of the data. In one embodiment, the solution can be used by the server to query other transporters in the vicinity of an accident so that the transporter can avoid the accident, such as when the transporter is involved in an accident. The server attempts 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 possible location of the sound source to the server, and the server determines the possible cause and can 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 is 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 media obtained by a device near 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.

[0063] 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 where the vehicle may come into contact with a transporter or another vehicle (while in motion or parked), and the system may capture 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, making it possible to safely and reliably obtain critical data from a vehicle that may be involved in a harmful event.

[0064] 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 may be used to monetize the data collected and stored by vehicle sensors by the owner of an autonomous vehicle, creating an incentive for the vehicle to receive compensation by sharing data for purposes such as improving the performance of future vehicles or providing services to the vehicle owner and providing additional data to entities.

[0065] In one embodiment, the solution may be used to increase or reduce the functions of a vehicle according to the operation of the vehicle 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 according to the fact that the authenticated functions are not impaired.

[0066] In one embodiment, the solution may be used to give an individual the ability to guarantee that the user is in the transporter and that the user reaches a specific destination. Further, the system guarantees that the driver (in the case of a non-autonomous vehicle) 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 in the blockchain. In one embodiment, the solution may be used to determine the characteristics of a driver through the analysis of driving style and other factors, and to take actions when the driver is not driving in the normal way, such as the way 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 consideration. The attributes consist of weather, whether the headlights are on, whether the navigation is in use, whether the HUD is in use, the volume of the media being played, etc. In one embodiment, the solution may be used to notify a user in a transporter in a dangerous situation when an item in the transporter indicates that the user is unaware of the dangerous situation.

[0067] 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 transporter 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 transporter in need of service sends information about a fault 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 sends it to store the safety level of the fault in the blockchain. In one embodiment, the solution may be used to determine the difference between the data of sensors outside the transporter and the sensor data of the transporter itself. The transporter requests software for fixing the problem to the server. In one embodiment, the solution can be used to enable message exchange by transporters in the vicinity or in that area when an event (e.g., a collision) occurs.

[0068] Referring to FIG. 2I, the operating environment 290A of a connected transporter in some embodiments is shown. As depicted, the transporter 276 includes a Controller Area Network (CAN) bus 291A that connects elements 292A through 299A of the transporter. Although other elements may be connected to the CAN bus, they 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 transporter 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0069] 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 display unit 299A. Processor 296A may 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. 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.

[0070] 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 performing 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). Transporter 276 may include one or more memories 297A without departing from the solution.

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

[0072] 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 276 receives a request from the user including the start point and the final point regarding the navigation route. The navigation system 295A may query a real-time data server 293, such as a server providing a driving direction, for navigation route data regarding the navigation route including the start point and the final point (via the network 292). The real-time data server 293 transfers the navigation route data to the transport 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the transport 276.

[0073] The ECU 293A controls many operations of the system including the ADAS system 294A of the transport 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 enabled state so as to be activated for the navigation route provided by the ADAS system 294A.

[0074] The sensor set 292A may include any sensors that generate sensor data within the transporter 276. For example, the sensor 292A may include a short-range sensor and a long-range sensor. In certain embodiments, the sensor set 292A of the 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 finder, 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. The navigation system 295A may store the sensor data in the memory 297A.

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

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

[0077] In one embodiment, the solutions described and depicted herein can be used for emergency scenarios and the management of transporter functions when the transporter is determined to enter an area without network access. In one embodiment, the solution can be used to manage and provide transporter 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 transporter matches the profile attributes of at least one user profile inside the transporter. A notification is sent from the transporter to establish communication.

[0078] In one embodiment, the solution can be used to analyze the convenience of users who are convenient for voice communication inside each transporter based on the remaining time inside the transporter 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 transporter to proceed along the road. In one embodiment, the solution may be used to delete confidential data from the transporter if the transporter is damaged to the point where it can no longer be used.

[0079] 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. The transporter then 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 elapsed time related to the biometric measurement, the transporter provides the unencrypted data to the user only when the user is able to 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 a function of presenting to an automotive user a function that reflects characteristics of a user who exists but is not currently activated.

[0080] 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 an intended gesture 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 conversing with navigation on) does not exceed the number of unsafe operations before gestures are permitted.

[0081] 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 to aid in analyzing the data to 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 being restricted from moving faster than a given speed, the transporter being prevented from approaching another transporter closer than a certain distance, and the transporter being prevented from traveling a distance greater than a threshold.

[0082] In one embodiment, the solution may be used to provide instructions from one particular (trying to vacate a location) transporter to another particular (searching for a location to occupy) transporter and perform authentication and coordination using a blockchain. In one embodiment, the solution may be used to determine the partial responsibility of a 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 a 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.

[0083] 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 associated transaction is 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 an accident victim to access another transporter to continue on to the original destination.

[0084] 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 remainder sent from the same vehicle or from another vehicle. In one embodiment, the solution may be used to provide an update of a vehicle's computer to the vehicle and to the driver / user's device of the vehicle. The update is presumably permitted by all drivers and / or users. The software update is provided to the vehicle and the device. 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 has been completed 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 by components of one or more vehicles, 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.

[0085] In one embodiment, the solution may be used to provide the second component with the ability to decrypt software updates located in the first component. Then, verify the first part of the critical update and the second part of the non-critical update, assign the verified first part to one process of the transporter, execute the verified first part by one process for a period, and in response to the positive result of that period, execute the verified first part together with another process after that period. In one embodiment, the solution may be used to provide the user with a service selection, 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 purchase history and preferences of the user obtained from the user profile in the blockchain.

[0086] Figure 3A shows a flowchart 300 of an example. Referring to Figure 3A, the processor determines, at 302, a first group of transporters that require charging and a second group of transporters that can provide charging, prioritizes, at 304, at least one transporter in the second group to come to the station earlier than at least one transporter in the first group comes to the station, receives, at 306, a first charge amount from at least one transporter in the second group, and provides, at 308, a second charge amount to at least one transporter in the first group, and executes one or more of the above.

[0087] Figure 3B shows another flowchart 320 of an embodiment. Referring to Figure 3B, the processor determines the current charge level at the station at the current time at 322, and based on the current charge level, determines the future time when at least one transporter of the second group will come to the station, the first charge amount required by two or more transporters of the first group, and the second charge amount that two or more transporters of the second group can provide, and at 324 determines the second charge amount required for at least one transporter of the first group, and selects at least one transporter of the second group that will come to the station based on the fact that the required charge amount is less than the sum of the current charge amount of the station and the first charge amount, at 326 determines the available charge amount and the charge time required to achieve the charge amount based on the position of at least one transporter of the second group and the current charge amount of the station, and transfers a request to at least one transporter of the second group to come to the station at a time after at least one transporter of the first group arrives at the station, and executes one or more of the above.

[0088] Figure 3C shows yet another flowchart 340 of an embodiment. Referring to Figure 3C, the processor may execute one or more of receiving verification of charging provided by at least one component at 342, where the verification comprises a blockchain consensus between a peer group consisting of a transporter and at least one component, and executing a smart contract for recording likely events and at least one component on the blockchain based on the blockchain consensus at 344.

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

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

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

[0092] In further embodiments, the transporter node 402 may send data from one or more sensors 404 to the machine learning training system 410. In yet other embodiments, the machine learning subsystem 406 may send the 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.

[0093] FIG. 5A shows a configuration example 500 of a vehicle for managing database transactions related to a vehicle according to an embodiment. Referring to FIG. 5A, a particular 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, constituents, credits, service descriptions, dates, times, locations, results, notifications, unexpected events, etc. These transactions within the transaction module 520 may be replicated within 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.

[0094] Figure 5B shows a vehicle configuration example 550 for the management of database transactions carried out between various vehicles according to an embodiment. When a vehicle reaches a state where a 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 its way to pick up a package 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 a package from vehicle 508 and / or a server (not shown) via wireless communication. 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 each block in the blockchain is different, 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 mounted on the transporter, may not be mounted on the transporter, and may be accessible directly and / or via the network.

[0095] 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 the members who are permitted access to the blockchain data, rather than all parties, are accessible. Blockchain nodes participate in a number of 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. The blockchain nodes initiate blockchain actions (such as authentication), seek to write to the immutable ledger of the blockchain stored on the blockchain, and a copy is also stored on the underlying physical infrastructure that supports it.

[0096] The blockchain transaction 620 is stored in the computer's memory, and the transaction is received 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 the transaction is committed to the blockchain through a commit procedure that includes hashing the data content of the transaction to the current block and referring to 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 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 the profile status, and whether to monitor their actions at subsequent events. For example, a service event may occur while the user is in the vehicle, sensor data monitoring is triggered, and it may be identified that certain parameters, such as the vehicle's charge level, exceed / fall below certain thresholds for a certain period, and as a result, the current state may be changed, and it may be required to send a warning to the parties involved in 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 have been taken, whether the vehicle has sufficient charge / fuel, etc. All such information may be the basis of the smart contract conditions 630 and is 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.

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

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

[0099] 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 engage the physical infrastructure. The encryption credit service may be used to verify entries such as asset exchange entries and keep information private.

[0100] The configuration of the blockchain architecture of 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 perform reminders, updates, and / or other notifications that are conditional such as changes, updates, etc. Smart contracts may be used to identify rules associated with authentication and access ledgers' 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 peer consensus. The physical infrastructure may be used to retrieve any data or information described herein.

[0101] Within the smart contract executable code, the smart contract can be created via high-level applications and programming languages and written to the blocks of the blockchain. The smart contract may include executable code that is registered, stored, and / or replicated on the 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 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. 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.

[0102] 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. Temporary data used / created by the smart contract is held in memory by the provided execution environment and deleted if the data required by the blockchain is identified.

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

[0104] FIG. 6C shows a blockchain configuration 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 an event where 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 of the vehicle. Smart contracts may be used to call rules, thresholds, sensor information collection, etc. for calling a vehicle service event when a service event occurs, such as when vehicle sensor data indicates a need for fuel / charging or maintenance services. 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.), compensation levels, distance traveled during the event, recipients 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.

[0105] FIG. 6D shows a blockchain block 680 that can be added to the distributed ledger according to the 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. In 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.

[0106] 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 linked by encryption, 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 append-only blockchain.

[0107] 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 data values of all keys included in the blockchain's chain entry log 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 of 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 an entry is accepted.

[0108] 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 method of endorsing an entry depends on an endorsement policy that may be specified in the smart contract executable code. An example of an endorsement policy is "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.

[0109] 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 end is the committing peer that receives the data block 682A to be stored on the blockchain. The ordering service may be composed of an ordering group. 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.

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

[0111] 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 through 684n, transaction-specific data 686A through 686n, and block metadata 688A through 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 through 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, the data stored therein, and the like.

[0112] The block data 690A may store entry information for each entry recorded within 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 functionality), identification of the client (creator) such as public key and certificate, client signature, endorser identity, endorser signature, hash of the proposal, events of the smart contract executable code, response status, namespace, read set (list such as keys and versions read for 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.

[0113] In one embodiment, the block data 690A may also store transaction-specific data 686A that adds additional information to a chain of blocks linked by hashes within the blockchain. Thus, the data 686A may be stored in an 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 multiple fields of metadata (e.g., as a byte array, etc.). 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 ordered the block, and the like. The signature, the last configuration block, and the ordering 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.

[0114] 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 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, and an auditable and immutable chain of custody is established.

[0115] The above-described embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the 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), a register, a hard disk, a removable disk, compact disk read-only memory (CD-ROM), or any other type of storage medium known in the art.

[0116] 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 components described above.

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

[0118] Within the computing node 700, there is a computer system / server 702 that can operate in various 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, but are not limited to, 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 computing environments including any of the above systems or devices, and the like.

[0119] The computer system / server 702 is described in the general context of executable instructions on a computing system, such as program modules 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 computing system storage media including memory storage devices.

[0120] 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, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the processor 704 from the system memory 706.

[0121] 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, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0122] The computer system / server 702 typically includes media that is readable by various computer systems. Such media may be any media 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 media readable by the computer system 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.

[0123] A program / utility having one set (at least one) of program modules may be stored in memory 706, along with, by way of non-limiting example, 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.

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

[0125] 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, 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, among others.

[0126] 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 a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or part 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, messages transmitted or received by any module may be transmitted or received directly and / or via one or more other modules.

[0127] It will be understood by those skilled in the art 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.

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

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

[0130] In fact, a module of executable code may be a single instruction, or a number of instructions, and may be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data is identified and shown within a module in this specification and may be embodied in any suitable form and organized in any suitable data structure. 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 simply exist as an electrical signal on a system or network.

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

[0132] Those skilled in the art will readily understand that the above 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.

[0133] Although preferred embodiments of the present application have been described, 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 (such as protocols, hardware devices, software platforms, etc.).

Claims

1. a station determines a first group of vehicles in need of charging and a second group of vehicles capable of providing charging; the station prioritizes such that at least one vehicle of the second group arrives at the station earlier than at least one vehicle of the first group when the at least one vehicle of the first group comes to the station; the station receives a first amount of charge from the at least one vehicle of the second group at the station; the station provides a second amount of charge to the at least one vehicle of the first group; a method comprising the above.

2. The method according to claim 1, wherein the second amount of charge is less than or equal to the first amount of charge.

3. determining the second amount of charge required for the at least one vehicle of the first group; selecting the at least one vehicle of the second group coming to the station based on the fact that the required amount of charge is less than the sum of the current charge amount of the station and the first amount of charge; The method according to claim 1, comprising the above.

4. determining the available charge amount and the charging time required to achieve the charging of the charge amount based on the position of the at least one vehicle of the second group and the current charge amount of the station; transferring a request to the at least one vehicle of the second group to come to the station at a time after the at least one vehicle of the first group arrives at the station; The method according to claim 1, comprising the above.

5. The method according to claim 1, comprising the station receiving verification of the provided charge from at least one component, the verification comprising a consensus related to a blockchain transaction between the at least one vehicle of the first group and a peer group consisting of the at least one component.

6. The method according to claim 5, comprising the station executing a smart contract for recording by the station to record the verification and the at least one component on the blockchain based on the consensus related to the blockchain transaction.

7. A station, Determine a first group of transport machines that require charging and a second group of transport machines that can provide charging, Prioritize so that at least one transport machine in the second group comes to the station earlier than at least one transport machine in the first group when at least one transport machine in the first group comes to the station, Receive a first amount of charge received by the station from the at least one transport machine in the second group, Provide a second amount of charge to be provided to the at least one transport machine in the first group, A station comprising a processor.

8. The station according to claim 7, wherein the second amount of charge is less than or equal to the first amount of charge.

9. The processor further determines the second amount of charge required for at least one transport machine in the first group, Select at least one transport machine in the second group that comes to the station so that the required amount of charge is less than the sum of the current charge amount of the station and the first amount of charge. The station according to claim 7.

10. The processor further determines the available charge amount and the charging time required to achieve the charging of the charge amount based on the position of the at least one transport machine in the second group and the current charge amount at the station, Transfer a request to at least one transport machine in the second group to come to the station at a time after at least one transport machine in the first group arrives at the station. The station according to claim 7.

11. The processor receives verification of the provided charge from at least one component, the verification comprising a consensus related to a blockchain transaction between the station and a peer group consisting of the at least one component. The station according to claim 7.

12. The station according to claim 11, wherein the processor executes a smart contract for recording the verification and the at least one component in a blockchain based on a consensus related to the blockchain transaction.

13. The station determines a first group of transport machines that require charging and a second group of transport machines that can provide charging, Causing the station to prioritize such that at least one transporter of the second group arrives at the station earlier than at least one transporter of the first group when the at least one transporter of the first group arrives at the station; Causing the station to receive a first amount of charge received from the at least one transporter of the second group at the station; Causing the station to provide a second amount of charge to the at least one transporter of the first group; A non-transitory computer-readable storage medium storing instructions for causing a processor to perform the above during execution.

14. The non-transitory computer-readable storage medium according to claim 13, wherein the second amount of charge is less than or equal to the first amount of charge.

15. The processor further determines the second amount of charge required for the at least one transporter of the first group, and selects the at least one transporter of the second group arriving at the station based on the fact that the required amount of charge is less than the sum of the current amount of charge of the station and the first amount of charge. The non-transitory computer-readable storage medium according to claim 13.

16. The processor further determines the available amount of charge and the charging time required to achieve the charging of the amount of charge based on the position of the at least one transporter of the second group and the current amount of charge at the station, and transfers a request to the at least one transporter of the second group to come to the station at a time after the at least one transporter of the first group arrives at the station. The non-transitory computer-readable storage medium according to claim 13.

17. The processor further causes the station to receive verification of the provided charge from at least one component, the verification comprising a consensus related to a blockchain transaction between the at least one transporter of the first group and a peer group consisting of the at least one component. The non-transitory computer-readable storage medium according to claim 13.

Images