WO2020051730A1

WO2020051730A1 - Methods and devices for shared vehicle management

Info

Publication number: WO2020051730A1
Application number: PCT/CN2018/104795
Authority: WO
Inventors: Zhancang WANG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-09-10
Filing date: 2018-09-10
Publication date: 2020-03-19

Abstract

A shared vehicle management method implemented by a first network node in a blockchain network is provided. The method comprises: acquiring vehicle information published on the blockchain network by vehicles and smart contracts associated with the vehicle information; selecting a target vehicle from the vehicles; obtaining vehicle information and a smart contract corresponding to the target vehicle; and broadcasting the obtained vehicle information and smart contract through the blockchain network. Therefore, the blockchain is used to supervise and manage the shared vehicles, thereby tracking the entire vehicle usage process more precisely, ensuring that the shared vehicles are parked at suitable locations, and preventing parking congestion.

Description

METHODS AND DEVICES FOR SHARED VEHICLE MANAGEMENT

TECHNICAL FIELD

The present disclosure generally relates to a wireless communication network, and more specifically to methods and devices for shared vehicle management.

BACKGROUND

This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Vehicle sharing means that many people may share a vehicle for frequent usage. A driver may have only the right to use the vehicle. There is no ownership, similarly to a short-term chartered vehicle in the vehicle rental industry. This approach not only saves money, but also helps alleviate traffic congestion, road wear, air pollution, and dependence on energy. The prospect for development may be extremely broad. In prior art, users usually reserve a vehicle through related software. The related software may rely on a centralized software construction model, and there may be a network trading platform. The user and the owner of the transaction may need to go through an online trading platform. The problem consists in that the transaction may need to pass through the online trading platform, i.e., a third party organization, which may affect transaction efficiency. Information on preservation of the vehicles by the third party organization may be changed, and authenticity and security of the information may not be guaranteed.

With high growth of urban population and the number of automobiles, shared vehicles including shared bicycles, shared cars, etc. have become a popular mobility option for both short and long distance travels. To avoid traffic congestion and pollution issues of society which may be caused by private vehicle usage, geographically dense communities such as cities and/or college campuses have adopted vehicle sharing systems.

Traditional vehicle sharing systems typically employ centralized management systems to allocate resources and incentives. In these systems, electronic payments may be made through rental tags based on a selected vehicle and a rental duration. Shared vehicles must maintain a wireless communication link to an administration server to perform the payment transaction and remote monitoring. Such centralized vehicle sharing and rental systems may require installation of an expensive infrastructure and investment from a central entity. Station-less vehicle rental systems typically employ a lock which includes a smart lock mounted and attached to each vehicle to secure the vehicle. The vehicle may be equipped with a Global Positioning System (GPS) device for tracking. In addition, the vehicle may include a solar panel or an internal dynamo hub (generator) along with a rechargeable battery to power the electronics and the lock. Each of the vehicles must maintain a constant wireless data connection over a mobile communication network to the administration server.

Although such station-less vehicle sharing systems incur less setup and infrastructure installation costs, they may require a separate GPS tracking device, battery, solar panel, or internal hub dynamo for each vehicle. The mobile data connection may also impose recurring data subscription fees for each vehicle.

Furthermore, the centralized shared vehicle management may require huge resources and costs for maintenance. The centralized vehicle management entity may also suffer from a trust issue or abuse of power to harm benefits of the users. The entity may intend to enhance performance of the system by enhancing controllability for the vehicle sharing system at the expense of equality and scalability of the shared vehicle network. Additionally, once the centralized entity malfunctions, an overall operation of the shared vehicle network may be influenced.

US20140266588 describes a battery-powered lock that is capable of communicating with a mobile device. A mobile device that is authorized to communicate with the lock can send lock and/or unlock commands to the lock. In addition, techniques are described for a station-less bike sharing system using the lock that enables a user to drop off and secure the rented bike anywhere at the end of the trip. Using the integrated GPS on the mobile device, the geographic location of the lock as well as the attached bike is tracked upon any lock/unlock requests. The mobile device communicates with an administration server to determine if the user is authorized to unlock the lock and utilize the bike.

US20100228405 proposes a locking and holding mechanism for a personal vehicle, which is composed of a connection device mounted to the vehicle and a receptacle mounted to a solid fixture. The receptacle is configured to directly receive and engage the connection device of the vehicle, and once received, the vehicle is locked to the receptacle held in a stable position. The connection device easily attaches a vehicle to a dock and enables a vehicle management system to charge, lock, hold in place and monitor presence of the vehicle when docked in a charge station. When docked in a charge station, if the status of the vehicle is altered unexpectedly the vehicle is equipped with communication equipment to alert the management system that the status of the vehicle has changed. The apparatus identifies a user through an ID device and/or code. A user in good standing accesses a user interface via a communication gateway to secure access to a vehicle by electronically detaching the vehicle from the dock.

In some other prior art vehicle management systems, a vehicle management center is needed to receive and authenticate a vehicle identifier and a user identifier, or to cause the vehicle to play at least one audio and/or video messages to a user when detecting that the vehicle is used by the user, or to connect to a cloud so that the cloud can provide a vehicle management strategy.

