Verification device, verification method, service provision system, and program

Abstract

The purpose of the present disclosure is to improve convenience of a service by enabling a specific user to transfer at least a part of usage rights (usage time, usage amount, usage count, etc.) granted to himself or herself to another user.　To achieve the purpose, a verification device included in a service provision system in which a service provision device provides a service to a user terminal: receives, from a specific user terminal, a request for providing the service together with a service-usage-right transfer certificate for the service; on the basis of the transfer certificate, verifies whether or not there is satisfied a condition that a service usage right for using at least a part of the service is transferred from a first user having the service usage right to a second user, and the transfer certificate is issued by the first user; and if the condition is satisfied, authorizes the service provision device to provide, to the specific user terminal, a predetermined service corresponding to service content associated with the transferred service usage right.

Description

Verification device, verification method, service providing system, and program

[0001] The present disclosure relates to a verification device, a verification method, a service providing system, and a program.

[0002] Self-Sovereign Identity (SSI) has been attracting attention in recent years. SSI is an identity management concept (idea) that aims to enable users to manage their own identifiers and identities themselves, without relying on a centralized identity provider (IdP), and to present only information selected at the users' own discretion to recipients such as service providers (Non-Patent Documents 1 and 2).

[0003] Here, a simple explanation will be given of the verification mechanism using SSI with reference to Fig. 18. Fig. 18 is a schematic diagram showing the verification mechanism using SSI. In the world of SSI, there are three parties: Holder, Issuer, and Verifier.

[0004] Holders are users such as students or working adults who create and hold their own decentralized identifiers such as DIDs (Decentralized Identifiers) and register them in databases (DBs) such as distributed repositories or blockchain networks.

[0005] The Issuer issues digital certificates to schools, hospitals, government institutions, etc., and issues digital certificates such as Verifiable Credentials (VCs) that include the user's distributed identifier, etc., obtained from the user, registers them in a DB, and presents them to the user. In this case, the Issuer, for example, certifies attribute information such as the user's name and qualification information such as the name of the company to which the user belongs, and then issues a digital certificate (e.g., VC) that includes the attribute information and qualification information.

[0006] The Verifier is a service provider such as a company, and uses a database to verify the attributes and qualifications of the Holder based on the digital certificate presented by the Holder, and determines whether or not to provide the service to the Holder.

[0007] There are various types of services available, such as video distribution, storage use, and communication. Until now, service providers have concluded contracts with users and granted them usage rights based on usage conditions or usage amounts, such as usage time, usage amount, and usage frequency.

[0008] W3C DID (https: / / www.w3.org / TR / did-core / )W3C VC (https: / / www.w3.org / TR / VC-data-model / )

[0009] However, in the above-mentioned service contracts and service provision formats, in order to improve the convenience of the service, a specific user was not able to transfer at least a portion of the usage rights (usage time, usage amount, number of uses, etc.) granted to that user to another user.

[0010] The present disclosure has been made in consideration of the above circumstances, and aims to enable a specified user to transfer at least a portion of the usage rights (usage time, usage amount, number of uses, etc.) granted to that user to another user in order to improve the convenience of the service.

[0011] In order to solve the above problem, the present disclosure provides a verification device included in a service provision system in which a service providing device provides a service to a user terminal, the verification device having: a communication unit that receives a service provision request from a specified user terminal along with a transfer certificate of service usage rights for the service; and a verification unit that verifies, based on the transfer certificate, whether the transfer certificate has been issued by a first user who holds the service usage rights and whether the service usage rights for using at least a portion of the service have been transferred from the first user to a second user, and if the conditions are met, gives permission to the service providing device to provide the specified user terminal with a specified service that corresponds to the service content related to the transferred service usage rights.

[0012] As described above, according to the present disclosure, in order to improve the convenience of the service, a specified user can transfer at least a portion of the usage rights (usage time, usage amount, number of uses, etc.) granted to that user to another user.

