JP7505938B2 - Reservation systems and programs - Google Patents

Description

Patent Law Article 30, Paragraph 2 applied Published in a paper at the 61st Civil Engineering Planning Research Symposium, Spring Conference, June 4, 2020 (held June 13-14, 2020)

The present invention relates to a reservation system and a program.

In recent years, due to the increase in the number of cars, there are cases where the parking lot is full even when you arrive at your destination and you are unable to park. To address this issue, systems have been known that allow you to reserve an available parking space using a mobile phone or a terminal connected to the Internet (for example, Patent Document 1).

Also, overseas, in order to alleviate constant urban congestion, a ride-sharing service is being offered that uses an application to match drivers and passengers who are heading in the same direction to their destination (for example, Non-Patent Document 1). Furthermore, the Ministry of Land, Infrastructure, Transport and Tourism has begun demonstration experiments on next-generation transportation infrastructure technology (MaaS: mobility as a service), which allows users to use a smartphone application to search and reserve optimal routes from a departure point to a destination using multiple public transportation methods all at once (for example, Non-Patent Document 2). Also, from the perspective of alleviating congestion and maintaining public transportation, efforts are being implemented and supported to improve public transportation services and to encourage people to switch from cars and promote the use of public transportation.

Reserving a parking space requires some sort of contract between the driver and the person managing the parking space, and reserving a carpooling service also requires some sort of contract between the driver and the person who wants to ride with them (carpool). In response to this, a technology called smart contract, which uses blockchain technology to automatically execute contracts over the Internet, has been attracting attention in recent years (for example, Non-Patent Document 3).

JP 2003-123195 A

UberPool, Internet <URL: https://www.uber.com/us/en/ride/uberpool/> Ministry of Land, Infrastructure, Transport and Tourism press release, July 31, 2019, Internet <URL: https://www.mlit.go.jp/report/press/sogo12_hh_000152.html> bitFlyer, Internet <URL: https://bitflyer.com/ja-jp/glossary/smartcotract>

For example, companies, universities, stations, various commercial facilities, etc. are common destinations for many people. Therefore, if there was a system that allowed drivers to reserve parking spaces at these locations and also recruit and accept reservations from people (passengers) who want to share a ride to the same destination, it would be possible to support the goal of alleviating traffic congestion mentioned above. However, there is no system that allows reservations for parking spaces and passengers to be made simultaneously and easily.

One embodiment of the present invention has been made in consideration of the above points, and aims to make it possible to simultaneously and easily reserve parking spaces and passengers.

To achieve the above objective, a reservation system according to one embodiment is a reservation system including a server that implements a smart contract on a blockchain platform, and the server is characterized by having a first issuance/transfer unit that issues and transfers a first token representing a reservation for a parking lot, a second issuance/transfer unit that issues and transfers a second token representing a reservation for a ride in a vehicle whose destination is the parking lot, a first amortization unit that amortizes the second token when a ride in the vehicle is made, and a second amortization unit that amortizes the first token when parking in the parking lot is made.

You can easily reserve a parking space and passengers at the same time.

1 is a diagram illustrating an example of an overall configuration of a reservation system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a functional configuration of a server according to the present embodiment. FIG. 2 is a diagram illustrating an example of a functional configuration of a driver's terminal according to the present embodiment. FIG. 2 is a diagram illustrating an example of a functional configuration of a passenger terminal according to the present embodiment. FIG. 4 is a diagram illustrating an example of a functional configuration of a verifying terminal according to the present embodiment. FIG. 2 illustrates an example of a parking reservation token. FIG. 2 illustrates an example of a passenger reservation token. FIG. 2 is a diagram showing an example of a flow of parking lot reservation and passenger reservation. This is a diagram (part 1) showing an example of the flow from carpooling to parking. This is a diagram (part 2) showing an example of the flow from carpooling to parking. FIG. 13 is a diagram showing an example of a flow of transferring a parking lot reservation token. FIG. 13 is a diagram showing an example of a flow of transferring a passenger reservation token.

One embodiment of the present invention will be described below. In this embodiment, a reservation system 1 will be described that can easily make contracts between parking lot managers and users, and between drivers and passengers, using smart contract technology, while ensuring the reliability of reservations using blockchain technology.

<Overall composition>
As shown in Fig. 1, the reservation system 1 according to this embodiment includes a plurality of servers 10, a driver terminal 20, a passenger terminal 30, and a confirmer terminal 40. These are communicatively connected via a communication network such as the Internet. Note that, as an example, Fig. 1 shows one each of the driver terminal 20, the passenger terminal 30, and the confirmer terminal 40, but there may be a plurality of each of the driver terminal 20, the passenger terminal 30, and the confirmer terminal 40.

The server 10 is a computer or computer system that constitutes a node of the blockchain network (hereinafter also referred to as a "BC node"). Each of these servers 10 exists in a distributed manner on the blockchain network and is connected to each other via P2P (Peer to Peer). Each server 10 also has a blockchain (distributed ledger) shared by the blockchain network, and has a smart contract implemented to execute transactions. The transfer and redemption of parking reservation tokens and passenger reservation tokens, which will be described later, are realized by executing transactions.