However, all of the above prior art systems use a centralized shared vehicle management system in which a centralized entity provides sufficient resources and communication to regulate the management of the shared vehicles. These architectures lack long term incentive for users or stuff to maintain a massive shared vehicle network. Moreover, trust between the users and the service provider is fragile, as any reason disabling the service provider to provide the service and management may bring the system to rest. Quality of service completely depends on the service provider, but there is no or a weak internal competition scheme of the centralized service providing entity.

SUMMARY

It is an object of the present disclosure to provide a shared vehicle supervision method capable of effectively supervising deposits, uses and locations of the shared vehicles. The method for shared vehicle supervision according to the present disclosed is based on a blockchain technology, i.e., using the blockchain technology for management of lease records and deposits of the shared vehicles, and each lease may be treated as a transaction stored in the blockchain. Using the blockchain technology, one can easily record a life cycle of each vehicle, and the record may be safe and convenient, and will not be easily tampered with by outsiders or malicious users. It is more efficient to ensure security of the shared vehicles, prevent theft and regulate the behavior of the vehicle user.

According to a first aspect of the present disclosure, a shared vehicle management method implemented by a first network node in a blockchain network is provided. The method comprises: acquiring vehicle information published on the blockchain network by vehicles and smart contracts associated with the vehicle information; selecting a target vehicle from the vehicles; obtaining vehicle information and a smart contract corresponding to the target vehicle; and broadcasting the obtained vehicle information and smart contract through the blockchain network.

In an alternative embodiment of the first aspect, if the first network node is a consensus network node, then the vehicle information published on the blockchain network and the smart contracts associated with the vehicle information may be acquired from a local account of the first network node, and if the first network node is a non-consensus network node, then the vehicle information published on the blockchain network and the smart contracts associated with the vehicle information may be acquired by receiving the vehicle information and the smart contracts from a consensus network node.

In an alternative embodiment of the first aspect, broadcasting the obtained vehicle information and smart contract may further comprise: transmitting service selection information associated with the target vehicle to other network nodes in the blockchain network.

In a further alternative embodiment of the first aspect, the method may further comprise signing a predetermined part of the obtained smart contract before broadcasting the obtained vehicle information and smart contract, wherein broadcasting the obtained vehicle information and smart contract may further comprise transmitting the obtained vehicle information and the signed smart contract to other network nodes in the blockchain network.

According to a second aspect of the present disclosure, a shared vehicle management method implemented by a second network node in a blockchain network is provided. The method comprises: receiving vehicle information and a smart contract corresponding to a target vehicle broadcast by a first network node in the blockchain network; determining whether the vehicle information corresponding to the target vehicle is associated with the second network node; if the vehicle information corresponding to the target vehicle is associated with the second network node, judging whether the first network node satisfies a vehicle use condition; and if the first network node satisfies the vehicle use condition, associating the first network node with the target vehicle.

According to a third aspect of the present disclosure, a first network node in a blockchain network is provided. The first network node comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the first network node to perform operations of the method of the above first aspect.

According to a fourth aspect of the present disclosure, a second network node in a blockchain network is provided. The second network node comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the second network node to perform operations of the method of the above second aspect.

According to a fifth aspect of the present disclosure, a blockchain network is provided. The blockchain network comprises: a plurality of first network nodes of the above third aspect; and a plurality of second network nodes of the above fourth aspect, adapted to receive messages broadcast by the plurality of the first network nodes.

According to a sixth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a first network node in a blockchain network, the computer program causes the first network node to perform operations of the method according to the above first aspect.

According to a seventh aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a second network node in a blockchain network, the computer program causes the second network node to perform operations of the method according to the above second aspect.

In the present disclosure, the blockchain is used to supervise and manage the shared vehicles, thereby tracking the entire vehicle usage process more precisely, ensuring that the shared vehicles are parked at suitable locations, and preventing parking congestion. Malicious users can be shielded from the blockchain network by using an inherent fault tolerance mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by way of example with reference to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:

Fig. 1 is a schematic diagram illustrating a shared vehicle management system in a blockchain network according to some embodiments of the present disclosure;

Fig. 2 is a schematic structural diagram of a blockchain operating environment according to some embodiments of the present disclosure;

Fig. 3 is an exemplary sequence diagram illustrating processes using smart contracts on the blockchain to supervise and manage the shared vehicles according to some embodiments of the present disclosure;

Fig. 4 is a flow chart illustrating a method implemented on a first network node according to some embodiments of the present disclosure;

Fig. 5 is a more specific flow chart illustrating a method implemented on a first network node according to some embodiments of the present disclosure;

Fig. 6 is a flow chart illustrating a method implemented on a second network node according to some embodiments of the present disclosure;

Fig. 7 is a more specific flow chart illustrating a method implemented on a second network node according to some embodiments of the present disclosure;

Fig. 8 is a block diagram illustrating a first network node according to some embodiments of the present disclosure;

Fig. 9 is another block diagram illustrating a first network node according to some embodiments of the present disclosure;