[0013] FIG. 1 is a schematic diagram of a communication system according to this embodiment, which performs verification using SSI. FIG. 1 is an electrical hardware configuration diagram of a service provision system, etc. FIG. 2 is a functional configuration diagram of a service provision system according to an embodiment. FIG. 3 is a conceptual diagram of a transferable service management table. FIG. 4 is a conceptual diagram of a transaction history table. FIG. 5 is a conceptual diagram of a certificate schema table. FIG. 6 is a conceptual diagram of a certificate status table. FIG. 7 is a conceptual diagram of a service contract table. FIG. 8 is a conceptual diagram of a public key table. FIG. 9 is a sequence diagram showing a public key registration process. FIG. 10 is a sequence diagram showing a process when a service provision system mediates the transfer of service usage rights between parties. FIG. 11 is a sequence diagram showing a transfer registration and service provision process. FIG. 12 is a flowchart showing a registration process related to provision to a transferee. FIG. 13 is a flowchart showing a verification process related to provision to a transferee. FIG. 14 is a flowchart showing a verification process related to provision to a transferor. FIG. 15 is a sequence diagram showing a process when service usage rights are transferred directly between parties. FIG. 16 is another functional configuration diagram of a service provision system according to an embodiment. FIG. 17 is a schematic diagram showing a mechanism of verification using SSI.

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0015] [Outline of System of Embodiment] First, an outline of the configuration of a communication system of this embodiment will be described with reference to Fig. 1. Fig. 1 is a schematic diagram of a communication system according to this embodiment.

[0016] As shown in FIG. 1, a communication system 1 of this embodiment is constructed by at least a service providing system 2, a user terminal 10a, and a user terminal 10b.

[0017] The service providing system 2 is constructed by one or more computers, and provides services such as an EC (Electronic Commerce) site, a corporate job application site, a community site, etc. The service providing system 2 is managed and operated by a service provider S acting as a verifier.

[0018] The user terminal 10a is a computer and a communication terminal used by user A as the Issuer. The user terminal 10b is a computer and a communication terminal used by user B as the Holder. The user terminals 10a and 10b are collectively referred to as "user terminal 10."

[0019] The user terminal 10 may be a laptop PC, a desktop PC, a tablet terminal, a smartphone, a smart watch, etc. There are many user terminals 10, but only two are shown in FIG.

[0020] Furthermore, the wallet (storage area (Digital Identity Wallet)) of user terminal 10a stores a user ID such as a DID, which is a distributed identifier for user A created by user A himself. Similarly, the wallet of user terminal 10b stores a user ID such as a DID, which is a distributed identifier for user B created by user B himself.

[0021] The user terminal 10 does not necessarily have to be a terminal that is in the hands of each user, but may be, for example, a terminal function provided on a cloud platform, and operated by the user via remote access.

[0022] Furthermore, the user terminal 10a issues a transfer certificate, which is a digital certificate such as a VC, and provides it to the user terminal 10b. The transfer certificate includes information indicating that it is a transfer certificate, identification information that uniquely identifies the transfer certificate, the user ID of the issuing user, the user ID of the transfer destination user, and a digital signature using a private key corresponding to the issuing user's user ID.

[0023] Furthermore, at least the service providing system 2 and the user terminal 10a, and the service providing system 2 and the user terminal 10b can communicate with each other via a communication network 100 such as the Internet or a LAN (Local Area Network). The connection form of the communication network 100 may be either wireless or wired. Note that the service providing system 2, the user terminal 10a, and the user terminal 10b can access a DB (distributed repository, blockchain network, etc.) as shown in FIG. 18.

[0024] [Hardware Configuration] <Hardware Configuration of Search System> Next, the electrical hardware configuration of the service providing system will be described with reference to Fig. 2. Fig. 2 is a diagram showing the electrical hardware configuration of the service providing system.

[0025] The computer serving as the service providing system 2 in Figure 2 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected by a bus 1010.

[0026] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via the communication network 100. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0027] The memory device 1003 reads and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes the functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a communication network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0028] The user terminal 10 has the same hardware configuration as the service providing system 2, and therefore a description thereof will be omitted.

[0029] [Functional Configuration of Service Providing System] Next, the functional configuration of the service providing system 2a will be described with reference to Fig. 3. Fig. 3 is a functional configuration diagram of the service providing system in the embodiment. Note that the service providing system 2a is an example of the service providing system 2 shown in Fig. 1.

[0030] 3, the service providing system 2a includes a communication unit 21, a registration unit 23, a verification unit 25, and a service providing unit 27. Each of these units has a function realized by an instruction from the CPU 1004 in FIG. 2 based on a program.

[0031] Furthermore, the auxiliary storage device 1002 or the memory device 1003 in FIG. 2 has built therein a transferable service DB d0, a transaction history DB d1, a certificate schema DB d2, a certificate status DB d3, a service contract DB d4, and a public key DB d5.