The driver terminal 20 is a terminal (e.g., a smartphone, a tablet terminal, a wearable device, etc.) used by the driver of the vehicle. The driver can reserve a parking space using the driver terminal 20. When reserving a parking space, the driver can invite passengers by specifying the number of passengers available, the meeting place, the meeting time, etc. A parking space is reserved by issuing a parking space reservation token from the server 10 in response to a request from the driver terminal 20, and transferring ownership of the token to the driver. When a passenger is invited, a passenger reservation token is issued by the server 10 in response to a request from the driver terminal 20. The parking space reservation token corresponds to an electronic ticket for using the parking space, and similarly, the passenger reservation token corresponds to an electronic ticket for riding in the vehicle driven by the driver.

The parking lot reservation token and passenger reservation token are realized by tokens defined in various blockchain platforms. In the reservation system 1 according to this embodiment, any platform can be used as the blockchain platform, but for example, when Ethereum (registered trademark) is used as the blockchain platform, the parking lot reservation token and passenger reservation token can be realized by tokens conforming to ERC721 (NFT: Non-Fungible Token), etc. Other blockchain platforms besides Ethereum include, for example, Hyperledger (registered trademark) Fabric.

The passenger terminal 30 is a terminal of any type (e.g., a smartphone, a tablet terminal, a wearable device, etc.) used by a passenger who wants to ride (share) in a vehicle driven by a driver. A passenger can make a reservation for a ride using the passenger terminal 30. A reservation for a ride is made by transferring ownership of a passenger reservation token to the passenger in the server 10 in response to a request from the passenger terminal 30.

The verifier terminal 40 is a terminal (e.g., a smartphone, a tablet terminal, a wearable device, etc.) used by the manager of the parking lot or the manager of the meeting place where passengers ride in the car (hereinafter also referred to as the "verifier"). The verifier terminal 40 verifies the ownership of the parking lot reservation token and the passenger reservation token, requests the redemption of the token, etc.

The verifier terminal 40 does not necessarily have to be a terminal used by the verifier, and any device or apparatus may be used as long as it is capable of verifying the owner of a token (parking lot reservation token or passenger reservation token) and requesting redemption, for example. For example, it may be a gate device installed at the entrance to a parking lot that allows a vehicle to enter if the owner of the parking lot reservation token is successfully verified. It may also be a gate device installed at a meeting place where passengers ride in a vehicle, and allows a passenger to ride in a vehicle if the owner of the passenger reservation token is successfully verified.

In addition, for example, when verifying the owner of a passenger reservation token or requesting redemption, the driver may be the verifier. Therefore, various terminals such as a smartphone used by the driver may function as the verifier terminal 40. In this case, the terminal may also function as the driver terminal 20 (i.e., the driver terminal 20 and the verifier terminal 40 may be the same terminal).

Here, although not shown in FIG. 1, there is a management server that manages the reservation status of the parking lot (i.e., the availability of parking spaces, etc.) and the reservation status of passengers (i.e., the availability of the number of passengers in the car, etc.), and the server 10, the driver's terminal 20, and the passenger's terminal 30 are connected to the management server so as to be able to communicate with each other via a communication network. The management server may be divided into a management server that manages the reservation status of the parking lot and a management server that manages the reservation status of the passengers. In addition, the management server may function as a Web server or a data distribution server that displays a parking reservation screen on the driver's terminal 20 and a passenger reservation screen on the passenger's terminal 30. In this way, although not shown in FIG. 1, the reservation system 1 according to this embodiment includes at least a server that manages the reservation status of the parking lot and the reservation status of the passengers, and a server that provides the data necessary for making a parking reservation on the driver's terminal 20 and making a passenger reservation on the passenger's terminal 30.

<Functional configuration>
Next, the functional configurations of the server 10, the driver terminal 20, the passenger terminal 30, and the verifying terminal 40 included in the reservation system 1 according to this embodiment will be described.

<Server 10>
2, the server 10 according to this embodiment includes a first token issuance and transfer unit 101, a first token retirement unit 102, a second token issuance and transfer unit 103, and a second token retirement unit 104. Each of these units is realized by a process executed by a processor such as a CPU (Central Processing Unit) or a GPU (Graphic Processing Unit) by a smart contract implemented on the blockchain platform.

The first token issuance and transfer unit 101 issues a parking lot reservation token in response to a request from the driver terminal 20 and transfers ownership of the parking lot reservation token to the driver.

The first token abolition unit 102 abolishes the parking lot reservation token in response to a request from the driver terminal 20 or the verifying terminal 40. Note that abolishing a parking lot reservation token means making it impossible to use the parking lot again with this parking lot reservation token. For example, the parking lot reservation token is abolished by discarding the parking lot reservation token, setting the parking lot reservation token to be unusable, transferring ownership of the parking lot reservation token to a predetermined person (for example, the administrator of the management server that manages the reservation status of the parking lot, the administrator of the parking lot, etc.).