Fig. 10 is a block diagram illustrating a second network node according to some embodiments of the present disclosure;

Fig. 11 is another block diagram illustrating a second network node according to some embodiments of the present disclosure; and

Fig. 12 is a block diagram illustrating a wireless communication system according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The following detailed description describes methods and devices for shared vehicle management. In the following detailed description, numerous specific details such as logic implementations, types and interrelationships of system components, etc. are set forth in order to provide a more thorough understanding of the present disclosure. It should be appreciated, however, by one skilled in the art that the present disclosure may be practiced without such specific details. In other instances, control structures, circuits and instruction sequences have not been shown in detail in order not to obscure the present disclosure. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to “one embodiment” , “an embodiment” , “an example embodiment” etc. indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure.

In the following detailed description and claims, the terms “coupled” and “connected, ” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, cooperate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

As used herein, the terms “first” , “second” and so forth refer to different elements. The singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” as used herein specify the presence of stated features, elements, and/or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

Fig. 1 is a schematic diagram illustrating a shared vehicle management system in a blockchain network according to some embodiments of the present disclosure. The blockchain network comprises vehicle end and service provider end. The blockchain supporting the blockchain network is maintained at the vehicle end. Any node in the blockchain maintained by the vehicle end can execute a program included in a smart contract. At the same time, the blockchain may implement a transaction between a node acting as a user terminal and a node acting as the vehicle, and the user terminal may access the blockchain network. The blockchain nodes with higher authority on the service provider end can manage this distributed shared vehicle network. As an example, the user terminal may be a personal computer (PC) , a mobile terminal or user equipment (UE) . The user terminal may send vehicle sharing requests and service selection information, and receive target vehicles and corresponding smart contracts. The vehicle end includes but is not limited to a car or a bicycle. A digital smart lock may be included on the vehicle end to verify the user′s identity. Only after the verification is passed can the vehicle be used normally. For example, the door and the engine can be started only after the verification is passed. If the user terminal satisfies conditions of the smart contract, the vehicle must be verified before normal use of the vehicle.

The service provider end and the vehicle end are under the same blockchain network. The blockchain is not provided by a third party. The server in the blockchain network, i.e., nodes with specific functions, can handle commands including judgment, detection, and so on.

The shared vehicle supervision system in the blockchain may be mainly in charge of account registration and vehicle use of the user terminals, rental and settlement of the shared vehicles, and locking and parking management of the shared vehicles.

Firstly, the shared vehicle service provider may build a blockchain platform responsible for maintaining and generating new blocks. The generated new blocks may be transmitted to the entire network. The network may be a peer-to-peer architecture. Each node may be a set of software programs containing a set of public keys, a routing program, and a blockchain data set to be used in trading. Then, these same nodes may be connected to form a network. At the same time, the shared vehicle service provider may generate a corresponding private key for each vehicle. This private key may be managed by the shared vehicle service provider based on an address of the vehicle. When each user registers and uses the shared vehicle, a private key corresponding to his/her own account may be formed. The private key may be stored locally in an offline store. Only a storage point that is visible to itself may be used to generate the public key through encryption and then put it into the network node. A quick response (QR) code of the generated public key may be displayed on the shared vehicle.

For vehicle rental, the user terminal may unlock the request and generate an address public key through the private key. Then the user terminal may send a vehicle rental request to the blockchain network in the form of a transaction, allowing other user terminals to verify the transaction and store it in their respective blocks as witnesses to the transaction. In this way, the entire vehicle rental information may be stored in the entire blockchain network to ensure security of account data.

For a vehicle locking process, a confirmation message may be issued each time by the vehicle, including a sequence indicating an operation of the locked vehicle, and location information of the vehicle may be sent to the blockchain network in the form of a transaction to verify that the location information is in compliance with the specification. If it fails in the verification process, the transaction may still be recorded, but will be marked. The marked transaction may serve as a violation record of the user terminal. Then the vehicle cannot be locked, or the account of the user terminal can no longer carry out vehicle rental transactions under economic punishment.

The transaction information stored in the blockchain may be public, so the transaction records for the entire vehicle rental may also be integrated to facilitate the user to view the location of the vehicle. For the shared vehicle service provider, the corresponding vehicle may be extracted from the corresponding private key of the vehicle to determine status and use of the vehicle. The public information may be used as a map of the shared vehicles, recommendations, etc.

For vehicle parking, the blockchain management may play a good role in restraining the parking of the vehicle. When the vehicle is parked in a suitable location, paired transaction record and blockchain may be generated. If there is an unpairing process for the entire usage record of the vehicle, then there may be a user. Correspondingly, there may be a violation record transaction, meaning that they may have illegal operations on the shared vehicles.

In this way, malicious users may be tracked through their behaviors. A blacklist may be formed to help the shared vehicle service providers effectively monitor customer groups.