[0032] 3, the verification unit 25 and the service providing unit 27 may be independent devices, and the service providing system 2a may have the verification device and the service providing device. In this case, each DB may be built in the verification device or the service providing device. Alternatively, at least one of the DBs may be built in a DB server or the like separate from the service providing system 2a.

[0033] <DB Description> (Transferable Service DB) Fig. 4 is a conceptual diagram of a transferable service table. The transferable service DB d0 is composed of the transferable service table shown in Fig. 4. In the transferable service table, a certificate ID, a transfer applicant ID, transferable service content, and a transfer status are associated and managed. The certificate ID is an example of identification information for identifying a certificate. The transfer applicant ID is an example of identification information for a transfer applicant for identifying a person who wishes to transfer the service usage rights. The available service content is information indicating the transferable service content that is the subject of transfer. The transfer status is information indicating whether the service has been transferred or not.

[0034] (Transaction History DB) FIG. 5 is a conceptual diagram of a transaction history table. The transaction history DB d1 is composed of the transaction history table shown in FIG. 5. In the transaction history table, a certificate ID, a transferor ID, a transferee ID, the transferred service content, and a signature using a private key corresponding to the transferor ID are associated and managed. The transferor ID is an example of identification information of the transferor for identifying the transferor, such as user A. The transferor ID is also an issuer ID. The issuer ID is an example of issuer identification information for identifying the issuer of a digital certificate. The transferee ID is an example of identification information of the transferee for identifying the transferee, such as user B. The transferred service content is information indicating the service content of the service to which the transferred usage rights apply. The signature using a private key corresponding to the transferor ID is an example of information for verifying that the person registering the information in the transaction history table is the user identified by the transferor ID.

[0035] (Certificate Schema DB) Fig. 6 is a conceptual diagram of a certificate schema table. The certificate schema DB d2 is composed of the certificate schema table shown in Fig. 6. In the certificate schema table, certificate types and schema information are associated and managed. The certificate type indicates the type of digital certificate and the type of transfer target. The schema information is information indicating the schema for each type of digital certificate.

[0036] (Certificate Status DB) Fig. 7 is a conceptual diagram of a certificate status table. The certificate status DB d3 is configured by the certificate status table shown in Fig. 7. In the certificate status table, certificate IDs and valid / invalid status information indicating whether the certificates are valid are managed in association with each other.

[0037] (Service Contract DB) Figure 8 is a conceptual diagram of a service contract table. The service contract DB d4 is composed of the service contract table shown in Figure 8. In the service contract table, subscriber IDs, service contract details, and service usage status are managed in association with each other. Furthermore, this information may be managed in association with information used for authentication, such as a password. The subscriber ID is an example of subscriber identification information for identifying a person, such as user A, who has entered into a contract with the service provider S to use the service. The service contract details indicate the contract details of the service available to the subscriber associated with the subscriber ID. The service contract details also include the service ID and service details. The service ID is an example of service identification information for identifying the service. The service usage status indicates the actual usage status of the service, such as the remaining available time for the service.

[0038] (Public Key DB) Fig. 9 is a conceptual diagram of a public key table. The public key DB d5 is configured by the public key table shown in Fig. 9. In the public key table, user IDs and public keys are managed in association with each other. The user ID is an example of user identification information for identifying the person who generated and registered a public key, such as user A or user B.

[0039] <Functional Configuration> Next, each functional configuration of the service providing system 2a will be described with reference to FIG.

[0040] The communication unit 21 transmits and receives data (information) to and from the user terminal 10 via the communication network 100 .

[0041] The registration unit 23 registers data (information) in each DB stored in the storage unit 20 and reads data (information) from each DB.

[0042] The verification unit 25 performs a variety of verification processes, which will be described in detail later.

[0043] The service providing unit 27 provides various services such as video distribution, storage use, and communication.

[0044] [Processing or Operation of the Embodiment] Next, the processing or operation of the embodiment will be described in detail with reference to FIGS.

[0045] <Public Key Registration Processing> First, the public key registration processing will be described. Fig. 10 is a sequence diagram showing the public key registration processing.

[0046] S11: The user terminal 10a generates a private key and a public key through an operation by user A. Note that the function for generating the user's private key and public key may be provided to the user or the user terminal as part of the function of, for example, a service providing system 2a outside the user terminal 10.

[0047] S12: The user terminal 10a transmits the user ID of user A and the public key generated in step S11 to the service providing system 2a. As a result, the communication unit 21 receives the user ID and the public key.