The second token issuing and transferring unit 103 issues a passenger reservation token in response to a request from the driver's terminal 20. The second token issuing and transferring unit 103 also transfers ownership of the passenger reservation token to the passenger in response to a request from the passenger's terminal 30.

The second token abolishment unit 104 abolishes passenger reservation tokens in response to requests from the driver's terminal 20 or the verifyer terminal 40. Note that abolishing a passenger reservation token means making it impossible for a passenger to ride again in a vehicle driven by the driver using this passenger reservation token. For example, a passenger reservation token is abolished by discarding the passenger reservation token, setting the passenger reservation token to be unusable, transferring ownership of the passenger reservation token to a predetermined person (for example, an administrator of a management server that manages the reservation status of passengers, a verifyer, etc.), etc.

<Driver terminal 20>
3, the driver terminal 20 according to this embodiment includes a first token issuance/transfer request unit 201, a second token issuance request unit 202, a first token retirement request unit 203, and a first code display unit 204. Each of these units is realized by a process in which one or more programs installed in the driver terminal 20 are executed by a processor such as a CPU.

The first token issuance/transfer request unit 201 requests the server 10 to issue and transfer a parking lot reservation token when reserving a parking lot.

The second token issuance request unit 202 requests the server 10 to issue a passenger reservation token when a passenger is recruited.

When a driver uses a reserved parking lot, the first token redemption request unit 203 requests the server 10 to redeem the parking lot reservation token for using this parking lot.

When the driver uses a reserved parking lot, the first code display unit 204 generates a code (e.g., a two-dimensional code such as a QR code (registered trademark)) that contains information about the parking lot reservation token for using the parking lot, and displays this code on the display of the driver's terminal 20, etc.

<Passenger terminal 30>
4, the passenger terminal 30 according to this embodiment includes a second token transfer request unit 301, a second token retirement request unit 302, and a second code display unit 303. Each of these units is realized by a process in which one or more programs installed in the passenger terminal 30 are executed by a processor such as a CPU.

The second token transfer request unit 301 requests the server 10 to transfer the passenger reservation token when a passenger reservation is made.

When a passenger rides in a reserved vehicle, the second token retirement request unit 302 requests the server 10 to retire the passenger reservation token for this ride.

When a passenger rides in a reserved car, the second code display unit 303 generates a code (e.g., a two-dimensional code such as a QR code) containing information about the passenger reservation token for this ride, and displays this code on the display of the passenger terminal 30, etc.

<Confirmer Terminal 40>
5, the verifier terminal 40 according to this embodiment includes a first reading unit 401, a first token verification unit 402, a first token expiration request unit 403, a second reading unit 404, a second token verification unit 405, and a second token expiration request unit 406. Each of these units is realized by a process in which one or more programs installed in the verifier terminal 40 are executed by a processor such as a CPU.

The first reading unit 401 reads the code displayed on the display of the driver terminal 20 and obtains the information contained in this code (i.e., the parking lot reservation token information).

The first token verification unit 402 verifies the owner of the parking lot reservation token using the information of the parking lot reservation token acquired by the first reading unit 401. In other words, the first token verification unit 402 verifies that the user of the driver terminal 20 is the legitimate owner of the parking lot reservation token.

The first token redemption request unit 403 requests the server 10 to redeem the parking lot reservation token if the first token verification unit 402 confirms that the person is the legitimate owner.

The second reading unit 404 reads the code displayed on the display of the passenger terminal 30 and obtains the information contained in this code (i.e., the passenger reservation token information).

The second token verification unit 405 verifies the owner of the passenger reservation token by using the information of the passenger reservation token acquired by the second reading unit 404. In other words, the second token verification unit 405 verifies that the user of the passenger terminal 30 is the legitimate owner of the passenger reservation token.

The second token redemption request unit 406 requests the server 10 to redeem the passenger reservation token if the second token verification unit 405 confirms that the person is the legitimate owner.

<Parking lot reservation token and passenger reservation token>
Here, an example of the data configuration of a parking lot reservation token is shown in FIG. 6. As shown in FIG. 6, the parking lot reservation token includes at least identification information (e.g., a token ID) for identifying the token and address information of the owner of the token. In addition to these, the parking lot reservation token may include identification information for identifying the car (vehicle) driven by the driver, identification information for identifying the reserved parking lot, the scheduled date and time of using the parking lot, a usability flag, and the like. The usability flag is a flag indicating whether the token is usable or not, and has a value indicating that the token is usable when the token is issued, and is updated to a value indicating that the token is unusable when the token is depreciated. In addition, the identification information of the car is the vehicle registration number (so-called number), etc., but in addition to this, information such as the model and color may be included. The address information of the token owner is created based on the public key of the user (the user of the driver's terminal 20, the user of the passenger's terminal 30, etc.).

An example of the data configuration of a passenger reservation token is shown in FIG. 7. As shown in FIG. 7, a passenger reservation token includes at least identification information for identifying the token (e.g., a token ID) and address information of the token owner. In addition to these, a passenger reservation token may also include identification information for identifying a parking reservation token (e.g., a token ID), identification information for identifying the vehicle in which the passenger will ride, identification information for identifying the meeting place and meeting time for the passenger to ride, and parking information for the destination, an availability flag, etc.