Fig. 2 is a schematic structural diagram of a blockchain operating environment according to some embodiments of the present disclosure. The blockchain may be constructed by the shared vehicle service provider and responsible for generating blocks and setting a private key for each vehicle to form an account. The shared vehicle service provider may attach the public key generated based on the private key hash to the shared vehicle. The use of the public key may be combined with an existing quick response (QR) payment code, so that a special transaction may be formed for each scan of the rental vehicle and the transaction may be stored in the blockchain. The vehicle rental records may be found through their own private keys and a rental history for each vehicle may be unlocked by the corresponding private key of the vehicle. The Block 1, Block 2, Block 3 ... Block M as shown may be transaction records in the blockchain network. The Data1, Data2 ... DataN contained in each of the blocks may be specific data items of the transaction records, which may include e.g. block head, a Hash (s) of an address (es) of a previous block (s) , a transaction counter, vehicle rental transaction records, etc.

Fig. 3 is an exemplary sequence diagram illustrating processes using smart contracts on the blockchain to supervise and manage the shared vehicles according to some embodiments of the present disclosure.

Network nodes

310 and 320 as shown in Fig. 3 may be any network node capable of storing the blocks, like a user terminal (UE) , a service provider, a vehicle, etc. The node 310 may be a consensus network node or a non-consensus network node in the blockchain network. In a decentralized network, finalization of a new block may require a consensus to ensure that all nodes can store the new block consistently. The consensus may be achieved by a voting mechanism. Nodes in the network which have a right to participate in the consensus are the consensus network nodes. Other nodes may not be involved in the consensus process at all. A key difference between the consensus network node and the non-consensus network node may be that the consensus network node is a network constructor/builder while the non-consensus network node is just a customer without any contribution to the construction of the network.

When it is a consensus network node, the node 310 may acquire, from its local account, vehicle information published by vehicles on the blockchain network and smart contracts which are generated based on the vehicle information in step 301. As an example, the node 310 may backtrack historical transaction records to acquire them.

When it is a non-consensus network node, the node 310 may receive the published vehicle information and the smart contrasts generated based on the vehicle information from a consensus network node in step 302.

In step 303, the node 310 may select a target vehicle 330 from the vehicles. Criteria for selecting the target vehicle 330 may be customized for the end user of the vehicle. Just like the way of selecting a Global Positioning System (GPS) routing strategy, the criteria may include price, credit, usage, location, service provider preference, etc.

In step 304, the node 310 may obtain vehicle information and a smart contract for the selected target vehicle. In step 305, the node 310 may broadcast the obtained vehicle information and smart contract to other network nodes (e.g. a part or all of other network nodes) of the whole blockchain network. As an example, service selection information for the target vehicle may be broadcast along with the vehicle information and the smart contract. The service selection information may include detailed items of the smart contract and any useful terms that are used in a shared vehicle rental process. As a further example, a part, e.g., a half, of the smart contract for the selected target vehicle may be signed by the node 310 before it broadcasts the signed smart contract to other network nodes (e.g. a part or all of the other network nodes) of the entire blockchain network.

Nodes receiving the broadcast vehicle information and smart contract as well as the service selection information may also be consensus nodes or non-consensus nodes. The receiving consensus nodes may store the broadcast message, and the receiving non-consensus nodes may not store the broadcast message.

A node 320 having received the message broadcast by the node 310 is a consensus network node in the blockchain network. In step 306, the node 320 may determine if the received vehicle information for the target vehicle is associated with itself. If not, the process may end. If so, in step 307, the node 320 may judge if the node 310 satisfies a vehicle use condition.

As an example, the node 320 may determine the number of tokens to be pledged by the node 310, based on the received smart contract and the received service selection information. Both parties which sign a smart contract need to pledge a certain number of tokens to a special address to ensure compliance with execution of the smart contract. For example, the node 310 and the node 320 each pledge the same number N of tokens to a smart contract address. If the node 310 violates the rule when executing the smart contract, the N tokens pledged by the node 310 will be directly transferred to the node 320 as a penalty, and the token pledged by the node 320 itself will be unlocked when the node 310 violates the rule, and return to an account of the node 320. In the same way, the node 320 is subject to the same constraint. Payment of tokens by the node 310 may be cut from the pledged tokens. Before the pledged tokens are used up, there should be a warning to recharge tokens. Once the pledged tokens are used up, a usage right of the shared vehicle may no longer be valid.

Then, the node 320 may query the blockchain network to determine if the node 310 completes the payment of all of the N tokens, and if so, determine whether a credit value of the node 310 is greater than a threshold value. If the credit value is greater than the threshold value, the node 320 may make a judgment that the node 310 satisfies the vehicle use condition.

If the node 310 satisfies the vehicle use condition, then in step 308, the node 320 may sign the rest, e.g., the other half, of the smart contract and broadcast the signed smart contract through the blockchain network. Then, in step 309, the node 320 may associate the node 310 with the target vehicle 330.

As an example, the node 320 may load a public key of the node 310 onto identity information of the node 310 to form a message body. Then, the node 320 may transmit the message body to the target vehicle 330 for the target vehicle 330 to verify a user identity of the node 310.