[0048] S13: In the service providing system 2a, the registration unit 23 registers the user ID and public key received in step S12 in the public key DB d5. For example, the user ID is registered in the VDR as a DID Document using the DID Method. In the case of the DID Method, the DID may be issued on the VDR side.

[0049] S14: User B operates the user terminal 10b to generate a private key and a public key.

[0050] S15: The user terminal 10b transmits the user ID of user B and the public key generated in step S14 to the service providing system 2a. As a result, the communication unit 21 receives the user ID and the public key.

[0051] S16: In the service providing system 2a, the registration unit 23 registers the user ID and public key received in step S15 in the public key DB d5.

[0052] The public key of each user may be registered in advance in, for example, a public blockchain-type Verifiable Data Registry (VDR) that does not belong to a specific service provider (that is, available across service providers or accessible by anyone). In this case, when the service providing system 2a needs the public key of each user, it may obtain the public key by querying the VDR using the user ID of the user as a search key (obtaining a DID Document containing the public key through the resolve process referred to in the W3C DID specification).

[0053] <Intermediation Process for Transfer of Service Use Right> Next, with reference to Fig. 11, an intermediation process will be described in which the service providing system 2a mediates the transfer of the service use right between the parties, user A and user B. Fig. 11 is a sequence diagram showing the intermediation process in which the service providing system mediates the transfer of the service use right between the parties.

[0054] S31: The user terminal 10a transmits information indicating the transferable service contents among the service contents related to the service usage rights owned by user A. This information includes the certificate ID, the transfer applicant ID which is user A's user ID, and the transferable service contents. As a result, the communication unit 21 receives the information indicating the transferable service contents.

[0055] S32: In the service providing system 2a, the registration unit 23 registers the information received in step S31 in the transferable service DB d0. At this point, the "transfer status" field in the transferable service DB d0 has "not transferred" registered.

[0056] S33: The communication unit 21 announces the details of the available services on a site or the like operated by the service provider S.

[0057] S34: In response to this, if user B wishes to use the published service content, user terminal 10b transmits a request for a service usage right transfer certificate to service providing system 2a along with user B's user ID. As a result, communication unit 21 receives this request and user B's user ID.

[0058] S35: The communication unit 21 identifies the user terminal 10a using the user ID of user A associated with the transfer applicant ID managed in the transferable service DB d0, and sends (or forwards) to the user terminal 10a a request for a transfer certificate of the service usage rights and the user ID of user B.

[0059] S36: The user terminal 10a, as an issuer, issues a transfer certificate (digital certificate) for the service usage rights using SSI technology.

[0060] S37: The user terminal 10a transmits the transfer certificate of the service usage right issued in step S36 to the service providing system 2a, whereupon the communication unit 21 receives the transfer certificate.

[0061] S38: In the service providing system 2a, the verification unit 25 verifies (confirms) that the transfer certificate received in step S37 contains the content requested by user B. Note that this step may be omitted.

[0062] S39: If the verification in step S38 shows that the content is as requested by user B, the communication unit 21 transmits a service usage right transfer certificate to the user terminal 10b as a response to step S34.

[0063] S40: The registration unit 23 also updates the corresponding "transfer status" field in the available service DB d0 from "not transferred" to "transferred."

[0064] This completes the intermediation process for the transfer of the transfer certificate.

[0065] <Transfer Registration and Service Provision Processing> Next, transfer registration and service provision processing will be described with reference to Fig. 12 to Fig. 15. Fig. 12 is a sequence diagram showing transfer registration and service provision processing.

[0066] S51: The user terminal 10a sends transaction history information of the transfer certificate to the service providing system 2a for registration regarding provision to the transfer destination. This transaction history information includes the certificate ID, the transfer source ID which is the user ID of user A, the transfer destination ID which is the user ID of user B, the service content of the transfer, and a digital (electronic) signature using the private key corresponding to the transfer source ID. As a result, the communication unit 21 receives the transaction history information of the transfer certificate.

[0067] S52: The service providing system 2a performs a registration process for the transaction history information of the transfer certificate received in step S51. The registration process of step S52 will now be described in detail with reference to FIG.

[0068] (Registration Process) FIG. 13 is a flowchart showing the registration process for providing to the transfer destination.