<Procedure for reserving parking spaces and passengers>
An example of the flow of parking lot reservation and passenger reservation will be described with reference to FIG.

First, the driver can use the driver's terminal 20 to check the availability of parking spaces on a specific screen, and then input the desired reservation date and time (scheduled parking date and time), the parking space to be reserved, and the driver's own vehicle identification information, to perform operations to reserve a parking space. The specific screen may be, for example, a web page provided by a web server, or a screen that displays data distributed from a data distribution server.

When an operation to reserve a parking space is performed, the first token issuance/transfer request unit 201 of the driver's terminal 20 transmits a request to issue/transfer a parking space reservation token to the server 10 (step S101). Here, the request to issue/transfer a parking space reservation token includes various information input in the operation to reserve a parking space (e.g., the desired date and time of reservation (scheduled date and time of parking), the parking space to be reserved, the identification information of the driver's own vehicle, etc.). At this time, the address information of the driver who will be the owner of the parking space reservation token may be included in the request to issue/transfer a parking space reservation token, or may be transmitted to the server 10 by any other method (e.g., email, SNS, input on a web page, etc.).

The driver's terminal 20 only needs to send a request for issuing and transferring a parking lot reservation token to a predetermined server 10 among the multiple servers 10 that make up the blockchain network. This also applies when the driver's terminal 20 sends various requests to the server 10 thereafter.