As another example, if the target vehicle 330 is in an abnormal state in violation of the smart contract, the node 320 may transmit a warning to the target vehicle 330. If the target vehicle 330 does not violate the smart contract, the node 320 may detect if the target vehicle 330 is in a normal state of the smart contract at expiry of use time. If not, the node 320 may disconnect the target vehicle 330 from the node 310, and if so, the node 320 may further detect if the node 310 is about to renew fees of the target vehicle 330. If so, the node 320 may permit the node 310 to continue using the target vehicle 330, and if not, the node 320 may inform the node 310 to transmit tokens to the target vehicle 330 based on the smart contract.

Fig. 4 is a flow chart illustrating a method 400 implemented on a first network node according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by the first network node, such as the network node 310 as shown in Fig. 3 but not limited thereto. The operations in this and other flow charts will be described with reference to the exemplary embodiments of the other figures. However, it should be appreciated that the operations of the flow charts may be performed by embodiments of the present disclosure other than those discussed with reference to the other figures, and the embodiments of the present disclosure discussed with reference to these other figures may perform operations different than those discussed with reference to the flow charts.

In one embodiment, the method 400 begins with the first network node acquiring vehicle information published on the blockchain network by vehicles and smart contracts generated based on the vehicle information (block 401) . The first network node may select a target vehicle from the vehicles (block 402) , and obtain vehicle information and a smart contract corresponding to the selected target vehicle (block 403) . The first network node may broadcast the obtained vehicle information and smart contract to other network nodes (e.g. a part or all of the other network nodes) of the entire blockchain network (block 404) .

Fig. 5 is a more specific flow chart illustrating a method 500 implemented on a first network node according to some embodiments of the present disclosure. As an example, the first network node may be the network node 310 as shown in Fig. 3 but not limited thereto.

In an embodiment, the first network node, which is a consensus network node, may acquire vehicle information published on the blockchain network by vehicles and smart contracts generated based on the vehicle information, by looking up its local account (block 501) . As an example, the first network node may backtrack the transaction records.

In another embodiment, the first network node, which is a non-consensus network node, may receive vehicle information published on the blockchain network by vehicles and smart contracts generated based on the vehicle information from a consensus network node (block 502) .

The first network node may select a target vehicle from the vehicles (block 503) , and obtain vehicle information and a smart contract corresponding to the selected target vehicle (block 504) .

Then, the first network node may sign a predetermined part (e.g., a half) of the obtained smart contract (block 505) , and broadcast the vehicle information obtained in block 504 and the smart contact signed in block 505, as well as service selection information associated with the target vehicle, to other network nodes of the entire blockchain network (block 506) .

Fig. 6 is a flow chart illustrating a method 600 implemented on a second network node according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by the network node 320 as shown in Fig. 3, but it is not limited thereto.

In one embodiment, the method 600 begins with the second network node receiving vehicle information and a smart contract corresponding to a target vehicle broadcast by a first network node (block 601) . As an example, the first network node may be the network node 310 as shown in Fig. 3, but it is not limited thereto.

The second network node may determine whether the received vehicle information corresponding to the target vehicle is associated with itself (block 602) . If so, the second network node may judge whether the first network node satisfies a vehicle use condition (block 603) . If so, the second network node may associate the first network node with the target vehicle (block 604) .

Fig. 7 is a more specific flow chart illustrating a method 700 implemented on a second network node according to some embodiments of the present disclosure. As an example, the second network node may be the network node 320 as shown in Fig. 3 but not limited thereto.

In one embodiment, the second network node may receive vehicle information and a smart contract as well as service selection information corresponding to a target vehicle broadcast by a first network node (block 701) . As an example, the first network node may be the network node 310 as shown in Fig. 3, but it is not limited thereto.

The second network node may determine whether the received vehicle information corresponding to the target vehicle is associated with itself (block 702) .

If the vehicle information is associated with the second network node, then the second network node may determine the number of tokens to be pledged by the first network node, based on the received smart contract and service selection information (block 703) . The second network node may determine whether the first network node has completed the payment of all the determined number of tokens (block 704) . If so, the second network node may determine whether a credit value of the first network node is greater than a predetermined threshold value (block 705) . If the credit value is greater than the threshold value, the second network node may determine that the first network node satisfies the vehicle use condition (block 706) .

After determining that the first network node satisfies the vehicle use condition, the second network node may sign the rest (e.g., the other half) of the smart contract (block 707) and broadcast the signed smart contract through the entire blockchain network (block 708) .

In one embodiment, the second network node may load a public key of the first network node onto identity information of the first network node, forming a message body (block 709) . Then, the second network node may transmit the message body to the target vehicle (block 710) so that the first network node is associated with the target vehicle.

In another embodiment, the second network node may detect status of the target vehicle. For instance, the second network may detect whether the target vehicle violates the smart contract (block 711) . If so, the second network node may transmit a warning message to the target vehicle (block 712) , and if not, the second network node may further detect whether the target vehicle is still in use at expiry of use time (block 713) .

If not, the second network node may disconnect the target vehicle from the first network node (block 714) , and if so, the second network node may further detect whether the first network node is about to renew the target vehicle (block 715) .