[0069] S101: The registration unit 23 associates each piece of transaction history information received in process S51 (certificate ID, transferor ID, transferee ID, transfer service content, and digital signature using a private key corresponding to the transferor ID) with the transaction history DB d1 and registers it. During this registration, the transfer registration date and time is registered in the transfer service content. The signature using the private key corresponding to the transferor ID is an example of information for verifying that the person who registered the information is the same user identified by the transferor ID. Using the transferor ID as a key, the public key associated with that ID is obtained from the public key DB d5, and it is confirmed that the signature verification is successful using the obtained public key.

[0070] S102: The registration unit 23 also registers the certificate ID received in step S51 and the validity or invalidity status information of the certificate (right of use) as "valid" in the certificate status DB d3.

[0071] S103: Furthermore, in conjunction with the transfer of part or all of the service usage rights, the registration unit 23 updates the service usage status that User A previously registered in the service contract DB d4 in order to receive the provision of the service. During this update, the update date and time are also registered as content of the service usage status. For example, if the available time is registered as 100 hours, 20 hours have already been used, and 80 hours remain, when 50 hours of usage rights are transferred to User B, the remaining 30 hours will be updated. Note that processing S103 does not necessarily have to be executed. User A is an example of a first user.

[0072] This completes the description of the registration process.

[0073] S53: Next, returning to Fig. 12, the user terminal 10b sends a service provision request to the service provision system 2a. As a result, the communication unit 21 receives the service provision request. This provision request includes the transfer certificate that user B obtained in process S39.

[0074] The transfer certificate can be resold by user B to a third party user (for example, user C). In this case, user B or user C is an example of a second user.

[0075] However, if the administrator or operator of the service providing system 2a has a policy of limiting the scope of service provision based on the transfer certificate to the original transfer destination user (user B) of the transfer certificate, the provision request in this process S53 includes the user ID of user B, who is the transfer destination and sender of the provision request, and a digital signature using the private key corresponding to that user ID. In this case, user B is an example of the second user.

[0076] S54: The service providing system 2a performs a verification process regarding provision to the transfer destination based on the request of step S53. The verification process regarding provision to the transfer destination in step S54 will now be described in detail with reference to FIG.

[0077] (Verification Process for Provision to Transfer Destination) FIG. 14 is a flowchart showing the verification process for provision to the transfer destination.

[0078] S121: The verification unit 25 verifies the syntax (schema) of the transfer certificate received in process S53 by referring to the certificate schema DB d2, thereby verifying whether the syntax of the transfer certificate is correct (whether the transfer certificate was issued using SSI technology, whether the data format is correct, etc.).

[0079] S122: The verification unit 25 verifies that the issuer of the transfer certificate is the contractor based on whether the issuer ID included in the transfer certificate is registered as a contractor ID in the service contract DB d4.

[0080] S123: The verification unit 25 verifies the legitimacy of the issuer of the transfer certificate by referencing the public key DB d5. Specifically, the verification unit 25 confirms that the digital signature can be successfully verified using the issuer ID included in the transfer certificate, the digital signature using the private key corresponding to this issuer ID, and the public key corresponding to the issuer ID managed in the public key DB d5.

[0081] S124: If the administrator or operator of the service providing system 2a has a policy of limiting the scope of service provision based on the transfer certificate to the original transfer destination user (user B) of the transfer certificate, the verification unit 25 verifies whether the user ID of the sender of the transfer certificate (the person requesting the service) matches the transfer destination ID included in the transfer certificate. In the case of W3C VC / VP, it verifies whether the subject ID of the VC (transfer certificate) within the VP matches the sender ID of the VP (holder ID). This process may be omitted.

[0082] S125: If, as a policy of the administrator or operator of the service providing system 2a, it is desired to limit the scope of service provision based on the transfer certificate to the original transfer destination user (user B) of the transfer certificate, the verification unit 25 then references the public key DB d5 and verifies the legitimacy of the sender of the transfer certificate (the person requesting the service). Specifically, the verification unit 25 confirms that the digital signature is successfully verified using the public key based on the sender ID for identifying user B (the sender) received in process 53, the digital signature using the private key corresponding to this sender ID, and the public key corresponding to the sender ID managed in public key DB d5. Note that this process may be omitted.

[0083] S126: The verification unit 25 refers to the certificate status DB d3 and verifies the validity of the transfer certificate based on the valid or invalid status information of the certificate corresponding to the certificate ID included in the transfer certificate received in process S53.

[0084] S127: Then, the verification unit 25 determines whether the verification results from the processes S121 to S126 are all valid (OK).