When the first token issuance/transfer unit 101 of the server 10 receives a request to issue/transfer a parking lot reservation token, it issues a parking lot reservation token (step S102). At this time, the first token issuance/transfer unit 101 issues a parking lot reservation token in which the address information of a predetermined person (e.g., the administrator of the management server that manages the reservation status of the parking lot or the administrator of the parking lot) is set as the address information of the token owner. In addition, the parking lot reservation token is set with various information included in the issuance/transfer request (scheduled parking date and time, the parking lot to be reserved, the driver's vehicle identification information, etc.).

Next, the first token issuance/transfer unit 101 of the server 10 transfers the ownership of the parking lot reservation token issued in step S103 above to the user (driver) of the driver terminal 20 that sent the parking lot reservation token issuance/transfer request in step S101 above (step S103). Then, the first token issuance/transfer unit 101 of the server 10 replies with the result of the parking lot reservation token issuance/transfer request (e.g., successful or unsuccessful issuance/transfer). Note that if the issuance and transfer of the parking lot reservation token is successful, this means that the parking lot reservation has been successful, and if not, this means that the parking lot reservation has failed.

Here, the transfer of ownership of a parking reservation token means rewriting the address information of the token's owner to the address information of the new owner, the driver. Such a transfer of ownership of a token is achieved by issuing a transaction that performs the above-mentioned rewrite. In other words, a transaction that performs the above-mentioned rewrite is sent to each server 10 in the blockchain network, and this transaction is verified and approved, and added to the blockchain as a new block. In this way, the transaction history is recorded as blocks in the blockchain.

When reserving a parking space (or after reserving a parking space), the driver can perform operations to recruit passengers by inputting the number of passengers available, the meeting place, the meeting time, etc. on a specific screen. Note that a specific screen is, for example, a web page provided by a web server, a screen displaying data distributed from a data distribution server, etc.

When an operation to recruit a passenger is performed, the second token issuance request unit 202 of the driver's terminal 20 transmits a request to issue a passenger reservation token to the server 10 (step S104). Here, the request to issue a passenger reservation token includes various information (e.g., the number of passengers available, the meeting place, the meeting time, etc.) that was input in the operation to recruit a passenger. In addition, the request to issue a passenger reservation token may include identification information of a parking lot reservation token for use of the parking lot reserved by the driver, identification information of the vehicle driven by the driver, identification information of the parking lot, etc.

When the second token issuance/transfer unit 103 of the server 10 receives a passenger reservation token issuance request, it issues a passenger reservation token (step S105). At this time, the second token issuance/transfer unit 103 issues passenger reservation tokens for the number of passengers who can ride together, with the address information of a predetermined person (for example, an administrator or a verifier of the management server that manages the reservation status of passengers) as the address information of the token owner. In addition, these passenger reservation tokens are set with various information included in the issuance request, such as the meeting place and meeting time, as well as parking lot reservation token identification information, vehicle identification information, parking lot identification information, etc.

Next, a passenger wishing to share a ride can use the passenger terminal 30 to check the passenger reservation token information (meeting place, meeting time, destination parking lot, etc.) on a specific screen, and select the desired passenger reservation token to perform operations to reserve a ride. The specific screen may be, for example, a web page provided by a web server, or a screen displaying data distributed from a data distribution server, etc.

When an operation to reserve a ride is performed, the second token transfer request unit 301 of the passenger terminal 30 sends a passenger reservation token transfer request to the server 10 (step S106). Here, the passenger reservation token transfer request includes information on the passenger reservation token selected in the operation to reserve a ride (meeting place, meeting time, destination parking lot, etc.). At this time, the address information of the passenger who will become the owner of the passenger reservation token may be included in the passenger reservation token transfer request, or may be sent to the server 10 by any other method (e.g., email, SNS, input on a web page, etc.).

The passenger terminal 30 only needs to send a transfer request for the passenger reservation token to a predetermined server 10 among the multiple servers 10 that make up the blockchain network. This also applies when the passenger terminal 30 sends various requests to the server 10 thereafter.

When the second token issuance and transfer unit 103 of the server 10 receives the transfer request for the passenger reservation token, it transfers the ownership of the passenger reservation token selected in the operation to reserve a ride to the user (passenger) of the passenger terminal 30 that sent the passenger reservation token transfer request in step S106 above (step S107). Note that if there are multiple passenger reservation tokens selected in the operation to reserve a ride, the ownership of one of these passenger reservation tokens can be transferred to the passenger in question.

Then, the second token issuance and transfer unit 103 of the server 10 replies with the result of the passenger reservation token transfer request (e.g., whether the transfer was successful or not). If the transfer of ownership of the passenger reservation token is successful, it means that the reservation for the ride was successful, and if not, it means that the reservation for the ride was unsuccessful. Also, the transfer of ownership of a passenger reservation token means rewriting the address information of the owner of the token to the address information of the new owner, the passenger, in the same way as the transfer of ownership of a parking lot reservation token.

<The process from carpooling to parking>
Next, a flow from when a passenger rides in a car driven by a driver to when the car is parked in a parking lot will be described. The flow when the verifying terminal 40 is not used will be described with reference to FIG. 9, and the flow when the verifying terminal 40 is used will be described with reference to FIG. 10.

<<When the confirmer terminal 40 is not used>>
The passenger uses the passenger terminal 30 to check the information in the passenger reservation token (e.g., meeting place, meeting time, vehicle identification information, etc.) on a specified screen, and heads to the meeting place at the meeting time to meet up with the driver. Note that the specified screen is, for example, a web page provided by a web server, a screen displaying data distributed from a data distribution server, etc. However, the passenger may meet up with the driver by checking, instead of the information in the passenger reservation token, for example, a web page that displays the location information of the vehicle in which the passenger has reserved a ride, or a data distribution application that distributes the location information.

When the passenger meets up with the driver and gets into the car, he or she operates the passenger terminal 30 to perform the amortization operation of the passenger reservation token. When this operation is performed, the second token amortization request unit 302 of the passenger terminal 30 sends a request for amortization of the passenger reservation token to the server 10 (step S201). Here, the request for amortization of the passenger reservation token includes information for identifying the passenger reservation token to be amortized (e.g., the token ID, the passenger's email address, telephone number, user ID, etc.).

When the second token redemption unit 104 of the server 10 receives a request to redeem a passenger reservation token, it determines the validity of the redemption request (step S202). The validity can be determined, for example, by verifying the electronic signature attached to the redemption request. The electronic signature is attached using the passenger's private key, and is verified using the passenger's public key.

Next, if the second token amortization unit 104 of the server 10 determines in step S202 above that the amortization request is valid, it amortizes the passenger reservation token related to the amortization request (step S203). Then, the second token amortization unit 104 of the server 10 replies with the result of the request to amortize the passenger reservation token (e.g., successful or failed amortization). If the passenger reservation token is successfully amortized, this means that the passenger's ride sharing has been permitted (or has been performed), and if not, this means that ride sharing has not been permitted.

Next, when the driver arrives at the reserved parking lot, the driver performs an amortization operation of the parking lot reservation token using the driver terminal 20. When this operation is performed, the first token amortization request unit 203 of the driver terminal 20 sends a request for amortization of the parking lot reservation token to the server 10 (step S204). Here, the request for amortization of the parking lot reservation token includes information for identifying the parking lot reservation token to be amortized (e.g., the token ID, the driver's email address, telephone number, user ID, etc.).

When the first token redemption unit 102 of the server 10 receives a request to redeem the parking lot reservation token, it determines the validity of the redemption request (step S205). The validity can be determined, for example, by verifying the electronic signature attached to the redemption request. The electronic signature is attached using the driver's private key, and is verified using the driver's public key.

Next, if the first token amortization unit 102 of the server 10 determines in step S205 above that the amortization request is valid, it amortizes the parking lot reservation token related to the amortization request (step S206). Then, the first token amortization unit 102 of the server 10 replies with the result of the request to amortize the parking lot reservation token (e.g., success or failure of the amortization). Note that if the parking lot reservation token is successfully amortized, this means that parking in the parking lot has been permitted (or parking has been completed), and if not, this means that parking has not been permitted.

<<When using the confirmer terminal 40>>
The passenger uses the passenger terminal 30 to check the information in the passenger reservation token (e.g., meeting place, meeting time, vehicle identification information, etc.) on a specified screen, and heads to the meeting place at the meeting time to meet up with the driver. Note that the specified screen is, for example, a web page provided by a web server, a screen displaying data distributed from a data distribution server, etc. However, the passenger may meet up with the driver by checking, instead of the information in the passenger reservation token, for example, a web page that displays the location information of the vehicle in which the passenger has reserved a ride, or a data distribution application that distributes the location information.

When the passenger meets up with the driver and gets into the car, the passenger uses the passenger terminal 30 to perform a display operation of a code containing information about the passenger reservation token. When this operation is performed, the second code display unit 303 of the passenger terminal 30 displays a code (e.g., a two-dimensional code such as a QR code) containing information about the passenger reservation token on the display (step S301). Note that the two-dimensional code is just one example, and a barcode or the like may also be used. In addition to this, for example, sound waves, flashing light, images, etc. that represent information about the passenger reservation token may also be output or displayed.

The second reading unit 404 of the verifying terminal 40 reads the code displayed on the display of the passenger terminal 30 in step S301 above, and obtains passenger reservation token information (token identification information (token ID), token owner address information, etc.) (step S302). Note that the second reading unit 404 may read the code using, for example, a camera device or the like provided in the verifying terminal 40.

The second token verification unit 405 of the verifying terminal 40 uses the information acquired in step S302 above to verify the owner of the passenger reservation token (step S303). That is, the second token verification unit 405 uses the token ID included in the information acquired in step S302 above to refer to the token corresponding to this token ID on the blockchain network and verify whether the address information of the owner of the token matches the address information included in the information acquired in step S302 above. If it is confirmed that these address information match, it means that the passenger has ownership of the passenger reservation token (i.e., is the legitimate owner), and if not, it means that the passenger does not have ownership of the passenger reservation token.

Then, the second token verification unit 405 of the verifying terminal 40 replies with the result of the owner verification (e.g., success or failure). Note that, by returning a result indicating success to the passenger terminal 30, the passenger is able to start sharing the ride before the passenger reservation token is actually redeemed. In other words, since a transaction needs to be executed to redeem a token, a waiting time of several seconds to several tens of seconds generally occurs, but by returning a result indicating success to the passenger terminal 30, it is possible to start sharing the ride without waiting time.

In addition, the above reply does not necessarily have to be sent; for example, the result may be displayed on the display of the confirmer terminal 40, and the passenger may confirm this result. Furthermore, as the request for redemption of the passenger reservation token is sent by the confirmer terminal 40 as described below, the passenger terminal 30 does not necessarily have to be connected to a communication network. Therefore, for example, even if the communication state of the passenger terminal 30 is poor and it is not possible to connect to the blockchain network, the passenger can start carpooling.

The second token redemption request unit 406 of the verifying terminal 40 sends a request for redemption of the passenger reservation token to the server 10 (step S304). Here, the request for redemption of the passenger reservation token includes information for identifying the passenger reservation token to be redeemed (e.g., the token ID, the passenger's email address, telephone number, user ID, etc.).

The verifying terminal 40 only needs to send a request for redemption of the passenger reservation token to a predetermined server 10 among the multiple servers 10 that make up the blockchain network. This also applies when the verifying terminal 40 sends various requests to the server 10 thereafter.

When the second token redemption unit 104 of the server 10 receives the redemption request for the passenger reservation token, it determines the validity of the redemption request (step S305). The validity can be determined, for example, by verifying the electronic signature attached to the redemption request. The electronic signature is attached using the verifier's private key, and is verified using the verifier's public key.

Next, if the redemption request is determined to be valid in step S305 above, the second token redemption unit 104 of the server 10 redeems the passenger reservation token related to the redemption request (step S306). Then, the second token redemption unit 104 of the server 10 replies with the result of the request to redeem the passenger reservation token (e.g., success or failure of redemption).

Next, when the driver arrives at the reserved parking lot, the driver uses the driver's terminal 20 to perform a display operation of a code including information of the parking lot reservation token. When this operation is performed, the first code display unit 204 of the driver's terminal 20 displays a code including information of the parking lot reservation token (for example, a two-dimensional code such as a QR code) on the display (step S307). As described above, the two-dimensional code is just one example, and may be a barcode, sound waves, flashing light, an image, etc.

The first reading unit 401 of the verifying terminal 40 reads the code displayed on the display of the driver's terminal 20 in step S307 above, and obtains information about the parking lot reservation token (token identification information (token ID), address information of the token owner, etc.) (step S308). Note that the first reading unit 401 may read the code using, for example, a camera device or the like provided in the verifying terminal 40.

The first token confirmation unit 402 of the confirmer terminal 40 uses the information acquired in step S308 above to confirm the owner of the parking lot reservation token (step S309). That is, the first token confirmation unit 402 uses the token ID included in the information acquired in step S308 above to refer to the token corresponding to this token ID on the blockchain network and confirms whether the address information of the owner of the token matches the address information included in the information acquired in step S308 above. If it is confirmed that these address information match, it means that the driver has ownership of the parking lot reservation token (i.e., is the legitimate owner), and if not, it means that the driver does not have ownership of the parking lot reservation token.

Then, the first token verification unit 402 of the verifying terminal 40 returns the result of the owner verification (e.g., success or failure). Note that, by returning a result indicating success to the driver's terminal 20, the driver is able to start parking in the parking lot before the parking lot reservation token is actually redeemed. In other words, since a transaction needs to be executed to redeem a token, a waiting time of several seconds to several tens of seconds generally occurs, but by returning a result indicating success to the driver's terminal 20, it is possible to start parking without waiting time.

In addition, the above reply does not necessarily have to be sent; for example, the result may be displayed on the display of the verifier terminal 40, and the driver may confirm this result. Furthermore, as the request for redemption of the parking lot reservation token is sent by the verifier terminal 40 as described below, the driver terminal 20 does not necessarily have to be connected to a communication network. Therefore, for example, even if the communication state of the driver terminal 20 is poor and it is not possible to connect to the blockchain network, the driver will be able to start parking.

The first token redemption request unit 403 of the verifying terminal 40 transmits a request for redemption of the parking lot reservation token to the server 10 (step S310). Here, the request for redemption of the parking lot reservation token includes information for identifying the parking lot reservation token to be redeemed (e.g., the token ID, the driver's email address, telephone number, user ID, etc.).

When the first token redemption unit 102 of the server 10 receives a request to redeem a parking lot reservation token, it determines the validity of the redemption request (step S311). The validity can be determined, for example, by verifying the electronic signature attached to the redemption request. The electronic signature is attached using the verifier's private key, and is verified using the verifier's public key.

Next, if the first token redemption unit 102 of the server 10 determines in step S311 that the redemption request is valid, the first token redemption unit 102 of the server 10 redeems the parking lot reservation token related to the redemption request (step S312). Then, the first token redemption unit 102 of the server 10 replies with the result of the request to redeem the parking lot reservation token (e.g., success or failure of redemption).

<Parking lot reservation token transfer procedure>
A driver (hereinafter referred to as Driver A) can transfer the ownership of a parking lot reservation token that he/she has reserved to another driver (hereinafter referred to as Driver B). This allows Driver A to transfer the reservation to Driver B, for example, when a change in plans makes the parking lot reservation unnecessary.

The flow of transferring a parking lot reservation token will now be described with reference to Figure 11. In Figure 11, the driver terminal 20 of driver A will be referred to as "driver terminal 20A" and the driver terminal 20 of driver B will be referred to as "driver terminal 20B."

First, driver A uses driver terminal 20A to perform an operation to transfer ownership of the parking lot reservation token to driver B. In this operation, driver B's address information (or information for identifying this address information (e.g., email address, telephone number, user ID, etc.)) is specified. Driver A may obtain driver B's address information (or information for identifying this address information) by any method (e.g., email, SNS, telephone, etc.).

When the above operation is performed, the first token issuance/transfer request unit 201 of the driver terminal 20A sends a transfer request for the parking lot reservation token to the server 10 (step S401). Here, the transfer request for the parking lot reservation token includes information for identifying the parking lot reservation token to be transferred and address information of the transfer destination driver B (or information for identifying this address information).

When the first token issuance and transfer unit 101 of the server 10 receives a transfer request for the parking lot reservation token, it transfers the ownership of the parking lot reservation token to be transferred from driver A to driver B (step S402). That is, the first token issuance and transfer unit 101 rewrites the address information of the owner of the parking lot reservation token to the address information of driver B.

Then, the first token issuance and transfer unit 101 of the server 10 transmits the result of the parking lot reservation token transfer request (e.g., success or failure of the transfer) to the driver terminal 20A and the driver terminal 20B.

<Passenger reservation token transfer procedure>
A person who has made a reservation to ride in a certain car (hereinafter referred to as passenger A) can transfer the ownership of the passenger reservation token that he/she has reserved to another person (hereinafter referred to as passenger B). This allows passenger A to transfer the reservation to passenger B, for example, when plans change and the ride sharing is no longer necessary.

The flow of passenger reservation token transfer will now be described with reference to Figure 12. In Figure 12, passenger A's passenger terminal 30 will be referred to as "passenger terminal 30A," and passenger B's passenger terminal 30 will be referred to as "passenger terminal 30B."

First, passenger A uses passenger terminal 30A to perform an operation to transfer ownership of the passenger reservation token to passenger B. In this operation, passenger B's address information (or information for identifying this address information (e.g., email address, telephone number, user ID, etc.)) is specified. Passenger A may obtain passenger B's address information (or information for identifying this address information) by any method (e.g., email, SNS, telephone, etc.).

When the above operation is performed, the second token transfer request unit 301 of the passenger terminal 30A sends a passenger reservation token transfer request to the server 10 (step S501). Here, the passenger reservation token transfer request includes information for identifying the passenger reservation token to be transferred and address information of passenger B, the transfer destination (or information for identifying this address information).

When the second token issuance/transfer unit 103 of the server 10 receives a transfer request for the passenger reservation token, it transfers the ownership of the passenger reservation token to be transferred from passenger A to passenger B (step S502). That is, the second token issuance/transfer unit 103 rewrites the address information of the owner of the passenger reservation token to the address information of passenger B.

Then, the second token issuance/transfer unit 103 of the server 10 transmits the result of the passenger reservation token transfer request (e.g., success or failure of the transfer) to the passenger terminal 30A and the passenger terminal 30B.

<Summary>
As described above, the reservation system 1 according to the present embodiment can simultaneously and easily reserve a parking space and reserve passengers (recruit passengers). Moreover, the reservation system 1 according to the present embodiment can ensure the reliability of reservations (i.e., reservations are not tampered with or fraudulent reservations are not made, etc.) by making reservations using tokens issued by smart contracts implemented on a blockchain platform as electronic tickets.

Here are some variations of this embodiment:

(Variation 1)
When the parking lot reservation token is amortized in step S206 of Fig. 9, the server 10 may check whether there is a passenger and perform amortization (i.e., permit use of the parking lot) only if there is a passenger. Specifically, the server 10 may refer to the blockchain network to search for a passenger reservation token that includes the token ID of the parking lot reservation token, and may amortize the parking lot reservation token only if such a passenger reservation token exists and has been amortized. This makes it possible to promote carpooling when drivers travel by car.

(Variation 2)
When issuing a parking lot reservation token in step S102 of Fig. 8, the server 10 may restrict issuance of parking lot reservation tokens depending on the characteristics of the driver. For example, the driver's address may be registered in advance, and only parking lots within the driver's residential area may be reserved, and the server 10 may restrict issuance of parking lot reservation tokens outside the residential area. Or, for example, parking lots may be reserved only on the driver's commuting or school days, and the server 10 may restrict issuance of parking lot reservation tokens on days other than commuting or school days.

(Variation 3)
A points system may be introduced for parking lot reservations. For example, a certain number of points may be given to drivers every month, and a certain number of points may be consumed when issuing a parking lot reservation token, and if the number of points held falls below a certain number, the driver may not be able to reserve a parking lot. This makes it possible to limit the number of times a parking lot can be reserved, and promote the use of public transportation.

For example, when a driver solicits passengers and issues a passenger reservation token, a certain number of points may be awarded. This can encourage drivers to carpool when traveling by car.

The present invention is not limited to the specifically disclosed embodiments above, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims.

1 Reservation system 10 Server (BC node)
20 Driver terminal 30 Passenger terminal 40 Confirmer terminal 101 First token issuing/transfer unit 102 First token abolishing unit 103 Second token issuing/transfer unit 104 Second token abolishing unit 201 First token issuing/transfer request unit 202 Second token issuing request unit 203 First token abolishing request unit 204 First code display unit 301 Second token transfer request unit 302 Second token abolishing request unit 303 Second code display unit 401 First reading unit 402 First token confirming unit 403 First token abolishing request unit 404 Second reading unit 405 Second token confirming unit 406 Second token abolishing request unit

Claims (7)

A reservation system including a server that implements a smart contract on a blockchain platform,
The server,
a first issuing and transferring unit that issues and transfers a first token representing a parking reservation;
a second issuing/transferring unit that issues and transfers a second token representing a reservation for a ride in a vehicle having the parking lot as a destination;
A first redemption unit that redeems the second token when the passenger rides in the vehicle;
a second redemption unit that redeems the first token when parking in the parking lot is performed;
A reservation system comprising: The reservation system further includes a first terminal and a second terminal;
The first terminal comprises:
A first request unit that requests issuance and transfer of the first token;
a second request unit that requests issuance of the second token,
The second terminal comprises:
2. The reservation system according to claim 1, further comprising a third request unit for requesting the transfer of the second token. The first terminal further includes a fourth request unit for requesting the redemption of the first token;
3. The reservation system according to claim 2, wherein the second terminal further comprises a fifth request unit for requesting redemption of the second token. The reservation system includes:
a first reader that reads information of the first token from the first terminal;
a first confirmation unit that confirms whether or not the owner of the first token is legitimate based on the information read by the first reading unit;
a sixth request unit that requests the redemption of the first token when the first confirmation unit confirms that the owner is a legitimate owner;
a second reader that reads information of the second token from the second terminal;
a second confirmation unit that confirms whether or not the owner of the second token is legitimate based on the information read by the second reading unit;
The reservation system of claim 2 or 3, further comprising a device having a seventh request unit that requests the redemption of the second token if the second confirmation unit confirms that the owner is a legitimate owner. The first reading unit includes:
reading information of the first token from a two-dimensional code displayed on a display device of the first terminal;
The second reading unit includes:
5. The reservation system according to claim 4, wherein information on the second token is read from a two-dimensional code displayed on a display device provided in the second terminal. The first issuing and transferring unit
When issuing the first token, a predetermined number of points given to the user who reserves the parking lot are consumed;
If the number of points granted to the user is less than the predetermined number, the first token is not issued;
The second issuing and transferring unit includes:
The reservation system according to any one of claims 1 to 5, characterized in that when the second token is issued, a predetermined number of points are awarded to the user who made the reservation for the parking space. A program that causes a computer to function as a server included in the reservation system described in any one of claims 1 to 6.

Images