If the first network node is to renew the target vehicle, the second network node may permit the first network node to continue using it (block 716) . If the first network node is not to renew the target vehicle, the second network node may inform the first network node to transmit a predetermined number of tokens to the target vehicle based on the smart contract (block 717) .

Fig. 8 is a block diagram illustrating a first network node 800 according to some embodiments of the present disclosure. As an example, the first network node 800 may act as the network node 310 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the first network node 800 may be implemented using components other than those illustrated in Fig. 8.

With reference to Fig. 8, the first network node 800 may comprise at least a processor 801, a memory 802, a network interface 803 and a communication medium 804. The processor 801, the memory 802 and the network interface 803 may be communicatively coupled to each other via the communication medium 804.

The processor 801 may include one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory 802, and selectively execute the instructions. In various embodiments, the processor 801 may be implemented in various ways. As an example, the processor 801 may be implemented as one or more processing cores. As another example, the processor 801 may comprise one or more separate microprocessors. In yet another example, the processor 801 may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In still another example, the processor 801 may provide specific functionality by using an ASIC and/or by executing computer-executable instructions.

The memory 802 may include one or more computer-usable or computer-readable storage medium capable of storing data and/or computer-executable instructions. It should be appreciated that the storage medium is preferably a non-transitory storage medium.

The network interface 803 may be a device or article of manufacture that enables the first network node 800 to send data to or receive data from other network nodes. In different embodiments, the network interface 803 may be implemented in different ways. As an example, the network interface 803 may be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., Wi-Fi, WiMax, etc. ) , or another type of network interface.

The communication medium 804 may facilitate communication among the processor 801, the memory 802 and the network interface 803. The communication medium 804 may be implemented in various ways. For example, the communication medium 804 may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium.

In the example of Fig. 8, the instructions stored in the memory 802 may include those that, when executed by the processor 801, cause the first network node 800 to implement the method described with respect to Fig. 4 or 5.

Fig. 9 is another block diagram illustrating a first network node 900 according to some embodiments of the present disclosure. As an example, the first network node 900 may act as the network node 310 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the first network node 900 may be implemented using components other than those illustrated in Fig. 9.

With reference to Fig. 9, the first network node 900 may comprise at least an acquisition unit 901, a selection unit 902, an obtaining unit 903 and a broadcasting unit 904. The acquisition unit 901 may be adapted to perform at least the operations described in block 401 of Fig. 4 and in

blocks

501 and 502 of Fig. 5. The selection unit 902 may be adapted to perform at least the operations described in block 402 of Fig. 4 and in block 503 of Fig. 5. The obtaining unit 903 may be adapted to perform at least the operations described in block 403 of Fig. 4 and in block 504 of Fig. 5. The broadcasting unit 904 may be adapted to perform at least the operations described in block 404 of Fig. 4 and in block 506 of Fig. 5.

In one embodiment, the first network node 900 may further comprise at least a signing unit 505. The signing unit 505 may be adapted to perform at least the operation described in block 505 of Fig. 5.

Fig. 10 is a block diagram illustrating a second network node 1000 according to some embodiments of the present disclosure. As an example, the second network node 1000 may act as the network node 320 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the second network node 1000 may be implemented using components other than those illustrated in Fig. 10.

With reference to Fig. 10, the second network node 1000 may comprise at least a processor 1001, a memory 1002, a network interface 1003 and a communication medium 1004. The processor 1001, the memory 1002 and the network interface 1003 may be communicatively coupled to each other via the communication medium 1004.

The processor 1001, the memory 1002, the network interface 1003 and the communication medium 1004 are structurally similar to the processor 801, the memory 802, the network interface 803 and the communication medium 804 respectively, and will not be described herein in detail.

In the example of Fig. 10, the instructions stored in the memory 1002 may include those that, when executed by the processor 1001, cause the second network node 1000 to implement the method described with respect to Fig. 6 or 7.

Fig. 11 is another block diagram illustrating a second network node 1100 according to some embodiments of the present disclosure. As an example, the second network node 1100 may act as the network node 320 as shown in Fig. 3, but it is not limited thereto. It should be appreciated that the second network node 1100 may be implemented using components other than those illustrated in Fig. 11.

With reference to Fig. 11, the second network node 1100 may comprise at least a receiving unit 1101, a determination unit 1102, a judging unit 1103 and an association unit 1104. The receiving unit 1101 may be adapted to perform at least the operations described in block 601 of Fig. 6 and in block 701 of Fig. 7. The determination unit 1102 may be adapted to perform at least the operations described in block 602 of Fig. 6 and in

blocks

702, 703, 704, 705 and 706 of Fig. 7. The judging unit 1103 may be adapted to perform at least the operation described in block 603 of Fig. 6. The association unit 1104 may be adapted to perform at least the operation described in block 604 of Fig. 6.

In one embodiment, the second network node 1100 may further comprise at least a signing unit 1105, a broadcasting unit 1106, a loading unit 1107, a transmission unit 1108, a detection unit 1109, a disconnection unit 1110, a usage permitting unit 1111 and an informing unit 1112.