[0085] S128: If all the results in step S127 are valid (S127; YES), the verification unit 25 determines that it is possible to provide the service in response to the service provision request made in step S53.

[0086] S129: On the other hand, if all of the verification results in process S127 are invalid, i.e., if there is at least one invalid verification result (S128: NO), the verification unit 25 determines that it is not possible to provide the service in response to the service provision request made in process S53.

[0087] This completes the explanation of the verification process for providing to the transfer destination.

[0088] S55: Next, returning to FIG. 12, the communication unit 21 transmits a response to the process S53 to the user terminal 10b indicating whether the service can be provided or whether the service cannot be provided (impossible). If the service can be provided, the verification unit 25 grants permission to the service providing unit 27 to provide the service to user B, and the service providing unit 27 can provide the user terminal 10b with a service according to the service content related to the transferred service usage right based on the "transferred service content" registered in the transaction history DB d1. Furthermore, even if user A transfers part of the service content related to the service usage right to user B, user A can still receive the remaining service. The process when user A receives the remaining service is described below.

[0089] S56: The user terminal 10a sends a service provision request to the service providing system 2a. This provision request includes the user A's user ID and, if necessary, a password. The communication unit 21 then receives the service provision request. The password is an example of information required for user authentication to access the service, and may be any authentication information, such as biometric information in the case of biometric authentication, or a digital signature using the private key of the user or device in the case of authentication using public key cryptography.

[0090] S57: Based on the request of step S56, the service providing system 2a performs a verification process regarding provision to the transfer source, i.e., user A. Here, the verification process regarding provision to the transfer source in step S57 will be described in detail with reference to Fig. 15. Note that this process is a normal process for providing a service, regardless of whether or not there has been a transfer.

[0091] (Verification Process for Provision to Transfer Source) Fig. 15 is a flowchart showing the verification process for provision to the transfer source. Fig. 15 shows an example of verification (user authentication) process using a password.

[0092] S141: The verification unit 25 verifies whether User A is a legitimate subscriber of the service provision by referring to the service contract DB d4 based on the user ID and password received in process S56 and whether the user ID and password are registered. If User A is not a legitimate subscriber (S141; NO), the process shown in FIG. 15 ends.

[0093] S142: If the subscriber is a legitimate subscriber (S141; YES), the verification unit 25 refers to the registration date and time of the transfer managed in the transaction history DB d1 and the update date and time of the service contract DB, and verifies whether a transfer of part or all of the usage rights has occurred after the service usage status in the service contract DB d4 has been updated.

[0094] S143: If a transfer has occurred (S142; YES), the registration unit 23 updates the service usage status in the service contract DB d4 based on the service content of the transfer in the transaction history DB d1. Note that, when the process S103 shown in FIG. 13 is performed, the processes S142 and S143 are not performed.

[0095] S144: After process S143 (or after process S141 if processes S142 and S143 are not performed), the registration unit 23 verifies whether or not a service can be provided to user A by referring to the service usage status of user A based on the contractor ID of user A in service contract DB d4. Note that the contracted service available time for user A (e.g., 100 hours), the service usage time by user A himself (e.g., 40 hours) or the remaining service usage time (e.g., 60 hours) may be stored in service contract DB d4, and during the process of transferring the service usage right between users A and B, while querying the service contract DB d4, the process of providing the service may be stopped if an attempt is made to execute a transaction that exceeds the available time (e.g., 60 hours).

[0096] Here, the verification process using a password has been described, but instead of the verification process using a password, other known verification processes may be performed, such as a verification process using a digital certificate or a verification process using biometric authentication.

[0097] This completes the explanation of the verification process regarding provision to the transfer source.

[0098] 12, the communication unit 21 transmits a response to the process S56 to the user terminal 10a indicating whether the service can be provided or whether the service cannot be provided (impossible). If the service can be provided, the verification unit 25 permits the service providing unit 27 to provide the service to user A, and the service providing unit 27 can provide the user terminal 10a with a service according to the service content related to the current service usage right.

[0099] Regarding the provision of services according to the service content related to the service usage rights, the method of limiting the usage time, usage capacity, number of uses, etc. is arbitrary. For example, in the case of usage time, the service providing system 2a measures the service usage time of user B, and when it reaches the upper limit registered in the transaction history DB d1, it is assumed that the service provision using the transfer certificate is terminated by changing the valid / invalid status information of the certificate in the certificate status DB d3 to "invalid" and executing a forced logout process from the service providing unit 27. [Another Example of Transfer of Service Usage Rights Between Parties] Next, as an alternative example to the process mediated by the service providing system shown in Figure 11, a process in which the service usage rights are transferred directly between the parties without the service providing system 2a acting as an intermediary will be described using Figure 16. Figure 16 is a sequence diagram showing the process in which the service usage rights are transferred directly between the parties.

[0100] S131: The user terminal 10a transmits transferable service content information to the user terminal 10b, whereby the user terminal 10b receives the transferable service content information.

[0101] S132: User B refers to the transferable service content information, and if he wishes to transfer some or all of the service usage rights presented by User A in process S131, user terminal 10b sends a request for a service usage right transfer certificate to user terminal 10a. This request has the same content as the request for a service usage right transfer certificate shown in process S34 in Figure 11. As a result, user terminal 10a receives the request for a service usage right transfer certificate.

[0102] S133: The user terminal 10a issues a transfer certificate of the service usage right, similar to the process S36 of FIG.

[0103] S134: The user terminal 10a transmits a service usage right transfer certificate to the user terminal 10b as a response to step S132, whereby the user terminal 10b can obtain the service usage right transfer certificate.

[0104] [Another Example of Service Providing System] Next, as another example of the service providing system 2a shown in Figure 3, a case where a DB other than the service contract DB d4 is managed in the blockchain network 110 will be described using Figure 17. Figure 17 is another functional configuration diagram of the service providing system in the embodiment. Note that in Figure 17, the same components as those in Figure 3 are assigned the same reference numerals, and descriptions thereof will be omitted.

[0105] 17, the service providing system 2b is managed and operated by a service provider S. The service providing system 2b is constructed by a verification device 3 and a service providing device 4. The electrical hardware configurations of the verification device 3 and the service providing device 4 are similar to the configuration shown in FIG.

[0106] The verification device 3 has a storage unit 30, a communication unit 31, a registration unit 33, and a verification unit 35. These have the same functions as the storage unit 20, the communication unit 21, the registration unit 23, and the verification unit 25 in Fig. 3. The storage unit 30 also stores a service contract DB d4, which the service provider S must keep confidential.

[0107] The service providing device 4 also has a communication unit 41 and a service providing unit 47, which have the same functions as the communication unit 21 and the service providing unit 24 in Fig. 3. The verification unit 35 of the verification device 3 notifies the service providing unit 47 of permission to provide the service via the communication units 31 and 41.

[0108] Furthermore, the blockchain network 110 includes multiple nodes 5, 6, 7, 8, and 9. The nodes 5, 6, 7, 8, and 9 have communication units 51, 61, 71, 81, and 91, respectively. The communication units 51, 61, 71, 81, and 91 have functions similar to those of the communication unit 21 shown in FIG. 3. The nodes 5, 6, 7, 8, and 9 also have registration units 53, 63, 73, 83, and 93, respectively. The registration units 53, 63, 73, 83, and 93 have functions similar to those of the registration unit 23 shown in FIG. 3. The nodes 5, 6, 7, 8, and 9 each have a transferable service DB d0, a transaction history DB d1, a certificate schema DB d2, a certificate status DB d3, and a public key DB d5 in their respective storage units. The verification unit 35 of the verification device 3 requests the registration units 53, 63, 73, 83, and 93 to register or update the DBs d0, d1, d2, d3, and d5 via the communication unit 31 and the communication units 51, 61, 71, 81, and 91.

[0109] Furthermore, in the registration process of FIG. 13, for steps S101 and S102, the user terminal 10 may directly request the registration units 63 and 83 to register or update the DBs d1 and d3.

[0110] In this case, a request for registration or update is sent for each of DBs d0, d1, d2, d3, and d5. The registration and update functions for each of DBs d0, d1, d2, d3, and d5 may be separated into separate functions corresponding to the APIs (Application Programming Interfaces) or protocols of each of DBs d0, d1, d2, d3, and d5, or may be provided by the verification device 3 or the user terminal 10.

[0111] As described above, the service contract DB d4 containing the user's privacy information can be placed in a closed environment, and other DBs can be placed in a public (accessible by anyone) environment on the blockchain network 110.

[0112] At least two of the DBs d0, d1, d2, d3, and d5 may be managed by the same node.