The signing unit 1105 may be adapted to perform at least the operation described in block 707 of Fig. 7. The broadcasting unit 1106 may be adapted to perform at least the operation described in block 708 of Fig. 7. The loading unit 1107 may be adapted to perform at least the operation described in block 709 of Fig. 7. The transmission unit 1108 may be adapted to perform at least the operations described in

blocks

710 and 712 of Fig. 7. The detection unit 1109 may be adapted to perform at least the operations described in

blocks

711, 713 and 715 of Fig. 7. The disconnection unit 1110 may be adapted to perform at least the operation described in block 714 of Fig. 7. The usage permitting unit 1111 may be adapted to perform at least the operation described in block 716 of Fig. 7. The informing unit 1112 may be adapted to perform at least the operation described in block 717 of Fig. 7.

The units 901-905 and 1101-1112 are illustrated as separate units in Figs. 9 and 11. However, this is merely to indicate that the functionality is separated. The units may be provided as separate elements. However, other arrangements are possible, e.g., some of them may be combined as one unit in each figure. Any combination of the units may be implemented in any combination of software, hardware, and/or firmware in any suitable location. For example, there may be more controllers configured separately, or just one controller for all of the components.

The units shown in Figs. 9 and 11 may constitute machine-executable instructions embodied within a machine, e.g., readable medium, which when executed by a machine will cause the machine to perform the operations described. Besides, any of these units may be implemented as hardware, such as an application specific integrated circuit (ASIC) , Digital Signal Processor (DSP) , Field Programmable Gate Array (FPGA) or the like.

Moreover, it should be appreciated that the arrangements described herein are set forth only as examples. Other arrangements (e.g., more controllers or more detectors, etc. ) may be used in addition to or instead of those shown, and some units may be omitted altogether. Functionality and cooperation of these units are correspondingly described in more detail with reference to Figs. 4-7.

Fig. 12 is a block diagram illustrating a blockchain network 1200 according to some embodiments of the present disclosure. The blockchain network 1200 may comprise at least a plurality of first network nodes 1201 and a plurality of second network nodes 1202 adapted to receive broadcast messages from the plurality of first network nodes 1201.

As an example, the first network nodes 1201 may act as the first network node as depicted in Fig. 8 or Fig. 9, and the second network nodes 1202 may act as the second network node as depicted in Fig. 10 or Fig. 11.

The present disclosure completes the implementation of the vehicle rental process for the user through the blockchain technology. Each vehicle user may rent the vehicle by scanning a QR code of the vehicle on an application (App) on a mobile phone. When the QR code is scanned, a message may be sent to a service provider, and the service provider may first verify reliability of the user. This may require only cryptographic verification. Then, credit of the user may be confirmed based on what is already recorded in the blockchain. If the user is a trusted user, the service provider may return a password and generate an unconfirmed transaction. The transaction may store a public key sent by the user and a public key of the corresponding vehicle. This transaction may be sent to the entire network, but each node may not immediately store the transaction completely in the blockchain, but instead put it into a pool to wait for further message verification. If the user does not receive the verification within a certain period of time, then the user may discard the transaction. If the user is an untrusted user, then payment may be refused and a violation notification may be returned. When the vehicle user unlocks the corresponding vehicle using a password, the vehicle may issue a confirmation message. This message may have a sequence of driving identifications. It may also contain the public key generated in front of the shared vehicle, time, location and/or other information. It may be propagated directly to the network. When a network node receives the message, it may look up the corresponding transactions in the pool, unlock the transaction and complete the transaction. The network node may then create a copy of the transaction and write it to the corresponding blockchain.

The present disclosure can complete the vehicle locking process also through the blockchain technology. When the vehicle user locks the vehicle, the vehicle may issue a confirmation message. This message may have a lock identification sequence, which may also contain a newly generated public key of the vehicle, time, location, and/or other information. The lock identification sequence may be spread throughout the entire network so that all of the network nodes receive this message. First, it may be determined whether location information in the message represents a legal location. A copy of the transaction may be generated, including the public key of the corresponding user, and it may be combined with the newly generated public key of the vehicle to generate a new transaction and store it in the blockchain. At this point, a service cycle of this vehicle is over. If location information in the message is illegal, a violation record transaction may be generated and distributed to the entire blockchain network. When the user does not lock the vehicle, a message may be sent to the entire network after a certain period of time. The message may contain an illegal field and the other nodes may verify it and generate a violation record transaction, which may be distributed to the entire blockchain network.

The service provider may perform the vehicle management process through the blockchain technology. Since the operating service provider is in charge of the private key of the vehicle, the blockchain may be unlocked with the private key corresponding to the contained transaction. These transactions may be compared with those for neighbor nodes to ensure authenticity. The result is a series of transaction information. For the public key of each vehicle user, there may be two transaction blocks in time. Through the time sequence of the transaction, it may be possible to determine an experience of using the vehicle, passing locations, and a final location. As to maintenance and damage of the vehicle, the user who has discovered the public key by looking at the transaction chain may finally rent the vehicle, so that the vehicle damage, violations, etc., may be linked to the user and play a regulatory role. This information is difficult to modify, and each transaction has reliable backup confirmation information at each node. For some statistical information on vehicles such as usage, an amount of transfer from an area to another, etc. may be obtained through this transaction, so behavioral information of some users may be directly obtained.

Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be appreciated, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to actions and processes of a computer system, or a similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system′s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present disclosure as described herein.