[0113] [Major Effects of the Embodiment] As described above, according to the present embodiment, in order to improve the convenience of the service, a predetermined user can transfer at least a part of the usage authority (usage time, amount of usage, number of times of use, etc.) granted to that user to another user.

[0114] 14, user B who has acquired the service usage right does not need to go through steps S56 to S58 in FIG. 12, which were performed by user A to receive the service. This has the effect of saving user B the trouble of having to register in advance in the service contract DB d4 (entering into a service contract with service provider S) in order to receive the service.

[0115] [Supplementary Note] The present invention is not limited to the above-described embodiment, and may have the following configurations or processes (operations).

[0116] (1) The service providing system 2 can be realized by a computer and a program, but this program can also be recorded on a (non-transitory) recording medium or provided via the communication network 100.

[0117] (2) In communication between the service providing system 2 and the user terminal 10, other devices (such as a server or a router) may relay data. For example, when this specification describes that the service providing system 2 transmits data (information) to the user terminal 10, this transmission process also includes cases where other devices relay the data. Also, when this specification describes that the service providing system 2 receives data (information) from the user terminal 10, this reception process also includes cases where other devices relay the data.

[0118] (3) The CPU 1004 as the processor in FIG. 2 may be a single processor or may be multiple processors.

[0119] 1 Communication system 2, 2a, 2b Service provision system 3 Verification device 4 Service provision device 20 Memory unit 21 Communication unit 23 Registration unit 25 Verification unit (or verification device) 27 Service provision unit (or service provision device) 31 Communication unit 33 Registration unit 35 Verification unit 41 Communication unit 47 Service provision unit 10a User terminal (an example of a first user terminal) 10b User terminal (an example of a predetermined user terminal, an example of a second user terminal) d0 Transferable service DB (an example of a transferable service management unit) d1 Transaction history DB (an example of a transaction history management unit) d2 Certificate schema (an example of a certificate schema management unit) d3 Certificate status (an example of a certificate status management unit) d4 Service contract DB (an example of a service contract management unit) d5 Public key DB (an example of a public key management unit)

Claims

1. A verification device included in a service provision system in which a service provision device provides a service to a user terminal, the verification device comprising: a communication unit that receives a service provision request from a specified user terminal together with a transfer certificate of service usage rights for said service; and a verification unit that verifies, based on said transfer certificate, whether said transfer certificate has been issued by a first user who holds said service usage rights and whether the conditions that service usage rights for using at least a part of said service have been transferred from said first user to a second user are met, and if said conditions are met, gives permission to said service provision device to provide said specified user terminal with a specified service corresponding to the service content related to the transferred service usage rights.

2. The verification device described in claim 1, wherein the transfer certificate includes identification information of the issuer of the transfer certificate and a signature made with a private key corresponding to the issuer's identification information, and the verification unit verifies whether the issuer's identification information is registered as the first user's identification information and whether the signature made with the private key corresponding to the issuer's identification information satisfies the conditions, including whether verification with a public key corresponding to the issuer's identification information is successful.

3. The verification device described in claim 1, wherein the communication unit receives from the specified user terminal the identification information of the sender of the transfer certificate and a signature created with a private key corresponding to the identification information of the sender, and the verification unit verifies whether the identification information of the sender matches the identification information of the second user included in the transfer certificate and whether the signature created with the private key corresponding to the identification information of the sender satisfies the conditions, including whether it is successfully verified with the public key corresponding to the identification information of the sender.

4. The verification device described in claim 1, wherein the communication unit receives a request for the transfer certificate from a second user terminal that is a terminal of the second user and transmits the request for the transfer certificate to a first user terminal that is a terminal of the first user, and the communication unit receives the transfer certificate issued by the first user from the first user terminal and transmits the transfer certificate to the second user terminal.

5. A service providing system comprising: a verification device according to any one of claims 1 to 4; and the service providing device.

6. A verification method executed by a verification device included in a service provision system in which a service provision device provides a service to a user terminal, the verification method comprising: receiving a service provision request from a specified user terminal together with a transfer certificate of service usage rights for said service; verifying, based on said transfer certificate, whether said transfer certificate has been issued by a first user who holds said service usage rights and whether the conditions that service usage rights for using at least a part of said service have been transferred from said first user to a second user are met; and, if said conditions are met, granting permission to said service provision device to provide said specified user terminal with a specified service corresponding to the service content related to the transferred service usage rights.

7. A program for causing a computer to execute the method according to claim 6.

Images