An embodiment of the present disclosure may be an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor” ) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines) . Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

In the foregoing detailed description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the spirit and scope of the present disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Throughout the description, some embodiments of the present disclosure have been presented through flow diagrams. It should be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present disclosure. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the spirit and scope of the present disclosure as set forth in the following claims.

Claims

A shared vehicle management method (400) implemented by a first network node in a blockchain network, comprising:

acquiring (401) vehicle information published on the blockchain network by vehicles and smart contracts associated with the vehicle information;

selecting (402, 503) a target vehicle from the vehicles;

obtaining (403, 504) vehicle information and a smart contract corresponding to the target vehicle; and

broadcasting (404) the obtained vehicle information and smart contract through the blockchain network.
The method of Claim 1,

wherein if the first network node is a consensus network node, then the vehicle information published on the blockchain network and the smart contracts associated with the vehicle information are acquired (501) from a local account of the first network node, and

wherein if the first network node is a non-consensus network node, then the vehicle information published on the blockchain network and the smart contracts associated with the vehicle information are acquired (502) by receiving the vehicle information and the smart contracts from a consensus network node.
The method of Claim 1, wherein broadcasting the obtained vehicle information and smart contract further comprises:

transmitting (506) service selection information associated with the target vehicle to other network nodes in the blockchain network.
The method of any of Claims 1 to 3, further comprising:

signing (505) a predetermined part of the obtained smart contract before broadcasting the obtained vehicle information and smart contract,

wherein broadcasting the obtained vehicle information and smart contract further comprises:

transmitting (506) the obtained vehicle information and the signed smart contract to other network nodes in the blockchain network.
A shared vehicle management method (600) implemented by a second network node in a blockchain network, comprising:

receiving (601) vehicle information and a smart contract corresponding to a target vehicle broadcast by a first network node in the blockchain network;

determining (602, 702) whether the vehicle information corresponding to the target vehicle is associated with the second network node;

if the vehicle information corresponding to the target vehicle is associated with the second network node, judging (603) whether the first network node satisfies a vehicle use condition; and

if the first network node satisfies the vehicle use condition, associating (604) the first network node with the target vehicle.
The method of Claim 5, wherein service selection information associated with the target vehicle is received (701) from the first network node along with the vehicle information and the smart contract.
The method of Claim 6, wherein judging whether the first network node satisfies the vehicle use condition further comprises:

determining (703) the number of tokens to be pledged by the first network node based on the smart contract and the service selection information;

determining (704) whether the first network node completes payment of the determined number of the tokens;

if the first network node completes the payment, determining (705) whether a credit value of the first network node is greater than a predetermined threshold value; and

if the credit value is greater than the predetermined threshold value, determining (706) that the first network node satisfies the vehicle use condition.
The method of Claim 5, wherein associating the first network node with the target vehicle further comprises:

loading (709) a public key of the first network node onto identity information of the first network node to form a message body; and

transmitting (710) the message body to the target vehicle.
The method of Claim 5, wherein associating the first network node with the target vehicle further comprises:

if the target vehicle violates the smart contract, transmitting (712) a warning message to the target vehicle,

if the target vehicle does not violate the smart contract, detecting (713) whether the target vehicle is still in a use state when use time is reached;

if the target vehicle is not in the use state when the use time is reached, disconnecting (714) the target vehicle from the first network node,

if the target vehicle is in the use state when the use time is reached, detecting (715) whether the first network node is to renew the target vehicle;

if the first network node is to renew the target vehicle, permitting (716) the first network node to continue using the target vehicle, and

if the first network node is not to renew the target vehicle, informing (717) the first network node to transmit a predetermined number of tokens to the target vehicle based on the smart contract.
The method of any of Claims 5 to 9, further comprising:

if a predetermined part of the smart contract is signed by the first network node, signing (707) the rest of the smart contract and broadcasting (708) the signed smart contract through the blockchain network after judging that the first network node satisfies the vehicle use condition.
A first network node (800) in a blockchain network, comprising:

a processor (801) ; and

a memory (802) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the first network node to perform operations of the method of any of Claims 1 to 4.
A second network node (1000) in a blockchain network, comprising:

a processor (1001) ; and

a memory (1002) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the second network node to perform operations of the method of any of Claims 5 to 10.
A blockchain network (1200) , comprising:

a plurality of first network nodes (1201) of Claim 11; and

a plurality of second network nodes (1202) of Claim 12 adapted to receive messages broadcast by the plurality of first network nodes.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a first network node in a blockchain network, causes the first network node to perform operations of the method of any of Claims 1 to 4.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a second network node in a blockchain network, causes the second network node to perform operations of the method of any of Claims 5 to 10.